87% en el benchmark, y aún no puede hacer evolucionar tu base de código

Ya viste el titular: los agentes de programación con IA ahora "resuelven" el 80–90% de SWE-bench, el benchmark estándar para arreglar issues reales de GitHub. En 2023 el número rondaba el 4%. El progreso es genuinamente asombroso, y la lectura natural es "la IA ya puede hacer ingeniería de software".

Esa lectura es equivocada, de una forma pequeña y luego de una forma fatal, y la brecha entre ambas es una de las cosas más importantes que hay que entender sobre dónde están realmente los agentes de programación.

El problema pequeño: el benchmark filtra

Empecemos con la advertencia poco glamorosa. SWE-bench no es tan limpio como sugiere el número. Una auditoría detallada encontró que cerca de un tercio de los parches "exitosos" implicaban que la solución se filtró en los datos de entrenamiento del modelo, y aproximadamente otro tercio pasó porque los casos de test/prueba eran demasiado débiles para detectar un arreglo incorrecto. Muchos de los issues de GitHub fueron reportados y arreglados antes de las fechas de corte de entrenamiento de los modelos, así que un modelo simplemente pudo haber visto la respuesta durante el entrenamiento. Cuando los investigadores construyeron una versión resistente a contaminación, SWE-Bench Pro, los puntajes se desplomaron por debajo del 25% — GPT-5 lo encabezó con 23.3%. Así que parte de ese impresionante 87% es memoria, no habilidad.

Vale la pena saberlo, pero no es la historia de fondo. Incluso un benchmark perfectamente limpio te despistaría aquí, por lo que mide.

El problema fatal: el benchmark no es el trabajo

SWE-bench le da a un agente un único issue aislado de GitHub, con un arreglo conocido, y un test que confirma cuándo está resuelto. Piensa en lo poco que eso se parece a tu trabajo real. La ingeniería de software de verdad no es un flujo de acertijos autocontenidos con la clave de respuestas a la mano. Es hacer evolucionar una base de código viva durante semanas — interpretar un requisito vago, coordinar un cambio a través de docenas de archivos, preservar todo lo que ya funcionaba, y discutir con un revisor sobre tradeoffs por el camino.

Los propios autores del benchmark son claros al respecto. SWE-bench mide la corrección a nivel de parche en un escenario aislado, de un solo issue; no mide la capacidad de un agente para mantener un hilo de desarrollo coherente de varias semanas, coordinarse con revisores humanos, gestionar prioridades de producto en competencia, ni razonar sobre las implicaciones de negocio de una decisión técnica. Lee esa lista de nuevo — es la mayor parte de lo que el trabajo realmente es.

Qué pasa cuando mides lo real

A finales de 2025, unos investigadores construyeron un benchmark para exactamente la parte que faltaba: SWE-EVO, que pone a prueba la evolución de software de horizonte largo (long-horizon) — cambios de múltiples pasos que abarcan, en promedio, 21 archivos y se verifican contra ~874 tests/pruebas por tarea. El resultado es brutal y esclarecedor. Una configuración de modelo que saca cerca del 73% en SWE-bench Verified saca solo ~25% en SWE-EVO. Los mismos modelos, la misma inteligencia — el puntaje no baja, se cae por un precipicio, porque coordinar un cambio sostenido a través de muchos archivos es una habilidad fundamentalmente distinta y más difícil que parchar un archivo en aislamiento. Es el mismo muro sobre el que escribí en "un agente que lo hace todo": mantén suficiente de un sistema real en contexto a la vez y el modelo empieza a ahogarse.

Ya conoces este patrón

Un benchmark es una tarea curada con la respuesta al alcance. Tu base de código es un blanco en movimiento sin clave de respuestas. Leer un puntaje alto en un benchmark como "puede hacer el trabajo" es exactamente el mismo error que creerle a una demo pulida — y ya hice ese argumento antes: la demo demuestra que el agente puede tener éxito una vez, bajo condiciones que alguien eligió para él. La producción — y una base de código real es producción — pregunta si puede seguir teniendo éxito en trabajo que nadie curó. SWE-bench es la demo. SWE-EVO es un vistazo al trabajo.

La lectura honesta

Esto no es "la programación con IA es falsa". Pasar del 4% a algo genuinamente fuerte en la resolución de issues aislados es real, y un agente que arregla de forma confiable un bug autocontenido es una palanca real que uso todos los días. El error es leer el leaderboard como una medida de "puede reemplazar a un ingeniero de software". Porque lo que hace que alguien sea un ingeniero de software es precisamente la parte de horizonte largo (long-horizon) que el benchmark deja fuera: cargar la intención a lo largo de semanas, coordinar el cambio a través de un sistema completo, y no romper los veinte archivos por los que nadie te preguntó. Ese es el trabajo. El benchmark mide el calentamiento.

Así que cuando aterrice el próximo titular de "la IA llega al 90% en SWE-bench", hazte la única pregunta que importa: ¿noventa por ciento de qué? Un issue curado con la respuesta al lado no es tu martes. Hasta que un benchmark pueda medir hacer evolucionar una base de código real durante semanas sin romperla, el puntaje está midiendo la demo — y ya sabes que la demo nunca fue el trabajo.