El benchmark Real-SWE expone la brecha entre las puntuaciones de programación con IA y el trabajo empresarial

Specific Labs lanzó el benchmark Real-SWE con 640 ejecuciones de agentes, y la configuración mejor clasificada resolvió solo el 38,8 por ciento del trabajo asignado.

Ese resultado plantea un contraste incómodo con las clasificaciones públicas de programación. Los agentes parecen cada vez más capaces de abordar problemas a nivel de repositorio, pero la mayoría de los intentos en Real-SWE fracasaron en sistemas privados de producción.

La diferencia no se debe simplemente a que Real-SWE contenga rompecabezas de programación más difíciles. Sus tareas exigen que los agentes reconstruyan reglas de negocio, naveguen por arquitecturas desconocidas y coordinen cambios entre código y servicios conectados.

Esta distinción importa porque las empresas no contratan ingenieros de software para resolver ejercicios aislados y sin contexto. Necesitan ingenieros que preserven el comportamiento existente mientras modifican sistemas que ya procesan datos de clientes, permisos, facturación e infraestructura.

Por tanto, Real-SWE cuestiona la promesa implícita en las altas puntuaciones de los benchmarks públicos. Pregunta si un agente puede entrar en una base de código empresarial desconocida y completar trabajo económicamente útil sin depender de artefactos públicos conocidos.

La respuesta inicial es aleccionadora. El benchmark ofrece evidencia de que los modelos de programación pueden producir parches creíbles, pero no respalda un despliegue sin supervisión en flujos de trabajo empresariales relevantes.

Qué cambió realmente el benchmark Real-SWE

Real-SWE desplaza el objetivo de evaluación de problemas en repositorios públicos a sistemas privados con reglas específicas de cada empresa y dependencias operativas.

Specific Labs anunció el benchmark el 12 de septiembre de 2026. La empresa lo describe como una evaluación de modelos de frontera sobre bases de código privadas de producción licenciadas por empresas operativas.

La versión inicial abarca diez tareas y ocho configuraciones de modelo y harness. Cada configuración recibe ocho intentos independientes por tarea, lo que produce 640 ejecuciones puntuadas.

Ese diseño de ejecuciones repetidas importa. Un único parche exitoso puede ocultar una inconsistencia considerable, mientras que ocho intentos muestran si un agente resuelve la misma clase de problema de forma fiable.

La clasificación publicada informa pass@1, es decir, la probabilidad de que un intento resuelva la tarea. Specific Labs promedia ese resultado entre las ocho ejecuciones asignadas a cada tarea.

Fable 5.1 con Claude Code lideró la clasificación inicial con un 38,8 por ciento. GPT-6 Astra con Codex CLI le siguió con un 33,8 por ciento, mientras que Gemini 3.8 Flash con Gemini CLI alcanzó el 31,2 por ciento.

GLM 5.3 con Claude Code registró un 28,8 por ciento. Grok 4.6 y Muse Spark 1.3 alcanzaron cada uno un 23,8 por ciento con sus respectivos sistemas de agentes.

Kimi K3 con Kimi Code alcanzó el 18,8 por ciento. GPT-5.6 Sol con Codex CLI terminó en el 16,2 por ciento en esta evaluación concreta.

Estos resultados evalúan combinaciones, no modelos de lenguaje aislados. Un harness proporciona herramientas, controla el ciclo de interacción y determina cómo un modelo explora y edita un repositorio.

Specific Labs afirma explícitamente que utilizó harnesses nativos diseñados para reflejar los flujos de trabajo de ingeniería actuales. Esa elección mejora la relevancia práctica, pero complica las comparaciones entre modelos.

Una puntuación más alta puede reflejar el razonamiento del modelo, el comportamiento del harness, la fiabilidad de las herramientas o la interacción entre los tres. La clasificación no puede aislar limpiamente esos efectos.

El cambio más profundo del benchmark se refiere a la exposición de los datos. Las pruebas públicas de programación suelen utilizar repositorios de código abierto, incidencias públicas e historiales de soluciones visibles.

Los repositorios privados reducen la probabilidad de que un modelo haya encontrado el parche pertinente durante el entrenamiento. También impiden que un agente encuentre una respuesta mediante búsqueda pública.

Según los resultados publicados de Real-SWE, cada tarea se originó en trabajo asociado a una base de código privada real. Según se informa, algunas instrucciones se extrajeron directamente de trabajo de ingeniería real.

