¡Caída abrupta! Incluso la IA más potente no puede manejar el desarrollo a largo plazo: cuanto más código se acumula, más rápido se colapsa el sistema

¡Para invertir en acciones, consulta los informes de análisis de los analistas de Gold Kirin; son autorizados, profesionales, oportunos y completos; te ayudan a descubrir oportunidades temáticas con potencial!

（Fuente：DeepTech深科技）

Escribe una función y la IA es casi invencible; pero, ¿por qué al mantener un sistema la IA empieza a colapsar?

Actualmente, la inteligencia artificial ya ha entrado en el “segundo semestre”. A medida que las capacidades de programación de la IA siguen mejorando, productos como OpenClaw están surgiendo poco a poco; “CLI everything” se está volviendo una realidad: la IA ya no necesita operar el ordenador, sino que convierte todas las interfaces en interfaces de línea de comandos (CLI); habilidades que antes eran “una por una” se están transformando en funciones de software.

Ahora, un Agent ya no es solo una herramienta de conversación para ejecutar una tarea puntual, sino que está evolucionando hacia un sistema de operación a largo plazo, que interactúa con el mundo real y ejecuta tareas complejas. Sin embargo, aparece un problema nuevo: durante la evolución continua, ¿puede la IA adaptarse constantemente a entornos nuevos y mantener estable su capacidad de desarrollo?

El científico jefe de IA en la “Oficina del CEO/Presidente” de Tencent, Yao Shunyu, mencionó en un blog titulado “The Second Half” que las tareas reales de programación dependen de forma consecutiva, no son paralelizables de manera independiente; pero en el ámbito académico actual no existe un benchmark de este tipo para evaluar las capacidades que la IA necesita en ese escenario, e incluso falta valor para romper el supuesto de independencia entre tareas — algo que durante mucho tiempo se ha aceptado ampliamente, precisamente para simplificar los problemas.

Recientemente, un equipo conjunto de la University of Southern California (USC), la University of California, Riverside (UCR), Stanford University, Princeton University, OpenHands, etc., publicó un nuevo benchmark de evaluación, EvoClaw, como una propuesta para resolver el problema anterior. El equipo de investigación extrajo historiales de evolución de código de alta calidad a partir de proyectos de código abierto, para que el Agent complete de manera continua, en un mismo repositorio, decenas de iteraciones funcionales con dependencias entre sí.

Los resultados muestran que la IA de primer nivel rinde de forma excelente en tareas de evaluación independientes (con puntajes de 80%+). Sin embargo, cuando entra en escenarios reales de ciclo largo, incluso el puntaje total más alto de Claude Opus 4.6 apenas logra 38.03%. Esto significa que, para tareas con mayor libertad de ejecución, la IA tiende a desviarse de la ruta; todavía existe una brecha significativa frente a lo que realmente puede manejar trabajo de evolución de software continuo y de largo ciclo.

（Fuente：arXiv）

Este estudio revela que, en la evolución a largo plazo, la IA cae con extrema facilidad en una “bola de nieve” de deuda técnica. Aunque puede seguir agregando nuevas funciones, no logra controlar la acumulación de errores al retornar; finalmente el sistema queda fuera de control. Esto también implica que la programación con IA está cambiando de “escribir código” a “gobernanza del sistema”.

El artículo relacionado, titulado 《EvoClaw：Evaluating AI Agents on Continuous Software Evolution》 (EvoClaw：Evaluating AI Agents on Continuous Software Evolution), se publicó recientemente en el sitio web de preprints arXiv[1].

Figura丨Artículo relacionado (Fuente：arXiv)

En la actualidad, la evaluación de la programación con IA no coincide con la experiencia real; ¿dónde está el problema?

¿Por qué los modelos punteros que obtienen altas puntuaciones en las pruebas independientes pierden colectivamente en la evaluación EvoClaw? La raíz está en que el paradigma de evaluación ha cambiado.

En estudios anteriores, la mayoría de los benchmarks de evaluación de programación convencionales se enfocaban en tareas independientes: se entrega un tema (issue) o una solicitud de extracción (PR, Pull Request); el modelo completa la corrección sobre una instantánea estática del código; si la verificación pasa, la evaluación se considera completada.

