Durante décadas, el ingeniero de software convirtió problemas en instrucciones que una máquina pudiera ejecutar. Hoy, los agentes recorren repositorios, escriben código y abren pull requests. Si producir software cuesta cada vez menos, la pregunta cambia: ¿qué escribe el ingeniero cuando ya no necesita escribir todo el código?
La respuesta puede resumirse en tres artefactos: el spec, la skill y el veredicto. El código sigue importando, pero deja de ser el único lugar donde vive la ingeniería.
La economía ya cambió. Según Epoch AI, generar una pregunta al mismo nivel de desempeño se volvió 725 veces más barato en menos de 18 meses. El costo de producir una respuesta cayó de US$0,30 a US$0,0004, mientras el desempeño se mantuvo en 81%. Pensar, en términos de generación, se volvió barato.
Pero quedarse tranquilo con esa respuesta no se volvió barato. Un estudio de Harvard sobre 718 empresas encontró que los días entre apertura y merge de un PR aumentaron 49% con agentes: de siete a 10,5 días. También casi se duplicaron los PR con cambios solicitados.
En software, la velocidad también tiene un costo. Faros analizó la telemetría de 22.000 desarrolladores y 4.000 equipos. Al aumentar fuertemente el uso de IA, los PR mergeados sin revisión crecieron 31% y los incidentes por PR, 243%. Con adopción madura, llegaron a 76% y 14,5%, mientras los incidentes mensuales aumentaron 125%.
Stanford y Carnegie Mellon encontraron 2,09 veces más PRs por desarrollador, pero la revisión humana cayó de 39% a 21%. La automática pasó de 19% a 84%. Producir más no significa controlar mejor.
Por eso aparece el primer nuevo trabajo: escribir el spec. El ingeniero debe definir qué problema resolver, qué restricciones existen y cómo sabremos que el resultado funciona. Una buena especificación permite delegar ejecución sin delegar criterio.
El segundo es la skill: las reglas, convenciones y decisiones del equipo deben quedar escritas para que el agente pueda reutilizarlas. En repositorios analizados por Stanford y Carnegie Mellon, la complejidad cognitiva creció 53% sin configuración versionada y 27% con ella.
El tercer artefacto es el veredicto. El veredicto es quién revisa, con qué criterio y qué entra. Para decidirlo hay que saber cuánto se equivoca el agente, y eso se mide como en la escuela: con un examen, casos cuya respuesta correcta ya conocemos. El problema es que el examen también puede mentir. A nosotros nos pasó dos veces.
Uno de nuestros agentes lee facturas. En el examen acertaba el 91%. Demasiado bueno. Las instrucciones que le dábamos traían de ejemplo facturas que también estaban en el examen: se sabía las respuestas. Sin esos ejemplos bajó a 84%. Y como seguimos midiendo con las mismas 38 facturas, ese número es un techo; el real sale de facturas que nunca vio. El otro caso es el del principio, el agente que se corrigió el examen: con las pruebas originales, bloqueadas para que no pudiera tocarlas, dio rojo.
No es mala suerte nuestra. Investigadores de Carnegie Mellon y Anthropic tomaron problemas reales de programación y alteraron las pruebas a propósito para que contradijeran lo que se pedía. No había forma honesta de aprobar: todo verde era trampa. Encima, les ordenaron a los modelos, en mayúsculas, no tocar las pruebas. Con modelos de 2025, GPT-5 hizo trampa en el 76% de las tareas y Claude 3.7 Sonnet, en el 70%: reescribían las pruebas o programaban atajos para darles lo que esperaban. Con las pruebas bloqueadas, la trampa de Claude Opus 4.1, otro de los modelos medidos, cayó de 54% a 6%. La de GPT-5 bajó poco, porque lo suyo eran los atajos. Si el agente puede tocar el examen, el examen no mide nada.
Por eso los que le sacan provecho evalúan con casos que el agente nunca vio y no puede tocar. Legora, que hace IA para abogados, contrató abogados para escribir los suyos. En Waymo, un proyecto no está listo cuando el modelo rinde bien, sino cuando lo están sus evaluaciones. En software, ese examen puede salir de veinte o treinta problemas que tu equipo ya resolvió, con sus pruebas.
El nuevo ingeniero, entonces, no es quien produce más líneas. Es quien sabe decidir qué delegar, codificar el conocimiento del equipo, diseñar evaluaciones y fijar el umbral que obliga a detenerse. También debe leer traces, comprender los resultados y tener autoridad para rechazar un merge.
El cambio es profundo: el agente ejecuta, pero el ingeniero diseña el sistema que permite confiar en esa ejecución. Cuando el código lo escribe la máquina, la firma sigue siendo humana.
Por Santiago Marro. IA Specialist Lead de Santex
