Vibe Coding: ¿revolución o espejismo?

Hay un término que está dividiendo a la industria tech ahora mismo: vibe coding. La idea es simple: describes lo que quieres en lenguaje natural, un agente de IA genera el código, y tú solo validas que funcione. Sin escribir una línea. Sin entender cada decisión del compilador.

Para unos es el futuro. Para otros es el principio del fin de la ingeniería de software seria. Yo llevo meses haciéndolo, y mi conclusión es que ambos tienen razón — pero por motivos que ninguno de los dos está viendo.

El término lo acuñó Andrej Karpathy a principios de 2025. Ex-director de IA en Tesla, cofundador de OpenAI. No es precisamente alguien que no entienda código. Su definición era provocadora a propósito: “Te rindes al vibe, abrazas los exponenciales, y te olvidas de que el código existe.”

La reacción fue inmediata. Los ingenieros senior se echaron las manos a la cabeza. Los builders que llevaban semanas prototipando con IA asintieron en silencio. Twitter se convirtió en un campo de batalla entre puristas y pragmáticos.

Pero el debate se está dando en términos equivocados. La pregunta no es si vibe coding “funciona” o “no funciona”. La pregunta es para qué funciona, para qué no, y qué cambia en cómo organizamos equipos de producto cuando una parte del equipo lo adopta.

Piensa en la Thermomix. Cuando apareció, los chefs profesionales la despreciaron. “Eso no es cocinar.” Y tenían razón — técnicamente. Pero millones de familias empezaron a preparar platos que antes les parecían imposibles. La Thermomix no sustituyó a los chefs. Cambió lo que podía hacer la gente que no era chef.

Vibe coding es la Thermomix del software. Y eso tiene implicaciones enormes para cualquiera que gestione un equipo de producto.

Cuando funciona (y funciona más de lo que los puristas admiten)

Hay un patrón que se repite en todos los equipos que conozco que han adoptado herramientas de vibe coding: el primer éxito llega rápidamente y es espectacular.

Un prototipo funcional en horas en lugar de días. Una herramienta interna que llevaba meses en el backlog y de repente existe. Un script de migración de datos que hubiera requerido una semana de trabajo manual. Una prueba de concepto para convencer a un stakeholder que antes necesitaba dos sprints de inversión.

No es magia. Lo que está pasando es que una enorme cantidad de código que escribimos es estructural, repetitivo, predecible. Configurar un proyecto, conectar una API, montar un CRUD, escribir tests unitarios para casos estándar. Un buen agente de IA hace esto en minutos porque ha visto millones de implementaciones similares. Y lo hace razonablemente bien.

Donde el vibe coding brilla de verdad es en ese espacio donde sabes exactamente lo que quieres pero el coste de implementarlo siempre ha sido demasiado alto. Herramientas internas que nadie prioriza. Automatizaciones que “ya haré cuando tenga tiempo”. Prototipos para validar ideas antes de invertir un sprint entero. Para un PM o un tech lead, esto es transformador: la distancia entre idea y validación se acorta radicalmente.

Cuando explota (y explota más de lo que los evangelistas admiten)

Ahora la otra cara. Y es una cara que muchos están descubriendo de la peor manera posible.

El problema fundamental del vibe coding es lo que yo llamo la deuda técnica invisible. Cuando un ingeniero escribe código, toma cientos de micro-decisiones: cómo manejar un error, qué pasa si la conexión se cae, cómo escala esto cuando hay diez mil usuarios concurrentes, qué asunciones estoy haciendo sobre los datos de entrada. Cada decisión es una pieza de conocimiento que vive en la cabeza del equipo.

Cuando el código lo genera una IA y tú solo validas que “funciona”, esas decisiones se toman igualmente. Pero nadie sabe cuáles fueron. El código pasa los tests. La feature funciona en staging. Todo verde. Hasta que en producción un edge case que nadie consideró tumba el servicio un viernes a las once de la noche. Y entonces necesitas debuguear código que no escribiste, basado en decisiones que no tomaste, con asunciones que no conoces.

He visto equipos que prototiparon algo en dos días con vibe coding y luego necesitaron tres semanas para hacerlo production-ready. El ratio real no es 10x. Es 2x con asterisco. Y el asterisco es importante.

El segundo problema es más sutil: la falsa sensación de competencia. Cuando puedes generar código que funciona sin entender por qué funciona, empiezas a tomar decisiones de arquitectura sin tener las bases para tomarlas. Es como conducir un Fórmula 1 con piloto automático — funciona hasta la primera curva que el sistema no ha visto antes.

