De prototipo a producción: el salto que nadie te cuenta del código generado por IA

Hace unas semanas, una emprendedora me mostró una aplicación web funcional que había construido en un fin de semana usando herramientas de IA. Sin carrera de sistemas, sin bootcamp, solo una idea clara y prompts bien diseñados. Era impresionante, honestamente.

Tenía login, un dashboard, persistencia de datos. Todo funcionando en menos de 72 horas.

Después me pidió ayuda para llevarla a usuarios reales.

Ahí es donde la historia se puso interesante.

El problema del prototipo

El prototipo funcionaba porque ella era la única usuaria. En el momento en que intentamos agregar una segunda persona, aparecieron errores de concurrencia. La base de datos no tenía migraciones de schema, así que cualquier rollback habría significado perder información. No había tests, lo que hacía que cualquier refactorización se sintiera como desarmar una bomba con los ojos vendados. Y el deployment era un proceso manual sin documentación alguna.

Su proyecto de fin de semana era un gran proof of concept. No era software listo para producción.

Esta es la parte que la conversación sobre "vibe coding" no menciona. Las herramientas son reales, la velocidad es real, y la democratización de la creación de software es genuinamente emocionante. Pero hay una diferencia entre generar código y construir software. Y esa diferencia importa más de lo que la mayoría imagina, hasta que están frente a una incidencia a las 3 de la mañana.

La métrica que realmente cuenta

La pregunta que me hago cada vez que veo código generado por IA es simple: ¿se puede fusionar de forma segura en un codebase compartido?

No estoy preguntando si funciona. No pregunto si el demo anduvo. Me refiero a fusión segura. Esa palabra "segura" implica mucho. Significa que el código puede ser revisado por alguien que no lo escribió. Significa que los tests verifican comportamiento, no solo que el programa no crashee. Significa que el rollback es posible sin pérdida de datos. Significa que el cambio es lo suficientemente acotado para entenderlo y explicarlo.

Cuando un vibe coder mide éxito, generalmente mide tiempo hasta la primera versión funcionando. Es una métrica útil para discovery y prototipado. Pero cuando el software entra en un ambiente compartido, esa métrica deja de servir. Ahora estás midiendo tiempo hasta fusión segura, y eso incluye costo de revisión, calidad de tests, riesgo de deployment, overhead de coordinación y carga de mantenimiento futura.

Un engineer piensa en todo ese ciclo de vida desde el principio. Un vibe coder suele descubrir estos temas después, cuando costaan más resolver.

Generación vs. Propiedad

Hay un cambio sutil pero crítico que ocurre cuando la IA genera tu código. El output todavía no es tu trabajo. Es un punto de partida que necesita transformarse en algo que realmente posees.

Propiedad significa varias cosas. Puedes explicar cada decisión importante en el cambio. Entiendes por qué existe cada archivo y qué hace. Has acotado el cambio exactamente a lo necesario, sin boilerplate extra ni limpiezas no relacionadas. Has escrito o verificado tests que проверяют comportamiento, no solo métricas de cobertura. Has considerado el camino de rollback.

Este es el trabajo que la IA no puede hacer por ti. La IA genera. Tú decides. Y "decidir" implica que has pensado en alternativas, pesado tradeoffs y entendido las consecuencias.

Cuando veo código generado por IA que no ha sido apropiadamente propiedad, suelen aparecer los mismos problemas. Cambios demasiado grandes porque el modelo generó más de lo necesario. Paquetes agregados sin justificación clara. Tests que parecen escritos para satisfacer una herramienta de cobertura en lugar de para atrapar bugs reales. Boilerplate que existe porque el modelo默认a a scaffolding en vez de a la simplicidad.

Ninguno de estos problemas es culpa de la IA. Son el resultado de un autor que tratò el output generado como progreso en lugar de como materia prima.

El problema de la revisión que nadie menciona

Algo que me quita el sueño: el código generado por IA cambia la ecuación de la revisión.

Cuando un engineer escribe código, generalmente hay un rastro de decisiones. Podrías no estar de acuerdo con sus elecciones, pero al menos hay decisiones. Puedes preguntar por qué usó esa abstracción, por qué la validación vive ahí, por qué eligió esa librería. Las respuestas podrían ser "no lo pensé" o "me parecía razonable en el momento", pero al menos hay una persona a quien preguntar.

Con código generado por IA, algunas de esas "decisiones" no son decisiones en absoluto. Son completaciones. El modelo eligió un patrón porque era estadísticamente probable, no porque fuera el ajuste correcto para tu problema. Y si el autor no ha convertido esa completación en trabajo propio, la revisión se convierte en un problema mucho más difícil.

No puedes preguntarle al modelo por qué eligió ese enfoque. No puedes preguntarle al autor por qué tomó esa decisión si realmente no lo sabe. Entonces la revisión o bien detecta problemas a través de un trial and error doloroso, o no sucede en absoluto.

Por eso creo que la habilidad más importante en la era del desarrollo asistido por IA no es hacer prompts. Es la capacidad de tomar output generado y convertirlo en código que entiendas lo suficientemente a fondo como para poseerlo, explicarlo y mantenerlo.

Qué significa esto para tu equipo

Si estás construyendo un prototipo para probar una idea, vibe coding es un enfoque legítimo. La velocidad de aprendizaje importa cuando todavía estás validando supuestos. Usa las herramientas, muévete rápido, construye algo para mostrarle a la gente.

Pero si ese prototipo va a convertirse en un producto real, en algún punto el código generado necesita pasar por el filtro de alguien que piensa como engineer. No para gatekeepear. No para ralentizar. Sino para asegurar que lo que se envía es código que un equipo puede entender, mantener y confiar cuando las cosas fallan a las 2 AM.

En NameOcean vemos este patrón constantemente. Startups que se mueven rápido con herramientas de IA para validar sus ideas, y luego golpean un muro cuando necesitan escalar. Las buenas traen ayuda de engineering en ese punto. Las malas siguen apilando features sobre un codebase que nadie realmente entiende.

El objetivo no es evitar el desarrollo asistido por IA. El objetivo es ser honestos sobre dónde empieza el trabajo y dónde termina. La IA puede generar código. Tú tienes que construir software.

La línea de fondo

Vibe coding es un punto de partida fantástico. Es una forma de probar ideas rápido, aprender qué es posible y pasar de concepto a algo tangible sin meses de desarrollo tradicional.

Pero la ingeniería de software es sobre el ciclo de vida completo. Es sobre código que tu equipo puede revisar, mantener y confiar cuando las cosas fallan a las 2 AM. Es sobre cambios lo suficientemente acotados para entender y hacer rollback si es necesario. Es sobre tomar responsabilidad por las decisiones, incluso cuando esas decisiones fueron informadas por sugerencias de IA.

Los mejores developers que conozco usan herramientas de IA extensivamente. Solo lo hacen con los ojos abiertos. Saben que el código generado es materia prima, no producto terminado. Y saben que en algún punto, alguien tiene que hacer el trabajo de ingeniería que hace la diferencia entre un demo cool y software que realmente puedes enviar.

Así que sí, vibe code tranquilo. Construí rápido, experimentá freely, usá todas las herramientas a tu disposición. Solo sabé cuándo es el momento de pasar de vibe a engineering. Tu yo del futuro, y tu equipo del futuro, te lo van a agradecer.