En el mundo de AI Coding acaba de aparecer un nuevo benchmark: ProgramBench. A primera vista, su resultado parece tranquilizador para los programadores: nueve modelos principales obtuvieron 0% en la métrica fully resolved, y ningún modelo completó por completo ni una sola tarea.
Pero lo verdaderamente inquietante no es que los grandes modelos actuales todavía fallen. Lo importante es que, por primera vez, la ingeniería de software completa se ha convertido en un conjunto claro de tareas evaluables, clasificables y optimizables de forma repetida.
Una vez que una tarea queda definida con claridad, la industria de IA suele hacer lo que mejor sabe hacer: resolver el benchmark, iterar, perseguir el leaderboard y empujar poco a poco lo que antes parecía imposible hacia el borde de lo utilizable.
Qué mide ProgramBench
Muchos benchmarks de programación miden completar funciones, corregir bugs, pasar unit tests o añadir una pequeña función a un proyecto existente. ProgramBench es mucho más duro. No proporciona código fuente, ni estructura de proyecto, ni test cases ya preparados.
El modelo recibe principalmente solo dos cosas:
- Un ejecutable ya compilado.
- La documentación de uso de ese programa.
El modelo debe ejecutar el binario por su cuenta, observar el comportamiento de entrada y salida, entender argumentos de línea de comandos, casos límite, mensajes de error y formas de almacenamiento de datos, y luego volver a implementar un programa con comportamiento equivalente.
Esto ya no es “escribir un fragmento de código”. Es una tarea de ingeniería de software simplificada pero completa: entender requisitos, explorar comportamiento, elegir lenguaje, diseñar estructura, escribir código fuente, proporcionar un método de build e intentar pasar las pruebas ocultas.
Según la descripción oficial de ProgramBench, actualmente contiene 200 tareas, desde pequeñas herramientas de línea de comandos hasta proyectos reales grandes como PHP, FFmpeg y SQLite. El conjunto de pruebas se genera mediante agent-driven fuzzing y supera las 248.000 pruebas de comportamiento.
Si descomponemos el flujo de evaluación, ProgramBench mide aproximadamente cuatro capacidades:
- Leer documentación: entender qué comandos, argumentos y salidas debe ofrecer el programa.
- Explorar comportamiento: ejecutar repetidamente el binario y observar entradas normales, entradas inválidas y casos límite.
- Reconstruir la implementación: elegir lenguaje y estructura de proyecto, y escribir un reemplazo con comportamiento cercano.
- Pasar pruebas ocultas: no basta con acertar el comportamiento normal; también cuentan el manejo de errores, el formato de salida y las condiciones de borde.
Por eso su valor de búsqueda no es simplemente “otro ranking”. Responde a una pregunta más concreta: ¿puede un gran modelo recrear software real desde cero, sin código fuente, usando solo documentación y comportamiento de caja negra?
Por qué el resultado es 0%
La métrica principal de ProgramBench es fully resolved: una tarea solo cuenta como completada si todas sus pruebas pasan. En el leaderboard actual, los nueve modelos tienen 0% en esta métrica.
Los modelos evaluados incluyen familias como Claude, GPT y Gemini, todos usando mini-SWE-agent como agent base. Claude Opus 4.7 es el mejor en la métrica almost resolved, con alrededor de 3.0% de tareas que pasan al menos el 95% de las pruebas. Claude Opus 4.6 llega a 2.5%, y Claude Sonnet 4.6 a 1.0%. GPT 5.4, GPT 5.4 mini, Gemini 3.1 Pro, Gemini 3 Flash y otros quedan en 0.0% en almost resolved.
Esto muestra que los grandes modelos actuales, combinados con un agent ligero, todavía no pueden reconstruir software completo desde cero. Incluso en las tareas más simples, alinear todos los detalles resulta difícil.
Pero hay un matiz importante: esta evaluación usó mini-SWE-agent, no Claude Code ni Codex. Con un coding agent más fuerte, más soporte de herramientas y un ciclo de exploración más largo, los resultados podrían mejorar. La interpretación más precisa es: los modelos actuales con un agent ligero aún no bastan para completar de forma estable la reconstrucción de software completo.
Qué significan fully resolved y almost resolved
Al leer los resultados de ProgramBench, estas dos métricas son fáciles de confundir.
fully resolved es la métrica más estricta: todas las pruebas ocultas de una tarea deben pasar para que se considere completamente resuelta. Si falta un caso límite, un formato de error o un comportamiento de argumento de línea de comandos, la tarea no cuenta como fully resolved.
almost resolved se parece más a “casi completado”: si una tarea pasa al menos el 95% de sus pruebas, entra en almost resolved. Refleja si el modelo logró reproducir la mayor parte del comportamiento, pero no significa que el programa ya pueda sustituir al software original.
Por eso el 0% debe leerse por partes. El 0% en fully resolved indica que los modelos aún no pueden entregar una solución completa. La diferencia en almost resolved muestra qué modelos ya se acercan al éxito en algunas tareas. Por ejemplo, Claude Opus 4.7 alcanza alrededor de 3.0% en almost resolved, lo que indica que se acerca más en unas pocas tareas relativamente simples, pero sigue muy lejos de reconstruir software completo de forma estable.
Por qué mini-SWE-agent afecta el resultado
La evaluación usa un mini-SWE-agent unificado, lo cual tiene una ventaja clara: equidad. Todos los modelos corren sobre el mismo marco ligero de agent, así que la comparación horizontal es más sencilla.
Pero también limita el techo. La reconstrucción de software completo no depende solo del modelo. También depende de si el agent puede planificar una estrategia de exploración, gestionar tareas largas, generar tests automáticamente, localizar causas de fallo de forma repetida y organizar la estructura del proyecto.
mini-SWE-agent se parece más a una línea base común que al entorno de ingeniería más potente posible.
Coding agents más completos como Claude Code o Codex suelen ofrecer mejor uso de herramientas, organización de contexto, descomposición de tareas y reparación en múltiples rondas. Si se usaran esas herramientas, los resultados podrían ser mejores.
Así que el resultado de ProgramBench se entiende mejor así: los modelos actuales no pueden realizar reconstrucción completa de software en un entorno de agent ligero. No demuestra que los modelos nunca podrán hacerlo, ni mide por completo el techo de todos los coding agents comerciales.
Diferencias con SWE-bench
SWE-bench ya es un benchmark importante en AI Coding. Pide a los modelos leer issues en repositorios reales de GitHub, modificar código y enviar parches, para evaluar su capacidad de resolver bugs reales.
Pero SWE-bench sigue siendo, en esencia, reparar un coche existente: el coche ya está ahí, y el stack tecnológico, la estructura de directorios, la organización del código y la arquitectura ya fueron creados por humanos. El modelo solo necesita encontrar el problema y arreglar la pieza rota.
ProgramBench se parece más a construir el coche de nuevo: solo sabes qué comportamiento debe tener, por ejemplo detenerse ante un semáforo rojo o tocar la bocina cerca de peatones. La estructura, el lenguaje, los módulos y el método de build deben decidirse desde cero.
Por eso es mucho más difícil. Ya no evalúa solo la capacidad de hacer parches locales, sino arquitectura de software, razonamiento de sistemas, exploración de comportamiento, pruebas automáticas, corrección en múltiples rondas y diseño de ingeniería a largo plazo.
La diferencia puede resumirse así:
| Dimensión | SWE-bench | ProgramBench |
|---|---|---|
| Punto de partida | Repositorio de GitHub e issue existentes | Ejecutable compilado y documentación de uso |
| Código fuente disponible | Sí | No |
| Tarea principal | Corregir un bug en un proyecto existente | Reimplementar un programa completo a partir del comportamiento |
| Stack tecnológico | Ya definido por el proyecto | Elegido por el modelo |
| Estructura del proyecto | Ya existe | Diseñada por el modelo |
| Método de prueba | Ejecutar tests tras enviar un parche | Usar pruebas ocultas de comportamiento para medir la reconstrucción |
| Enfoque principal | Leer código, localizar problemas, reparar con parches | Explorar comportamiento, abstraer sistemas, diseñar arquitectura, implementar completo |
Por eso ProgramBench encaja mejor como objetivo de la siguiente etapa de AI Coding: empuja el problema desde “arreglar código existente” hacia “reconstruir software completo”.
0% no significa seguridad
Al ver 0%, la primera reacción de muchas personas puede ser: el trabajo de los programadores está a salvo por ahora.
A corto plazo, eso es cierto. Los grandes modelos actuales todavía no pueden completar ingeniería de software completa de forma estable, especialmente sin código fuente, test cases ni estructura de proyecto. La aclaración de requisitos, el diseño de arquitectura, el mantenimiento a largo plazo, el control de seguridad, la colaboración de equipo y la comprensión del negocio siguen siendo ventajas importantes de los ingenieros humanos.
Pero interpretar 0% como “AI Coding llegó a su límite” sería demasiado optimista.
Lo que ProgramBench cambia de verdad es la definición del problema. Antes ya sabíamos que la IA podía completar código y corregir bugs, pero “reconstruir software completo a partir de un ejecutable y documentación” no estaba colocado en una pista común. Ahora son 200 tareas, una evaluación unificada y un ranking unificado.
Eso significa que las empresas de modelos, agents y herramientas de desarrollo saben hacia dónde empujar: hacer que la IA evolucione de escribir fragmentos de código a mantener, reconstruir y entregar sistemas de software completos.
Por qué hacen falta modo offline y anti-cheating
Hay un detalle importante en el diseño de ProgramBench: evitar trampas.
En pruebas iniciales, los modelos intentaban encontrar directamente el código fuente en GitHub, descargar paquetes que contenían el código mediante package managers, o incluso buscar paquetes ya descargados en directorios de caché del sistema. Eso rompe el propósito de la evaluación, porque la pregunta deja de ser “puede reconstruir software desde el comportamiento” y pasa a ser “puede encontrar el código fuente original”.
Por eso ProgramBench usa sandbox y entorno offline. No permite acceso a internet, ni decompilación, ni desensamblado, ni lectura del contenido del ejecutable. El modelo solo puede ejecutar el programa, observar su comportamiento y luego implementar su propia versión.
Esta restricción hace la evaluación más limpia y la acerca a la pregunta real: ¿puede un gran modelo de lenguaje partir del comportamiento y la documentación de un programa para construir por sí mismo un proyecto de software ejecutable?
Lo más preocupante puede ser el cambio en la forma del código
ProgramBench también muestra algo más importante que el 0% para los ingenieros de software: el código generado por modelos a menudo no se parece a los proyectos que escribirían ingenieros humanos.
Los materiales públicos mencionan que los modelos tienden a generar menos archivos, jerarquías de directorios más planas, menos funciones y funciones individuales más largas. En otras palabras, pueden producir un script enorme que funciona, en lugar de un proyecto de software bien estructurado y fácil de mantener por humanos.
Desde la ingeniería de software tradicional, eso suele ser mal código. Muy pocos archivos, funciones demasiado largas, poca abstracción y límites de módulos poco claros dificultan el mantenimiento humano.
Pero el problema es que la IA quizá no necesite escribir código siguiendo la forma en que los humanos lo mantienen.
Los humanos enfatizan abstracción, nombres, estructura de directorios y límites de módulos principalmente porque la memoria humana es limitada, los equipos necesitan colaborar y el código debe reutilizarse durante mucho tiempo. Si la IA puede usar contextos más largos, sistemas de búsqueda y pruebas automáticas para reescribir código repetidamente, quizá no necesite tanto esas convenciones de ingeniería familiares para nosotros.
Esto crea un riesgo muy real: el software escrito por IA en el futuro quizá funcione, e incluso funcione rápido, pero sea cada vez más difícil de mantener por humanos.
Qué deben mejorar realmente los programadores
El resultado de ProgramBench no es simplemente una buena noticia ni una mala noticia para los programadores.
A corto plazo, la ingeniería de software completa sigue siendo difícil, y los programadores no van a perder su trabajo de inmediato por este benchmark. En especial, el juicio arquitectónico, la aclaración de requisitos, el control de seguridad, la validación de calidad y la comprensión del negocio todavía requieren responsabilidad humana.
A largo plazo, el trabajo del programador seguirá subiendo de nivel. Las personas más vulnerables no son quienes “no saben escribir código”, sino quienes solo saben escribir código y no saben definir problemas, verificar resultados, organizar toolchains ni controlar riesgos.
El ingeniero de software del futuro podría parecerse más a esto:
- Definidor de requisitos: convertir problemas de negocio difusos en objetivos ejecutables.
- Validador de sistemas: juzgar si el resultado generado por IA realmente cumple los requisitos.
- Organizador de toolchains: combinar modelos, agents, tests, despliegue y monitorización.
- Responsable de calidad: controlar seguridad, mantenibilidad, casos límite y riesgos a largo plazo.
- Traductor entre negocio y tecnología: convertir problemas reales en restricciones que un sistema de ingeniería pueda manejar.
Si la IA realmente evoluciona de asistente de código a ingeniero de software completo, el valor del programador humano ya no será escribir cada línea a mano. Será definir qué vale la pena construir, qué cuenta como correcto y dónde no se puede fallar.
Resumen
El 0% de ProgramBench no es el final. Es el comienzo de una nueva etapa.
Muestra que los grandes modelos actuales todavía no pueden reconstruir de forma estable sistemas de software completos desde cero. Pero también define con claridad el objetivo de la próxima generación de AI Coding agents: pasar de parches locales a proyectos completos, de fragmentos de código a entrega de sistemas.
Para los programadores, a corto plazo se puede respirar un poco. Pero a largo plazo no conviene quedarse mirando solo que “la IA todavía no puede”. Lo más importante es subir cuanto antes de ejecutor de código a definidor de problemas, validador de resultados y controlador de riesgos.
Lo verdaderamente inquietante no es que la IA haya sacado 0% hoy. Es que el examen ya está escrito.