Lo que cambia para el PM y el Tech Lead

Si gestionas un equipo de producto, vibe coding ya te afecta aunque no lo hayas adoptado oficialmente. Alguno de tus ingenieros lo está usando. La pregunta es si lo sabes y si has pensado en qué significa.

Lo primero que cambia son las estimaciones. Cuando un junior puede entregar en días lo que antes costaba semanas, tus modelos de capacidad dejan de funcionar. ¿Asignas más trabajo? ¿Reduces el equipo? ¿Asumes que la velocidad es sostenible? Ninguna de las tres respuestas es correcta sin contexto.

Lo segundo que cambia es el code review. Ya no estás revisando el trabajo de un ingeniero que tomó cada decisión conscientemente. Estás revisando código generado donde el autor no puede explicarte por qué eligió ese patrón y no otro. Esto requiere un tipo de revisión diferente: menos “¿por qué hiciste esto así?” y más “¿qué pasa si esto falla?”. Más adversarial, menos colaborativo.

Lo tercero, y esto es lo más importante para PMs: cambia lo que puedes pedir. Antes, un prototipo era caro. Ahora es barato. Eso significa que puedes validar más hipótesis antes de comprometer al equipo. Puedes mostrar un prototipo funcional al stakeholder en lugar de un wireframe. Puedes probar tres enfoques en paralelo en lugar de apostar por uno. Si eres PM y no estás aprovechando esto, estás dejando dinero en la mesa.

El buscador que construimos hablando

Voy a ponerte un ejemplo real, porque creo que es la forma más honesta de hablar de esto.

En Mercadona Tech teníamos un problema con nuestro buscador de la tienda online. Usábamos Algolia, un SaaS que nos costaba entre 9.000 y 15.000 dólares al mes. Funcionaba, pero teníamos un 4% de búsquedas sin resultados, un ranking que no podíamos controlar como queríamos, y una dependencia total de un proveedor externo para una pieza crítica del negocio: 4,4 millones de búsquedas a la semana.

Decidimos construir nuestro propio buscador. Búsqueda híbrida con keyword y semántica, un modelo de Learning to Rank entrenado con datos reales de clics de nuestros usuarios, autocompletado, el stack completo. Y lo desarrollamos con Claude Code.

¿Qué funcionó? La velocidad de exploración fue brutal. Analizar 479 megabytes de datos de catálogo y analítica, iterar sobre 12 experimentos diferentes, hacer una competición de 5 modelos de ranking con validación cruzada — todo eso se hizo conversando con agentes de IA. Tareas que hubieran requerido semanas de trabajo de un equipo de data science las completamos en días.

¿Qué no funcionó sin intervención humana? Las decisiones que definen si el sistema aguanta en producción o se cae el primer día. No usar Elasticsearch porque el coste y la latencia no encajaban. No usar Cloud Run porque los cold starts son fatales para un buscador. Diseñar un índice maestro con bitsets en lugar de 762 índices separados. Establecer las reglas de gobernanza del modelo: validación walk-forward en lugar de aleatoria, corrección de sesgo de posición obligatoria, un guardrail que bloquea automáticamente cualquier modelo que degrade más de un 2% las métricas.

Esas 29 decisiones técnicas no las tomó la IA. Las tomó un equipo con criterio. Y son exactamente las decisiones que separan un prototipo que impresiona en una demo de un sistema que sirve 4,4 millones de búsquedas a la semana sin caerse.

El resultado: un buscador que mejora el ranking un 85% respecto a Algolia, elimina completamente las búsquedas sin resultados, y cuesta menos de 900 dólares al mes. Construido en gran parte con vibe coding. Pero las decisiones que importan, tomadas por personas.

La herramienta, no la respuesta

Vibe coding no es revolución ni espejismo. Es una herramienta extraordinariamente potente que está en manos de todo el mundo por primera vez.

La Thermomix no mató a los restaurantes. Pero cambió para siempre lo que una persona sin formación culinaria podía preparar en su cocina. Vibe coding no va a eliminar a los ingenieros senior. Pero va a cambiar radicalmente lo que puede construir alguien con una idea clara y ganas de iterar.

La pregunta que deberías hacerte no es “¿vibe coding sí o no?”. Es: ¿en qué partes de mi producto estoy gastando tiempo de ingeniería en trabajo que una IA puede hacer igual de bien? ¿Y en qué partes estoy en riesgo de confiar en código que nadie entiende realmente?

Si puedes responder a esas dos preguntas con honestidad, el vibe coding va a ser una ventaja enorme. Si no puedes, va a ser una trampa.