Senar: por qué los agentes de AI no reemplazan a los programadores y cambian el proceso de desarrollo

En la segunda parte de una serie sobre SENAR, el autor examina no la calidad de los modelos, sino el propio proceso de desarrollo con agentes de IA. La idea principal es simple: un agente puede escribir código más rápido que un humano, pero no se comporta como un ingeniero cuando se encuentra con una brecha de conocimiento.

Dónde falla el agente

El caso más revelador es una auditoría de un antiguo sistema Java con 17 módulos y sin documentación actualizada. El agente compiló un mapa arquitectónico convincente: dependencias, interfaces, descripciones de componentes y relaciones entre servicios. Todo parecía preciso hasta que llegó a una antigua capa proxy que quedó después de migrar a una cola de mensajes.

En el código, esta capa parecía una llamada HTTP común, y el agente la describió con confianza como parte estándar de la arquitectura, aunque para las personas que habían trabajado en el proyecto antes era un parche temporal y un rastro de una solución antigua. Aquí es donde se manifiesta la diferencia clave entre un agente y un desarrollador. Una persona típicamente nota una construcción extraña, marca el riesgo e intenta aclarar el historial de la decisión con el equipo o con el autor del código.

Un agente a menudo reconstruye la explicación faltante por sí mismo: formula una razón lógica, inventa un propósito y no distingue entre hechos del repositorio y su propia reconstrucción. Cuanto más pulido se vea tal resultado, mayor es la posibilidad de pasar por alto un error en la revisión y aceptar una hipótesis como verdad arquitectónica.

"La diferencia entre un programador y un agente no es la velocidad."

Cinco conclusiones clave

A partir de este caso, el autor extrae cinco patrones recurrentes que, según su experiencia, surgen en casi cualquier proyecto con agentes de IA para desarrollo. Afectan no solo la calidad del código, sino también cómo el agente percibe tareas, contexto y consecuencias de sus decisiones. En conjunto, esto explica por qué la misma herramienta puede acelerar drásticamente el desarrollo en tareas simples y crear rápidamente problemas ocultos en tareas complejas.

• El agente no tiene memoria del proyecto: si el historial de decisiones no se transmite explícitamente, no existe para el agente.
• Ejecuta la tarea literalmente y no rellena el contexto comercial como lo haría un desarrollador experimentado.
• Un supuesto erróneo se multiplica rápidamente en una serie de archivos y utilidades similares.
• El agente no ve la arquitectura más allá del prompt actual y elige el camino localmente conveniente.
• No vive con las consecuencias de sus decisiones, por lo que la responsabilidad del lanzamiento y los datos permanece con los humanos.

La conclusión práctica de estas observaciones es dura: la tarea debe contener no solo objetivos y criterios de aceptación, sino también escenarios negativos, restricciones, prohibiciones y límites arquitectónicos. Si dejas vacíos, el agente los llenará. Por eso la puerta de entrada de calidad en SENAR requiere primero reunir especificación y contexto, luego iniciar la generación. La velocidad es útil solo cuando el espacio para especulación se reduce de antemano por un humano.

El costo de la automatización rápida

El código rápido de un agente crea un tipo diferente de deuda—cognitiva. Un módulo puede funcionar, las pruebas pasan, el linter está silencioso, pero el equipo no entiende por qué está estructurado así y qué decisiones están codificadas en él. El autor da un ejemplo de un módulo de caché de aproximadamente 500 líneas: después de un par de semanas, fue necesario cambiar la estrategia de purga de datos obsoletos, y en lugar de una hora para retrabajar, se gastó medio día restaurando la lógica que nadie había aceptado explícitamente ni registrado.

Para evitar enmascarar fallos del sistema con correcciones manuales, el autor propone calcular MIR—la proporción de tareas donde fueron necesarias ediciones manuales del código después del trabajo del agente. En proyectos maduros, esta métrica se mantuvo alrededor del 5–15%, al inicio de uno nuevo—alrededor del 20%. El punto no es un informe bonito, sino retroalimentación: si las correcciones manuales se repiten, el problema no está en un archivo sino en contexto, especificación, límites arquitectónicos o en el modelo elegido.

El nuevo papel del ingeniero

Esto cambia el papel de los humanos en el equipo. Según el autor, hasta el 60% del tiempo ahora va a especificación de tareas, recopilación de contexto y decisiones arquitectónicas, aproximadamente 30% a verificar resultados y otro 10% a ajustar herramientas, métricas y el proceso en sí. Escribir código deja de ser el centro del trabajo: los ingenieros cada vez más se parecen a quienes establecen tolerancias, descomponen sistemas complejos y verifican que el resultado pulido del agente no se haya convertido en un error costoso.

Una conclusión separada suena dura: todo lo no escrito no existe para el agente. Si los límites de módulos, convenciones de API, razones de decisiones pasadas y dependencias prohibidas viven solo en la cabeza de un tech lead, el agente casi seguramente las violará, porque técnicamente la importación puede funcionar y las pruebas pueden pasar. Por eso la documentación en el modelo SENAR es necesaria no para cumplimiento normativo, sino como una interfaz de trabajo entre humanos, agentes y futuros desarrolladores que tendrán que mantener este código.

Lo que significa

Para equipos que están adoptando seriamente agentes de IA en el desarrollo, la gran noticia no es que aceleren el desarrollo. Lo que importa mucho más es esto: sin especificación rigurosa, registro de decisiones y verificación constante, la velocidad rápidamente se convierte en deuda cognitiva, y el ingeniero cambia de autor de código a editor, arquitecto y controlador de calidad.