Evaluaciones continuas: el sistema operativo de los agentes de codificación

El viejo trato con los asistentes de programación era sencillo: te sugerían una línea, tú entrecerrabas los ojos y quizá nadie salía herido. Ahora los agentes de programación pueden llamar herramientas, modificar estado y avanzar a trompicones por un repositorio como un pasante muy seguro de sí mismo con acceso root. Las corazonadas ya no son una estrategia de QA. Son una vela aromática en un túnel de viento.

El enfoque útil de LetsLearnGenAI es que las evaluaciones se están convirtiendo en el sistema operativo de la programación asistida por IA. No la capa brillante de la app, no el fondo de pantalla de la tabla de clasificación, sino la superficie de control que les dice a los equipos qué cambió, qué se rompió y si el agente debería seguir trabajando o recibir una cajita de jugo y ser escoltado fuera del pipeline de compilación.

Anthropic da la definición aburrida que necesitamos

Anthropic define una evaluación como una prueba para un sistema de IA: se proporciona una entrada y luego se aplica lógica de calificación a la salida para medir el éxito. En su publicación de ingeniería del 09 de enero de 2026, Anthropic dice que las buenas evaluaciones ayudan a los equipos a lanzar agentes con más confianza al hacer visibles los fallos y los cambios de comportamiento antes de que lleguen a los usuarios. La empresa también señala por qué los agentes son más difíciles de medir que los chatbots: operan durante muchos turnos, llaman herramientas, modifican estado y se adaptan según resultados intermedios.

@title Estructura de evaluación
@source Demystifying evals for AI agents

  Input
    │
    ▼
  AI system
    │
    ▼
  Output
    │
    ▼
  Grading logic
    │
    ▼
  Success measure

@caption Anthropic describe las evaluaciones como entrada, salida, lógica de calificación y medición del éxito.

Esa definición suena casi ofensivamente simple, y por eso importa. Los agentes de repositorio no solo predicen el siguiente token; realizan acciones dentro de entornos llenos de pruebas frágiles, dependencias inquietantes y un archivo llamado final_final_really.py. Si no puedes reproducir una tarea y calificar el resultado de forma consistente, no estás adoptando un agente. Lo estás invocando.

El tipo de tarea es la variable escurridiza

Un estudio de arXiv estratificado por tipo de tarea comparó OpenAI Codex, GitHub Copilot, Devin, Cursor y Claude Code en 7,156 pull requests del conjunto de datos AIDev. El artículo encontró que el tipo de tarea tenía un gran efecto: las tareas de documentación alcanzaron un 82.1% de aceptación, mientras que las nuevas funcionalidades alcanzaron un 66.1%, una brecha de 16 puntos porcentuales que superó la variación típica entre agentes para la mayoría de las tareas. También informó que Devin mostró la única tendencia positiva consistente en la tasa de aceptación, con 0.77% por semana durante 32 semanas, mientras que los demás agentes se mantuvieron en gran parte estables.

Esa es la parte que los equipos deberían tatuarse en el interior de su panel de CI. Elegir un agente de programación por su puntuación promedio en benchmarks es como elegir un restaurante por la cantidad de tenedores en el cajón. Tu conjunto local de evaluaciones debería dividir las tareas según el trabajo que realmente haces: documentación, corrección de errores, refactorizaciones, migraciones, pruebas y nuevas funcionalidades. De lo contrario, el agente que parece brillante en tareas fáciles de mantenimiento puede devorar silenciosamente tu arquitectura como un mapache en una sala de servidores.

Las evaluaciones de producción necesitan tareas con forma de producción

El artículo REAP sostiene que el despliegue en producción de agentes de programación con IA necesita señales de evaluación rápidas y reproducibles. Dice que las pruebas A/B en línea pueden tardar semanas y poner en riesgo la experiencia del usuario, que el despliegue en sombra no produce señales reproducibles entre ejecuciones y que los benchmarks públicos pueden alejarse de las cargas de trabajo reales en distribución de lenguajes, estilo de prompts y estructura de la base de código. REAP propone seleccionar automáticamente benchmarks derivados de producción a partir de sesiones reales entre desarrolladores y agentes, sin etiquetado manual.

Este es el puente entre las evaluaciones de investigación y la disciplina operativa. Una evaluación útil para un equipo no es un museo de problemas tipo acertijo; es una suite viva de regresión construida a partir del desorden que tu base de código realmente produce. El artículo REAP también señala minas prácticas: prompts no comprobables, pruebas mal alineadas y pruebas inestables pueden comprometer la fiabilidad. Traducción: si tu evaluación no puede distinguir a un mal agente de una mala prueba, felicidades, construiste una máquina de niebla con YAML.

Los benchmarks son necesarios, no suficientes

ProjDevBench presiona sobre una debilidad diferente: el desarrollo de proyectos de extremo a extremo. Según su resumen en arXiv, el benchmark entrega requisitos de proyecto a agentes de programación y evalúa los repositorios resultantes usando pruebas de Online Judge más revisión de código asistida por LLM. Cubre 20 problemas de programación en 8 categorías, evalúa seis agentes de programación e informa una tasa general de aceptación del 27.38%.

Esa baja tasa de aceptación no es una razón para entrar en pánico; es una razón para definir el alcance con responsabilidad. El artículo dice que los agentes manejan funcionalidad básica y estructuras de datos, pero tienen dificultades con diseño de sistemas complejo, optimización de complejidad temporal y gestión de recursos. Para quienes construyen, el movimiento práctico es claro: empieza con tareas estrechas y de alta señal donde se pueda comprobar la corrección, y luego expande solo cuando tus evaluaciones muestren que el agente está mejorando. La autonomía sin medición es solo autocompletado con gabardina.

Mantén al humano en el proceso, idealmente despierto

El artículo Agents That Teach añade un modo de fallo más suave pero importante: el aprendizaje del desarrollador. Sostiene que, a medida que los desarrolladores delegan tareas sustanciales de programación a agentes autónomos, el aprendizaje incidental puede quedar cortocircuitado, creando lo que los autores llaman Deuda de Conocimiento. El artículo propone seis principios de diseño y presenta SHIELD, un sistema multiagente pensado para sacar a la luz aprendizaje contextual y fuera de banda a partir del propio razonamiento del agente de programación.

Eso importa porque las evaluaciones deberían medir más que si las pruebas están en verde. Los equipos también necesitan preguntarse si los desarrolladores pueden explicar el cambio, mantenerlo y notar cuando el agente inventa con confianza una pequeña catedral de sinsentido. El siguiente paso práctico no es un enorme imperio de evaluaciones. Construye una pequeña suite local, ejecútala sobre tareas reales, estratifica por tipo de tarea, rastrea regresiones y sigue añadiendo casos a partir de fallos detectados en producción.

Si el agente va a conducir, las evaluaciones son el volante, no los dados de peluche.