Por que a IA tem dificuldade para retomar uma tarefa inacabada

Embora agentes de IA consigam resolver tarefas complexas, um novo estudo indica que têm dificuldade para continuar o trabalho iniciado por outra pessoa ou agente. Isso duplica esforços, torna o progresso mais lento e aumenta os custos.

Um dos aspectos mais cansativos, mas essenciais, do trabalho com agentes e interfaces de IA é a necessidade de colocar a IA a par da situação no início de quase toda troca de mensagens.

Embora modelos de linguagem populares, como o ChatGPT, ofereçam algum acesso a memórias persistentes personalizadas, o funcionamento costuma ser inconsistente. No fim, normalmente é mais seguro fazer o esforço de explicar à IA o contexto da tarefa*, nem que seja para impedir o modelo de adivinhar um contexto errado a partir do seu espaço latente, formado durante o treinamento.

Retomando o trabalho pendente no mundo real

O desafio é anterior à IA, é claro. Muitas empresas já exigem que os funcionários documentem os processos que desenvolvem ou aperfeiçoam, em parte para facilitar a integração de novos colegas, mas também, pode-se argumentar, para impedir que os funcionários ganhem poder de negociação.

Na prática, porém, muitas vezes são apenas as organizações maiores e mais bem financiadas que realmente criam, atualizam e mantêm a documentação. Quem precisa assumir o trabalho dos outros frequentemente recebe, em vez disso, uma tarefa de detetive: é necessário reconstruir pacientemente a sequência dos acontecimentos que levou ao trabalho inacabado que agora lhe foi entregue.

Uma documentação impecável obviamente economizaria dias, semanas ou até meses de trabalho, desde que sua produção fosse financeiramente justificável.

Quando quem executa o trabalho são agentes de IA, porém, pode haver mais oportunidades para resolver o problema.

Passagem do trabalho

Um novo artigo de pesquisa dos EUA quantifica essa carga causada pela falta de documentação e chama o problema de dívida de transferência.

Se a dívida técnica descreve como soluções técnicas rápidas, improvisadas e baratas de hoje levam a sistemas frágeis ou difíceis de manter no futuro, a dívida de transferência define o custo de redescoberta — a reconstrução, a partir dos vestígios deixados, dos passos de um trabalhador ou de outra entidade que não está disponível para orientar, por exemplo após uma demissão conflituosa, por falta de tempo ou por ter falecido. A entidade também pode ser incapaz de orientar, como um modelo de linguagem que já perdeu o contexto que levou ao estado atual do trabalho.

O novo artigo^† — uma colaboração entre pesquisadores independentes e pesquisadores vinculados à Georgia State University — analisa a dívida de transferência no caso de agentes de programação que precisam continuar, em uma base de código, de onde outra sessão, pessoa ou entidade parou.

Um dos objetivos é estabelecer quanta documentação é necessária para reduzir a dívida de transferência e quais procedimentos e protocolos poderiam ser recomendados como prática padrão no futuro para minimizar o problema.

Restrições de orçamento

Em uma situação ideal, seria possível configurar o registro de logs para o modo detalhado, verbose e simplesmente fornecer ao novo agente que assume a tarefa os logs do trabalho inacabado.

No entanto, extrair informações úteis de um volume tão grande de dados levaria tempo, consumiria o orçamento de tokens e poderia esbarrar nos limites de espaço de armazenamento.

Isso é um problema de orçamento: processar dados brutos exportados é pesado, enquanto logs selecionados e organizados são menos confusos, mas exigem uma alocação prévia de recursos.

Anotações preparadas especificamente para a transferência colocariam o sucessor a par da situação com muita eficiência. Mas exigiriam ainda mais preparação, que talvez nunca fosse necessária se a lógica do trabalho acabasse sendo evidente, o trabalho fosse abandonado ou nunca mais fosse revisado.

Os autores do novo trabalho, intitulado Handoff Debt: The Rediscovery Cost When Coding Agents Take Over Interrupted Tasks, consideraram todos esses cenários e adaptaram modelos de tarefas existentes a novas formas de quantificar e enfrentar a dívida de transferência. Embora a pesquisa se concentre em agentes de programação, ela pode apontar caminhos úteis também para usos mais amplos da IA e para a organização das políticas de documentação.

Os autores afirmam:

“A dívida de transferência surge quando um agente faz progresso visível, mas deixa um estado a partir do qual o sucessor não consegue continuar facilmente, como alterações sem explicação, arquivos temporários de trabalho, pressupostos ocultos ou falta de evidências de validação.

“Uma métrica baseada apenas na resolução final não permite distinguir uma redescoberta dispendiosa de uma continuação eficiente.

“Dois agentes antecessores podem deixar o mesmo ponto de controle de um repositório, mas seus sucessores enfrentarão custos de continuação muito diferentes: um pode continuar imediatamente, enquanto outro precisa de muitas interações com ferramentas para reconstruir a intenção a partir de arquivos temporários e de um histórico incompleto de comandos.”

Método

Os autores definem antecessor como o agente anterior (aquele que iniciou o trabalho ou o executou pela última vez) e sucessor como o agente atual, encarregado de assumir o trabalho.

