Vibe Coding
Por qué importa
En profundidad
La descripción original de Karpathy era deliberadamente provocadora: hablaba de usar entrada de voz en vez de escribir, pulsar "aceptar todo" en cada cambio sugerido sin leer los diffs y corregir errores pegando sus mensajes de vuelta al modelo hasta que desaparecieran. Si se elimina la provocación, el flujo de trabajo es sencillo — describir, generar, ejecutar, reaccionar —, con el humano actuando como gerente de producto y evaluador en vez de autor. Lo que lo volvió viable en 2025 no fue que la IA pudiera escribir código — los Asistentes de codificación IA llevaban años haciéndolo —, sino que los modelos subyacentes de tipo Modelo de lenguaje grande se volvieron lo bastante buenos para mantener unido un pequeño proyecto completo a través de muchos turnos de ese bucle. En cuestión de meses, el término escapó por completo de los círculos tecnológicos, apareció en medios generalistas y en la lista de candidatos a palabra del año del Collins Dictionary, y se convirtió en la abreviatura predeterminada de un cambio real en quién puede construir software.
Las herramientas que lo hacen posible
Vibe coding se volvió práctico cuando los asistentes de codificación incorporaron modos de agente. En vez de completar una línea a la vez, herramientas como Cursor, GitHub Copilot y Windsurf ahora pueden editar varios archivos a la vez, crear otros nuevos, ejecutar comandos de shell, ejecutar el programa, leer la salida e iterar — exactamente el bucle que quien practica vibe coding quiere delegar. Una Ventana de contexto larga permite que el modelo tenga presente a la vez el código de un proyecto pequeño, y un mejor seguimiento de instrucciones significa que una descripción imprecisa de la intención suele producir algo ejecutable. Herramientas más autónomas como Devin llevan la misma idea más lejos, al recibir una descripción de tarea y trabajar en ella durante periodos prolongados con supervisión mínima.
Dónde brilla el vibe coding
El punto ideal es el software útil pero desechable: proyectos de fin de semana, herramientas personales, scripts de datos para una sola ocasión, prototipos, demostraciones y dashboards internos. El propio encuadre de Karpathy eran proyectos desechables de fin de semana — cosas que nunca te habrías molestado en escribir a mano porque el esfuerzo superaba el beneficio. Para quienes no programan, el atractivo es aún más directo: un docente, profesional de marketing o dueño de una pequeña empresa puede describir una aplicación sencilla y obtener una versión funcional en una tarde, algo que antes exigía contratar a un desarrollador o aprender a programar. Los ingenieros experimentados usan el mismo modo para código repetitivo, migraciones y código de integración, donde la forma de la solución es evidente y leer cada línea aporta poco. En todos estos casos, el costo de un error sutil es bajo, por lo que saltarse la revisión es una contrapartida racional.
La deuda de revisión y seguridad
Los riesgos son la otra cara de la misma elección. Un modelo puede incurrir en Alucinación de funciones de bibliotecas, elegir API obsoletas o conectar incorrectamente la autenticación, y si nadie lee el diff, esos errores llegan a producción. Investigadores de Seguridad de la IA han descubierto repetidamente que el código generado por IA contiene una tasa considerable de vulnerabilidades — fallos de inyección, comprobaciones de autorización ausentes, secretos escritos directamente en el código —, y 2025 vio una serie de incidentes en los que aplicaciones creadas rápidamente mediante vibe coding expusieron datos de usuarios o claves de API en producción. También hay un costo estructural más lento: una base de código que nadie comprende por completo es difícil de depurar, y una vez que crece más allá de lo que cabe en la ventana de contexto del modelo, hasta la IA comienza a hacer cambios incoherentes. Los críticos agrupan lo peor de estas salidas bajo la etiqueta Slop — código que parece plausible, funciona en su mayor parte y se pudre discretamente.
No es lo mismo que la programación asistida por IA
Una idea equivocada común es que vibe coding es solo un nombre nuevo para cualquier programación asistida por IA. No es así. El término se refiere específicamente a renunciar al paso de revisión: si el modelo escribió el código pero tú lo leíste, comprendiste y asumiste la responsabilidad, eso es desarrollo ordinario asistido por IA con mejores herramientas — una distinción que autores como Simon Willison marcaron pronto y con claridad. La idea equivocada opuesta es que el humano no aporta nada. En la práctica, un buen vibe coding es una habilidad: describir la intención con precisión, saber qué pedir después y reconocer cuándo la salida huele mal son factores importantes, por lo que la disciplina se superpone con la Ingeniería de prompts y la ingeniería de contexto.
Cómo lo usan realmente los profesionales
La mayoría de los equipos en activo adopta un patrón combinado. El prototipo se crea mediante vibe coding — rápido, desechable, juzgado por si funciona bien en una demostración —, y todo lo destinado a producción pasa por una revisión normal, con pruebas e integración continua como red de seguridad que sustituye la lectura anticipada de cada línea. Un límite común es el riesgo: las herramientas y scripts internos son terreno válido, mientras que la autenticación, los pagos y todo lo que toca datos de usuarios recibe escrutinio humano sin importar cómo se haya escrito. Los desarrolladores sénior tienden a sacar mayor provecho del estilo porque su instinto detecta rápidamente salidas que parecen incorrectas; los júnior que dependen de él demasiado pronto se arriesgan a lanzar código que no pueden explicar ni arreglar. Tratar el código generado como un pull request de un colega júnior rápido pero descuidado — útil, bienvenido y nunca fusionado sin leer — es el modelo mental en el que han convergido muchos equipos.