Queda abrupta! Mesmo a IA mais avançada não consegue lidar com o desenvolvimento a longo prazo: quanto mais código acumulado, mais rápido o sistema entra em colapso

Comprar acções é apenas olhar para os relatórios de analistas da Golden Qilin: autoridade, profissionalismo, atempado e abrangente, ajude-o a descobrir oportunidades temáticas com potencial!

（Fonte: DeepTech）

Escreva uma função, e a IA é quase invencível; mas manter um sistema, porque é que a IA começa a falhar?

Atualmente, a inteligência artificial já entrou na “segunda metade”. À medida que as capacidades de programação da IA continuam a melhorar, produtos como o OpenClaw começam a surgir. “CLI everything” está a tornar-se realidade: a IA não precisa de operar o computador, mas sim transformar todas as interfaces em uma interface de linha de comandos (CLI). Habilidades, uma a uma, estão a transformar-se em funcionalidades de software.

Agora, o Agent não é apenas uma ferramenta de conversação para executar uma única tarefa; está a evoluir para um sistema de operação a longo prazo, interagindo com o mundo real e executando tarefas complexas. No entanto, aparece um novo problema: durante a evolução contínua, será que a IA consegue adaptar-se continuamente a novos ambientes e manter as capacidades de desenvolvimento estáveis?

O principal cientista de IA no “Gabinete do CEO/Presidência” da Tencent, Yao Shunyu, mencionou num blogue intitulado “The Second Half” que tarefas de programação reais dependem continuamente uma da outra, não são independentes e em paralelo. Mas, na academia, não existe, atualmente, um benchmark para avaliar as capacidades exigidas pela IA neste cenário; até falta coragem para quebrar a suposição de independência entre tarefas, amplamente aceite há muito tempo, usada para simplificar os problemas.

Recentemente, uma equipa conjunta, incluindo a University of Southern California, a University of California Riverside, a Stanford University, a Princeton University e a OpenHands, lançou um novo benchmark de avaliação, o EvoClaw, propondo uma nova solução para as questões acima. A equipa de investigação extraiu históricos de evolução de código de alta qualidade a partir de projetos open source, permitindo que o Agent completasse continuamente dezenas de iterações funcionais interdependentes na mesma base de código.

Os resultados mostram que a IA de topo tem um desempenho excelente em tarefas avaliadas de forma independente (pontuações 80%+); mas, quando entra em cenários reais de longo ciclo, mesmo o Claude Opus 4.6 com pontuação geral mais alta só alcança 38,03%. Isto significa que, para tarefas em que existe maior liberdade de execução, a IA tende a desviar-se do rumo; ainda há uma diferença significativa em relação ao que consegue realmente lidar com um trabalho de evolução de software longo e contínuo.

（Fonte: arXiv）

Este estudo revela que, na evolução a longo prazo, a IA tende facilmente a cair numa dívida técnica em espiral tipo “bola de neve”. Embora consiga continuar a adicionar novas funcionalidades, não consegue controlar a acumulação de erros na regressão, o que acaba por levar o sistema a perder o controlo. Isto também significa que a programação por IA está a mudar de escrever código para governação de sistemas.

O artigo relacionado, intitulado “EvoClaw: Evaluating AI Agents on Continuous Software Evolution”, foi publicado recentemente no site de pré-impressões arXiv[1].

Figura丨 Artigo relacionado (Fonte: arXiv)

Atualmente, a avaliação de programação por IA e a experiência real estão desalinhadas: onde está o problema?

Por que é que os modelos de topo que obtêm boas pontuações nas avaliações independentes falham em conjunto no teste EvoClaw? A raiz do problema é que a metodologia de avaliação mudou.

Em estudos anteriores, os principais benchmarks de avaliação de programação focavam na maioria das vezes em tarefas independentes: dado um tema (issue) ou um pedido de alteração (PR, Pull Request), o modelo completa a correção numa captura estática do código; a validação passa e a avaliação é concluída.

Mas existe uma lacuna que não pode ser ignorada entre os resultados dos benchmarks anteriores e as capacidades reais de desenvolvimento: o ambiente estático é um estado relativamente ideal, enquanto o ambiente real é muito mais complexo e dinâmico. À medida que o tempo passa, mesmo um bug pequeno de alguns meses atrás, após iterações de versão, pode tornar-se cada vez maior como uma bola de neve, levando a que o sistema colapse.

