Por que a IA tem dificuldade em pegar uma tarefa inacabada

Embora os agentes de IA possam resolver tarefas complexas, um novo estudo indica que eles têm dificuldade em continuar o trabalho iniciado por outro, levando a esforço duplicado, progresso mais lento e maior custo.

Uma das tarefas mais exaustivas, mas essenciais, ao lidar com agentes e interfaces de IA é que a IA precisa ser “trazida ao mesmo nível” no início de uma troca, na maioria dos casos.

Enquanto modelos de linguagem populares, como ChatGPT, oferecem algum acesso a memórias personalizadas “persistentes”, a implementação geralmente é um assunto de sorte; no final, é normalmente mais seguro aceitar o esforço de contextualizar* a tarefa para a IA – pelo menos, para evitar que ela “adivinhe” um contexto errado a partir de seu espaço latente treinado .

Pegando o Slack do Mundo Real

O desafio precede a IA, é claro; muitas empresas já exigem que os funcionários mantenham documentação sobre processos que desenvolvem ou aprimoram (em parte para uma integração mais suave, mas também para evitar que os funcionários ganhem vantagem).

No entanto, na prática, é frequentemente apenas as organizações maiores e melhor financiadas que honram um compromisso de criar, atualizar e manter documentação. Muito frequentemente, em vez disso, os funcionários que precisam pegar o trabalho de outros são entregues a uma tarefa de “detetive” que exige que eles desentranhem pacientemente a linha do tempo que levou ao trabalho abandonado que agora lhes foi dado.

É óbvio que uma documentação imaculada economizaria dias, semanas ou até meses de trabalho – se apenas fosse uma proposta financeiramente racional.

No entanto, onde os agentes de IA são os operativos em questão, pode haver um maior escopo para potencialmente resolver o problema.

Entregue

Essa carga de “não documentação” é quantificada em um novo artigo de pesquisa dos EUA, que chama o problema de dívida de entrega.

Se dívida técnica é a síndrome em que soluções técnicas rápidas e baratas hoje levam a soluções frágeis ou difíceis de manter no futuro, então dívida de entrega define o custo de redescoberta – a retraçagem forense dos passos de um trabalhador ou entidade que não está disponível para aconselhar (demissão hostil, muito ocupado, morto, etc.) ou que não pode aconselhar (por exemplo, um LLM que já eliminou o contexto que levou ao estado atual do trabalho).

O novo artigo^† – uma colaboração entre pesquisadores independentes e afiliados à Universidade Estadual da Geórgia – lida com a dívida de entrega como se aplica a agentes de codificação que são encarregados de pegar onde outro agente, pessoa ou entidade parou em um código.

Um dos objetivos do trabalho é estabelecer exatamente quanto de documentação é necessário para reduzir a dívida de entrega e quais procedimentos e protocolos podem ser recomendados para adotar como prática padrão no futuro, para minimizar o problema.

Preocupações Orçamentárias

Em um mundo ideal, alguém poderia definir o registro para verbose e simplesmente alimentar o agente neófito (aquele que pega a tarefa) com os registros relacionados à tarefa incompleta.

No entanto, analisar esse volume de dados em dados úteis seria demorado e também consumiria o orçamento de tokens – além de trazer restrições de espaço de armazenamento.

Isso é um problema orçamentário, porque usar dumps brutos é exaustivo, enquanto usar logs curados é menos confuso, mas exige um compromisso prévio de recursos.

Notas adequadas e dedicadas seriam muito eficazes para colocar um “artista de pegar” em velocidade, mas ao custo de um compromisso ainda maior de esforço – esforço que pode nunca ser necessário, se a lógica do trabalho acabar provando ser autoevidente, ou se o trabalho for abandonado, ou nunca revisado novamente.