Ese diseño hace que la evaluación se parezca menos a un examen creado para modelos. La acerca más a incorporar a un nuevo contratista en una organización de software desconocida.

La distinción también cambia el significado del fracaso. Un parche fallido puede reflejar una programación deficiente, pero también puede revelar un descubrimiento pobre de requisitos o una comprensión incompleta del sistema.

Ese es precisamente el terreno en el que los despliegues empresariales se vuelven arriesgados. Un parche puede compilar, superar pruebas evidentes y aun así infringir una regla integrada en otra parte del negocio.

Por qué el código empresarial privado plantea una prueba diferente

El desafío central no es generar más código. Es descubrir de qué comportamiento ya depende el negocio y preservarlo en múltiples sistemas.

Un ejemplo de Real-SWE pide a un agente corregir la tributación de facturas. La breve descripción oculta varias condiciones relacionadas con la configuración empresarial, las exenciones de clientes, las reglas geográficas y los servicios fiscales externos.

El agente debe determinar cuándo usar una tasa almacenada y cuándo calcular el impuesto a partir del destino del comprador. Debe reconocer las cuentas que no recaudan impuestos.

También debe preservar las exenciones, registrar correctamente los totales de las facturas e informar de direcciones rechazadas sin detener la factura. Las transacciones liquidadas deben devolverse a la autoridad fiscal.

Las transacciones europeas añaden otro requisito relacionado con los registros de IVA. Completar el trabajo puede implicar un servicio TypeScript, entornos TaxJar y un libro mayor InfluxDB.

Ninguna de estas operaciones individuales representa un algoritmo exótico. La dificultad proviene de coordinarlas sin pasar por alto una condición ni dañar el comportamiento existente.

Ese patrón aparece en todo el software empresarial. Una solicitud que parece local suele atravesar API, bases de datos, trabajos en segundo plano, configuración, pruebas y herramientas operativas.

Los entornos Real-SWE pueden exponer servicios y herramientas que incluyen Docker, Kubernetes, GitHub, PostgreSQL, MySQL, Redis, Slack, correo electrónico y sistemas de atención al cliente.

Cada tarea recibe solo los servicios que necesita su flujo de trabajo. Aun así, un agente debe decidir qué sistemas contienen evidencia relevante y cuáles son distracciones.

El benchmark informa de una longitud mediana de instrucciones de 1.742 caracteres. Es menos que una especificación detallada de implementación, por lo que los agentes deben inferir la estructura a partir del código y el contexto disponibles.

Las soluciones de referencia modificaron una mediana de 11 archivos. Los datos comparativos del benchmark sitúan esa cifra por encima de las medianas de seis archivos comunicadas para FrontierCode y DeepSWE.

Esta diferencia ayuda a explicar por qué la navegación por repositorios importa. Un modelo que encuentra un punto de implementación obvio puede aun así pasar por alto la validación, la persistencia, la configuración o los consumidores posteriores.

Specific Labs afirma que seis de las diez tareas tuvieron tasas de resolución inferiores al 15 por ciento. Ninguna configuración evaluada resolvió todas las tareas.

El análisis de fallos identifica los requisitos omitidos como la categoría más común. Otros fallos observados incluyeron supuestos no verificados, errores de integración, regresiones y ediciones en el archivo equivocado.

Estas categorías se parecen más a comentarios habituales de revisión de ingeniería que a errores de sintaxis. Sugieren que los agentes producen con frecuencia cambios locales plausibles sin construir un modelo completo del sistema.

El tiempo por sí solo no separó a los ganadores de los fracasos. El benchmark afirma que 70 de 98 ejecuciones de menos de diez minutos fracasaron, una tasa de fracaso del 71,4 por ciento.

Entre las ejecuciones más largas, 398 de 542 fracasaron, lo que representa el 73,4 por ciento. Por tanto, más tiempo de ejecución no corrigió automáticamente una exploración deficiente ni supuestos erróneos.

La comparación entre intentos cortos y largos no debe interpretarse como prueba de que un razonamiento adicional nunca ayuda. Es probable que las tareas más difíciles generen intentos más largos, lo que crea un importante factor de confusión.

Aun así, el resultado debilita una explicación conveniente. Estos agentes no fracasaron simplemente porque todas las ejecuciones terminaran antes de que el modelo pudiera acabar de escribir una solución.

El mecanismo más creíble es la formación incompleta de contexto. Un agente debe identificar los requisitos, localizar su implementación, rastrear dependencias y verificar el cambio completo.

