Es un poco como ser director de cine. Un director no pasa su día preocupándose por la distancia focal del lente o el vataje exacto de la luz principal. Describe el ambiente, el ritmo y el encuadre, y luego delega la ejecución técnica a un equipo que realmente sabe manejar el equipo. El director se centra en la visión; el equipo, en la implementación. Si el director intenta microgestionar al encargado de iluminación, la producción se ralentiza hasta detenerse y todos se ponen de mal humor.
Por mucho tiempo, la ingeniería de software ha sido lo contrario. Hemos sido el equipo, pasando el 90% de nuestro tiempo luchando con la sintaxis, persiguiendo punteros nulos y discutiendo sobre la indentación. El reciente artículo de Terry Tao sobre el uso de agentes de codificación modernos sugiere que finalmente estamos pasando a la silla del director.
La idea central es que ahora podemos tratar las especificaciones de alto nivel como el artefacto principal. En lugar de escribir código, describimos el comportamiento de la aplicación—ya sea desde cero o haciendo referencia a un software antiguo—y dejamos que un bucle de agentes se encargue del trabajo pesado. Esto no es solo "Copilot para autocompletar" o un generador de fragmentos elegante. Es el cambio hacia agentes que pueden planificar, ejecutar, probar y autocorregirse. (Y todos hemos visto las llamadas a API alucinadas que suelen romper este bucle).
La fricción sigue ahí, por supuesto. La latencia de un bucle de agentes de múltiples pasos es desesperante comparada con un IDE local, y los costos de tokens para una refactorización masiva pueden empezar a parecerse a una hipoteca mensual si no tienes cuidado. Pasas cinco minutos mirando un spinner de carga solo para que el agente te diga que olvidó instalar una dependencia. Pero el intercambio se está volviendo aceptable. Nos estamos alejando del "cómo" y nos estamos acercando al "qué".
Aquí es donde el optimismo choca con un muro. Hay una diferencia enorme entre un agente que puede generar un prototipo funcional y uno que puede mantener un sistema en producción.
El peligro es que estamos creando una generación de "arquitectos" que no tienen idea de cómo se sostiene realmente el edificio. Si usas un agente para construir una aplicación compleja y simplemente "aceptas" la salida porque pasa las pruebas básicas, en realidad no has construido un producto. Has construido una caja negra que no entiendes. ¿Quién querría realmente mantener un archivo de 10.000 líneas que no escribió?
Cuando el agente falle (y lo hará), la persona en la silla del director estará completamente indefensa. No tendrá la intuición para saber por qué ocurre una fuga de memoria específica o por qué el modelo de concurrencia se está colapsando bajo carga. Simplemente seguirán pidiéndole al agente que lo "arregle", lo que usualmente resulta en que el agente añada otra capa de abstracción que hace que el error original sea aún más difícil de encontrar. Es el equivalente en software de intentar arreglar una tubería con fugas simplemente pintando encima las manchas de agua.
O quizás el conjunto de habilidades simplemente cambia. Tal vez la "implementación" que estamos perdiendo es solo la parte aburrida, y la habilidad real ahora es la precisión de la especificación. Si no puedes describir un sistema con rigor matemático, solo estás adivinando con una herramienta más cara. Básicamente estamos intercambiando la habilidad de escribir código por la habilidad de escribir un prompt perfecto, lo cual es un poco como intercambiar un bisturí por un megáfono.
La era del "programador" ha terminado; la era del "arquitecto" ha llegado.
Si esta tendencia se mantiene, veremos el primer código empresarial importante refactorizado completamente por un agente sin que un humano escriba una sola línea de C++ para Q4. Eso suena eficiente hasta que te das cuenta de que la persona que supervisa el proceso podría no saber realmente si el código resultante es una obra maestra o una bomba de tiempo. Estamos intercambiando la comprensión profunda por la velocidad, y en el mundo de la ingeniería de sistemas, eso suele ser un mal intercambio.