Pero entre los resultados de benchmarks pasados y la capacidad real de desarrollo existe una brecha que no se puede ignorar: el entorno estático es un estado relativamente ideal, mientras que el entorno real es más complejo y dinámico. Con el avance del tiempo, incluso un bug pequeño de hace meses, tras iteraciones de versión, puede hacerse cada vez más grande como una bola de nieve, y acabar provocando que el sistema colapse.

（Fuente：arXiv）

El primer autor del artículo, el estudiante de doctorado de la University of Southern California, Deng Gangda, dijo a DeepTech: “La granularidad de los commits y releases existentes es o demasiado fina o demasiado gruesa. Por lo tanto, estos historiales de desarrollo no reflejan el proceso de evolución del software.”

Figura丨Deng Gangda (Fuente：entrevistado)

El equipo de investigación introdujo por primera vez la dimensión temporal en el sistema de evaluación de la capacidad de programación con IA. Empleó un nivel completamente nuevo — Milestone — para reconstruir la historia de la evolución del software, de modo que pueda mantener a la vez la integridad semántica y la capacidad de conservar dependencias de evolución. Exige que la IA complete secuencialmente múltiples unidades de funcionalidad sobre el mismo repositorio; así no solo se conserva la producción de cada paso, sino que también se convierte en el punto de partida del siguiente.

（Fuente：arXiv）

Para apoyar la extracción de historiales de evolución de software de alta calidad a partir de grandes repositorios de código abierto, los investigadores, basándose en la potente capacidad de la IA de vanguardia, propusieron un conjunto de canalizaciones automatizadas impulsadas por Agent, DeepCommit. Esto implementa por primera vez la reconstrucción de registros de desarrollo de Git ruidosos en un grafo de dependencias de tareas de Milestone verificables y cohesionadas por función (Milestone DAG), y construye un entorno de evaluación para cada Milestone. Incluye principalmente tres etapas: preprocesamiento del historial de Git, construcción del DAG impulsada por Agent y configuración y verificación del entorno de Milestone.

En realidad, reconstruir la evolución histórica del Agent con Milestone no es fácil, porque no solo hay que construir un DAG estático que sea puramente observable; además, hace falta una secuencia de entornos de evaluación ejecutables, y al mismo tiempo asegurar la corrección mientras cambian las dependencias de evolución.

Esto significa que, cuando se desordena el orden global de los commits y se vuelven a agrupar y conectar, puede ocurrir que los commits no se puedan aplicar, que las interfaces queden desalineadas y que aparezcan errores masivos de compilación. Para resolver este problema, los investigadores diseñaron un ciclo iterativo de reparación: el Agent analiza activamente los logs de error y modifica dinámicamente el Dockerfile para asegurar que sea ejecutable.

Lo más clave es que, basándose en el DAG original, completa dependencias implícitas omitidas; mediante el ajuste de las relaciones de restricciones de “prioridad” entre Milestones, los conflictos de interfaces pueden resolverse adecuadamente. Tras repetidas iteraciones, finalmente se logra recolectar correctamente el 87.1% de los casos de prueba originales.

“Comparado con un escenario de una única tarea de programación, la programación autónoma estable, fiable y efectiva de ciclo largo es un tema de investigación más avanzado. Por ejemplo, Anthropic y OpenAI han dejado claro que han trasladado el foco a la capacidad de programación de ciclo largo de sus modelos.”, dijo Deng Gangda.

Figura丨Diagrama de la arquitectura de la canalización DeepCommit (Fuente：arXiv)

Los investigadores compararon el grafo de evolución generado automáticamente por DeepCommit con las anotaciones manuales de expertos humanos. Lo que les sorprendió fue que ambos adoptaron lógicas de organización diferentes y a la vez se complementaban.

En concreto, los Milestone de los expertos humanos suelen estar dentro de una ventana local de tiempo: primero definen el tema y luego reúnen los commits. Es un desglose semántico de arriba hacia abajo; en cambio, DeepCommit, para garantizar una precisión absoluta, parte de las relaciones de dependencia entre commits, reconstruye el hilo de la evolución del software de abajo hacia arriba y enfatiza más la estructura topológica y las restricciones de ejecución.