Ese flujo de trabajo se beneficia de un conocimiento duradero del repositorio. Los equipos de ingeniería ya mantienen notas de arquitectura, historial de incidentes, decisiones y documentos técnicos por la misma razón.

Una base de conocimiento de ingeniería con capacidad de búsqueda puede reducir el trabajo repetido de descubrimiento para las personas. Los sistemas de agentes necesitan cada vez más una capa de contexto equivalente.

Real-SWE no establece que la memoria persistente resolvería estas tareas. Sí demuestra por qué la generación de código sin estado es un modelo incompleto para la ingeniería empresarial.

Las puntuaciones públicas de programación frente a la realidad del código privado

La principal disputa se da entre la capacidad de programación visible en los benchmarks y el rendimiento fiable dentro de sistemas que los modelos nunca han encontrado.

SWE-bench cambió la evaluación de programación al pedir a los modelos que resolvieran incidencias reales de GitHub dentro de instantáneas de repositorios. Fue una mejora importante respecto a las pruebas aisladas de generación de funciones.

El benchmark original conectaba descripciones de incidencias, estado del repositorio y calificación basada en ejecución. Ayudó a orientar el campo hacia agentes que exploran, editan y prueban software.

Sin embargo, esos repositorios e historiales de incidencias son públicos. A medida que los modelos mejoran y los datos de evaluación circulan, la contaminación se vuelve más difícil de excluir.

La contaminación ocurre cuando los datos de entrenamiento de un modelo contienen tareas del benchmark, parches pertinentes o copias cercanas. Una puntuación alta puede entonces mezclar generalización con reconocimiento o memorización.

SWE-bench Verified intentó mejorar la calidad de las tareas mediante revisión humana. Su conjunto de datos verificado conservó 500 muestras después de examinar las descripciones de incidencias y las pruebas.

La propia revisión demostró lo difícil que es construir evaluaciones de programación. OpenAI informó de que el 68,3 por ciento de las muestras examinadas se eliminó por problemas de especificación, pruebas u otros relacionados.

El benchmark filtrado siguió siendo útil, pero no eliminó la exposición pública. Los desarrolladores de modelos aún podían estudiar los repositorios, las tareas, el comportamiento de calificación y los patrones de fallo comunes.

Auditorías más recientes aumentaron la presión para crear nuevos diseños de evaluación. La auditoría de benchmarks de OpenAI de 2026 informó de preocupaciones de diseño y contaminación en evaluaciones de programación ampliamente utilizadas.

La auditoría también estimó que alrededor del 30 por ciento de las tareas de SWE-Bench Pro estaban defectuosas. Los problemas comunicados incluían pruebas estrictas, requisitos ausentes, cobertura deficiente y prompts engañosos.

Real-SWE aborda una parte de este problema al mantener privados los repositorios y soluciones subyacentes. Los modelos no pueden recuperar un parche público exacto si ese parche nunca se publicó.

Sin embargo, los datos privados introducen una disyuntiva diferente. Los investigadores externos no pueden inspeccionar libremente cada repositorio, reproducir cada tarea ni auditar las pruebas ocultas.

Eso reduce la transparencia precisamente cuando un benchmark formula afirmaciones comercialmente significativas. Los lectores deben confiar en el proceso del operador del benchmark para las licencias, la anonimización, la construcción de tareas y la puntuación.

Real-SWE proporciona ejemplos de tareas, resultados agregados, intervalos de confianza y una taxonomía de fallos. Estas divulgaciones ayudan, pero no equivalen a una evaluación abiertamente reproducible.

El tamaño de diez tareas presenta otra limitación. Las ejecuciones repetidas miden la consistencia entre intentos, pero la repetición no crea una cobertura más amplia de tareas.

Un benchmark con diez tareas puede ser sensible a la selección de tareas. Una arquitectura, combinación de lenguajes o dominio empresarial puede influir materialmente en las clasificaciones.

La combinación de modelo y arnés añade más incertidumbre. Claude Code aparece con más de un modelo, mientras que Codex CLI también aparece con varios modelos.

Esa variación aporta información útil sobre el despliegue. No produce una comparación controlada en la que cada modelo reciba una estructura y una política de herramientas idénticas.

Por tanto, la interpretación correcta es más limitada que una clasificación universal de modelos. Estas puntuaciones muestran cómo se desempeñaron configuraciones concretas en esta versión de Real-SWE bajo la configuración documentada.

No demuestran que el modelo líder sea el mejor para todas las empresas. Tampoco establecen que la configuración peor clasificada carezca de capacidades de programación útiles.

