Afirmar que "programar está resuelto" es no entender la ingeniería de software
Cada pocas semanas, alguien declara que programar está resuelto. Si se refieren a convertir un problema bien especificado en código que funciona, tienen parte de razón. Pero, ¿fue alguna vez escribir código ejecutable el problema completo? La confusión entre "escribir código" y "construir software" se ha vuelto más visible que nunca con la irrupción de la inteligencia artificial generativa.
Los modelos de lenguaje han transformado la ingeniería de software en la medida en que los procesadores de texto transformaron el periodismo: hicieron más fácil producir el resultado. Pedirle a una IA que construya una API REST o implemente un componente de React es ahora cuestión de minutos, cuando antes tomaba horas. Resultado notable, sí. Pero las organizaciones necesitan respuesta a una pregunta más difícil: ¿puede la IA resolver los problemas que realmente tienen?
La trampa de las aplicaciones demo
La forma más sencilla de convencerse de que programar está resuelto es construir una aplicación de demostración: una lista de tareas, una app del clima, un panel personal. Los requisitos son claros, apenas hay restricciones y la arquitectura se inventa sobre la marcha. Se construye sobre un lienzo en blanco.
Ahora compárese con una organización madura. La tarea puede sonar a "agregar un botón", pero antes de escribir una sola línea de código hay que responder: ¿qué servicio posee esta funcionalidad? ¿Existe ya una API que deberíamos usar? ¿Por qué no se implementó antes? ¿Qué requisitos de seguridad aplican? ¿Qué patrones arquitectónicos son aceptables? ¿Qué equipo es dueño de esta área? ¿Cómo afectará esto a los sistemas downstream? ¿Qué restricciones de negocio estamos optimizando?
¿Cuántas de estas preguntas tratan sobre escribir código? Muy pocas. La mayoría requieren entender la organización. Por eso, el mismo modelo que se siente mágico en un proyecto de fin de semana puede sentirse meramente útil dentro de una empresa. El problema de programación es similar; el entorno lo hace más difícil.
Confundimos el cuello de botella con la disciplina
Durante décadas, escribir código fue una de las partes más costosas del desarrollo de software, y comenzamos a equiparar ingeniería de software con implementación. La IA está abarató la implementación drásticamente y está moviendo el cuello de botella a otro lugar.
La automatización cambia lo que se vuelve escaso. La ingeniería de software siempre ha involucrado varias capas de abstracción: objetivo de negocio ("¿qué problema tratamos de resolver?"), diseño de producto ("¿cómo deben los usuarios experimentar la solución?"), diseño de solución ("¿cómo debe el sistema realizar esa experiencia?") e implementación ("¿cómo lo expresamos en código?"). Los modelos actuales son excepcionalmente buenos en la capa inferior. El resto de la pila sigue ahí, y por fin estamos notando cuánto trabajo existe por encima de la implementación.
Las organizaciones funcionan con contexto
Lo que separa a los proyectos de hobby del software empresarial es el contexto, específicamente, el contexto organizacional. Una empresa ya conoce su arquitectura y su lenguaje de dominio. Tiene decisiones históricas, convenciones de ingeniería, fronteras de propiedad, requisitos de seguridad y prioridades de negocio. Años de construcción de software también han generado incontables supuestos que nadie escribió.
Este contexto influye en cada paso. La estrategia y la regulación moldean las decisiones de negocio. Las expectativas del cliente y los patrones UX establecidos moldean las decisiones de producto. Las plataformas y servicios existentes constriñen el diseño de la solución. Los estándares de código, frameworks y pipelines de despliegue guían la implementación. Una startup crea este contexto a medida que crece; una empresa hereda décadas de él. Pedirle a un modelo de lenguaje que construya una aplicación greenfield es fundamentalmente diferente a pedirle que extienda un sistema de producción con diez años de antigüedad. La parte difícil es tomar buenas decisiones dentro de un paisaje existente.
La IA está subiendo la escalera de abstracción
Cada generación de herramientas de desarrollo automatiza la capa más concreta de la ingeniería de software: los compiladores automatizaron el código máquina, los lenguajes de alto nivel automatizaron la programación de bajo nivel, los frameworks automatizaron la infraestructura, y ahora los modelos de lenguaje están automatizando la implementación. Cada avance se siente revolucionario hasta que la siguiente capa se convierte en el cuello de botella. Exactamente eso es lo que está ocurriendo hoy.
Cuanto mejor se vuelve la IA produciendo código, más se desplazan nuestras conversaciones hacia entender el problema de negocio y diseñar la experiencia correcta. Invertir más tiempo en encajar soluciones dentro de sistemas existentes y tomar decisiones acertadas dentro de las restricciones organizacionales.
Un problema, N soluciones correctas
Considérese un requisito de ingeniería relativamente ordinario: procesar eventos entrantes y actualizar algunos datos. Las primeras preguntas que surgen en una discusión técnica tienen poco que ver con la sintaxis: ¿procesamos síncronamente o los metemos en una cola? ¿Necesitamos procesamiento exactly-once o basta con at-least-once? ¿El sistema tolera consistencia eventual? ¿Qué ocurre cuando el procesamiento falla a mitad de camino? ¿Cuánto tráfico esperamos hoy y dentro de dos años? ¿Qué consecuencias tiene procesar un evento dos veces?
Esto se vuelve especialmente obvio cuando el software existe dentro de un negocio. Imaginemos dos empresas que piden a sus equipos construir lo que suena como exactamente la misma funcionalidad. Sus requisitos pueden parecer idénticos sobre el papel, pero: la primera tiene 500 usuarios mientras la otra tiene 20 millones; una puede tener tres ingenieros manteniendo el sistema y la otra 200; una puede requerir consistencia fuerte porque los errores tienen consecuencias financieras graves, mientras la otra acepta consistencia eventual a cambio de disponibilidad y throughput; una debe entregar en tres semanas y la otra espera que el sistema permanezca operativo durante quince años; una ya cuenta con Kafka, Kubernetes, PostgreSQL, infraestructura de observabilidad e ingenieros experimentados en sistemas distribuidos, mientras la otra tiene un único servidor de aplicaciones y una base PostgreSQL mantenida por cuatro desarrolladores. La solución técnicamente impresionante para una empresa podría ser una solución irresponsable para la otra.
La elección del lenguaje de programación importa porque afecta la fluidez del equipo, su rendimiento, el rendimiento del sistema, la seguridad, la mantenibilidad y las características operacionales, pero no responde las preguntas fundamentales. La parte difícil es elegir la arquitectura que represente el conjunto correcto de compromisos, y rara vez hay una respuesta universalmente correcta.
Código siempre fue el medio, no el objetivo
La IA puede escribir código. El error es asumir que escribir código fue alguna vez el trabajo completo. Las organizaciones pagan a ingenieros para resolver problemas de negocio. El código es el medio, no el resultado. Si por "programar está resuelto" se entiende traducir una especificación clara en software funcional, estamos cerca. Pero la ingeniería de software cubre toda la pila. Cada generación de herramientas abarata una capa y revela la siguiente. La IA está revelando aquello que la ingeniería de software fue siempre.