Vibe coding vs. ingeniería asistida por IA: la diferencia que decide la calidad
Vibe coding acepta el código sin leerlo; la ingeniería asistida lo revisa, lo prueba y parte de una especificación. Qué cambia y cuándo usar cada una.
¿Qué separa a una de la otra?
Ambas empiezan igual: una descripción en lenguaje natural y una IA que genera código. La diferencia aparece en tres momentos.
| Momento | Vibe coding | Ingeniería asistida por IA |
|---|---|---|
| Antes de codificar | Se describe la idea y se pide que la IA la construya | Se escribe una especificación o un mini-PRD y se pide un plan antes de tocar código |
| Mientras se genera | Se acepta el resultado si la pantalla se ve bien | Se revisa cada cambio, se piden pruebas y se leen los diffs |
| Después | Se publica si funciona en la demo | Se prueba, se revisa la seguridad y se documenta qué se cambió |
Addy Osmani, “Engineering Leader” en Google enfocado en IA y experiencia de desarrollo, lo plantea en su guía en línea Beyond Vibe Coding como un espectro: el desarrollo asistido por IA va desde el vibe coding simple hasta la ingeniería compleja y lista para producción. Define el vibe coding como un enfoque lúdico basado en prompts de alto nivel, y la ingeniería asistida como un enfoque más estructurado que suma la creatividad del vibe coding al rigor de las prácticas tradicionales de ingeniería (Osmani, Beyond Vibe Coding).
Simon Willison pone el corte en la revisión: para él, vibe coding es construir software con un LLM sin revisar el código que escribe, y no es lo mismo que escribir código con ayuda de un LLM. Su regla personal es no subir al repositorio nada que no pueda explicar a otra persona (Willison, 19 de marzo de 2025).
¿Por qué le importa a un diseñador?
Porque el vibe coding llega rápido hasta cierto punto y después se frena. Osmani lo llama “el problema del 70%”: las herramientas de IA permiten llegar a cerca del 70% de una app funcional sorprendentemente rápido, pero el 30% final, la parte que hace al software listo para producción, mantenible y robusto, se vuelve un ejercicio de rendimientos decrecientes (Osmani, diciembre de 2024). En ese ensayo también señala que el software de demo suele tener casos borde que hacen fallar la aplicación y que quien acepta el resultado de la IA sin cuestionarlo pasa por alto consideraciones de seguridad y rendimiento. Y en su guía advierte que el vibe coding es divertido hasta que empiezas a filtrar credenciales de bases de datos.
Para un diseñador, la consecuencia práctica es que el prototipo engaña. Una demo que se ve bien prueba que la idea funciona visualmente, no que el sistema sea seguro ni mantenible.
¿Qué hace un proceso de ingeniería asistida?
No hace falta ser programador, pero sí pedir cuatro cosas, que coinciden con las recomendaciones de la guía de Osmani:
- Especificación primero. Un SPEC o mini-PRD con objetivo, usuarios, reglas y casos que deben funcionar. Mira cómo escribir un PRD que un agente entienda.
- Plan antes de código. Pide a la IA el plan antes de la implementación (el modo plan sirve para eso) y apruébalo antes de que ejecute.
- Pruebas después de cada cambio. Pruebas automáticas para cada función generada y una revisión de seguridad. Mira seguridad básica en vibe coding.
- Una persona que aprueba. Osmani pide mantener supervisión humana como revisora y aprobadora final, y tratar el código generado como el de una persona desarrolladora junior: necesita revisión y pruebas antes de entrar.
¿Cuándo es suficiente el vibe coding?
Cuando el objetivo es aprender, explorar o validar una idea y nadie depende del resultado. Willison pide que los proyectos sean de bajo riesgo (“low stakes”). El límite aparece cuando hay datos reales de personas, dinero o una promesa de disponibilidad: ahí la ingeniería asistida deja de ser opcional. Una prueba rápida: si el código puede afectar a alguien que no eres tú, usa el segundo enfoque. Los criterios para parar están en cuándo no hacer vibe coding.
Ejemplo
Ejemplo ilustrativo: un equipo de producto construye un prototipo de reservas con vibe coding en un par de días. Para pasarlo a producción, redactan una especificación de una página (roles, estados de una reserva, qué pasa si se cancela), piden a la IA un plan de cambios por módulo y pasan cada cambio por pruebas de reservas duplicadas y de permisos. Una persona de ingeniería revisa las credenciales y la forma de guardar los datos antes del lanzamiento. El prototipo se hizo rápido; la versión publicada llevó mucho más tiempo, y ese tiempo es el último 30%.
¿Qué puedes hacer mañana?
- Antes de pedir una función, escribe tres líneas: qué problema resuelve, para quién y qué significa que funcione. Es el primer paso de cualquier especificación; sigue con spec-driven development.
- Pide un plan con la lista de archivos que van a cambiar y revísalo antes de aprobar. Si toca algo que no esperabas, pregunta por qué. Mira también iterar por prompts.
- Define una prueba mínima repetible: un flujo que el sistema debe completar sin errores. Vuelve a ejecutarla después de cada cambio.
- Antes de publicar, pide a una persona de ingeniería que revise accesos, secretos y datos personales, y anota lo que encontró para la siguiente versión.
Errores comunes
- Creer que la velocidad del prototipo predice el tiempo de producción.
- Saltarse la especificación porque “la IA entiende”.
- Aprobar planes sin leerlos, solo para avanzar.
- Confundir pruebas visuales con pruebas automáticas.
- Dejar que la IA gestione secretos o credenciales sin revisión.
- Usar la palabra “ingeniería” como etiqueta, sin cambiar el proceso.
Fuentes
- Addy Osmani, “Beyond Vibe Coding” (guía en línea sobre el espectro entre vibe coding e ingeniería asistida): https://beyond.addy.ie/
- Addy Osmani, “The 70% problem: Hard truths about AI-assisted coding” (4 de diciembre de 2024): https://addyo.substack.com/p/the-70-problem-hard-truths-about
- Simon Willison, “Not all AI-assisted programming is vibe coding (but vibe coding rocks)” (19 de marzo de 2025): https://simonwillison.net/2025/Mar/19/vibe-coding/