En cambio, el benchmark advierte contra trasladar directamente las puntuaciones públicas a las expectativas de despliegues privados. Esa advertencia coincide con la reevaluación más amplia del campo de la evaluación.

METR establece una distinción relacionada en su metodología de tareas. Sus tareas autocontenidas proporcionan deliberadamente a los modelos criterios de éxito claros y una dependencia limitada del historial organizativo.

METR señala que el trabajo real suele depender de conversaciones previas, conocimiento tácito y familiaridad con una base de código existente. Su metodología compara a los agentes más estrechamente con contratistas que cuentan con poco contexto.

Real-SWE se adentra más en ese problema de bajo contexto. Conserva una evaluación ejecutable al tiempo que introduce convenciones específicas de cada empresa y relaciones operativas.

Esta es la inversión más importante del benchmark. Un rendimiento sólido en incidencias públicas deja de ser evidencia suficiente de una autonomía empresarial fiable.

La clasificación presiona tanto a los compradores como a los proveedores de modelos

Real-SWE somete a presión a los equipos de evaluación empresariales porque las puntuaciones de los proveedores no pueden sustituir las pruebas dentro del entorno del propio comprador.

Una empresa que evalúa agentes de programación suele enfrentarse a una asimetría de información. Los proveedores conocen sus modelos, mientras que los compradores conocen sus repositorios, flujos de trabajo y tolerancia al riesgo.

Las clasificaciones públicas ofrecen a ambas partes una referencia común. Simplifican la comparación, pero esa simplicidad se vuelve peligrosa cuando el entorno de despliegue difiere del benchmark.

Real-SWE hace visible esa discrepancia. Incluso su configuración más sólida falló en más de seis de cada diez intentos en el conjunto de tareas evaluado.

Un comprador no debería traducir ese número directamente en una tasa esperada de fallos en producción. Diez tareas de benchmark no pueden representar todos los repositorios ni todas las organizaciones de ingeniería.

Aun así, el número cambia la conversación de adquisición. Los equipos necesitan evidencia sobre la fiabilidad en su propio código, no solo sobre el rendimiento en historiales de incidencias públicas.

Eso implica crear evaluaciones internas a partir de trabajo representativo ya completado. Las tareas adecuadas pueden incluir correcciones de errores, migraciones, cambios de permisos y trabajo de integración con resultados conocidos.

La solución de referencia no debería convertirse en la única implementación aceptable. Los revisores deben distinguir la corrección funcional de la similitud superficial con el parche original de un ingeniero.

Las pruebas ocultas también requieren escrutinio. Un benchmark puede penalizar una alternativa válida si su verificador codifica detalles de implementación no declarados.

Las auditorías de benchmarks de OpenAI muestran con qué frecuencia sucede esto. La calidad de la evaluación exige que ingenieros experimentados comparen instrucciones, pruebas, cambios de referencia y trazas de los agentes.

Las organizaciones también deberían probar configuraciones completas. La decisión de Real-SWE de puntuar pares de modelo y arnés refleja cómo operan los agentes de programación en la práctica.

La búsqueda en repositorios, el acceso al shell, la ejecución de pruebas, la gestión de contexto y las políticas de reintento pueden alterar materialmente el rendimiento. Medir solo el modelo subyacente ignora esas dependencias.

La seguridad pertenece a la misma evaluación. El acceso a código fuente privado plantea cuestiones sobre retención, controles del proveedor, exposición de secretos, registros y permisos.

Un agente que resuelve más tareas aún puede ser inadecuado si recibe un acceso más amplio del que la organización puede conceder de forma segura. La capacidad y el riesgo de despliegue deben evaluarse juntos.

La carga de revisión aporta otra medida crítica. Un parche que finalmente funciona puede requerir tanta investigación humana que ofrece pocos beneficios de productividad.

Los equipos deberían registrar con qué frecuencia un agente incumple requisitos, crea regresiones o necesita indicaciones correctivas. Esas medidas se corresponden estrechamente con las categorías de fallo de Real-SWE.

También deberían seguir la variabilidad. Una demostración exitosa dice poco sobre si el agente puede repetir el resultado en el siguiente intento.

La discusión sobre el benchmark en Hacker News recogió ambos lados de esta cuestión. Algunos participantes valoraron los ensayos repetidos de pass@1 porque revelan consistencia.