（Fonte: arXiv）

O primeiro autor do artigo, o estudante de doutoramento da University of Southern California, Deng Gangda, disse à DeepTech: “O nível de granulação dos commits e das releases existentes é demasiado miúdo ou demasiado grosseiro. Assim, esses históricos de desenvolvimento não conseguem refletir o processo de evolução do software.”

Figura丨 Deng Gangda (Fonte: entrevistado)

Pela primeira vez, a equipa de investigação introduziu a dimensão do tempo no sistema de avaliação das capacidades de programação por IA. Utilizaram uma hierarquia totalmente nova — Milestone — para reconstruir o histórico da evolução do software, permitindo unidades funcionais que conciliam integridade semântica e preservação de dependências de evolução. Isso exige que a IA conclua, por ordem, várias unidades funcionais na mesma base de código. Assim, não só preserva o resultado de cada passo, como também se torna o ponto de partida para o passo seguinte.

（Fonte: arXiv）

Para suportar a extração de históricos de evolução de software de alta qualidade a partir de grandes quantidades de bases de código open source, os investigadores, com base nas capacidades fortes de agentes de IA de topo, propuseram um conjunto de pipeline automatizado orientado por Agent, DeepCommit. Foi a primeira vez que reconstruiu um registo de desenvolvimento Git “barulhento” num grafo de dependências de tarefas de Milestone (Milestone DAG) verificável e coeso por funcionalidade, e construiu um ambiente de avaliação para cada Milestone. Inclui principalmente três fases: pré-processamento do histórico Git, construção do DAG orientada por Agent e configuração e validação do ambiente de Milestone.

Na prática, reconstruir a evolução histórica do Agent com Milestone não é fácil, porque não é apenas construir um DAG estático que possa ser puramente observado; é preciso também uma sequência de ambientes de avaliação executáveis, mantendo a correção enquanto as dependências de evolução mudam.

Isto significa que, ao embaralhar a ordem global dos commits e depois reorganizá-los em clusters e conectá-los novamente, podem surgir situações em que os commits não conseguem ser aplicados, as interfaces não batem certo e há erros de compilação em grande escala. Para resolver este problema, os investigadores desenharam um ciclo iterativo de reparação: o Agent analisa ativamente os registos de erro e modifica dinamicamente o Dockerfile para garantir executabilidade.

Mais importante ainda, ele complementa dependências implícitas que foram omitidas com base no DAG original, ajustando as relações de restrição de precedência dos Milestones para resolver adequadamente os conflitos de interfaces. Após inúmeras iterações, conseguiu, finalmente, recolher corretamente 87,1% dos casos de teste originais.

“Comparado com o cenário de uma única tarefa de programação, a programação autónoma estável, fiável e eficaz de longo ciclo é uma área de investigação mais avançada e quente. Por exemplo, a Anthropic e a OpenAI deixam claro que já mudaram o foco para a capacidade de programação de longo ciclo dos modelos em treino.” Disse Deng Gangda.

Figura丨 Diagrama da arquitetura do pipeline DeepCommit (Fonte: arXiv)

Os investigadores compararam o grafo de evolução gerado automaticamente pelo DeepCommit com as anotações manuais de especialistas humanos. O que lhes surpreendeu foi que ambos usam lógicas de organização diferentes e complementam-se entre si.

Mais especificamente, os Milestones dos especialistas humanos são normalmente definidos dentro de uma janela temporal local: primeiro definem o tema e depois agrupam os commits. É uma decomposição semântica de cima para baixo. O DeepCommit, para garantir precisão absoluta, reconstrói a evolução do software de baixo para cima com base nas relações de dependência entre commits, colocando maior ênfase na estrutura topológica e nas restrições de execução.

Para a avaliação, isto mostra exatamente que o papel-chave do DeepCommit é extrair, do histórico de desenvolvimento do código, uma estrutura de Milestone executável e verificável. Pelos resultados, o DeepCommit consegue filtrar tarefas de Milestone de alta qualidade, adequadas para avaliação, e que são executáveis e verificáveis em ambientes reais, assegurando a fiabilidade da avaliação.