Os autores do novo trabalho, intitulado Dívida de Entrega: O Custo de Redescoberta Quando Agentes de Codificação Assumem Tarefas Interrompidas, consideraram todos esses cenários e adaptaram modelos de tarefa existentes a novas maneiras de quantificar e abordar a dívida de entrega. Embora o trabalho lide especificamente com agentes de codificação, ele pode indicar rotas úteis para contextos mais amplos de IA e políticas de documentação.

Os autores afirmam:

‘A dívida de entrega surge quando um agente faz progresso visível, mas deixa um estado que um sucessor não pode prontamente continuar, como edições não explicadas, arquivos de rascunho, suposições ocultas ou evidências de validação faltantes.

‘Uma métrica baseada apenas na resolução final não pode distinguir entre redescoberta custosa e continuação eficiente.

‘Dois agentes antecessores podem deixar o mesmo repositório marcado, mas seus sucessores podem enfrentar custos de continuação muito diferentes: um pode continuar imediatamente, enquanto outro deve gastar muitas interações de ferramenta redescobrindo a intenção a partir de arquivos de rascunho e histórico de comando incompleto.’

Método

Os autores definem antecessor como o agente anterior (aquele que originou ou última vez realizou o trabalho) e sucessor como o agente atual (aquele encarregado de pegar o trabalho),

Em apoio a um benchmark projetado para medir o custo de transferir tarefas de engenharia de software inacabadas entre agentes, 75 tarefas do SWE-bench Verificado foram convertidas em 181 pontos de entrega cenários, cada um representando um ponto em que o trabalho foi interrompido e passado para um agente sucessor. Três diferentes modelos de sucessor foram testados em 2.172 tentativas de assumir o trabalho.

As famílias de modelos usadas, e variadamente misturadas nesses testes de entrega, foram Qwen, Gemma e Devstral.

Os experimentos examinaram quatro níveis de informações herdadas: no cenário mais restritivo, o sucessor recebeu apenas o estado do repositório (efetivamente, entrando em uma “área de desastre” não documentada). Outros cenários forneceram contexto cada vez mais detalhado, desde traços de atividade e histórico de comandos, até resumos compactos que descreviam o que já havia sido tentado e aprendido:

Rather than focusing solely on whether a task was eventually solved, o estudo foi projetado para medir o custo de continuação em si, com atenção dada ao uso de ferramentas, consumo de tokens e quantidade de esforço necessário para reconstruir o raciocínio por trás do trabalho anterior.

Três definições de detecção de ponto de entrega e três estados de entrega foram definidos para os experimentos:

Dados e Testes

Para criar cenários de entrega realistas, o benchmark dos autores foi construído a partir de 75 tarefas de engenharia de software extraídas do SWE-Bench Verificado, com ênfase em problemas que normalmente levam entre 15 minutos e 4 horas para resolver.

Ao invés de avaliar apenas tarefas concluídas, os pesquisadores capturaram vários pontos intermediários durante o trabalho, criando situações em que um agente de IA precisava assumir o trabalho de outro:

Construção do benchmark de entrega. Setenta e cinco tarefas do SWE-bench Verificado foram expandidas em 181 pontos de entrega que abrangem três estágios de trabalho, rotulados de acordo com o estado do repositório no momento da entrega e avaliados sob quatro condições de compartilhamento de informações, produzindo 2.172 execuções totais de agente sucessor. Fonte

Como cada tarefa pode gerar vários pontos de entrega e cada entrega é testada usando quatro formas diferentes de informações transferidas, o benchmark se expande rapidamente, com o conjunto de dados final compreendendo 181 tarefas de entrega distintas e 724 avaliações de agente sucessor para cada modelo de agente sucessor, produzindo 2.172 execuções de agente sucessor nos três sistemas de IA testados.

Um ambiente de agente de codificação do tipo OpenHands foi usado para os testes, apresentando ações de terminal, congelamento de repositório nos pontos de entrega, edição de arquivos e validação oficial do benchmark SWE-Bench.