Otros sostuvieron que las herramientas actuales todavía funcionan mejor mediante una estrecha colaboración humana. Desde esa perspectiva, el operador cualificado sigue formando parte del sistema que se evalúa.

Este modelo de “centauro” empareja a una persona con un agente de IA. La persona aporta criterio, contexto y revisión, mientras que el agente se encarga de la exploración, los borradores y los cambios mecánicos.

Real-SWE no compara agentes autónomos con equipos de expertos y agentes. Por tanto, sus resultados no deberían interpretarse como evidencia de que los asistentes de programación carecen de valor práctico.

Indican algo más específico. Las configuraciones probadas no sustituyen de forma fiable el trabajo de contextualización y verificación realizado por ingenieros experimentados.

Esa diferencia importa para las afirmaciones sobre despliegue. Asistir a un ingeniero y asumir de forma autónoma un cambio empresarial son umbrales de capacidad distintos.

Los compradores deberían exigir a los proveedores que indiquen qué umbral respalda su evidencia. Una puntuación pública por sí sola no puede responder a esa pregunta.

Lo que las cifras de Real-SWE no demuestran

El benchmark ofrece una advertencia significativa, pero su pequeña muestra privada no puede respaldar conclusiones generales sobre todos los modelos o bases de código empresariales.

En primer lugar, las tareas de Real-SWE proceden de empresas seleccionadas por Specific Labs. Los ejemplos publicados incluyen una aplicación de consumo, una plataforma fintech y software empresarial de ventas.

Specific Labs afirma que una de las aplicaciones representadas atiende a más de 200.000 usuarios. Otra plataforma, según se informa, procesa más de 100.000 extractos bancarios.

Esos detalles establecen relevancia comercial, pero las empresas siguen siendo anónimas. Los lectores no pueden evaluar de forma independiente su calidad de ingeniería, arquitectura o complejidad de dominio.

En segundo lugar, la privacidad del benchmark impide una replicación pública completa. Esa privacidad protege el código bajo licencia y reduce la contaminación directa, aunque concentra la autoridad de validación.

Los evaluadores independientes necesitan acceso controlado para confirmar la procedencia de las tareas, la calidad del verificador, la paridad del entorno y la puntuación. Sin esa revisión, cierta incertidumbre sigue siendo inevitable.

En tercer lugar, la clasificación combina distintos modelos con distintos arneses nativos. Esto se parece al uso real de los productos, pero debilita las conclusiones sobre la inteligencia subyacente de los modelos.

Una configuración puede perder porque falla su estrategia de búsqueda, se rompen sus llamadas a herramientas o su gestión de contexto descarta evidencia relevante. Son fallos de producto, pero no fallos idénticos.

En cuarto lugar, el benchmark utiliza la resolución automatizada como resultado principal. Superar un verificador es necesario, aunque la aceptabilidad empresarial puede requerir más.

La revisión de producción puede considerar mantenibilidad, observabilidad, seguridad, seguridad de migración, estilo y carga operativa futura. Un aprobado binario no puede captar plenamente esas dimensiones.

A la inversa, un parche válido puede fallar ante un verificador imperfecto. La historia de las auditorías de SWE-bench muestra que las pruebas ocultas pueden rechazar soluciones razonables o pasar por alto otras incompletas.

Real-SWE afirma que el comportamiento requerido debe estar declarado o ser razonablemente detectable. Ese estándar es sensato, pero “razonablemente detectable” sigue requiriendo criterio.

En quinto lugar, las tareas empresariales anónimas pueden favorecer a modelos o arneses cuyos patrones de exploración coincidan con el benchmark. Una estructura de repositorio distinta podría invertir algunas clasificaciones.

Los intervalos de confianza del 95 por ciento mostrados en la clasificación reconocen la variación de muestreo entre ejecuciones. No eliminan la incertidumbre derivada de seleccionar solo diez tareas.

En sexto lugar, la página de lanzamiento afirma de forma amplia que la mayoría de los tokens empresariales permanecen ocultos para los modelos de frontera. Esa afirmación respalda la motivación del benchmark, pero carece de detalles públicos de medición.

Debe tratarse como el encuadre de la empresa, no como una estadística establecida de forma independiente. La conclusión más prudente es que una parte sustancial del contexto empresarial sigue siendo privada.

Por último, una baja tasa de resolución autónoma no equivale a un bajo impacto en productividad. Un agente puede ahorrar tiempo mediante investigación, generación de pruebas, documentación o parches preliminares sin terminar de forma independiente.

También es cierto lo contrario. Un parche completado puede generar costes de revisión o riesgos sutiles que compensen su aparente rapidez.