Assim que se entra no desenvolvimento real, porque é que as pontuações dos modelos “caem para metade” em conjunto?

O EvoClaw abrange cinco linguagens de programação mainstream, incluindo Python, Java, Go, Rust e TypeScript. Os projetos selecionados atravessam o período de desenvolvimento real mais longo, até 750 dias.

Quanto às métricas de avaliação, a equipa de investigação não adotou uma taxa de aprovação simples. Em vez disso, introduziu dois dimensionamentos mais centrais — Recall (taxa de recuperação) e Precision (precisão) — e usou a ponderação do F1 como pontuação de cada Milestone. A taxa de recuperação mede a completude de implementação de funcionalidades, enquanto a precisão captura o grau em que o modelo ao adicionar novas funcionalidades destrói o código existente.

A equipa testou várias combinações de frameworks e modelos, como Claude Code e OpenHands. Os resultados mostram que, em avaliações independentes, as pontuações dos modelos de topo tendem a ficar entre 80%-90%. Mas após os testes de benchmark do EvoClaw, todas sofreram uma queda abrupta em conjunto. O Claude Opus 4.6 com maior pontuação apenas obteve 38,03%.

Figura丨 Principais resultados experimentais do EvoClaw (Fonte: arXiv)

O GPT 5.3 Codex, com uma pontuação geral de 28,88%, fica logo atrás do Opus 4.6 e ocupa o segundo lugar. Por secção de repositório, o GPT 5.3 Codex tem desempenho fraco em dois projetos Rust (Nushell, ripgrep), mas nos restantes repositórios consegue aproximar-se ou até ultrapassar o Opus 4.6. Na taxa de resolução total, mesmo o Gemini 3 Pro com melhor pontuação é apenas 13,37%, e a grande maioria das implementações corretas são tarefas sem dependências prévias.

Segundo se sabe, os investigadores controlaram o custo global dentro de um intervalo razoável. Por exemplo, no caso do Claude Opus 4.5, o custo para uma avaliação completa é de cerca de 500 dólares; Kimi K2.5 e Gemini 3 Flash ficam dentro de 50 dólares; quanto a modelos pequenos, o custo é ainda mais baixo.

（Fonte: arXiv）

Então, se dermos ao modelo uma janela de desenvolvimento mais longa, ele acabará por conseguir resolver 100% do projeto?

O estudo dá uma resposta negativa: independentemente de quanto se prolongue a janela de desenvolvimento, o desempenho final de todos os modelos vai inevitavelmente atingir um “teto”. Quanto mais tarde a ordem de execução das tarefas e quanto mais profundo é o nível no DAG, mais baixas ficam as pontuações e as taxas de resolução. A extrapolação fora da função de saturação prova que, mesmo para o Opus 4.6 ideal, a pontuação acumulada fica presa em torno dos 45% na curva assintótica.

“Embora o Opus 4.6, no site oficial da Anthropic, mencione que tem melhor desempenho em tarefas de longo ciclo do que o 4.5, não forneceu indicadores de avaliação detalhados. O EvoClaw valida essa afirmação a partir de outro ângulo.” Disse Deng Gangda.

Além disso, os experimentos também mostraram diferenças significativas entre famílias de modelos. Em concreto, o desempenho de Claude e GPT no cenário de evolução contínua melhora de forma constante com as atualizações de versão. Entre eles, o Opus 4.6 demonstrou o melhor desempenho de manutenção do sistema na programação de longo ciclo; o GPT 5.3 fica na segunda posição porque tem desempenho fraco no conjunto de dados Rust, o que reduz a pontuação.

（Fonte: arXiv）

O que surpreende, ao comparar, é que a família Gemini apresenta uma tendência completamente diferente: de 3 Flash para 3 Pro e depois para 3.1 Pro, cada geração arranca mais rápido no início e tem melhor desempenho na fase inicial, mas o desempenho a longo alcance praticamente não melhora de forma significativa. Deng Gangda explicou: “A queda evidente do desempenho do Gemini em execução de longo ciclo significa que não é apenas o seguimento de instruções que piora — ele também passa cada vez mais a ignorar as necessidades das especificações do software (SRS) — e, ao mesmo tempo, carece de manutenção do sistema de software que constrói.”