Para criar um benchmark que mede o custo de transferir tarefas inacabadas de engenharia de software entre agentes, 75 tarefas do SWE-bench Verified foram convertidas em 181 cenários de transferência, cada um correspondente a um ponto em que o trabalho foi interrompido e passado a um agente sucessor. Em seguida, três modelos diferentes de sucessor foram testados em 2.172 tentativas de assumir o trabalho.

As famílias de modelos usadas em diferentes combinações nesses testes de transferência foram Qwen, Gemma e Devstral.

Os experimentos examinaram quatro níveis de informações herdadas. Na condição mais restritiva, o sucessor recebeu apenas o estado do repositório, como se entrasse em uma zona de desastre sem documentação. As outras condições ofereceram um contexto cada vez mais detalhado, desde registros de atividades e históricos de comandos até resumos concisos do que já havia sido tentado e aprendido:

Em vez de se concentrar apenas em saber se a tarefa acabou resolvida, o estudo foi projetado para medir o custo da própria continuação, considerando o uso de ferramentas, o consumo de tokens e o esforço para reconstruir o raciocínio por trás do trabalho anterior.

Para os experimentos, foram definidos três momentos que acionam a transferência e três estados na transferência:

Dados e testes

Para criar cenários realistas de transferência, os autores construíram o benchmark com 75 tarefas de engenharia de software do SWE-bench Verified, com foco em problemas que normalmente levam de 15 minutos a 4 horas para resolver.

Em vez de avaliar apenas tarefas concluídas, os pesquisadores registraram vários pontos de controle intermediários durante o trabalho, criando situações em que um agente de IA precisava assumir a tarefa de outro:

Construção do benchmark de transferência de tarefas. As 75 tarefas do SWE-bench Verified foram expandidas para 181 pontos de transferência em três etapas de trabalho, classificados pelo estado do repositório no momento da transferência e avaliados em quatro condições de compartilhamento de informações, resultando em 2.172 execuções nas quais o agente sucessor assume a tarefa. Fonte

Como cada tarefa podia gerar vários pontos de transferência e cada ponto era testado com quatro formas de informações transmitidas, o benchmark cresceu rapidamente. O conjunto final reuniu 181 tarefas distintas de transferência e 724 avaliações por modelo sucessor, totalizando 2.172 execuções nos três sistemas de IA testados.

Os testes de programação usaram um ambiente do tipo OpenHands, com ações no terminal, congelamento do estado do repositório nos pontos de transferência, edição de arquivos e validação oficial SWE-bench.

No estudo principal, todos os pontos de transferência vêm de execuções em que o antecessor é Qwen, para garantir um ponto de partida fixo ao avaliar diferenças entre combinações de agentes e cenários.

Os pares testados foram Qwen → Qwen, Qwen → Gemma e Qwen → Devstral.

O registro bruto produziu as maiores reduções no esforço do sucessor, diminuindo os eventos do agente em 57–59%, enquanto as notas de resumo e as notas estruturadas reduziram os eventos em 20–46%. O consumo de tokens de entrada também caiu nas três abordagens, com reduções de 42–63%:

Nas transferências com apenas o repositório, os sucessores precisaram de interações adicionais para reconstruir a intenção do antecessor, as evidências anteriores e as abordagens que falharam. O registro bruto, as notas de resumo e as notas estruturadas transmitiram parte dessas informações diretamente, reduzindo a necessidade de redescoberta, embora exigissem prompts iniciais maiores.

Para verificar se os ganhos eram reais, cada transferência com mais contexto foi comparada a uma transferência com apenas o repositório que partia do mesmo ponto. Em todos os pares de modelos, o contexto mais rico reduziu de modo consistente o trabalho necessário do sucessor.

Os registros completos de eventos produziram as maiores reduções, mas as notas de resumo e as notas estruturadas também geraram economias substanciais. O efeito apareceu em todo o benchmark e não foi causado por poucos casos incomuns:

Para confirmar que o efeito não era causado por poucos casos incomuns, os pesquisadores compararam cada transferência a uma transferência com apenas o repositório que partia do mesmo ponto. As reduções continuaram consistentes em todos os pares de modelos, indicando um padrão significativo de benefícios, e não apenas alguns exemplos excepcionais.

A principal lição…

Em resumo^†, os autores descobriram que, quando um agente de IA passa uma tarefa a outro, até notas simples ajudam o segundo agente a continuar com mais eficiência.

Os registros completos de eventos funcionam melhor, mas qualquer informação na transferência é preferível a deixar o sucessor reconstruir tudo apenas a partir do código. Os resultados acima também mostram que a abordagem baseada no log bruto completo inevitavelmente tem um custo maior de tokens.

Conclusão

Embora o próprio artigo se destine estritamente a outros pesquisadores e tenha apelo limitado para o leitor comum, o novo trabalho aborda um dos problemas mais interessantes e urgentes das atuais interfaces e dos protocolos entre humanos e IA.

Espera-se que os métodos desenvolvidos e as percepções obtidas nesse tipo de pesquisa possam se estender a usos mais amplos da IA, além da programação por agentes.

Uma direção adicional para pesquisas futuras seria avaliar o nível mínimo de documentação de um projeto com base em suas características e em seu caso de uso. No entanto, até essa funcionalidade, que ajudaria a racionalizar o gasto de tempo e dinheiro, exige tempo e dinheiro. Assim, o dilema orçamentário da documentação continua difícil de evitar.

* 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