Cómo hacer bien vibe coding

Le pides a la IA que te monte una pantalla de login. Te la escupe en treinta segundos. La pegas, arranca, hace lo que tiene que hacer. Commit. A otra cosa.

Tres días después llega el mensaje: “Oye, esto no funciona y tu código es como raro…”.

Bienvenido al lado oscuro del vibe coding. No el de “soy un mago que construye apps sin saber programar”, sino el de “construí algo que no entiendo y ahora me toca pagar la factura”. La parte buena es que no tienes que elegir entre velocidad y cordura. Hay un punto intermedio, y de eso va este post.

Esto es lo que vas a encontrar:

• Qué es el vibe coding sin el humo de LinkedIn.
• Por qué el problema nunca fue el vibe coding, sino no saber cuándo frenar.
• Los tres niveles en los que puedes trabajar con IA, según lo que te juegues.
• Una checklist para detectar cuándo tu vibe coding se está pasando de listo.
• Los errores que cometemos todos (yo el primero) y cómo evitarlos.

Qué es vibe coding y por qué todo el mundo habla de ello ¶

El vibe coding es programar describiéndole a una IA lo que quieres en lenguaje natural y aceptando el código que te devuelve, muchas veces sin leerlo a fondo. Cuando algo se rompe, copias el error, lo pegas en el prompt y le pides que lo arregle. Repites hasta que parece que funciona.

El término lo acuñó Andrej Karpathy en febrero de 2025. Hablaba de “dejarte llevar por las vibes, abrazar los exponenciales y olvidarte de que el código existe”. La frase pegó porque puso nombre a algo que ya hacía medio mundo. En cuestión de meses, “vibe coding” pasó a describir cualquier flujo de trabajo asistido por IA, y ahí empezó la confusión.

Porque no es lo mismo un fin de semana montando un prototipo desechable que un equipo metiendo IA en el sistema de pagos.

Los números dan vértigo: según datos recogidos en el informe The New SDLC With Vibe Coding de Google (mayo de 2026), a principios de 2026 el 85% de los developers profesionales usaban agentes de IA con regularidad, el 51% a diario, y se estimaba que el 41% de todo el código nuevo lo generaba la IA. No es una moda de nicho. Es el agua en la que nadamos.

Nota: Este post está basado en gran medida en ese informe “The New SDLC With Vibe Coding” de Addy Osmani, Shubham Saboo y Sokratis Kartakis.

No voy a gastar mil quinientas palabras repitiendo lo que ya cuenta medio internet. Lo interesante viene ahora.

El problema no es el vibe coding: es no saber cuándo parar ¶

Aquí va la tesis, y quiero que la leas dos veces.

El vibe coding no es basura. Es una herramienta excelente para explorar, prototipar y validar ideas a toda velocidad. El problema aparece cuando lo usas para todo, sin distinguir entre un experimento que vas a tirar mañana y un servicio del que dependen usuarios reales.

El propio Karpathy reconoció a principios de 2026 que su definición original se quedaba corta, e introdujo el término agentic engineering (ingeniería agéntica) para la parte más disciplinada del asunto. Como cuenta Addy Osmani en su blog, no es un binario: es un espectro. Y el diferenciador no es si usas IA o no. Es cuánta estructura, verificación y criterio humano rodean al output de la IA.

Piénsalo con un coche. El modelo de IA es el motor. Pero un motor solo no fabrica un coche: necesita correas, engranajes, sensores de seguridad y una línea de montaje. Esa maquinaria que rodea al modelo se llama harness, y es donde está el 90% del valor. De hecho, en pruebas públicas como Terminal Bench 2.0, un equipo subió un agente de fuera del Top 30 al Top 5 sin cambiar el modelo, solo afinando el harness. Otro estudio en LangChain mejoró la puntuación en 13,7 puntos tocando únicamente el prompt, las herramientas y el middleware. El motor era el mismo.

