Andrej Karpathy popularizó el término "vibe coding" en 2024: un modo de desarrollo en el que describes lo que quieres a un LLM, aceptas el código generado y sigues sin leer lo que fue escrito. "Los vibes son buenos", el código funciona, sigues adelante.

Para demos, experimentos y prototipos personales, esto funciona. Pero existe una conversación que el hype en torno al vibe coding está posponiendo: cuáles son las implicaciones reales de llevar a producción código que el ingeniero no leyó, no entiende y no sabe mantener?

Lo que el "vibe coding" captura de verdad

La idea detrás del vibe coding no es nueva. Es el mismo argumento de siempre a favor de la abstracción. Cuanto menos necesitas pensar en implementación, más energía va al problema que importa.

Y hay verdad en eso. Tareas repetitivas, boilerplate, transformaciones bien definidas, generación de tests para casos obvios. La IA hace todo eso bien, y hay poco valor en hacerlo manualmente. Aceptar código generado para esas tareas sin leer línea a línea es razonable.

El problema empieza cuando el "vibe" se extiende a lógica de negocio, seguridad, performance y decisiones de arquitectura, las partes donde equivocarse tiene costo real.

Lo que la IA no sabe sobre tu contexto

Los LLMs son excelentes en patrones. Están limitados en contexto específico. No saben:

  • Las invariantes de negocio de tu dominio que un bug puede violar
  • Los contratos implícitos entre partes del sistema que solo existen en la cabeza del equipo
  • Las propiedades de performance que el sistema necesita mantener bajo carga real
  • Los requisitos de seguridad específicos de tu producto y de tus usuarios
  • El historial de decisiones de trade-off que hicieron que el sistema sea como es

Código generado por IA es correcto en el contexto de lo que el modelo fue entrenado. Puede ser incorrecto en el contexto de tu sistema, y la única forma de saberlo es entender lo que fue generado.

El argumento de los tests

Un contraargumento común: "No necesito entender el código si tengo suficientes tests." El problema es que los tests también pueden ser generados por IA, con los mismos gaps de contexto. Los tests generados cubren lo que el modelo cree que debe cubrirse, no necesariamente lo que tú necesitas cubrir.

Además, código que no entiendes es código que no puedes debuggear cuando falla en producción. Va a fallar. La cuestión es si vas a entender por qué.

La escala del problema en producción

En proyectos personales y prototipos, el costo de los bugs es bajo. En producción con usuarios reales:

  • Un bug de seguridad introducido por código generado sin revisión adecuada puede exponer datos de usuarios
  • Una race condition en lógica de pago puede crear transacciones duplicadas
  • Un memory leak en un componente generado puede tumbar el servicio bajo carga
  • Una falla en validación de input puede abrir vector de injection

Ninguno de estos escenarios es hipotético. Todos ocurren con código generado por humanos también, pero código que el ingeniero leyó, entendió y revisó tiene más chances de tener estos problemas capturados antes de producción.

El modelo correcto: IA como par, no como sustituto

El modelo más útil: IA como pair programmer, no como desarrollador autónomo. Todavía tomas decisiones, revisas lo que fue generado y eres responsable por el resultado.

En la práctica, esto significa:

  • Describes el problema, la IA genera una solución. Tú lees y entiendes antes de aceptar
  • Para lógica de negocio, revisas con el mismo rigor con el que revisarías código de un junior
  • Para código de seguridad, verificas lo que se está haciendo, no solo que parece funcionar
  • Mantienes la capacidad de explicar lo que el código hace. Si no puedes, no revisaste lo suficiente

Dónde el vibe coding tiene sentido

Para ser justos: existe espacio legítimo para aceptar código generado con menos revisión. Scripts de automatización internos. Prototipado rápido. Código de test con lógica simple. Migrations bien delimitadas. En esos contextos, el costo de una revisión profunda es desproporcionado al riesgo.

La distinción que importa: el ingeniero sabe en qué parte del espectro está, y ajusta el nivel de revisión de acuerdo. Vibe coding como modo default para todo es el problema, no la IA en sí.