--- title: "Lo que entendí en un año de vibe coding — y de lo que me da un poco de vergüenza" url: "https://www.mikefluff.com/es/blog/vibe-coding-without-illusions" locale: "es" author: "Mike Fluff" updated: "2026-06-20" description: "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." tags: - "vibe-coding" - "ai" - "developer" alternates: - locale: "en" url: "https://www.mikefluff.com/en/blog/vibe-coding-without-illusions" markdown: "https://www.mikefluff.com/en/blog/vibe-coding-without-illusions.md" - locale: "ru" url: "https://www.mikefluff.com/ru/blog/vibe-coding-without-illusions" markdown: "https://www.mikefluff.com/ru/blog/vibe-coding-without-illusions.md" - locale: "pt" url: "https://www.mikefluff.com/pt/blog/vibe-coding-without-illusions" markdown: "https://www.mikefluff.com/pt/blog/vibe-coding-without-illusions.md" - locale: "es" url: "https://www.mikefluff.com/es/blog/vibe-coding-without-illusions" markdown: "https://www.mikefluff.com/es/blog/vibe-coding-without-illusions.md" --- # Lo que entendí en un año de vibe coding — y de lo que me da un poco de vergüenza > **En resumen:** El vibe coding elimina la parte mecánica de programar y deja el trabajo de formular la tarea. De doce proyectos en un año funcionaron prototipos, integraciones y refactors, y fallaron un backend distribuido y un SDK sin análogo. Mis reglas son formular el resultado en vez del código, probar cada iteración a mano y leer el código antes de aceptarlo. 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. **[Curso de vibe coding](https://www.mikefluff.com/es/vibe-coding-course)** — Seis módulos, $19. Herramientas, prompts, proceso. Sin entusiasmo ni decepción — sobre cómo funciona de verdad.