🔑 El diferenciador entre hacer el tonto con la IA y hacer ingeniería con la IA no es la herramienta que usas. Es cuánta estructura le pones alrededor. El mismo agente sirve para las dos cosas.

Si quieres ver este concepto del harness aplicado a una herramienta concreta, lo desarrollé en el tutorial de qué es Claude Code y cómo usarlo bien: la parte que “piensa” es el modelo, pero el día a día lo domina cómo el agente coordina contexto, herramientas y ciclo de trabajo. Y da un poco igual qué agente uses: si dudas entre dos de los más extendidos en terminal, tengo una comparativa honesta entre Claude Code y OpenCode que te ahorra semanas de prueba y error. Si lo que quieres es entender qué hay dentro del harness y cómo funciona su bucle de tool calls, tengo un análisis a fondo sobre qué es el AI harness y cómo se construye.

El delta de garantías: lo que separa “parece que funciona” de “me atrevo a mantenerlo” ¶

Voy a darte un concepto que uso para pensar en todo esto. Lo llamo el delta de garantías.

El delta es todo lo que añades entre “parece que funciona” y “me atrevo a mantenerlo”.

Cuando haces vibe coding puro, el delta es cero. Le pides algo a la IA, lo arrancas, hace lo que tiene que hacer y te lo crees. Cuando haces ingeniería de verdad, el delta crece: contexto bien escrito, tests, evals, revisión humana, revisión de seguridad, frontera clara entre prototipo y producción. Cada cosa que añades es una garantía más de que el código no te va a explotar en la cara dentro de seis meses.

El informe de Google lo sostiene con una frase que merece la pena retener: escribir los tests y las evals antes del código convierte el desarrollo asistido por IA en algo más cercano a la ingeniería agéntica, porque esos tests y esas evals funcionan como un contrato con la IA. Le dicen qué significa “correcto” y le dan una forma de verificarlo sola.

Buena parte de ese andamiaje ya está estandarizándose: MCP para conectar herramientas, Agent Skills para empaquetar conocimiento, AGENTS.md para el contexto del proyecto. Si te suenan a chino, hice un repaso de los protocolos y estándares que usan los agentes de IA para que no te pierdas en la jerga.

La buena noticia: el delta no es todo o nada. Puedes subirlo y bajarlo según lo que te juegues. Y para eso me gusta pensar en tres niveles.

👉 Empecemos por el más ligero, el que casi todo el mundo usa sin darse cuenta.

Nivel 1: Cómo pasar de la idea al prototipo ¶

Este es el nivel donde el vibe coding brilla y donde no tienes que sentir ni una pizca de culpa.

Aquí el delta es bajo a propósito. Estás explorando, no construyendo nada que vaya a sobrevivir. La velocidad lo es todo, y la verificación es opcional porque el coste de equivocarte es ridículo.

Casos perfectos para este nivel:

• Prototipos que vas a enseñar y tirar.
• Scripts personales que solo usas tú.
• Pruebas de UI para ver cómo queda algo.
• Demos para una reunión.
• Experimentos para aprender una librería nueva.
• Validación rápida de una idea antes de comprometerte.

Si eres principiante, este es tu campo de juego natural. Aprende aquí, rómpelo todo aquí, gana confianza aquí. Un prototipo de fin de semana puede ser vibe coding puro y no pasa nada. Es más, es lo sensato: invertir en tests y arquitectura para algo que vas a borrar el lunes sería tirar el tiempo.

La única regla de este nivel es saber que estás en este nivel. El desastre empieza cuando un experimento se disfraza de producto.

Nivel 2: Cómo pasar del prototipo a una feature fiable ¶

Aquí subes el delta. Sigues yendo rápido, pero ya no aceptas lo primero que te llega.

