Michael JohnsonÉ possível atribuir uma tarefa a um agente, aguardar as alterações no repositório e receber um rascunho de pull request para revisão. Mas, junto com o código, surge uma pergunta: o resultado atende à tarefa e os testes deixaram passar algum problema importante?
Em 4 de fevereiro de 2026, o GitHub anunciou a prévia pública do Claude e do Codex como agentes de código. A empresa informou que é possível atribuir tarefas aos agentes a partir de issues e pull requests e, depois, revisar o rascunho de PR preparado por eles. Isso confirma que esse fluxo passou a estar disponível na interface de desenvolvimento, mas não comprova economia de tempo nem melhoria da qualidade do código.
A questão, portanto, não é apenas se o agente consegue escrever código. Importa saber que trabalho a pessoa precisa realizar em torno da tarefa delegada: definir restrições, acompanhar o andamento e avaliar o resultado.
A supervisão não se resume à revisão final
Em um preprint publicado no arXiv em 21 de setembro de 2026, pesquisadores propõem tratar a supervisão de agentes de código como um processo contínuo. O estudo The Work Behind Delegation baseia-se em observações e esquemas de fluxo de trabalho de 19 desenvolvedores experientes. Os autores descrevem sete etapas de supervisão e aplicam essa estrutura a discussões públicas de desenvolvedores no Reddit.
Entre as abordagens descritas pelos autores estão dar mais atenção ao planejamento, delegar parte das tarefas de supervisão a outros agentes e transformar instruções recorrentes em materiais reutilizáveis. Trata-se de uma estrutura analítica, não de uma medição do tempo gasto: o estudo não determina quanto tempo os desenvolvedores dedicam à supervisão nem se esse processo é mais rápido do que o trabalho manual. Na página do arXiv, o preprint está marcado como em revisão por pares, portanto suas conclusões devem ser consideradas preliminares.
Na prática, é útil distinguir três ações. Definir a tarefa estabelece o objetivo e as restrições. Acompanhar ajuda a perceber se o agente se desviou do que foi pedido. Verificar permite avaliar se o resultado pode ser aceito, considerando os requisitos, o código e os testes. O êxito em uma etapa não garante o da seguinte: um patch pode parecer plausível, mas resolver o problema errado ou exigir uma reformulação substancial.
A experiência da comunidade não é estatística
Em uma discussão no r/LocalLLaMA, um participante escreveu que sua experiência com modelos locais e agentes foi decepcionante: segundo ele, era preciso corrigir o resultado e lembrar os agentes das instruções. Outros participantes da mesma conversa descreveram um fluxo de trabalho que lhes foi mais útil: limitar as tarefas, trabalhar por etapas e revisar o código com atenção. São observações individuais de usuários, não um teste comparativo de modelos nem uma medição da produtividade das equipes.
Esses relatos diferentes mostram que a experiência pode depender da tarefa, do modelo, do ambiente e da forma de trabalhar. Mas uma única discussão não permite determinar quais práticas são, em média, mais eficazes ou com que frequência surgem problemas. A conversa trata de modelos locais, portanto suas observações não devem ser automaticamente generalizadas para todas as ferramentas com agentes.
A participação humana não significa, por si só, que delegar seja inútil. O desenvolvedor pode dividir a tarefa em partes, verificar as alterações e esclarecer os requisitos, continuando responsável pelo resultado final. Mas, sem contabilizar o tempo gasto na definição da tarefa, nas correções e na revisão, não é possível dizer se o volume total de trabalho diminuiu.
Um rascunho de PR ainda não é um PR aprovado
No fluxo descrito pelo GitHub, é possível atribuir um issue ao agente e receber um rascunho de pull request. Entre sua criação e a aprovação, permanecem questões distintas: a alteração atende aos requisitos, considera os casos extremos, tem testes suficientes e é adequada à arquitetura do projeto?
Esses critérios não podem ser reduzidos a uma única métrica. O número de alterações criadas não equivale ao número de alterações aproveitáveis, e a aprovação nos testes não necessariamente confirma todas as propriedades importantes do patch. Mesmo um resultado que parece de alta qualidade não revela, por si só, quanto trabalho foi necessário para prepará-lo e revisá-lo.
Para avaliar o efeito geral, é preciso considerar o ciclo completo: definir a tarefa, aguardar o resultado, revisar, corrigir e manter o código posteriormente. As fontes analisadas não oferecem essa comparação abrangente.
O que é possível concluir
O preprint propõe uma estrutura para discutir a supervisão, e o GitHub informou sobre um fluxo em que se atribui uma tarefa a um agente e se revisa o PR que ele preparou. A discussão no Reddit mostra que alguns usuários relatam tanto dificuldades quanto formas úteis de trabalhar com modelos locais. Em conjunto, esses materiais permitem perguntar como organizar a revisão do código delegado, mas não respondem qual é o ganho líquido de produtividade.
Não é possível concluir, a partir deles, que os desenvolvedores em geral já passaram da escrita de código para a supervisão, que os agentes sempre criam trabalho adicional ou que aumentam a produtividade do setor. Para chegar a essas conclusões, são necessárias medições comparáveis de tempo e qualidade em tarefas e equipes diferentes.
A pergunta prática para uma equipe é mais específica: que alterações o agente pode preparar sozinho, o que precisa ser verificado antes da integração e quem é responsável por garantir que o resultado resolva a tarefa original? Delegar não elimina esse trabalho de engenharia — muda onde ele começa e em que se concentra.