Quando os investigadores decomporam ainda mais a pontuação global em Recall e Precision, apareceu um fenómeno mais interessante: a taxa de recuperação quase apresenta uma tendência contínua de aumento, aproximando-se de um crescimento quase linear. Isto significa que, mesmo quando a base de código fica cada vez mais caótica e frágil, o Agent ainda é bom em implementar as novas funcionalidades para os objetivos atuais.

O verdadeiro gargalo está na precisão: o Agent tem dificuldade em manter sistemas existentes. A velocidade com que os erros de regressão se acumulam supera a sua capacidade de corrigir esses problemas, e é exatamente essa a causa fundamental de que o desenvolvimento a longo prazo acabe por estagnar.

Figura丨 Esquerda: diagrama ilustrativo da cadeia de erros; Direita: distribuição da cadeia de erros (Fonte: arXiv)

Para compreender em profundidade a causa fundamental de quando os modelos perdem o controlo durante as iterações, a equipa de investigação propôs uma estrutura de análise das Error Chains (cadeias de erros). A partir do primeiro momento em que ocorre um erro, eles seguiram cada teste e observaram se o erro é herdado, se se propaga, se é ignorado ou se é corrigido nos Milestones subsequentes.

Os resultados mostram que a velocidade de surgimento de novos problemas não se acelera; o modelo pode até reparar de forma substancial alguns erros históricos, mas a velocidade de acumulação de erros anteriores supera claramente a velocidade de reparação. No fim, acaba por cair num “default de dívida técnica”.

Para fornecer avaliação geral ao depurar com AI Harness

Recentemente, há um conceito muito em voga, “Harness Engineering”, que pretende configurar todo o fluxo de desenvolvimento de software para um ambiente que seja adequado para o envolvimento de Agent. O benchmark do EvoClaw fornece um playground desse tipo, geral e adequado para avaliar evolução de código de longo ciclo, funcionando bem para depurar o framework AI Harness.

Por exemplo, os casos de falha mencionados neste estudo: se o Agent de repente se mostrar muito proativo em iterar, ou se ficar constantemente a editar e a validar, é provável que o Agent tenha encontrado dificuldades. Nessa situação, pode-se construir proteções (guard-rails) nas posições correspondentes para detetar problemas cedo e permitir intervenção humana atempada, melhorando a eficiência.

Uma vez que a arquitetura do modelo dá ao Agent a propriedade geral de “implementar novas funcionalidades muito mais do que manter funcionalidades antigas de longo prazo”, então o futuro poderá dar origem a uma nova forma de software e a novos modos de desenvolvimento?

Por exemplo, o software irá enfatizar mais flexibilidade e compatibilidade, com reestruturações massivas mais fiáveis; ou ainda será mais “descartável”: a lógica de negócio específica é gerada em tempo real, sem necessidade de manutenção, com foco em reforçar componentes reutilizáveis e infraestruturas.

A equipa de investigação acredita que, ao afrouxar adequadamente as restrições de qualidade do software nos modos de desenvolvimento, é possível reduzir o número de intervenções humanas, trocando por maior capacidade de processamento (throughput), acelerando assim a iteração do software.

Deng Gangda apontou: “Este estudo prova que estamos a seguir um caminho correto: a capacidade de programação de longo prazo da IA ainda não atingiu um gargalo, conseguindo melhorar de forma estável com o tempo. Há potencial para que, num determinado dia repentinamente, a mudança quantitativa das pontuações em rankings se converta numa mudança qualitativa que altere o mundo.”

Com o desenvolvimento da tecnologia, no futuro, a IA pode evoluir: de reduzir gradualmente a participação humana no desenvolvimento de software, para que a IA apresente necessidades novas de forma autónoma e evolua a base de código, até que a IA ultrapasse totalmente os humanos e abandone os humanos, e finalmente realize uma evolução contínua de si mesma.

Referências:

1. Artigo relacionado:

2. Página do projeto:

Paginação: Liu Yaqun

Notícias em grande volume, interpretações precisas — tudo na app Sina Finance