Este nivel intermedio es lo que en el informe de Google llaman structured AI-assisted coding: ni vibe coding a ciegas ni la disciplina completa de producción, sino el punto medio del espectro. Es el terreno donde trabajan la mayoría de developers que meten IA en proyectos reales: features dentro de un código que ya existe, donde un fallo tiene consecuencias pero no catastróficas. La IA implementa, tú decides. El criterio humano entra en los puntos clave. Si quieres exprimir el agente sin pasarte de la raya, tengo una recopilación de 60 trucos para dominar Claude Code que encaja justo en este nivel.

Lo que cambia respecto al nivel 1:

1. Escribes el prompt con contexto, no con una frase suelta.
2. Defines criterios de aceptación antes de pedir nada.
3. Avanzas en pasos pequeños, no de un golpe.
4. Revisas las rutas críticas del código que genera.
5. Haces pruebas manuales de lo importante.
6. Commiteas a menudo, para poder volver atrás.
7. No aceptas cambios masivos que no entiendes.

El punto 1 tiene más miga de la que parece. Un estudio de la ETH de Zúrich puso cifras a algo que muchos sospechábamos: los ficheros de contexto generados por IA con /init no mejoran el rendimiento de los agentes e incluso lo empeoran un 3%, mientras que los escritos por un humano aportan un 4%, pero solo si son breves y concretos. La diferencia entre un buen contexto y uno malo no es trivial: en las pruebas de Vercel, un índice comprimido de documentación llevó la tasa de acierto del 53% al 100%. Si quieres hacerlo bien, te explico cómo escribir un AGENTS.md mínimo que de verdad funcione.

💡 Si solo te llevas una cosa de este nivel: avanza en pasos pequeños y commitea a menudo. Un cambio que no entiendes es deuda técnica que aún no sabes que tienes.

Nivel 3: Cómo pasar de la feature a producción ¶

A estas alturas ya casi no deberíamos llamarlo vibe coding. Pero lo dejo así porque sé que lo vas a buscar con ese nombre, y porque la transición es gradual.

Aquí el delta está al máximo, y con razón. Hablamos de sistemas de los que dependen usuarios reales, donde un bug se traduce en dinero, datos comprometidos o una llamada a las tres de la mañana. La verificación deja de ser opcional para convertirse en sistemática.

El arsenal completo:

• Specs claras de qué hay que construir.
• Tests automáticos que cubren el comportamiento.
• Evals que verifican lo que los tests no pueden (¿el agente tomó el camino correcto?).
• CI que ejecuta todo eso en cada cambio.
• Revisión humana de cada línea que va a producción.
• Revisión de seguridad pensando en entradas maliciosas.
• Mecanismo de rollback para deshacer un despliegue malo.
• Permisos limitados para cada agente y cada herramienta.
• Observabilidad para saber qué hizo el agente y por qué.

Sobre los tests y las evals: no son burocracia, son comunicación. Una suite de tests bien escrita le dice a la IA qué significa “correcto” con más precisión que cualquier prompt en lenguaje natural. Profundicé en esto en el post sobre si necesitas revisar todo el código que genera la IA, donde el TDD con agentes tiene una ventaja brutal: el agente no se cansa de ver un test fallar una y otra vez hasta que pasa. Si quieres herramientas concretas para armar esa suite, hay una guía sobre cómo hacer testing con IA que cubre mutation testing, property-based testing y Playwright Agents.

Y sobre la seguridad, no te fíes de que el código “parece correcto”. Cada parámetro que llega del exterior es territorio enemigo hasta que demuestres lo contrario. Lo cuenta bien Johannes Dahse, VP de Code Security en Sonar, en la entrevista sobre la seguridad de tu código en tiempos de IA: tienes que saber qué hace tu código, incluido el que genera la IA y las dependencias de tus dependencias.

