Software engineering agents

En el Radar compartido: Trial (valoración de la edición aportada).

Cómo funciona

Un agente itera entre modelo, herramientas y evidencia. Puede inspeccionar archivos, proponer un plan, editar y reaccionar a errores de compilación o pruebas.

Ejemplo de uso

Entregar un bug con reproducción, alcance y criterios de aceptación. Permitir cambios locales y exigir pruebas relevantes y un diff revisable antes de integrar.

Niveles de autonomía

Nivel	Ejemplo	Supervisión
Asistente	Autocompletado, preguntas sobre el código	Cada sugerencia
Agente supervisado	Edita varios archivos y ejecuta pruebas en local	Aprobación de acciones y del diff
Agente asíncrono	Recibe un ticket y abre un PR desde un entorno remoto	Revisión del PR
Flota de agentes	Migraciones en decenas de repositorios en paralelo	Revisión por muestreo y métricas

Subir de nivel exige más inversión en verificación automática: pruebas, linters, sandbox y feedback sensors.

El bucle del agente

Tarea → explorar código → plan → editar → ejecutar (build, tests, lint)
          ▲                                     │
          └──────── leer errores y corregir ────┘
                                  → diff + resumen para revisión humana

La calidad del resultado depende sobre todo de la calidad del feedback: un agente sin pruebas fiables solo puede adivinar si acertó.

Qué preparar en el repositorio

• Instrucciones del proyecto (AGENTS.md, instrucciones compartidas) con comandos de build y test.
• Pruebas rápidas que se puedan ejecutar de forma aislada.
• Entorno reproducible (Dev Containers, mise).
• Skills para procedimientos repetidos (Agent Skills).
• Ejecución aislada (sandboxed execution).

Medir el impacto

Métrica	Por qué
PR de agentes integrados vs. abiertos	Proporción de trabajo útil
Tiempo de revisión por PR	El coste se traslada a los revisores
Change fail rate de esos cambios	Calidad en producción (DORA)
Retrabajo a 30 días	Código que hubo que rehacer
Coste por tarea completada	Tokens y tiempo de cómputo

Los benchmarks públicos como SWE-bench son útiles para comparar modelos, pero no predicen el rendimiento en tu base de código: evalúa con tareas propias.

Rol del líder

Define qué tipo de tareas se delegan, quién revisa y con qué criterios, y cómo se protege el aprendizaje de las personas que se incorporan. Un equipo que solo revisa código generado pierde, con el tiempo, el conocimiento profundo del sistema.

Criterios de implementación

Acotar tareas, aislar ejecución y controlar acciones externas. Evaluar mantenibilidad y defectos posteriores además del tiempo ahorrado; evitar aceptar pruebas sin aserciones útiles.