No estudo principal, todos os pontos de entrega provêm de execuções do antecessor baseadas em Qwen, a fim de fornecer um ponto de partida fixo para avaliar a diferença entre várias combinações de agentes e os diversos cenários.

Os pares de agente testados foram Qwen-para-Qwen; Qwen-para-Gemma; e Qwen-para-Devstral.

Traço bruto produziu as maiores reduções no esforço do sucessor, cortando eventos do agente por 57-59%, enquanto Notas de resumo e Notas estruturadas reduziram eventos por 20-46%. O uso de tokens de prompt também caiu em todas as três abordagens, com reduções variando de 42-63%:

Em entregas Repositório apenas, os agentes sucessores tiveram que gastar interações adicionais reconstruindo a intenção do antecessor, evidências anteriores e abordagens fracassadas. Traço bruto, Notas de resumo e Notas estruturadas transferiram parte dessas informações diretamente, reduzindo a quantidade de redescoberta necessária, embora ao custo de prompts iniciais maiores.

Para testar se os ganhos eram genuínos, cada entrega rica em contexto foi comparada com uma entrega Repositório apenas iniciada a partir do mesmo ponto. Em todas as combinações de modelos, entregas mais ricas consistentemente reduziram o trabalho necessário dos agentes sucessores.

Registros de eventos completos produziram as maiores reduções, enquanto notas de resumo e notas estruturadas também entregaram economias substanciais. O efeito permaneceu consistente em todo o benchmark, indicando que os benefícios refletem um padrão significativo, em vez de alguns exemplos excepcionais:

Para confirmar que o efeito não foi impulsionado por alguns casos incomuns, os pesquisadores compararam cada entrega contra uma entrega Repositório apenas equivalente iniciada a partir do mesmo ponto. As reduções permaneceram consistentes em todas as combinações de modelos, indicando que os benefícios refletem um padrão significativo, em vez de alguns exemplos excepcionais.

Leve-o Embora…

Em resumo^†, os autores descobriram que quando um agente de IA entrega uma tarefa para outro, até mesmo notas simples ajudam o segundo agente de IA a continuar mais eficientemente.

Registros de eventos completos funcionam melhor, mas qualquer informação de entrega é melhor do que deixar o sucessor reconstruir tudo a partir do código sozinho; e os resultados acima ilustram que a abordagem “completa” de traço bruto inevitavelmente tem um maior custo de token.

Conclusão

Embora o artigo em si seja dirigido estritamente a pesquisadores colegas, com apelo limitado para o leitor casual, o novo trabalho aborda um dos problemas mais interessantes e prementes em relação ao estado atual da arte em interfaces e protocolos humanos>IA.

Alguém poderia esperar que os paradigmas desenvolvidos e as percepções ganhas nesse tipo de exploração possam eventualmente se estender a um contexto mais amplo de uso de IA do que apenas codificação agente.

Uma avenue adicional de exploração pode ser que projetos futuros considerem maneiras de avaliar qual nível de documentação pode ser considerado o mínimo para um projeto específico, com base em suas características e caso de uso. No entanto, mesmo essa funcionalidade, que ajudaria a racionalizar o gasto de tempo e dinheiro, por si só custa tempo e dinheiro; e assim, o dilema orçamentário envolvido em cenários de documentação permanece difícil de escapar.

* Pessoalmente, para sessões do ChatGPT que se tornam sobrecarregadas com atrasos e contexto excessivo, eu tenho recentemente adotado a prática de exportar (com alguma dificuldade) um PDF limpo da conversa e usá-lo como ponto de partida para uma nova sessão, que se torna ‘parte 2’.

^† Infelizmente, este não é o artigo mais acessível que eu li este ano, e por essa razão, não posso recomendar ao leitor o trabalho original, embora os resultados resumidos permaneçam de interesse.

Publicado pela primeira vez na quarta-feira, 3 de junho de 2026