Hay un coste que muchos olvidan en este nivel: el de los tokens. El vibe coding puro suele caer en un bucle caro de “pídele que arregle su propio fallo”, con tasas de acierto a la primera bajísimas. La ingeniería agéntica invierte más por adelantado (specs, tests, buen contexto) y rebaja drásticamente el coste de cada feature. Si quieres profundizar en esa economía, escribí sobre el tokenmaxxing y cómo gastar tokens con criterio: quemar más no es producir más. Y para dejar de adivinar y empezar a medir dónde se te van los tokens, échale un ojo a CodeBurn.

Para que veas las tres formas de un vistazo:

Checklist para saber si tu vibe coding se está pasando de listo ¶

Esta es la parte que te puedes guardar en marcadores. Antes de dar por bueno algo que la IA ha generado, hazte estas diez preguntas:

1. ¿Tengo una spec mínima de lo que quería construir?
2. ¿Sé qué archivos ha tocado el agente?
3. ¿He revisado las dependencias nuevas que ha añadido?
4. ¿Hay tests que cubran lo importante?
5. ¿He pensado en los casos límite?
6. ¿Puedo explicar lo que hace este código a otra persona?
7. ¿Sé cómo revertir el cambio si sale mal?
8. ¿He probado errores reales, no solo el camino feliz?
9. ¿Hay datos sensibles de por medio?
10. ¿Esto va a llegar a usuarios reales?

La regla es sencilla. Si estás en el nivel 1, puedes responder “no” a casi todas y dormir tranquilo. Si respondes “sí” a la última pregunta y “no” a la mayoría de las anteriores, tienes un problema. Eso es vibe coding pasándose de listo.

⚠️ Cuidado con el momento en que un prototipo “que solo iba a ser una prueba” empieza a recibir tráfico real. Es el accidente más común. Los equipos que no marcan la frontera entre prototipo y producción acaban desplegando experimentos sin querer.

Errores comunes al hacer vibe coding ¶

Todos hemos caído en estos. Yo el primero, así que esto es más confesión que sermón.

Pedir features demasiado grandes.
Le sueltas “hazme el sistema de autenticación completo con OAuth, recuperación de contraseña y dos factores” y esperas magia. El agente genera una montaña de código plausible que nadie ha pensado de verdad. Descompón. Pide trozos pequeños que puedas revisar.

Aceptar el primer output sin más.
El primero que llega rara vez es el bueno. Mira lo que ha hecho, cuestiónalo, pídele alternativas. Desconfía especialmente de lo que parezca “demasiado listo”: el código que presume suele esconder supuestos que no se sostienen.

Usar la IA para verificar su propio trabajo sin tests externos.
Pedirle al agente que compruebe si su código está bien es como pedirle al zorro que vigile el gallinero. Necesitas tests que vivan fuera de su criterio.

No leer los imports ni las dependencias.
Aquí hay un riesgo concreto con nombre propio: el slopsquatting. La IA alucina el nombre de un paquete que no existe, y alguien con malas intenciones registra ese nombre en el repositorio con código malicioso dentro. Tú lo instalas sin mirar. Comprueba que cada import apunta a un paquete real.

Arreglar errores a base de copiar y pegar.
Copiar el error al prompt, aceptar el parche, repetir. Funciona hasta que deja de hacerlo y ya no entiendes nada de lo que tienes delante. Diagnostica la causa, aunque sea una vez.

Convertir una demo en producto.
El error de los errores. Una demo es código que demuestra una idea. Un producto es código que aguanta el mundo real. No son lo mismo, aunque arranquen igual.

No controlar el coste de tokens.
El bucle de “pídele que arregle su propio fallo” no solo te genera código frágil: te quema tokens a una velocidad que asusta. Cada retry tiene un precio, y quemar más no es producir más.

No tener rollback.
Si no sabes cómo deshacer un despliegue malo, no estás listo para desplegar. Punto.

El informe de Google es contundente en este apartado, y lo suscribo: revisa cada línea que vaya a producción, desconfía del código que parezca demasiado listo, comprueba que los imports apuntan a paquetes reales y valida que el manejo de errores cubre fallos realistas. El código que tu equipo no entiende se convierte en un coste de depuración que tu equipo no se puede permitir.

