Debemos dejar de llamar a todo Vibe Coding

Volví a programar después de una larga pausa, y Lovable fue donde lo retomé. Las aplicaciones se veían geniales, funcionaban a primera vista y se ensamblaban en unas pocas horas. Al principio, eso resultó notable. Pero dejó de ser suficiente en el momento en que quise saber qué hacía el código – y por qué. Fue entonces cuando mi enfoque empezó a cambiar.

La diferencia no está en la herramienta, ni en cuánto código escribe la IA por ti. Se trata del contrato que aceptas con tu salida: si puedes explicar lo que acabas de lanzar al mundo, o no.

Vibe coding, en su sentido original, significa aceptar software generado por IA sin examinar o comprender adecuadamente lo que hay debajo. El desarrollo asistido por IA es diferente. El modelo puede seguir escribiendo la mayor parte del código, pero la persona que construye el sistema sigue siendo responsable de entender su comportamiento, probar sus supuestos y decidir si está listo para ser entregado.

Para un experimento desechable que nunca abandona tu propia máquina, la distinción puede tener pocas consecuencias. Una vez que el software se despliega, lo usan otros o se conecta a datos reales, la diferencia importa enormemente.

Cómo “Vibe Coding” perdió su significado

El término “vibe coding” fue acuñado en febrero de 2025 por Andrej Karpathy, cofundador de OpenAI. Su ejemplo era deliberadamente informal: un “proyecto de fin de semana desechable” construido al hacer clic automáticamente en “Aceptar todo”, ignorando los diffs y permitiendo que el código creciera más allá de su comprensión.

Semanas después, el desarrollador y creador de herramientas Simon Willison notó que el término se estaba usando de forma muy distinta: como un sustituto de cualquier programación asistida por IA, lo que, según él, diluye el término y da una impresión falsa de lo que el desarrollo responsable asistido por IA puede lograr.

Lo revelador es que Karpathy finalmente estuvo de acuerdo. Un año después, introdujo un término diferente para un trabajo más disciplinado con agentes de codificación. Describió la “ingeniería agentiva” como un flujo de trabajo en el que los desarrolladores dirigen y supervisan a los agentes en lugar de aceptar simplemente lo que producen. La distinción importa: el desarrollo profesional asistido por IA requiere planificación, escrutinio y responsabilidad de maneras que el “vibe coding” casual no contempla.

La línea es la responsabilidad

La regla de Willison es simple, y funciona como prueba para cualquiera: no comprometas código que no puedas explicar a otra persona. Eso no significa leer cada línea: con agentes generando cientos de líneas a la vez, ni siquiera los desarrolladores experimentados lo hacen ya. Significa entender la lógica central y poder justificar por qué el código hace exactamente lo que hace. Si puedes, no importa si lo escribió un modelo o tú: eso no es “vibe coding”, es usar una herramienta para crear software.

Una investigación publicada en diciembre de 2025 respalda esa distinción. Basándose en observaciones de campo y una encuesta cualitativa a desarrolladores profesionales, los investigadores hallaron que los practicantes experimentados mantenían el control sobre el diseño e implementación del software en lugar de delegar todo el proceso a la IA. Trataban a los agentes como colaboradores, planificaban su trabajo cuidadosamente y permanecían involucrados en la supervisión.

Así que la experiencia por sí sola no lo explica. Se trata de si estás dispuesto a asumir la responsabilidad de lo que genera la IA. Esa es una decisión que cada desarrollador vuelve a tomar en cada proyecto.

Qué ocurre cuando falta el control

Las consecuencias de lanzar software sin comprender o verificar su seguridad no son abstractas. Tea, una aplicación destinada a ayudar a las mujeres a mantenerse seguras mientras salen con citas, exponía decenas de miles de fotos de identificación y más de un millón de mensajes privados en dos incidentes de seguridad. Las fallas incluían un bucket de almacenamiento sin seguridad y una base de datos separada accesible sin autenticación.

