Yusuf Aytas retoma en este artículo una distinción que ya formuló hace casi una década con «Java Developer vs. Software Engineer», esta vez aplicada al momento actual de la programación asistida por inteligencia artificial. Su argumento central es que el debate público sobre el «vibe coding» mide mal el progreso: la métrica habitual de «tiempo hasta la primera versión que funciona» solo sirve para la fase de descubrimiento, mientras que en un equipo de desarrollo lo que importa es el «tiempo hasta una fusión segura» (time to safe merge), que incluye coste de revisión, de pruebas, de despliegue, de rollback, de coordinación y de mantenimiento futuro.
A partir de ahí, Aytas articula cuatro diferencias operativas entre un vibe coder y un ingeniero de software. Primera: la unidad de medida del trabajo; el primero celebra el output generado, el segundo asume que cualquier cambio es una unidad de responsabilidad que debe ser estrecha, explicable y acotada. Segunda: el alcance del cambio; el código asistido por IA debe ser mejor, no más grande, y partirse si es necesario, porque un autor que no puede justificar cada fichero modificado no está listo para revisión. Tercera: la autoría; un vibe coder puede escudarse en que «lo generó el modelo», mientras que un ingeniero de software debe poder decir «lo asumo», convirtiendo las completions en decisiones de ingeniería antes de pedir revisión. Cuarta: el espacio de decisión; dar al modelo un objetivo abierto es propio del hobby de fin de semana, mientras que producción exige tareas acotadas con restricciones explícitas sobre qué interfaz usar o qué capa no tocar.
El texto cierra con una observación sobre el contexto: los modelos leen mucho código, pero buena parte del contexto de ingeniería vive en incidentes, migraciones, comportamiento de clientes, convenciones de equipo y requisitos de cumplimiento que no caben en una ventana de contexto. Por eso, concluye Aytas, los ingenieros experimentados obtendrán más valor de la IA no dándole más libertad, sino menos.