🛡️ Antes de lanzar nada a usuarios reales: tests que cubran los casos críticos, revisión humana de cada línea, y un plan claro de rollback. Si falta alguno de los tres, todavía estás en modo prototipo.

El 80% que la IA resuelve y el 20% que te toca a ti ¶

Hay un patrón que conviene tener grabado: el llamado problema del 80%. Los agentes generan con facilidad alrededor del 80% del código de una feature. El 20% restante (los casos límite, el manejo de errores, los puntos de integración, los requisitos sutiles de corrección) exige un conocimiento del contexto que los modelos de hoy no tienen.

Y aquí está lo peligroso. La naturaleza de los errores de la IA ha cambiado. Ya no son fallos de sintaxis que saltan a la vista. Ahora son fallos conceptuales: supuestos equivocados sobre la lógica de negocio, casos límite que se pasa por alto, decisiones de arquitectura que generan deuda a largo plazo. Son más difíciles de detectar precisamente porque el código “parece correcto” y hasta puede pasar los tests básicos.

Esto encaja con lo que ya veníamos viendo en los datos. Según la Stack Overflow Developer Survey de 2025, el 66% de los developers cita como su mayor frustración lidiar con “soluciones de IA que casi aciertan, pero no del todo”, y la confianza en el output de estas herramientas ha caído: solo el 29% de los profesionales se fía, once puntos menos que en 2024.

Los developers que mejor navegan esto adoptan una postura concreta: usan la IA para lo que se le da bien (implementar rápido tareas bien definidas) y reservan su atención para lo que se le atraganta (requisitos ambiguos, decisiones de arquitectura, verificación de la corrección). No intentan ser más rápidos aceptándolo todo. Son más rápidos enfocando su criterio donde más pesa. Si te preguntas qué habilidades concretas pesan más en ese nuevo reparto, Boris Cherny, creador de Claude Code, lo desglosa en qué habilidades necesita un programador para trabajar con IA.

Que es, al final, de lo que va este post entero.

La velocidad no está reñida con el criterio ¶

Hay un mito que conviene desmontar: que ir rápido y hacerlo bien son cosas opuestas. No lo son. Lo que cuenta el informe de Google es que la IA amplifica la cultura de ingeniería en la que aterriza. Los equipos con buenas prácticas de testing, estándares de arquitectura claros y revisiones de código sanas sacan muchísimo más partido de la IA que los que van sin red.

La IA es un multiplicador. Multiplica tus fortalezas y, con la misma alegría, tus debilidades.

Por eso el dato de productividad real es más matizado de lo que venden los titulares. Las encuestas del sector hablan de mejoras del 25 al 39%, pero un estudio de METR encontró que developers con experiencia tardaban un 19% más en ciertas tareas con asistentes de IA, sobre todo por el tiempo de verificar, depurar y corregir el output. La IA no elimina el trabajo de implementación: lo transforma de escribir a revisar, guiar y verificar.

Esa es la habilidad nueva. No escribir más código, sino dirigir mejor a quien lo escribe.

TL;DR ¶

• 🎚️ El vibe coding no es bueno ni malo: es un nivel del espectro. El truco está en saber en cuál estás y subir el “delta de garantías” según lo que te juegues.
• 🚀 Nivel 1 (explorar): prototipos, scripts, demos. Velocidad total, verificación opcional. Sin culpa.
• 🔧 Nivel 2 (con estructura): contexto, criterios de aceptación, pasos pequeños, commits frecuentes. Para features en proyectos reales.
• 🛡️ Nivel 3 (producción): specs, tests, evals, CI, revisión humana, seguridad, rollback y permisos limitados. No negociable si hay usuarios reales.
• ⚡ El 80% lo genera la IA; el 20% difícil (casos límite, seguridad, arquitectura) es tu trabajo, y es donde está tu valor.