Para la evaluación, esto precisamente demuestra que la clave de DeepCommit consiste en extraer de la historia de desarrollo del código una estructura de Milestones ejecutable y verificable. Según los resultados, DeepCommit puede filtrar Milestones de alta calidad, adecuados para evaluación, y que además son ejecutables y verificables en entornos reales, aportando garantías para la fiabilidad de la evaluación.

Al entrar en un desarrollo real, ¿por qué las puntuaciones de los modelos “se desploman” colectivamente?

EvoClaw cubre cinco lenguajes principales: Python, Java, Go, Rust y TypeScript. Los proyectos seleccionados abarcan el ciclo de desarrollo real más largo de hasta 750 días.

En cuanto a métricas de evaluación, el equipo de investigación no adoptó una tasa de aprobación simple; en su lugar introdujo dos dimensiones más centrales: Recall y Precision, con un F1 ponderado como puntuación de cada Milestone. Donde el Recall se usa para medir la exhaustividad de la implementación de funcionalidades; y la Precision captura en qué medida el modelo al añadir nuevas funciones rompe el código existente.

El equipo de investigación probó múltiples combinaciones de marcos y modelos, como Claude Code y OpenHands. Los resultados muestran que en evaluaciones independientes, las puntuaciones de los modelos punteros suelen estar entre 80%-90%; pero después de pasar las pruebas basadas en el benchmark EvoClaw, todas caen de forma drástica. El que obtuvo la puntuación más alta, Claude Opus 4.6, solo obtuvo 38.03%.

Figura丨Resultados principales del experimento de EvoClaw (Fuente：arXiv)

GPT 5.3 Codex, con una puntuación total integral de 28.88%, queda justo detrás de Opus4.6, ocupando el segundo lugar. Por repositorio, GPT 5.3 Codex rinde más débil en dos proyectos de Rust (Nushell, ripgrep), mientras que en el resto de repositorios puede acercarse e incluso superar a Opus4.6. En cuanto a tasa de resolución completa, incluso Gemini 3 Pro, con la puntuación más alta, solo alcanza 13.37%, y la gran mayoría de las implementaciones correctas corresponden a tareas sin dependencias previas.

Según se informó, los investigadores mantuvieron los costos globales dentro de un rango razonable. Por ejemplo, con Claude Opus 4.5, el costo de una evaluación completa es de aproximadamente 500 dólares; Kimi K2.5 y Gemini 3 Flash están dentro de los 50 dólares; los costos de los modelos pequeños serán aún más bajos.

（Fuente：arXiv）

Entonces, si se diera a los modelos una ventana de desarrollo más larga, ¿podrían al final completar el proyecto al 100%?

El estudio da una respuesta negativa: independientemente de lo larga que sea la ventana de desarrollo, el rendimiento final de todos los modelos terminará chocando con un “techo”. Cuanto más tarde se ejecuta una tarea en el orden y cuanto más profundo es el nivel en el DAG, más baja serán la puntuación y la tasa de resolución. La extrapolación fuera de la función de saturación prueba que incluso el óptimo Opus 4.6 tiene su puntaje acumulado atrapado alrededor de una línea asintótica de ~45%.

“Aunque Opus 4.6 en el sitio web oficial de Anthropic menciona que se desempeña mejor que 4.5 en tareas de ciclo largo, no proporcionó indicadores de evaluación detallados. EvoClaw verifica su afirmación desde otro ángulo.”, dijo Deng Gangda.

Además, en el experimento también se observaron diferencias significativas entre familias de modelos. En concreto, el desempeño de Claude y GPT en escenarios de evolución continua mejora de manera constante con las actualizaciones de versión. Entre ellos, Opus 4.6 ha demostrado su mejor rendimiento en mantenimiento de sistemas en programación de ciclo largo; GPT 5.3 reduce la puntuación debido a su mal desempeño en el dataset de Rust, y por eso ocupa el segundo lugar.

（Fuente：arXiv）

