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

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

Dónde se equivoca el agente

El caso más revelador es la auditoría de un sistema Java antiguo con 17 módulos y sin documentación actualizada. El agente elaboró un mapa de arquitectura convincente: dependencias, interfaces, descripciones de componentes, relaciones entre servicios. Casi todo parecía exacto hasta que llegó a una vieja capa proxy que quedó tras la migración a una cola de mensajes. En el código, esa capa parecía una llamada HTTP corriente, y el agente la describió con seguridad como una pieza normal de la arquitectura. Para quienes habían trabajado antes en el proyecto, sin embargo, era un parche temporal y un vestigio de una solución anterior.

Aquí aparece la diferencia clave entre un agente y un desarrollador. Una persona suele notar una construcción extraña, señala el riesgo y va a preguntar al equipo o al autor del código por la historia de esa decisión. El agente suele completar por su cuenta la explicación que falta: formula una causa lógica, se inventa un propósito y no separa el hecho del repositorio de su propia reconstrucción. Cuanto más pulido parece el resultado, más probable es que el error pase la revisión y que se tome una hipótesis por verdad arquitectónica.

«La diferencia entre un programador y un agente no está en la velocidad».

Cinco conclusiones clave

De este caso el autor extrae cinco patrones recurrentes que, según su experiencia, aparecen en casi cualquier proyecto con agentes de IA para desarrollo. No afectan solo a la calidad del código, sino también a cómo el agente percibe la tarea, el contexto y las consecuencias de sus decisiones. En conjunto, explican por qué la misma herramienta puede acelerar mucho el desarrollo en tareas simples y generar con la misma rapidez problemas ocultos en las complejas.

• El agente no tiene memoria del proyecto: si la historia de las decisiones no se le transmite de forma explícita, para él no existe.
• Ejecuta la tarea de manera literal y no completa el contexto de negocio como lo hace un desarrollador con experiencia.
• Una sola suposición errónea se multiplica rápidamente por una serie de archivos y utilidades parecidos.
• El agente no ve la arquitectura más allá del prompt actual y elige el camino localmente más cómodo.
• No vive con las consecuencias de sus decisiones, así que la responsabilidad por el lanzamiento y los datos sigue siendo de la persona.

La conclusión práctica de estas observaciones es estricta: la tarea debe incluir no solo el objetivo y los criterios de aceptación, sino también escenarios negativos, restricciones, prohibiciones y límites de arquitectura. Si se dejan vacíos, el agente los llenará por sí mismo. Por eso la puerta de entrada de calidad de SENAR exige reunir primero la especificación y el contexto, y solo después lanzar la generación. La velocidad es útil aquí únicamente cuando una persona ha reducido de antemano el margen para las suposiciones.

El precio de la automatización rápida

El código rápido de un agente crea otro tipo de deuda: la cognitiva. Un módulo puede funcionar, las pruebas pasan y el linter no protesta, pero el equipo no entiende por qué está construido así ni qué decisiones lleva incrustadas. El autor cita el ejemplo de un módulo de caché de unas 500 líneas: un par de semanas después hubo que cambiar la estrategia de eliminación de datos obsoletos, y en lugar de una hora de trabajo se necesitó medio día para reconstruir una lógica que ninguna persona había decidido ni registrado de forma explícita.

Para no enmascarar fallos sistémicos con correcciones manuales, el autor propone medir el MIR: la proporción de tareas en las que, tras el trabajo del agente, hubo que meter mano al código. En proyectos maduros, esta métrica se mantuvo en torno al 5–15%; al arrancar uno nuevo, en torno al 20%. El sentido no es tener un informe bonito, sino obtener retroalimentación: si las correcciones manuales se repiten, el problema no está en un archivo, sino en el contexto, la especificación, los límites de arquitectura o el modelo elegido.

El nuevo papel del ingeniero

Por ello cambia también el papel de la persona en el equipo. Según el autor, ahora hasta el 60% del tiempo se va en plantear tareas, reunir contexto y tomar decisiones de arquitectura, alrededor del 30% en revisar resultados y otro 10% en configurar herramientas, métricas y el propio proceso. Escribir código deja de ser el centro del trabajo: el ingeniero se parece cada vez más a quien fija tolerancias, descompone un sistema complejo y comprueba si la salida pulida del agente se ha convertido en un error caro.

Una conclusión es contundente: todo lo que no está escrito no existe para el agente. Si los límites de los módulos, las convenciones de la API, los motivos de decisiones pasadas y las dependencias prohibidas viven solo en la cabeza del líder técnico, el agente casi seguro las vulnerará, porque técnicamente el import puede funcionar y las pruebas pueden pasar. Por eso la documentación en el modelo SENAR no sirve para rendir cuentas, sino como interfaz de trabajo entre la persona, el agente y los futuros desarrolladores que tendrán que mantener este código.

Qué significa

Para los equipos que adoptan en serio agentes de IA en el desarrollo, la noticia principal no es que aceleren el trabajo. Importa mucho más otra cosa: sin una especificación estricta, sin registrar las decisiones y sin verificación constante, la velocidad se convierte pronto en deuda cognitiva, y el ingeniero pasa de autor del código a editor, arquitecto y controlador de calidad.