Lo que entendí en un año de vibe coding — y de lo que me da un poco de vergüenza
Hace un año pensaba que programar ya no hacía falta. Luego pasé una semana depurando código que el modelo generó en quince minutos. Balance personal.
En junio del año pasado monté mi primer producto "serio" en modo vibe. Era una herramienta interna para un cliente — un bot que sacaba correos de un buzón, los resumía y dejaba el resumen en una hoja. Lo monté un sábado. Dieciséis horas, sin contar comida y un paseo con el perro. El domingo miré, decidí que funcionaba, y me fui a dormir contento.
El lunes el cliente llamó para decir que el bot "se comporta algo raro". Sobre todo — empezó a meter en los resúmenes hechos que no estaban en los correos. El bot alucinaba, como un buen estudiante de primero de filosofía.
Me senté a depurar. En los cinco días siguientes entendí catorce cosas que el modelo no me había dicho mientras escribía el código. La principal: yo en realidad no sabía qué estaba construyendo. Sabía que quería que funcionara. No es lo mismo, resulta.
Sobre vibe coding escriben, más o menos, dos tipos de gente. Primero — los entusiastas: "¡ahora en un fin de semana entrego lo que antes me llevaba un mes!". Segundo — los decepcionados: "es todo ficción, la IA no sirve, mientras paguemos programadores de verdad todo bien". Ambos, creo, se pierden el punto.
El punto es que el vibe coding no elimina la programación. Elimina la parte mecánica de la programación. Teclear bucles. Parsear JSON de boilerplate. Escribir tu décima paginación en la vida. Si pensabas que el trabajo del dev es teclear — ganas mucho. Si pensabas que es tomar decisiones — el modelo no es ayudante, es interlocutor. Y, honestamente, no muy listo. Sabe hacer; no sabe por qué.
Aquel bot del verano es un ejemplo clásico. Yo formulaba tareas como "haz una función que coja correos de la API de Gmail y devuelva un array". El modelo lo hacía. Funcionaba. Luego "resume cada correo". El modelo lo hacía. También funcionaba.
El problema era que yo no había especificado ningún criterio de corrección para resumir. Yo asumía que "resumir" = "extraer puntos clave sin distorsionar". El modelo asumía que "resumir" = "reformular más corto". Coinciden. No del todo.
El viernes entendí que lo que había que reescribir no era el código sino el prompt dentro del modelo resumidor. Lo reformulé en un lenguaje que no admite doble interpretación: "Extrae hechos del correo. Hecho = afirmación con sujeto, verbo y objeto. No añadas nada que no esté en el correo. En caso de duda, escribe 'no mencionado'.". Las alucinaciones desaparecieron. El código quedó igual. El prompt lo resolvió.
Y eso es lo que entendí en un año. El vibe coding funciona cuando sabes formular. No cuando sabes programar. No cuando sabes escribir prompt. Sino cuando sabes formular la tarea de forma que no pueda responderse mal.
(Aunque "no pueda" es una hipérbole. Los modelos son inventivos.)
Ese mismo año monté unas doce cosas en modo vibe. De ellas:
Cuatro — prototipos para clientes que fueron a producción sin reescribir. Landings, pequeños paneles admin, herramientas internas. Siguen funcionando. Vibe coding para tareas así es la herramienta ideal. No volvería a escribirlas a mano. Es uno de esos casos en que "desarrollo tradicional" se vuelve tortura doméstica.
Tres — integraciones. Coges entrada de una API, haces algo, envías a otra. En 2026 eso suele ser un prompt, no un sprint. En integraciones el modelo va bien, porque el contexto de las APIs públicas es en lo que lo entrenaron.
Dos — refactors. Le paso al modelo código ajeno, describo qué quiero, propone, acepto. Es mi uso favorito, porque el modelo aquí funciona como compañero junior de paciencia infinita y ego cero.
Dos — fracasos completos. Intentos de hacer cosas que yo mismo no entendía del todo. Uno fue un backend complejo con colas asíncronas y locks distribuidos. El modelo escribió código que compilaba, parecía correcto, y contenía una race condition sutil en los locks de Redis, que descubrí sólo en producción, cuando dos usuarios pidieron lo mismo a la vez. El modelo no coge eso porque no ve causalidad en sistemas distribuidos. Ve código. El código parece correcto.
El otro — intento de hacer un SDK custom con lógica de negocio única, sin análogo en internet. El modelo rellenó la lógica por la media del sector, y lo que salió fue "un SDK típico para una tarea típica", no el mío concreto. Después lo reescribí a mano. Más rápido habría sido empezar por ahí.
Tres reglas con las que me quedé en un año, si me permiten la brevedad.
Primera. Formula el resultado, no el código. "Añade un endpoint POST /orders que acepta { id, items[], total }, valida, escribe en BBDD, devuelve 201" es una petición. "Haz que los pedidos funcionen" es un rezo. Entre una y otra: el 80% del éxito.
Segunda. Prueba a mano cada iteración. No tras cinco prompts. Tras cada uno. Tengo una regla dura conmigo: si no he comprobado que el código funciona, no acepto el siguiente prompt. Si no, el modelo construye una torre de suposiciones, cada una sobre la anterior, y cuando cae — cae entera.
Tercera. Lee el código, no sólo lo aceptes. Si las líneas 40–60 son opacas — pregunta al modelo. Si el modelo no lo explica de forma que lo entiendas — no está listo para producción. No va de desconfianza. Va de que tu trabajo ahora es review. Revisar código ajeno, aunque el ajeno sea un modelo de lenguaje, requiere comprensión.
Quien dice que los desarrolladores ya no hacen falta o nunca arregló código ajeno a las 3 AM, o está vendiendo un curso de $500. (Ya lo he escrito en alguna parte. Me gusta la formulación porque es exacta.)
El modelo es una palanca. Una palanca sin apoyo se rompe en el primer trabajo serio. El apoyo eres tú, quien entiende qué construye, por qué y qué pasa cuando se rompe.
En junio del año pasado pensaba que programar ya no hacía falta. En junio de este año pienso que programar hace falta más — pero no con las manos. Con la cabeza.