Lo más inesperado al comparar es que la familia Gemini muestra una tendencia completamente distinta: de 3 Flash a 3 Pro y luego a 3.1 Pro, cada generación arranca más rápido al inicio y tiene mejor desempeño en la fase temprana, pero su desempeño de larga distancia casi no mejora de forma significativa. Deng Gangda explicó: “El claro deterioro de Gemini en ejecuciones de ciclo largo significa que no solo empeora en el seguimiento de instrucciones, sino que cada vez ignora más las necesidades de la Especificación de Requisitos de Software (SRS), además de carecer de mantenimiento del sistema de software que construye.”

Cuando los investigadores descompusieron aún más la puntuación total en Recall y Precision, surgió un fenómeno más interesante: el Recall muestra casi una tendencia continuamente creciente, acercándose al crecimiento lineal. Esto significa que, aunque el repositorio se vuelve cada vez más caótico y frágil, el Agent aún es experto en implementar las nuevas funciones objetivo que se le asignan.

El verdadero cuello de botella está en la Precision: al Agent le cuesta mantener el sistema existente; la velocidad de acumulación de errores vuelve a superar su capacidad para reparar esos problemas, y ahí está la causa fundamental por la que el desarrollo a largo plazo termina estancándose.

Figura丨Izquierda: diagrama ilustrativo de la cadena de errores; derecha: distribución de la cadena de errores (Fuente：arXiv）

Para comprender a fondo la razón fundamental por la cual los modelos se descontrolan durante la iteración, el equipo propuso un marco de análisis de Cadenas de Error (Error Chains). Siguen cada test desde el primer momento en que ocurre el error, y observan si el error se hereda, se difunde, se omite o se repara en los Milestones posteriores.

Los resultados muestran que la velocidad de aparición de nuevos problemas no se acelera; incluso el modelo repara de manera sustancial parte de los errores históricos bajo la forma de reacción pasiva. Sin embargo, la velocidad de acumulación de errores previos supera con creces la velocidad de reparación, y finalmente cae en una “quiebra de deuda técnica”.

Para depurar AI Harness con una evaluación general

Recientemente hay un concepto muy candente: “Harness Engineering”, que busca configurar todo el proceso de desarrollo de software en un entorno apto para la participación de Agent. El benchmark EvoClaw ofrece un playground general que evalúa la evolución del código a largo plazo, y es adecuado para depurar el marco AI Harness.

Por ejemplo, en los casos de fallo mencionados en este estudio, si un Agent de repente muestra una iteración muy proactiva, o edita y valida de forma constante, es muy posible que el Agent se esté encontrando con dificultades. En ese caso, se pueden construir “barandillas/guardrails” en las ubicaciones correspondientes para detectar los problemas con anticipación e intervenir a tiempo de manera manual, mejorando así la eficiencia.

Dado que la arquitectura del modelo le da al Agent una propiedad general de que “implementar nuevas funciones es muy superior a mantener funciones antiguas a largo plazo”, ¿es posible que en el futuro surjan nuevas formas de software y patrones de desarrollo?

Por ejemplo, el software podría enfatizar más la flexibilidad y la compatibilidad, o reorganizaciones a gran escala más fiables; o bien, podría volverse más “de una sola vez”: la lógica de negocio específica se genera en tiempo real y no necesita mantenimiento; el foco estaría en reforzar componentes reutilizables e infraestructura.

El equipo de investigación considera que, en los patrones de desarrollo, relajar adecuadamente las restricciones sobre la calidad del software puede reducir la cantidad de intervención humana, a cambio de un mayor rendimiento (throughput), acelerando así la iteración del software.

Deng Gangda señaló: “Este estudio prueba que vamos por un camino correcto; la capacidad de programación de IA a largo plazo aún no ha encontrado cuellos de botella y puede mejorar de forma estable con el tiempo. Con potencial de que, algún día de repente, la variación cuantitativa de los puntos de la tabla se transforme en un cambio cualitativo que altere el mundo.”

Con el desarrollo de la tecnología, es posible que en el futuro la IA evolucione desde la reducción gradual de la participación humana en el desarrollo de software; hacia que la IA proponga nuevas necesidades de forma autónoma para evolucionar el repositorio de código; y finalmente hasta que la IA supere por completo a los humanos, los abandone y logre una autoevolución continua.

Referencias：

1. Artículo relacionado：

2. Página de inicio del proyecto：

Maquetación：Liu Yaqun

Gran cantidad de información, interpretación precisa: todo en la app de Sina Finance