Desarrollar sin leer el código generado por la IA y pulsando solo Accept All es lo que hoy llamamos «vibe coding». El inicio es sorprendentemente rápido y muchos dicen que, una vez probado, cuesta volver atrás; aun así, conviene saber de antemano dónde y cómo se cobrará el precio de no leer el código.
Este artículo define con precisión el vibe coding, explica sus ventajas, tres problemas reales de no leer el código y tres soluciones para reducir incidentes sin leerlo todo.
Empecemos por la conclusión.
El vibe coding hace que empieces diez veces más rápido, pero si no lees el código, acabarás devolviendo esa velocidad en forma de costes de mantenimiento.
Para un prototipo o una herramienta de uso personal, merece la pena probarlo. Pero si vas a ofrecer un servicio a otras personas o mantener el código durante mucho tiempo, la historia cambia. Veamos por qué.
¿Qué es exactamente el vibe coding?
Empecemos por el término. «Vibe coding» nació de una publicación que Andrey Karpathy hizo en Twitter en febrero de 2025.
La idea central es esta: le dices a la IA lo que quieres en lenguaje natural, la IA escribe el código y la persona no lo lee con atención.
El propio Karpathy dijo: «Siempre pulso Accept All y ya no leo el diff». Cuando aparece un error, copia el mensaje tal cual y se lo vuelve a enviar a la IA.
Por cierto, Collins Dictionary también eligió este término como «palabra del año» de 2025.
La esencia del vibe coding se acerca más a «no leer el código» que a «programar con IA». Si usas IA pero lees todo el diff, eso es simplemente desarrollo asistido por IA, no vibe coding.
Las ventajas son claras
El vibe coding se ha popularizado por una razón.
Primero, la velocidad de inicio. La configuración inicial de un proyecto, que antes tardaba días, se reduce a decenas de minutos. El tiempo hasta que aparece algo en pantalla se acorta drásticamente.
Segundo, compensa las carencias. La barrera de entrada a áreas desconocidas baja mucho; por ejemplo, un desarrollador backend puede describir un diseño CSS con palabras y hacerlo generar.
Tercero, el obstáculo psicológico. Crece la actitud de «vamos a construirlo primero», y empiezas a tocar ideas que llevabas tiempo posponiendo.
El problema es que esta satisfacción suele durar solo al principio, mientras el código todavía es pequeño.
Lo que realmente ocurre si no lees el código
Cuando la base de código crece lo suficiente, aparecen tres problemas comunes.
1. Ya no puedes corregir errores. Si entregas cada error directamente a la IA, te bloqueas cuando la IA no puede solucionarlo. Como nunca has leído el código, ni siquiera puedes intuir dónde está el problema.
2. La misma funcionalidad aparece en varios sitios. La IA suele olvidar el código anterior y crea una y otra vez funciones parecidas. Más tarde corriges una y las demás permanecen intactas.
3. Se abren agujeros de seguridad silenciosos. El caso típico es que una clave de API quede incrustada directamente en el código del cliente. La IA solo sigue instrucciones y la persona no comprueba el resultado.
El tercero es el más preocupante. Por ejemplo, un código como este.
// AICódigo escrito por la IA — clave expuesta en el cliente
let apiKey = "sk-live-abc123" // Incluida directamente en el binario de la aplicación
let url = URL(string: "https://api.example.com?key=\(apiKey)")!
URLSession.shared.dataTask(with: url).resume()Con un código así, cualquiera puede ver la clave en cuanto se publica la aplicación. Si no lees el diff, pasas por alto estas cosas.
Entonces, ¿qué hacemos? Tres soluciones
Por suerte, hay formas de reducir mucho los incidentes sin volver a «leerlo absolutamente todo».
Solución 1. Lee personalmente las tres áreas críticas. Aunque no puedas leerlo todo, decide cuáles son las partes difíciles de revertir si ocurre un incidente y revísalas.
// Como mínimo, comprueba personalmente estas tres cosas
// 1) Código relacionado con autenticación y claves
// 2) Lógica relacionada con pagos y dinero
// 3) Partes que eliminan o modifican datos de usuarioConcentrarte en estas tres cosas reduce mucho la probabilidad de un incidente grave.
Solución 2. Lee el resumen de la IA en lugar del código. Si no quieres leer el código, al menos pide una vez más: «Resume solo los riesgos de seguridad, dinero y eliminación de datos del código que acabas de escribir», y lee ese resumen. Haz que lo revise una IA distinta, en una sesión nueva y no en la sesión que escribió el código, para reducir también el sesgo de defender su propio código.
Solución 3. Si las personas no lo leen, haz que lo lean las máquinas. Si añades un escáner de secretos como gitleaks a un hook pre-commit, la exposición de claves de API anterior se detectará automáticamente durante el commit. Integrar linters y pruebas en CI sigue el mismo principio.
Las tres soluciones comparten una idea: reducir el coste de lectura sin reducir la verificación a cero.
Entonces, ¿hay que usar vibe coding o no?
La conclusión es: «depende de la situación».
| Situación | Nivel de recomendación | Motivo |
|---|---|---|
| Prototipo/demo | Muy recomendable | Se puede crear rápido y desecharlo |
| Herramienta de uso personal | Recomendable | Si falla, solo me perjudica a mí |
| Proyecto paralelo | Condicional | Leer la lógica principal |
| Servicio en producción/colaboración en equipo | No recomendable | El coste de mantenimiento se come la velocidad |
La diferencia clave es si no lees nada de código o si solo lees las partes importantes.
P. ¿Pueden los principiantes aprender desarrollo con vibe coding? R. Es estupendo para disfrutar del proceso de crear. Pero si no lees nada de código, mejorarás poco. Después de crear algo, pregunta a la IA «¿por qué escribiste el código así?» y acompáñalo de un hábito de lectura.
P. ¿Hasta qué punto puedo confiar en el código escrito por la IA? R. Que funcione y que sea seguro son cosas distintas. Puedes confiar en la IA para hacerlo funcionar, pero una persona o un mecanismo de verificación independiente debe confirmar que sea seguro y mantenible.
En resumen: «la velocidad para la IA, el juicio para mí». No hace falta leerlo todo, pero si no lees nada, algún día pagarás el precio. Si incorporas hoy хотя sea una de las tres soluciones anteriores al proyecto, puedes reducirlo mucho.
Yendo un paso más allá, existe una metodología llamada desarrollo guiado por especificaciones (SDD), que primero fija los requisitos en un documento antes de pedirle a la IA que escriba código. Es el enfoque opuesto al vibe coding y lo trataré en detalle en el próximo artículo.
Referencias
- Vibe coding - Wikipedia
- Not all AI-assisted programming is vibe coding (but vibe coding rocks) - Simon Willison