# ¿Qué es vibe coding y qué NO es?

> Si llevas un tiempo rondando el ecosistema de desarrollo web, seguro que has visto “vibe code”, “vibe coding” y una mezcla de hype + memes + “esto lo hago

- URL canónica: https://www.martagonzalez.dev/blog/que-es-vibe-coding-y-que-no-es/
- Fecha de publicación: 2025-12-15T12:35:57
- Última actualización: 2026-05-25T21:03:35

---

[![Imagen del artículo](https://martagonzalez.dev/wp/wp-content/uploads/2025/12/que-es-vibe-coding-y-que-no-es-1024x683.avif)](https://martagonzalez.dev/wp/wp-content/uploads/2025/12/que-es-vibe-coding-y-que-no-es.avif) 
Si llevas un tiempo rondando el ecosistema de desarrollo web , seguro que has visto “ vibe code ”, “ vibe coding ” y una mezcla de hype + memes + “esto lo hago en 10 minutos con IA”. Y sí: hay una parte real (productiva) y otra parte peligrosa (cuando confundes velocidad con ingeniería).
 
En este artículo vamos a aterrizarlo con criterio: qué es vibe coding , qué NO es , cómo usarlo sin convertir tu proyecto en un castillo de naipes, y por qué la comparación clave no es “IA vs no IA”, sino tiempo de decisión vs carga cognitiva . Todo con ejemplos técnicos de diseño e interacción para que te lleves ideas prácticas.
 
## Vibe coding: definición útil (sin humo)
 
Vibe coding se usa para describir un flujo de trabajo donde delegas gran parte de la escritura de código a un modelo (LLM) y tú te enfocas en intención, feedback, pruebas, iteración y producto . La frase se popularizó en 2025, asociada a Andrej Karpathy, con una idea muy concreta: dejar que la IA genere y tú “guías por sensaciones” , a veces sin mirar demasiado el código . [X (formerly Twitter)+1](https://x.com/karpathy/status/1886192184808149383?lang=en)
 
### ¿Por qué engancha tanto?
 
Porque reduce fricción de arranque en tareas donde la mente sufre: boilerplate, wiring, pegar piezas, integrar librerías, estructurar carpetas, scaffolding de tests… y eso, en desarrollo web, puede ser medio proyecto.
 
En otras palabras: vibe coding te puede dar velocidad de prototipado , sobre todo cuando estás explorando UI, interacciones, microcopy, y flujos de estado.
 
### Definición operativa (la que te sirve en el día a día)
 
Para que no sea un concepto nebuloso, quédate con esto:
 

- Tú defines el objetivo y las restricciones (UX, accesibilidad, performance, seguridad, stack). 
- La IA produce código (componentes, estilos, hooks, tests, scripts). 
- Tú evalúas por comportamiento , no por “qué bonito está el código”, y vas iterando.
 
Y ojo: si en tu equipo se usa “vibe coding” como sinónimo de “usar Copilot”, ya empezamos mal: usar IA como asistente no es necesariamente vibe coding.
 
## Qué NO es vibe coding (y por qué importa en proyectos reales)
 
Aquí viene la parte que te ahorra bugs, deuda técnica y sustos en producción.
 
### 1) No es “ingeniería asistida por IA” (aunque suene parecido)
 
Ingeniería implica: diseño, trade-offs, pruebas, seguridad, mantenimiento, observabilidad, y decisiones con contexto. Vibe coding, en su versión extrema, puede convertirse en: “funciona en mi máquina, ship it” .
 
Si estás construyendo un sistema con vida larga, múltiples contributors y requisitos serios, vibe coding sin guardrails es una receta de deuda .
 
### 2) No es “no-code”, ni magia sin conocimientos
 
Aunque parezca democratizador (lo es a ratos), el desarrollo web serio sigue necesitando:
 

- modelos mentales (estado, render, efectos, asincronía), 
- base de seguridad (XSS, CSRF, auth), 
- arquitectura, 
- y criterio.
 
Cuando no tienes eso, el output puede “funcionar” pero ser frágil, inseguro o imposible de escalar. (Y sí, hay análisis públicos remarcando estos riesgos, especialmente en seguridad y gobernanza). [TechRadar+1](https://www.techradar.com/pro/vibe-coding-convenience-risk-and-the-future-of-software-development)
 
### 3) No es copiar-pegar prompts y ya
 
Si tu proceso es:
 
> “Pido feature → copio output → rezo → repito”
 
…eso no es productividad; es ruleta .
 
#### Señales de que te has pasado de “vibes”
 

- No sabes explicar por qué algo funciona. 
- Te da miedo tocar cualquier archivo. 
- Cada cambio rompe tres cosas. 
- Dependencias añadidas “porque sí”. 
- Tests inexistentes o que no cubren el flujo crítico.
 
## Tiempo de decisión vs carga cognitiva: la comparación que de verdad importa
 
Vamos con el núcleo del tema, porque aquí está la diferencia entre “usar IA con cabeza” y “vivir en un loop de parches”.
 
### ¿Qué es el tiempo de decisión?
 
El tiempo de decisión es cuánto tardas en elegir qué hacer (no en teclear). Ejemplos:
 

- “¿Esta interacción va con animación o con transición?” 
- “¿Uso React Query o fetch + caché manual?” 
- “¿Este componente merece ser genérico o específico?” 
- “¿Cómo gestiono foco y teclado en este modal?”
 
En desarrollo web avanzado, el tiempo se va muchísimo en decidir bien .
 
### ¿Qué es la carga cognitiva?
 
La carga cognitiva es cuánta energía mental consumes para entender, mantener y evolucionar el sistema. No solo “entender código”, también:
 

- contexto (qué rompe qué), 
- estados posibles, 
- edge cases, 
- accesibilidad, 
- performance, 
- efectos secundarios.
 
### La paradoja del vibe coding (la trampa típica)
 

- Baja el tiempo de decisión superficial : la IA te propone 3 opciones en 10 segundos. 
- Pero puede subir la carga cognitiva : te genera 600 líneas con abstracciones raras, y ahora validar eso te drena. (Hay artículos recientes que lo describen justo así: el cansancio no está en generar, sino en verificar). [Medium+1](https://medium.com/ducky-ai/vibe-coding-is-too-much-cognitive-load-5ad78769d61d)
 
Regla práctica:
 
> Si la IA te ahorra 30 minutos de teclear, pero te añade 2 horas de “entender qué narices ha hecho”, no ganaste velocidad; cambiaste deuda por dopamina.
 
#### Mini-métrica para usar en tu sprint (muy simple)
 

- Decisión : ¿cuántas decisiones críticas resolviste hoy? 
- Carga : ¿cuántas piezas nuevas añadiste que mañana te costarán entender?
 
Tu objetivo no es “más commits”. Es más decisiones buenas con menos carga innecesaria .
 
## Vibe coding en desarrollo web, bien hecho: un workflow avanzado con guardrails
 
Aquí va la parte aplicable. Si quieres que vibe coding sea una ventaja y no una bomba, ponle estructura.
 
### Paso 1: define restricciones como si fueras tu propio tech lead
 
Antes de pedir código, escribe un “contrato” mínimo:
 
Objetivo: añadir un modal de confirmación reutilizable Stack: React + TypeScript + Tailwind Requisitos UX: foco atrapado, Escape cierra, click fuera opcional A11y: role="dialog", aria-modal="true", aria-labelledby Performance: sin dependencias nuevas, SSR-safe Tests: uno unitario + uno e2e del flujo crítico Esto baja la ambigüedad y reduce la carga cognitiva futura .
 
### Paso 2: genera UI con intención de interacción (no solo “layout bonito”)
 
#### Ejemplo 1 — Modal accesible con gestión de foco (React + TS)
 
import React, { useEffect, useRef } from "react"; type ConfirmModalProps = { open: boolean; title: string; description?: string; onConfirm: () => void; onClose: () => void; }; export function ConfirmModal({ open, title, description, onConfirm, onClose, }: ConfirmModalProps) { const dialogRef = useRef (null); const lastActiveRef = useRef (null); useEffect(() => { if (!open) return; lastActiveRef.current = document.activeElement as HTMLElement | null; // Enfocar el primer botón al abrir const firstFocusable = dialogRef.current?.querySelector ( 'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])' ); firstFocusable?.focus(); const onKeyDown = (e: KeyboardEvent) => { if (e.key === "Escape") onClose(); // Trap de Tab (simple y efectivo) if (e.key === "Tab" && dialogRef.current) { const focusables = Array.from( dialogRef.current.querySelectorAll ( 'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])' ) ).filter((el) => !el.hasAttribute("disabled")); const first = focusables[0]; const last = focusables[focusables.length - 1]; if (!first || !last) return; if (e.shiftKey && document.activeElement === first) { e.preventDefault(); last.focus(); } else if (!e.shiftKey && document.activeElement === last) { e.preventDefault(); first.focus(); } } }; window.addEventListener("keydown", onKeyDown); return () => { window.removeEventListener("keydown", onKeyDown); lastActiveRef.current?.focus(); // devuelve foco al elemento anterior }; }, [open, onClose]); if (!open) return null; return ( { if (e.target === e.currentTarget) onClose(); }} > {title} {description ? ( {description} ) : null} Cancelar Confirmar ); } Por qué este snippet es “vibe coding con criterio”: porque la interacción (foco, teclado, Escape) está definida desde el principio. Aquí no estás “pintando un modal”, estás construyendo comportamiento .
 
### Paso 3: reduce carga cognitiva con tokens y estados explícitos
 
En UI avanzada, muchas veces lo que mata no es el CSS, sino la inconsistencia. Usa tokens:
 
:root { --radius-lg: 16px; --shadow-elev: 0 10px 30px rgba(0,0,0,.12); --ease-out: cubic-bezier(.16, 1, .3, 1); --dur-fast: 160ms; } .card { border-radius: var(--radius-lg); box-shadow: var(--shadow-elev); transition: transform var(--dur-fast) var(--ease-out); } .card:hover { transform: translateY(-2px); } Esto es simple, pero baja muchísimo la carga cognitiva : decisiones visuales coherentes y centralizadas.
 
#### Ejemplo 2 — Microinteracción respetando prefers-reduced-motion 
 
export function shouldReduceMotion() { return window.matchMedia?.("(prefers-reduced-motion: reduce)").matches ?? false; } export function animateIn(el: HTMLElement) { if (shouldReduceMotion()) { el.style.opacity = "1"; el.style.transform = "none"; return; } el.animate( [ { opacity: 0, transform: "translateY(6px)" }, { opacity: 1, transform: "translateY(0px)" }, ], { duration: 180, easing: "cubic-bezier(.16, 1, .3, 1)" } ); } Esto es desarrollo web serio: interacción + accesibilidad sin drama.
 
### Paso 4: tests como freno automático (tu mejor antídoto anti-vibes)
 
Si vas a acelerar, necesitas frenos.
 
#### Ejemplo 3 — Test e2e mínimo (Playwright)
 
import { test, expect } from "@playwright/test"; test("confirm modal: cierra con Escape y devuelve el foco", async ({ page }) => { await page.goto("/demo/modal"); const openBtn = page.getByRole("button", { name: "Abrir modal" }); await openBtn.focus(); await openBtn.click(); await expect(page.getByRole("dialog")).toBeVisible(); await page.keyboard.press("Escape"); await expect(page.getByRole("dialog")).toHaveCount(0); // foco vuelve al botón de abrir await expect(openBtn).toBeFocused(); }); Con esto, aunque la IA te proponga cambios “creativos”, tu sistema te protege .
 
## Cuándo sí usar vibe coding (y cuándo no)
 
### Casos donde brilla (especialmente en desarrollo web)
 

- Prototipos de UI/UX y microinteracciones. 
- Generación de variantes de componentes (con tokens y constraints). 
- Exploración de arquitectura (comparar enfoques rápidamente). 
- Documentación técnica, ejemplos, scaffolding de tests.
 
### Casos donde conviene bajarle el volumen
 

- Auth, pagos, permisos, seguridad. 
- Migraciones delicadas. 
- Sistemas con alta criticidad y compliance. 
- Refactors grandes sin cobertura de tests.
 
Y un recordatorio importante: hay análisis públicos avisando que la velocidad puede degradar calidad y seguridad si no hay revisión y gobernanza. [TechRadar+1](https://www.techradar.com/pro/vibe-coding-convenience-risk-and-the-future-of-software-development)
 
## Preguntas frecuentes (FAQs)
 
### 1) ¿“Vibe code” y “vibe coding” son lo mismo?
 
En la práctica, sí: vibe code suele usarse como expresión corta, y vibe coding como el nombre del enfoque. Lo importante es el matiz: delegar generación y priorizar iteración guiada , a veces con poca lectura del código. [Wikipedia+1](https://en.wikipedia.org/wiki/Vibe_coding)
 
### 2) ¿Se puede usar vibe coding en producción?
 
Sí, pero no “a pelo” . Si lo usas en producción, necesitas guardrails : linters, tests, revisión, análisis de dependencias, y criterios de diseño. En equipos, lo sano es tratarlo como acelerador, no como sustituto del proceso.
 
### 3) ¿Esto sirve para perfiles junior o les perjudica?
 
Puede servir para aprender si se usa con intención (preguntar “por qué”, revisar, escribir tests). Pero si se usa para evitar pensar, puede crear dependencia y lagunas. La clave es que la IA te reduzca fricción, no que te quite el control.
 
## Que la IA te dé velocidad, pero que tú pongas el criterio
 
Vibe coding no es “bien” o “mal”. Es un modo . Y como cualquier modo rápido, tiene un coste: si reduces demasiado el tiempo de decisión, pero subes la carga cognitiva, la factura llega después (y suele llegar con intereses).
 
Mi recomendación realista es esta: usa vibe coding para explorar y acelerar , pero convierte esa velocidad en software mantenible con tres hábitos:
 

- Restricciones claras , 
- tests como freno , 
- y diseño de interacción consciente (accesibilidad incluida).
 
Así no estás eligiendo entre “vibes” o “ingeniería”: estás usando las vibes para llegar antes… y la ingeniería para quedarte.