Vibe coding: lo estoy usando y esto es lo que nadie te dice
Llevo meses usando vibe coding en proyectos reales. El balance es positivo, pero no es lo que los titulares venden. Esto es lo que aprendí usándolo de verdad.
Santiago Gómez
Vibe coding: lo estoy usando y esto es lo que nadie te dice
Hace unos meses estaba construyendo el backend de un proyecto. Tenía claro lo que quería, pero el tiempo no sobraba. En algún punto de esa semana empecé a describir lo que necesitaba en lenguaje natural, dejar que la IA generara la base, y yo revisaba, ajustaba y dirigía. El código salía. Rápido.
Eso es vibe coding. Y desde entonces no he parado de usarlo, para bien y para mal.
Qué es exactamente
El término lo acuñó Andrej Karpathy, cofundador de OpenAI, en febrero de 2025. Lo describió como "dejarse llevar por las vibraciones, abrazar los exponenciales, y olvidar que el código existe." Básicamente: describes lo que quieres en lenguaje natural, la IA escribe el código, tú revisas y diriges.
No es solo un copiloto que autocompleta líneas. Herramientas como Cursor, Windsurf o Claude Code tienen acceso a tu terminal, a tus archivos, al contexto completo del proyecto. No te preguntan cómo hacerlo, te preguntan qué quieres que pase.
Los números que hay detrás son difíciles de ignorar. El 92% de los developers en EEUU ya usan herramientas de IA a diario, y el 41% del código que se escribe globalmente en 2026 es generado por IA. Eso no es una tendencia que viene, es una que ya está aquí.
Por qué funciona de verdad
Lo primero que notas cuando empiezas a usarlo bien es que el cuello de botella cambia de sitio. Antes el cuello de botella era escribir el código. Ahora es tener claro qué quieres construir y saber evaluar si lo que salió es correcto.
Para alguien que lleva años programando, eso es una ventaja enorme. Porque el criterio para evaluar si una arquitectura tiene sentido, si hay un edge case sin cubrir, si la solución va a escalar, eso no lo tiene la IA. Lo tienes tú. Y ahora tienes más tiempo para usarlo porque no estás escribiendo boilerplate.
Un MVP que antes costaba tres meses y cincuenta mil euros ahora se puede construir en un fin de semana largo. No perfectamente, pero funcional. Eso cambia completamente el cálculo de qué vale la pena intentar.
Por qué también puede salir muy mal
Aquí es donde hay que ser honesto, porque la mayoría de los artículos sobre vibe coding lo venden sin matices.
La IA hallucina. Inventa nombres de funciones que no existen. Referencia APIs que llevan años deprecadas. Genera código que parece correcto, está bien estructurado, sigue buenas convenciones, y llama a una función que nunca existió. Un developer con criterio lo detecta inmediatamente. Alguien que no entiende el código que está aceptando, no.
El otro problema es el contexto global. Cuando le pides a un agente que haga una tarea, la hace. Literalmente, sin considerar cómo encaja con el resto del proyecto. Puede resolver perfectamente lo que pediste y crear tres problemas nuevos en el proceso, porque no tiene la visión de conjunto que tú tienes.
Y hay un riesgo más silencioso: el de perder el criterio. Si empiezas a aceptar código sin entenderlo, con el tiempo dejas de saber si lo que estás construyendo es sólido o es una casa de naipes que funciona hasta que no funciona.
Cómo lo uso yo
No uso vibe coding para todo. Hay partes del código donde quiero control total, donde la arquitectura importa demasiado como para delegarla. Y hay partes donde es exactamente la herramienta correcta.
Lo uso para arrancar rápido. Para generar la estructura base de algo nuevo, el scaffolding, los tests repetitivos, la integración con una API que ya conozco pero no quiero escribir a mano. Para explorar una solución antes de compreterme con ella.
Lo que no hago es aceptar código sin leerlo. Cada bloque que entra al proyecto lo entiendo o lo rechazo. Eso ralentiza el proceso, pero mantiene el criterio intacto.
La mentalidad que me funciona es tratarlo como un junior muy rápido. Le das contexto, le explicas qué quieres, revisas lo que hace, y corriges cuando se equivoca. Si lo tratas como un oráculo que siempre tiene razón, el problema eres tú.
Lo que cambia para los developers
Hay una conversación incómoda que está pasando en silencio en el sector. Si el código lo puede generar una IA, ¿qué valor aporta el developer?
La respuesta que me convence es que el valor nunca estuvo en escribir líneas. Estuvo en entender el problema, en tomar decisiones de arquitectura, en saber cuándo una solución que funciona hoy va a ser un problema en seis meses. Eso no lo hace la IA.
Lo que sí está cambiando es que los developers que no adopten estas herramientas van a competir en velocidad con los que sí las usan. Y esa es una competición difícil de ganar.
El developer que gana en 2026 no es el que más código escribe. Es el que mejor sabe qué construir, por qué, y cómo verificar que lo que salió es correcto.
Llevo meses usando esto en proyectos reales. El balance es positivo, pero no es magia. Es una herramienta con sus límites, y como todas las herramientas, el resultado depende de quién la usa.
Nos leemos.
Santi
