El primer proyecto que construí sin abrir apenas el editor fue un asistente de nutrición en Telegram. Le describí a la IA lo que quería, probé el resultado en el móvil, pedí el siguiente cambio, y al cabo de dos tardes tenía un bot funcionando que hoy no sabría reconstruir de memoria. Me sirvió para lo que lo quería. También me dejó una pregunta que este post intenta contestar con criterio y no con entusiasmo: hasta dónde llega esto.
Vibe coding: definición y origen
El vibe coding es programar conversando con una IA. Describes el problema en lenguaje natural, el modelo genera el código, compruebas el resultado y pides el siguiente cambio, sin leer línea a línea lo que sube. El término lo acuñó Andrej Karpathy en febrero de 2025 para nombrar exactamente ese estado de trabajo: rendirse al flujo, aceptar los cambios que llegan y olvidar que el código existe. Un mes después, Simon Willison lo documentó con el matiz que importa: no toda la programación con IA es vibe coding, y la frontera no la marca la herramienta, sino cuánto de lo que despliegas has leído realmente.
El vibe coding es programar conversando con una IA y aceptar su código sin revisarlo línea a línea. Funciona para prototipos, herramientas internas y aprender construyendo; su límite lo marca el propio mercado: 2.039 de 31.557 ofertas tech activas en España nombran la revisión de código, el doble que las que nombran Copilot (análisis de mercado de Shakers, n=31.557, septiembre de 2026). La regla práctica: el vibe se queda donde romperse no duela.
¿Cómo funciona el vibe coding?
Es un flujo de trabajo, no una herramienta. La interfaz deja de ser el editor y pasa a ser la conversación: explicas qué quieres conseguir, la IA escribe el código, y tú evalúas el resultado en vez de la implementación. Si la app hace lo que pediste, sigues; si no, describes qué falla y vuelve a empezar. El ciclo completo puede durar minutos.
Tres rasgos lo distinguen de programar como se ha programado siempre. El primero, el lenguaje natural como medio principal: quien practica vibe coding especifica y opina, no teclea la solución. El segundo, la iteración por resultado visible: la prueba es que la cosa funcione delante de ti, no que el test pase. Y el tercero, el que da nombre al asunto: la aceptación de código que no has leído entero, que es una decisión legítima en algunos contextos y una negligencia en otros.
Conviene decirlo ya: eso último no es una característica menor del flujo, es su condición. Karpathy lo describió con sorna y con precisión a la vez, dar plenamente a las vibraciones y olvidarse del código, y esa mitad del chiste es la que separa una técnica útil de un problema latente. Un flujo donde nadie entiende lo que se despliega no escala hacia ningún sitio bueno. La pregunta operativa no es si hacer vibe coding, es dónde.
¿En qué se diferencia de programar con IA?
En casi todo, aunque vivan en la misma conversación de mercado. El desarrollo asistido por IA es el uso mayoritario: el modelo autocompleta, propone una función o refactoriza un módulo, y quien programa revisa el diff antes de subirlo. El conocimiento del código se queda en la persona y la máquina acelera la parte mecánica. Es lo que hace la mayoría: según la encuesta de Stack Overflow de 2025, el 84% de los developers usa o planea usar herramientas de IA en su proceso de desarrollo, subiendo del 76% del año anterior (Stack Overflow Developer Survey 2025).
El vibe coding mueve el punto de control. No evalúas el código, evalúas el producto. La distinción es simple de enunciar y dura de sostener en producción:
| Dimensión | Desarrollo asistido por IA | Vibe coding |
|---|---|---|
| Dónde trabaja el modelo | Propone, quien programa decide | Construye, quien conversa evalúa |
| Qué revisas | El diff antes de subirlo | El resultado funcionando |
| Qué sabes del código | Todo lo que subiste | Lo que el modelo quiera contarte |
| Dónde encaja | Producto, sistemas, entornos vivos | Prototipos, bordes, herramientas internas |
| Riesgo dominante | Errores puntuales que la revisión caza | Desplegar lo que nadie comprende |
Ninguna de las dos columnas es la buena. Son perfiles de riesgo distintos para problemas distintos, y el error habitual es aplicar la columna derecha a los terrenos de la izquierda porque la velocidad engancha.
¿Cuándo funciona de verdad?
Allí donde el coste de romperse es bajo y el valor de aprender rápido es alto. Los prototipos son su hábitat natural: quieres saber si una idea merece una semana de trabajo, y el vibe te da la respuesta en una tarde. Las herramientas internas, ese script de reporting o el panel que nadie quiere construir a mano, encajan igual de bien. Y el aprendizaje: montar un bot propio de cero te enseña más de arquitectura, APIs y despliegue que cualquier tutorial, porque los errores son tuyos y duelen en tu proyecto.
Lo he comprobado dos veces. La primera, con el asistente de nutrición del arranque: un proyecto de fin de semana que resolvió una necesidad mía real sin costarme una semana. La segunda, organizando hackathones internos de vibe coding en la oficina: equipos mixtos que nunca habían tocado juntas frontend, backend y despliegue entregando prototipos funcionando en una tarde. En ambos casos el objetivo no era el código, era comprobar una idea con gente real usándola. Eso es exactamente lo que este flujo compra.
La productividad medida, además, existe. McKinsey (2024) midió hasta un 55% más de productividad y un 27% menos de coste cuando los equipos integran IA en el desarrollo. Con una precisión honesta: esa medición corresponde a equipos que revisan lo que la IA produce, no al olvido del código. El dato premia la aceleración con criterio, que es la combinación, y no la sustitución de uno por la otra.
¿Dónde está el límite?
Donde empieza lo que no controlas. Los mismos developers que usan IA a diario son los primeros en señalarlo: el 66% cita como mayor frustración las soluciones de IA que son casi correctas, pero no del todo, y el 45% reconoce que depurar código generado por IA le cuesta más tiempo que escribirlo; más developers desconfían de la precisión de estas herramientas (46%) que los que confían en ella (33%), según la misma encuesta de Stack Overflow de 2025. El "casi" es la trampa: el código casi correcto pasa el primer filtro, falla en el segundo y nadie sabe por qué porque nadie lo escribió.
El suelo es más duro que la fricción. Cuando aceptas código sin leer, aceptas también sus dependencias, y una IA que inventa una librería inexistente convierte tu prototipo en una puerta trasera, que es lo que ya tiene nombre propio de slopsquatting. En producción, con datos personales, dinero o clientes delante, la lectura deja de ser opcional.
El mercado español, de hecho, ya lo ha escrito. Según el análisis de mercado de Shakers, 2.039 de 31.557 ofertas tech activas en España nombran la revisión de código, frente a 1.008 que nombran Copilot (n=31.557, septiembre 2026). Dos menciones del criterio para juzgar lo que la máquina escribe por cada mención de la herramienta que lo escribe. Y hay una señal más pequeña y más fina: una oferta publicada en Barcelona para un puesto bautizado como Vibe Engineer lo formula mejor que la mayoría de políticas internas, primero el prompt, pero la revisión nunca es opcional y cada línea que se despliega pasa por ojos humanos. Es un caso suelto, no una tendencia. Pero es el mercado diciendo la última palabra del término.
¿Cómo se aplica en un equipo de producto?
Con una frontera explícita y un flujo que la respeta. Esto es lo que hacemos, y lo que recomendaría a cualquiera que empiece:
El flujo en cinco pasos
- Paso 1: elige un terreno que no duela. Prototipo, herramienta interna, proyecto personal. Nunca producción, nunca datos que no sean tuyos.
- Paso 2: especifica como si fuera un ticket. El prompt es una especificación: contexto, objetivo, restricciones. La misma disciplina que al escribir para humanos, que es justo lo que analiza la pieza sobre spec-driven development.
- Paso 3: itera por resultado visible. Prueba la funcionalidad delante de ti en cada vuelta. Si necesitas la tercera iteración para entender la primera, para.
- Paso 4: declara lo que eres. Un prototipo hecho por vibe coding se presenta como tal. Nadie lo mantiene creyendo que hay alguien detrás que lo entiende.
- Paso 5: cuando cruza a producción, alguien lo lee entero. El pase de escala cambia el contrato: revisión de código completa, tests, y una persona capaz de defender cada línea. El día que ese cuello de botella se respeta, el día anterior fue bien gastado.
El paso cinco no es burocracia defensiva. Es donde el prototipo barato se convierte en ventaja real: llegas a la revisión con la parte exploratoria ya resuelta, y el tiempo senior se gasta en decidir, no en teclear. Si la revisión de código es hoy el cuello de botella de los equipos que usan IA, el vibe coding bien usado es la forma de llegar a ese cuello con menos ruido y más decisiones tomadas.
¿Qué queda del trabajo del developer?
Más que antes, y distinto. La parte mecánica de escribir código se automatizó; la parte de decidir qué construir y responder de lo construido se encareció. El trabajo se desplaza de los roles a las skills y los agentes, y quien combina criterio de producto con manejo real de IA aplicada queda en el punto donde el mercado está pagando. Ese perfil con nombre propio, el que construye con IA en el centro del flujo, es lo que ya llamamos AI builder.
Para mi generación de engineers esto no es una amenaza lejana, es la descripción del trabajo de todos los lunes. Si construyes y quieres construir con IA de verdad, el camino pasa por equipos que ya lo hacen: desde aquí se trabaja con talento de desarrollo e IA aplicada, y si lo tuyo es sumarte a ese lado de la mesa, puedes registrarte como talento en Shakers y dedicarte a lo interesante.
Preguntas frecuentes sobre el vibe coding
- ¿Qué es el vibe coding?
Es un flujo de programación en el que describes el problema a una IA en lenguaje natural, aceptas el código que genera sin leerlo línea a línea y evalúas el resultado funcionando. El término lo acuñó Andrej Karpathy en febrero de 2025 y Simon Willison lo documentó en marzo de ese año.
- ¿Es lo mismo que programar con GitHub Copilot?
No. Con Copilot o Cursor en modo asistido, quien programa revisa cada cambio antes de subirlo y mantiene el conocimiento del código. En el vibe coding el punto de control se mueve al resultado: se evalúa que la aplicación funcione, no lo que hay dentro. Son dos perfiles de riesgo distintos.
- ¿Hay que saber programar para hacer vibe coding?
Para prototipos, no es imprescindible: la barrera de entrada es saber describir lo que quieres. Para que el resultado valga algo más que la demo, sí: detectar el código casi correcto, depurar lo que falla y decidir cuándo algo merece revisión humana exige criterio técnico.
- ¿Es seguro usar vibe coding en producción?
No como flujo puro. Aceptar código sin leer implica aceptar también sus dependencias, con riesgos como el slopsquatting, y desplegar software que nadie en el equipo comprende. En producción, la revisión completa y los tests son condición de entrada, no un lujo.
- ¿Qué piden las empresas españolas sobre esto?
Criterio por delante de la herramienta. Según el análisis de mercado de Shakers, 2.039 de 31.557 ofertas tech activas en España nombran la revisión de código, frente a 1.008 que nombran Copilot (n=31.557, septiembre 2026): el doble de menciones para saber juzgar el código que para la herramienta que lo genera.
- ¿Con qué herramientas se puede hacer vibe coding?
Con cualquier asistente conversacional capaz de generar y ejecutar código: agentes de terminal como Claude Code, IDEs con IA como Cursor o constructores de aplicaciones como Bolt o Lovable. La elección del stack por capas y caso de uso está detallada en nuestra guía de herramientas de coding con IA.