Preguntas frecuentes sobre vibe coding ¶

¿Qué es exactamente el vibe coding?

Es programar describiéndole a una IA lo que quieres en lenguaje natural y aceptando el código que genera, a menudo sin revisarlo en profundidad. El término lo acuñó Andrej Karpathy en febrero de 2025 y describe un flujo donde, cuando algo falla, copias el error al prompt y pides que lo arregle.

¿Es malo hacer vibe coding?

No. Es una herramienta excelente para explorar, prototipar y validar ideas rápido. El problema aparece cuando lo usas para sistemas de producción sin añadir verificación, tests ni revisión humana. El riesgo depende de lo que te juegues.

¿Cuándo debo dejar de hacer vibe coding puro?

En cuanto el código vaya a llegar a usuarios reales, maneje datos sensibles o tenga que mantenerse a largo plazo. En ese momento necesitas specs, tests, evals, revisión humana y un plan de rollback.

¿Qué diferencia hay entre vibe coding e ingeniería agéntica?

No usan herramientas distintas; el mismo agente sirve para ambas. La diferencia está en cuánta estructura, verificación y criterio humano rodean al output de la IA. El vibe coding usa andamiaje mínimo; la ingeniería agéntica usa specs, tests y guardarraíles desde el primer documento.

¿Por qué el código generado por IA falla aunque parezca correcto?

Porque los errores de la IA han pasado de ser fallos de sintaxis visibles a fallos conceptuales: supuestos equivocados sobre la lógica de negocio, casos límite olvidados o decisiones de arquitectura problemáticas. Son difíciles de detectar porque el código parece bien y hasta puede pasar tests básicos.

¿Necesito escribir tests si la IA genera el código?

Sí, y conviene escribirlos antes. Una suite de tests bien hecha le comunica a la IA qué significa “correcto” con más precisión que cualquier prompt y le da una forma automática de verificarse. Es lo que convierte el vibe coding en ingeniería de verdad.

¿Qué es el problema del 80% en el vibe coding?

Es el patrón por el que los agentes generan con facilidad el 80% del código de una feature, pero el 20% restante (casos límite, manejo de errores, integraciones, corrección sutil) exige un conocimiento del contexto que los modelos actuales no tienen. Ese 20% es tu trabajo.

¿Qué es el slopsquatting y por qué debería preocuparme?

Es cuando la IA alucina el nombre de un paquete que no existe y un atacante registra ese nombre con código malicioso dentro. Si instalas dependencias sin revisarlas, puedes acabar ejecutando malware. Comprueba siempre que cada import apunta a un paquete real.

¿El vibe coding me hace más productivo de verdad?

Depende. Las encuestas hablan de mejoras del 25 al 39%, pero un estudio de METR halló que developers experimentados tardaban un 19% más en ciertas tareas por el tiempo de verificar y corregir. La IA transforma el trabajo de escribir a revisar y guiar, más que eliminarlo.

¿Es buena idea empezar a programar directamente con vibe coding si soy principiante?

Para aprender, explorar y montar prototipos, sí: es un campo de juego ideal y de bajo riesgo. Pero no te saltes los fundamentos. Sin saber leer y entender el código que genera la IA, no podrás detectar cuándo se equivoca, y se equivoca a menudo.

Fuentes ¶

• Google, The New SDLC With Vibe Coding (Addy Osmani, Shubham Saboo y Sokratis Kartakis, mayo de 2026)
• Andrej Karpathy, el tuit original sobre vibe coding (febrero de 2025)
• Addy Osmani, Agentic Engineering
• METR, Uplift Update: Measuring the Impact of AI Coding Tools (febrero de 2026)
• Stack Overflow, Developer Survey 2025
• Gloaguen et al., Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents? (ETH Zúrich, febrero de 2026)

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter