Que funcione no significa que esté bien construido
Hoy, con IA, una persona puede transformar una idea en una aplicación funcional en muy poco tiempo. Eso abre posibilidades enormes, permite probar más ideas, construir prototipos mucho más rápido. Pero esta nueva capacidad trae una confusión , una cosa es lograr que una aplicación haga lo que necesitamos y otra muy distinta es construir software preparado para mantenerse, operar, crecer y cambiar.
Hoy podés describir una aplicación, abrir una herramienta de IA y empezar a construir.
Un login.
Un dashboard.
Una API.
Una integración.
En pocas horas podés tener algo que hace lo que necesitabas.
Y funciona.
El problema es que en software, que algo funcione es solamente una parte de la historia.
La parte que vemos
Cuando pensamos una aplicación solemos pensar en lo funcional.
El usuario tiene que poder registrarse.
Tiene que cargar un archivo.
El sistema tiene que procesarlo.
Tiene que mostrar un resultado.
Tiene que enviar una notificación.
Son cosas fáciles de describir porque son visibles.
Podemos probarlas.
Hacemos clic, cargamos el archivo y vemos si aparece el resultado.
Con IA y vibe coding, traducir ese tipo de requerimientos a código se volvió increíblemente rápido.
Le explicás qué necesitás.
La herramienta genera.
Probás.
Corregís.
Volvés a generar.
Hasta que funciona.
Pero hay otra parte del software que casi nunca aparece en el primer prompt.
Lo que no se ve en una demo
¿Qué pasa si entran mil usuarios al mismo tiempo?
¿Qué pasa si una API externa tarda treinta segundos en responder?
¿Qué pasa si procesamos dos veces el mismo evento?
¿Qué pasa si un deploy falla?
¿Qué pasa si necesitás saber por qué una operación salió mal hace tres días?
¿Qué puede ver cada usuario?
¿Cómo rotás una credencial?
¿Cómo recuperás los datos?
¿Qué tan fácil es cambiar una parte del sistema sin romper otras cinco?
Nada de eso suele aparecer en la demo.
Hasta que aparece.
Y cuando aparece, la aplicación puede seguir haciendo exactamente lo que pediste funcionalmente.
El problema es que no fue diseñada para operar, crecer o cambiar.
Lo funcional es solamente una parte del software
En ingeniería de software hace tiempo que existe esta separación.
Por un lado están los requisitos funcionales: qué hace el sistema.
Por otro, todo lo que define cómo tiene que comportarse mientras lo hace.
Performance.
Seguridad.
Disponibilidad.
Escalabilidad.
Observabilidad.
Mantenibilidad.
Recuperación ante errores.
No siempre todos importan de la misma manera.
Una herramienta interna para cinco personas no necesita la misma arquitectura que una plataforma que procesa miles de operaciones.
Y ese es justamente el punto.
Hay que saber que esas decisiones existen para poder decidir cuáles importan.
La IA también nos permite fallar más rápido
Hay algo muy valioso en todo esto.
La IA redujo muchísimo el costo de probar una idea.
Podemos construir una primera versión.
Ponerla frente a usuarios.
Descubrir que entendimos mal el problema.
Tirar parte de lo construido.
Y volver a empezar.
Todo mucho más rápido que antes.
La IA puede ayudarnos a fallar rápido.
Y fallar rápido, cuando el objetivo es aprender, es una ventaja enorme.
El problema es no distinguir cuándo estamos experimentando y cuándo estamos construyendo algo que tiene que vivir en producción.
Un prototipo puede estar lleno de decisiones temporales.
Puede repetir código.
Puede tener procesos manuales.
Puede soportar diez usuarios.
Puede romperse y volver a levantarse.
Está bien.
Su objetivo es responder una pregunta.
¿Esto resuelve un problema real?
Pero cuando la respuesta es sí, aparece una nueva pregunta:
¿Cómo construimos esto para que pueda sobrevivir?
El error es asumir que porque el prototipo funcionó, el trabajo de ingeniería ya está terminado.
A veces recién está empezando.
El problema no es el vibe coding
El problema no es construir con IA.
Nosotros usamos IA para desarrollar software y cada vez ocupa más lugar en nuestra forma de trabajar.
El problema aparece cuando confundimos poder generar una aplicación con saber construir un sistema.
La IA puede escribir un retry.
Puede agregar un cache.
Puede crear logs.
Puede configurar una cola.
Puede proponer una arquitectura.
Pero primero alguien tiene que entender por qué necesita un retry.
Qué debería cachear.
Qué necesita observar.
Dónde puede perder un evento.
Qué parte del sistema va a cambiar dentro de seis meses.
No podés pedir una solución para un problema que no sabés que existe.
Y muchas de las decisiones más importantes de un sistema son justamente sobre problemas que todavía no pasaron.
"Funciona en mi máquina", ahora en versión IA
Durante años los desarrolladores usamos casi como chiste la frase:
"Funciona en mi máquina."
Hoy quizás estamos construyendo una nueva versión del mismo problema.
"Funciona en la demo."
El flujo anda.
La interfaz se ve bien.
Los datos se guardan.
La IA hizo en dos días algo que antes llevaba semanas.
Perfecto.
Ahora viene la pregunta difícil:
¿Qué tiene que pasar para que esto siga funcionando cuando salga de la demo?
Ahí empieza otro tipo de trabajo.
Pensar fallos.
Pensar carga.
Pensar cambios.
Pensar seguridad.
Pensar operación.
En definitiva, pensar el sistema.
Generar código más rápido cambia dónde está el problema
La IA bajó la barrera para crear software.
Y eso es algo bueno.
Hoy más personas pueden transformar una idea en una aplicación.
Equipos chicos pueden probar soluciones mucho más rápido.
Un prototipo puede existir en días en lugar de meses.
Podemos probar más ideas.
Descartar antes las malas.
Y equivocarnos mucho más barato.
Pero bajar la barrera para escribir código no elimina la ingeniería de software.
De hecho, puede hacerla más importante.
Porque cuando generar código deja de ser la parte lenta, el cuello de botella pasa a ser el criterio.
Saber qué construir.
Saber qué estamos intentando aprender.
Saber cuándo tirar lo construido.
Saber qué puede fallar.
Y saber cuándo un prototipo dejó de ser un experimento y se convirtió en un sistema del que alguien depende.
La IA puede ayudarte a construir prácticamente cualquiera de esas piezas.
También puede ayudarte a probar una idea y descubrir rápidamente que estabas equivocado.
Eso es parte de su valor.
Pero alguien tiene que saber qué preguntas hacer.
Qué riesgos mirar.
Qué decisiones pueden esperar.
Y cuáles no.
Que una aplicación haga lo que necesitás es el primer paso.
A veces alcanza para aprender y descartarla.
Otras veces es el comienzo de algo que tiene que mantenerse, operar y crecer durante años.
Saber distinguir una cosa de la otra también es ingeniería de software.
Y generar más código, incluso mucho más rápido, no reemplaza saber diseñar sistemas.
Marcos Reynoso
Founder – The41