Por qué los agentes de codificación siguen teniendo dificultades con el código de las empresas privadas
Real-SWE prueba ocho agentes de codificación en bases de código privadas con licencia. El mejor resuelve el 38,8 por ciento de los casos, y las cinco categorías de fallos muestran dónde cometen errores los agentes.
Fuentes: Coding Agents Still Struggle With Private Company Code
Los benchmarks de programación públicos prueban habilidades útiles, pero dicen poco sobre lo que ocurre dentro del código de producción privado de una empresa. Un benchmark llamado Real-SWE intenta este segundo tipo de prueba. Sus creadores, una pequeña startup respaldada por Y Combinator llamada Specific Labs, obtuvieron licencia para usar código privado de empresas reales, extrajeron diez tareas que los ingenieros de esas empresas ya habían completado y las asignaron a ocho asistentes de programación. El mejor de ellos logró un 38,8 por ciento.
Una de las tareas comienza con una emergencia en facturación: las facturas emitidas por el servicio salen sin ningún impuesto, y la facturación vuelve a iniciarse el lunes. En total, los asistentes realizaron sesenta y cuatro intentos, y dos funcionaron. La tarea se denomina “Jurisdicción fiscal” y es una de las diez.
Por qué este código permanece oculto
Los fundadores publicaron recientemente el benchmark, y este llegó a la portada de Hacker News con unos pocos cientos de puntos y más de cien comentarios. Real-SWE evalúa ocho combinaciones de modelo y agente en diez tareas, con ocho intentos por tarea. Eso da un total de 640 pruebas evaluadas, y la puntuación final corresponde a la proporción de intentos que tuvieron éxito.
Los proyectos subyacentes parecen ser software comercial ordinario: una aplicación para eventos con más de 200,000 usuarios y posición entre los 100 mejores de la App Store, un producto fintech que ha procesado más de 100,000 estados de cuenta bancarios, y una plataforma de ventas para empresas. Los agentes cuentan con Docker y Kubernetes, tres bases de datos (Postgres, MySQL, MongoDB), Redis, GitHub y una nube Amazon emulada, aunque cada tarea solo expone los servicios que necesita su propio flujo de trabajo.
Algunos entornos incluyen Slack, Intercom, Google Drive, ClickUp y un servidor MCP de Linear, lo que permite al agente leer los tickets directamente desde Linear. Cuando algún detalle no se incluyó en el ticket, el agente debe buscarlo en un hilo de conversación o en un documento, de la misma manera que lo haría el ingeniero de ese equipo.
Solo el trabajo relacionado con impuestos se ejecuta contra un servicio NestJS en TypeScript, dos instancias de la misma autoridad fiscal externa (un entorno de pruebas y el sistema en vivo que presenta solicitudes reales), y un registro de InfluxDB donde se registran las ventas completadas.
Las tareas utilizan el formato Harbor, y la verificación permanece oculta hasta el momento de la calificación. Esto tiene como objetivo reducir las posibilidades de que el agente se adapte a una prueba expuesta en lugar de a los requisitos reales. Los verificadores provienen de conjuntos de pruebas que esas empresas ya ejecutan, en algunos casos de forma literal.
Los autores explican su motivación con una afirmación llamativa: el 99 por ciento de los tokens en las empresas reales están ocultos para los modelos Frontier. Dado que estas tareas provienen de software privado y no de proyectos públicos en GitHub, los modelos no pudieron haber visto el código ni sus secretos durante su entrenamiento.
Las cifras del propio benchmark muestran una instrucción mediana de 1,742 caracteres, lo cual es menor que en FrontierCode (2,056) o DeepSWE (1,975). Sin embargo, en el caso mediano, la solución de referencia afecta a 11 archivos, mientras que esas otras dos herramientas solo lo hacen en 6.
Los resultados varían drásticamente de tarea en tarea
Una sola puntuación general oculta dos grupos muy diferentes: las tareas que los agentes resuelven una y otra vez, y aquellas en las que fallan cada vez. La solución mediante análisis multi-región funcionó en el 67.2 por ciento de los casos, las claves API y los entornos en el 65.6 por ciento, las líneas de exceso de derechos en el 50 por ciento y la migración de identidades de clientes en el 40.6 por ciento.
La situación al final de la lista es preocupante. La jurisdicción fiscal se sitúa en el 3,1 por ciento y el escaneo linealizable en el 4,7; las mediciones del almacenamiento S3 (10,9), la medición de tokens API (12,5) y la migración del calendario de facturación (14,1) están ligeramente por encima. En cuanto al reductor de flujos analíticos, nadie logró avances: cero intentos exitosos en sesenta y cuatro pruebas.
En cuanto a la jurisdicción fiscal, los únicos dos éxitos provinieron de dos modelos diferentes, y cada uno de esos modelos falló en las otras siete pruebas que realizó para esa misma tarea. En el escaneo multi-región, la tarea más sencilla, tres modelos lograron ocho éxitos de ocho intentos, mientras que otros dos lo lograron solo dos veces. Al promediar esto en un 67,2 por ciento, se oculta un grupo que nunca falló y otro que casi nunca lo logró.
Uno de los autores dijo en Hacker News que las bajas tasas reflejan tareas “en las que los ingenieros reales trabajaron durante semanas”.
El ranking completo:
| Rango | Modelo y herramienta |
|---|
Una puntuación no explica el fracaso
Cada implementación fallida lleva una de cinco etiquetas, tomadas de la taxonomía de DeepSWE:
- Suposición no verificada. En lugar de verificar el espacio de trabajo, el agente adivina cómo se comportará el sistema.
Cada porcentaje utiliza las ejecuciones fallidas del propio modelo como denominador.
Grok 4.6 presentó 61 fallos, de los cuales dos tercios (67.2 por ciento) correspondían a incumplimiento de requisitos. Gemini 3.8 Flash tuvo 55 fallos, y el 49.1 por ciento de ellos fueron errores de integración. En GPT-5.6 Sol, el grupo más numeroso está formado por suposiciones no verificadas: el 43.3 por ciento de los 67 fallos, mientras que en Fable 5.1, con 49 fallos, la distribución es más uniforme: aproximadamente el 37 por ciento son incumplimientos de requisitos y cerca del 35 por ciento son errores de integración.
Dos modelos, Grok 4.6 y Muse Spark 1.3, alcanzaron un 23.8 por ciento en el nivel de rendimiento, pero presentan fallos de forma diferente. Grok tiene un alto porcentaje de incumplimientos de requisitos, mientras que Muse Spark presenta errores de integración en un 41 por ciento. Las regresiones nunca superan el 10.9 por ciento y son nulas en tres de las ocho configuraciones. La categoría de archivo incorrecto aparece solo dos veces: GLM 5.3 (7 por ciento) y Kimi K3 (3.1).
Existe una advertencia: aunque se han publicado las etiquetas, el proceso detrás de ellas no está descrito lo suficientemente bien como para considerar los porcentajes como evidencia definitiva. La descripción pública no aclara si fueron ingenieros humanos, un modelo automatizado o una combinación de ambos los que realizaron la clasificación.
Las pruebas más largas no fueron más fiables
También se dividió el análisis según el tiempo transcurrido. En menos de diez minutos, 70 de 98 pruebas fallaron, lo que representa el 71.4 por ciento. En diez minutos o más, 398 de 542 pruebas fallaron, es decir, el 73.4 por ciento.
El uso de tokens cuenta una historia relacionada. Grok 4.6 alcanza un promedio de 3,000 a 20,000 tokens de salida en ocho de las diez tareas, pero genera 261,000 tokens en la tarea de escaneo linealizable y 315,000 en la de reducción de flujos analíticos, las dos tareas con menor puntuación. Un alto uso de tokens puede ser una señal de alerta, especialmente cuando está muy por encima del nivel normal de un repositorio. Cuando una ejecución produce varias veces más salida de la esperada, se debe examinar su evolución o intervenir, en lugar de permitir que un intento bloqueado agote los recursos.
El agente más caro no siempre fue el mejor
El costo estimado de una ejecución varía desde $2.50 (Gemini 3.8 Flash) hasta $6.96 (Fable 5.1), y el orden de los precios no sigue necesariamente al ranking de mejores opciones. GPT-5.6 Sol cuesta $2.65 y ocupa el último lugar, mientras que la opción más económica, Gemini 3.8 Flash, queda en tercer puesto. Todas estas son estimaciones de referencia y no representan un ranking universal de precios, ya que el gasto real depende de los precios, configuraciones, duración de la tarea, intentos de repetición y uso de herramientas.
Fable 5.1 cuesta 2.78 veces más que Gemini 3.8 Flash y resuelve un 7.6 por ciento más de tareas. Si eso vale la pena depende del costo que implica un fallo en la tarea. En este contexto, un fallo puede ser un error en la facturación, un cliente al que se le cobra cuando debería estar exento, o un registro que no se ajusta al final del trimestre. Para pequeños ajustes en la interfaz, las cifras son completamente diferentes.
Mismo entorno de ejecución, diecisiete puntos de diferencia
Cada modelo se combina con las herramientas proporcionadas por su propio proveedor, y por eso el benchmark describe sus resultados como “combinaciones de modelo y entorno de ejecución, en lugar de modelos por separado”. Sin embargo, dos entornos de ejecución aparecen dos veces, lo que permite una comparación aproximada. Con Codex CLI, GPT-6 Astra logra un 33.8 por ciento de eficiencia, frente al 16.2 por ciento de GPT-5.6 Sol, lo que supone una diferencia de 17.6 puntos. Con Claude Code, Fable 5.1 alcanza el 38.8 por ciento y GLM 5.3, el 28.8 por ciento, con una diferencia de diez puntos.
Aun así, diez tareas y ocho configuraciones conforman una tabla pequeña, y cada puntuación incluye un intervalo de confianza publicado. Cada modelo se ejecutó 80 veces; por lo tanto, el 38,8 por ciento de Fable 5.1 corresponde a 31 pruebas exitosas, mientras que el 16,2 por ciento de GPT-5.6 Sol equivale a 13 pruebas. Si una sola tarea da un resultado diferente para un modelo, su puntuación cambia en varios puntos. Nadie debería elegir a un proveedor basándose en una tabla de este tamaño, y los autores no lo piden a nadie. Lo que este ejercicio demuestra es que las puntuaciones públicas pueden ser una guía incompleta del rendimiento en un código privado, y asigna cinco categorías prácticas de fallos a esa diferencia.
Ejecuta las cinco etiquetas en tu propio código
La taxonomía es la parte que se puede transferir. Puedes aplicarla a tu propio repositorio cuando lo desees.
Tome las últimas veinte solicitudes de integración que abrió un agente y asigne a cada una que falló o fue modificada en gran medida una sola de las cinco clases. Cuéntelas. La distribución resultante es el hallazgo, y no coincidirá con ningún modelo del que haya leído esta semana, ya que depende tanto de su base de código y sus hábitos al redactar tickets como del modelo en sí. La clase que resulte ser la más frecuente deberá estar sujeta a una restricción específica.
Si predominan suposiciones no verificadas, se necesita un registro de lecturas. Pida al agente que anote qué archivos abrió antes de realizar cualquier cambio, y rechace el cambio si la lista omite el archivo donde se encuentra dicho comportamiento. Los requisitos omitidos suelen remontarse al ticket correspondiente. Convierta la instrucción en una lista de criterios de aceptación y marque cada uno por separado, ya que una instrucción con cinco requisitos ocultos en un párrafo largo es la causa del 67,2 por ciento de errores en Grok. Los errores de integración significan que las pruebas pasan a nivel unitario pero fallan en la cadena de llamadas, por lo que debe probarse a lo largo del camino que sigue la aplicación en producción, comenzando por su punto de entrada. Un fallo debido al archivo incorrecto es lo suficientemente raro como para investigar cada ocurrencia: verifique que se pueda acceder a cada archivo modificado desde el código que la aplicación realmente invoca.
A partir de entonces, basta con seguir un único número: la proporción de solicitudes de pull request generadas por los agentes que pasan la revisión a la primera, desglosada por categoría de fallo. Este valor cambia cuando se endurecen los requisitos y vuelve a cambiar cuando el modelo subyacente se modifica.