Estas limitaciones no hacen que Real-SWE sea irrelevante. Definen las condiciones en las que sus hallazgos resultan útiles.

El benchmark es más sólido como evidencia de una brecha de despliegue. Es más débil como clasificación definitiva de modelos o pronóstico del empleo en ingeniería.

Specific Labs también es un participante comercial en datos y evaluación empresariales. Su perfil de empresa describe un negocio construido en torno a entornos y conjuntos de datos empresariales realistas.

Eso no invalida el trabajo. Hace más importantes la replicación independiente y una metodología transparente.

Un ecosistema de benchmarks creíble necesita múltiples operadores, tareas privadas rotativas y auditorías de terceros. Ninguna clasificación única debería convertirse en la autoridad final.

Tres señales que determinarán si Real-SWE importa

Real-SWE solo tendrá consecuencias si su señal de código privado resiste la expansión, la revisión independiente y lanzamientos repetidos de modelos.

La primera señal es el crecimiento del conjunto de tareas. Diez tareas pueden revelar modos de fallo, pero una colección mayor debe cubrir más lenguajes, arquitecturas y dominios de negocio.

La expansión debería preservar la procedencia privada al tiempo que publica suficientes metadatos para que los lectores comprendan la diversidad de las tareas. También debería separar las muestras basadas en repositorios de otros formatos de tareas.

Si las clasificaciones se mantienen similares en un conjunto de pruebas más amplio, la afirmación de una brecha empresarial persistente se fortalece. Grandes cambios de posición mostrarían que la selección determinó los resultados del lanzamiento.

La segunda señal es la evaluación independiente. Investigadores externos o proveedores de modelos necesitan acceso controlado para auditar tareas, verificadores y entornos de ejecución.

Una auditoría útil examinaría si las indicaciones contienen información suficiente, si las pruebas ocultas aceptan implementaciones alternativas y si las soluciones de referencia representan trabajo de producción genuino.

La coincidencia entre revisores independientes fortalecería la confianza en las tasas de resolución reportadas. Los defectos de prueba descubiertos limitarían o revisarían las conclusiones del benchmark.

La tercera señal es el progreso a lo largo de lanzamientos repetidos. Los benchmarks privados pierden valor si las tareas se filtran, se convierten en objetivos de entrenamiento o permanecen estáticas mientras los sistemas de agentes se adaptan.

Specific Labs necesitará tareas nuevas reservadas y un versionado claro. Los resultados deberían distinguir las mejoras procedentes de modelos, arneses, reintentos y exposición a las tareas.

Un aumento rápido de las puntuaciones en nuevas tareas privadas indicaría una mejor generalización. Las ganancias limitadas a tareas antiguas sugerirían una optimización en torno al propio benchmark.

Las empresas deberían observar la composición de los fallos junto con la tasa principal de aprobados. Menos requisitos incumplidos y menos supuestos sin verificar importarían más que parches generados más bonitos.

La consistencia también debería mejorar. Sigue siendo difícil confiar en un modelo que resuelve una tarea ocasionalmente cuando la misma indicación suele producir una regresión.

Las comparaciones entre humanos y agentes añadirían otra capa útil. Medir el tiempo de revisión y el tiempo total de finalización podría mostrar dónde los agentes ya crean valor sin autonomía total.

Real-SWE ha planteado la pregunta adecuada ante los desarrolladores y compradores de modelos. ¿Puede un agente modificar de forma segura un software cuya historia, convenciones y lógica de negocio nunca fueron públicas?

Sus primeros resultados indican que los sistemas actuales a menudo no pueden hacerlo. La mejor configuración resolvió menos de cuatro de cada diez intentos, mientras que los requisitos no cumplidos dominaron los fallos observados.

Esta conclusión debería impulsar mejores evaluaciones, no un rechazo generalizado. Los agentes de programación pueden seguir siendo valiosos cuando los ingenieros controlan el alcance, aportan contexto y verifican las consecuencias.

El siguiente paso práctico es probar trabajo interno representativo antes de ampliar los permisos. Los equipos deberían comparar configuraciones, repetir cada tarea y estudiar por qué fallan parches aparentemente razonables.

El benchmark Real-SWE importa si logra cambiar el comportamiento de compra: pasar de confiar en puntuaciones públicas a exigir evidencia privada. ¿Su próxima prueba de un agente de programación medirá código generado o trabajo terminado que su empresa pueda aceptar con seguridad?