El cuello de botella nunca fue el código: lo que los agentes de IA revelan sobre cómo trabajamos
Los agentes de codificación han reducido drásticamente el coste de escribir código. Pero el verdadero coste del software siempre estuvo en otro sitio: en las negociaciones, las especificaciones y el contexto compartido. Y eso no se ha vuelto más barato.
Durante décadas, hemos asumido que el código era el recurso escaso del desarrollo de software. La automatización prometía multiplicar lo que un programador podía producir, reduciendo costes y acelerando entregas. Los agentes de IA han cumplido esa promesa de forma espectacular: tareas que antes requerían días ahora se completan en horas.
Y sin embargo, algo no cuadra. Los equipos que han adoptado agentes de codificación no están viendo las ganancias de productividad masivas que esperaban. ¿Por qué?
La respuesta, según un análisis reciente de dottxt, está en lo que siempre hemos ignorado: el código es solo el residuo de conversaciones más difíciles. Y esas conversaciones no se han vuelto más baratas.
El código fue siempre el residuo
Fred Brooks lo escribió en The Mythical Man-Month en 1975. Gerald Weinberg lo observó en The Psychology of Computer Programming en 1971. El software no es el código: el código es lo que queda después de que un grupo de humanos se pone de acuerdo sobre lo que el sistema debe hacer.
Durante cincuenta años, ese residuo fue lo bastante caro como para ocupar toda nuestra atención. Velocidad de escritura, elección de lenguaje, plugins de IDE, tooling de code review — todo estaba diseñado para reducir el coste del código. Con los agentes de IA, ese coste se ha desplomado lo suficiente como para ver lo que hay debajo: personas intentando ponerse de acuerdo.
La hoja de especificaciones es el nuevo límite
Cuando los agentes implementan a velocidad de ritmo, lo que ralentiza a los equipos ya no son los programadores esperando a otros programadores. Son los managers esperando la siguiente especificación lo bastante precisa para que un agente pueda recogerla y ejecutar.
Roadmap, por escrito. Criterios de aceptación, por escrito. El "lo que realmente queremos" forzado a precisión, ya sea mediante un suite de tests, un ticket o un diseño documentado. La velocidad ha dejado de estar en el código y ha pasado a estar en la negociación.
Features se implementan a velocidad vertiginosa, y los ingenieros no están esperando a otros ingenieros. Están esperando a la siguiente especificación bien formada. El cuello de botella se ha desplazado de las personas que escriben código a las personas que decidan qué código debería existir.
Paradoja de Jevons: más código, más features, más ruido
Cuando algo se abarata, tendemos a usarlo más, no menos. Cuando el código se vuelve 10x más barato de escribir, no gastamos el mismo esfuerzo en los mismos resultados. Gastamos el mismo esfuerzo en resultados que antes no merecían la pena. Prototipos que habrían sido "no merece la pena el tiempo" hace tres meses se montan en una tarde.
El resultado: cada producto vibe-coded con 12 features está a 11 features de ser genial. Los equipos pueden absorber features solo a un cierto ritmo, y ese ritmo se mantiene más o menos constante tanto si el equipo shippea diez features como si shippea cincuenta.
El contexto es oro
Toda esa negociación funciona sobre algo que rara vez pensamos: el contexto compartido. Es la comprensión común de qué estamos construyendo, por qué importa, qué se ha intentado, quién decidió qué, qué es estructural y qué es vestigial. Los humanos en un equipo lo acumulan por ósmosis: por estar en la sala, por leer el mismo canal de Slack, por hacer debug del mismo outage a las dos de la mañana.
Los agentes de IA no tienen ese contexto. Pueden escribir código excelente en un contexto mal definido — y eso es peligroso. Un código perfecto para un problema mal entendido sigue siendo código que no debería existir.
¿Qué significa esto para los equipos de seguridad?
En ciberseguridad, donde los errores pueden tener consecuencias catastróficas, este fenómeno es especialmente relevante. Un agente de IA que escribe código de seguridad sin entender el modelo de amenazas completo puede generar falsa sensación de protección. El código pasa los tests, la implementación parece completa, pero las vulnerabilidades persisten en los bordes que nadie especificó.
La implicancia directa: la figura del especificador técnico se vuelve más crítica, no menos. Saber qué código necesita existir — y por qué — es el trabajo que los agentes no pueden hacer (aún). La persona que puede traducir un modelo de amenazas a criterios de aceptación precisos es el activo más valioso de un equipo de seguridad que usa agentes de IA.
Conclusión
Los agentes de codificación no han eliminado el cuello de botella del desarrollo de software. Lo han revelado. Durante años culpamos al código cuando el verdadero problema era la coordinación. Ahora que el código es barato, no podemos seguir escondiéndonos detrás de él.
La pregunta ya no es ¿cuánto código podemos generar? Es ¿sabemos realmente qué estamos construyendo?