El mismo problema subyacente – software que parecía funcionar mientras su lógica de autorización permanecía peligrosamente equivocada – apareció en una aplicación construida sobre la plataforma Lovable: una investigación de seguridad encontró la lógica de autorización invertida, bloqueando a usuarios autenticados mientras permitía la entrada libre de atacantes no autenticados, afectando a más de 18 000 usuarios, incluidos estudiantes.

Estos no son casos aislados que solo ocurren en proyectos “malos”. Según el informe DORA de Google de 2025, el 90 % de los desarrolladores ya usan IA en el trabajo, mientras que aproximadamente un tercio reporta poca o ninguna confianza en lo que genera.

El uso de IA está ahora muy extendido, aunque la confianza sigue siendo limitada. Y eso hace que la revisión cuidadosa sea especialmente importante cuando el código generado maneja autenticación, permisos o datos sensibles.

El control se construye en capas, no de una sola vez

En mi caso, no comencé con una auditoría de seguridad formal. Simplemente me negué a avanzar siempre que no podía explicar por qué algo se comportaba de la manera que lo hacía – un instinto natural que aplico como analista. Me importa menos la sintaxis que si el resultado coincide con lo que originalmente necesitábamos. Cuando no coincide, sigo investigando.

Mi flujo de trabajo se volvió más estructurado a medida que los proyectos se volvieron más serios. En lugar de confiar solo en los prompts, comencé a preparar especificaciones antes de generar cualquier cosa. Documenté los requisitos de negocio, la pila tecnológica y las integraciones. Luego añadí pruebas unitarias y pruebas con Playwright para los principales recorridos de usuario.

Las verificaciones de seguridad se añadieron de manera similar. Revisé las bibliotecas que la IA seleccionó e introduje escaneos de malware para los archivos subidos. Cada verificación surgió de preguntar qué podría salir mal a continuación, en lugar de seguir una lista de control preparada al inicio.

Esa costumbre detectó un problema en un proyecto. La IA introdujo una biblioteca que era incompatible con la versión del framework que estaba usando. La aplicación no falló de inmediato, por lo que la incompatibilidad podría haber pasado desapercibida. Detectarla más tarde habría dificultado mucho identificar la causa.

Comparado con los casos de Tea y Lovable, este fue un problema ordinario. Lo encontré temprano, lo corregí y seguí adelante. Así es normalmente la revisión en la práctica. La mayor parte del tiempo, evita que pequeños problemas se conviertan en problemas mayores.

No desconfío del código solo porque lo haya producido la IA. Tampoco confío en él solo porque la aplicación funciona. Las pruebas y la revisión son cómo establezco si se comporta como se espera.

De Vibe Coding a la Ingeniería Agentiva

El propio alejamiento de Karpathy de “vibe coding” hacia la “ingeniería agentiva” no es solo un cambio de vocabulario. “Ingeniería agentiva” nos brinda un nombre más útil para la dirección que está tomando el desarrollo profesional. Los desarrolladores pueden escribir menos líneas ellos mismos, pero eso no reduce su responsabilidad. Desplaza su trabajo hacia la especificación de lo que el sistema debe hacer, la dirección de los agentes, la prueba de sus resultados y la decisión de qué es seguro lanzar.

El peligro no es que la IA genere código rápidamente. Es que la generación puede avanzar más rápido que la comprensión. Cuando eso ocurre, la aparente productividad oculta riesgos que nadie ha examinado adecuadamente.

Una regla que vale la pena mantener

Deja de usar “vibe coding” como etiqueta para cualquier forma de desarrollo asistido por IA – diluye el término y elimina una distinción de control que importa. Establece una regla simple: no entregues lo que no puedes explicar. Y construye el control en el proyecto a medida que crece, capa por capa, añadiendo verificaciones en consonancia con los riesgos que emergen.

La IA puede escribir la mayor parte del código. No puede asumir la responsabilidad de entregarlo. Eso sigue perteneciendo a nosotros.