Como reduzir retrabalho em código gerado por IA

Quando uma alteração gerada por IA volta para a fila, pedir outra resposta ao modelo pode só trocar o sintoma. A equipe reduz retrabalho quando classifica a origem provável da falha: requisito, contexto ou verificação. O diagnóstico vem antes da correção: a inteligência artificial implementou a coisa errada, decidiu com informação insuficiente ou passou por um processo incapaz de barrar a falha.

Por que o retrabalho de código gerado por IA precisa ser classificado

Quando uma alteração assistida por inteligência artificial volta da revisão, a reação mais comum é tratar tudo como problema de código. Ajusta uma função, muda uma condição, troca um teste, pede outra geração. Às vezes funciona. Mas, quando o erro reaparece, a equipe descobre que corrigiu o sintoma.

O incômodo não está apenas no tempo gasto. Está na opacidade do aprendizado. Se ninguém sabe por que a falha aconteceu, todo retrabalho vira uma conversa genérica sobre “a IA errou”, “faltou revisar melhor” ou “o prompt estava ruim”. Essas frases podem ser verdadeiras, mas raramente orientam a próxima decisão.

A separação útil é mais simples:

erro de requisito: a tarefa permitia interpretações diferentes;
erro de contexto: a tarefa era razoável, mas o agente não tinha informações suficientes para decidir bem;
erro de verificação: requisito e contexto existiam, mas a falha passou por revisão, testes ou integração.

Essa classificação define onde a equipe deve investir a próxima correção. Reescrever a demanda é uma ação diferente de atualizar o contexto. Criar uma verificação objetiva é diferente de revisar estilo ou pedir mais cuidado.

Esse ponto também evita uma armadilha de liderança: comprar velocidade na geração e pagar juros na integração. O DORA recomenda unidades de trabalho pequenas, independentes e testáveis para obter retorno mais cedo sobre mudanças e hipóteses. A mesma orientação alerta para a dificuldade de revisar e integrar grandes mudanças geradas com IA. Para reduzir retrabalho, tamanho e rastreabilidade importam.

Erro de requisito: quando a IA implementa bem a coisa errada

Um erro de requisito acontece quando o código é uma resposta plausível para uma pergunta mal delimitada. A IA não necessariamente “alucinou”. Ela escolheu uma interpretação possível, mas diferente da intenção da equipe.

Sinais comuns:

a tarefa descrevia a intenção geral, mas não o comportamento esperado;
a regra de negócio tinha exceções não documentadas;
o critério de aceite era subjetivo, como “melhorar”, “corrigir” ou “ajustar”;
produto e engenharia tinham expectativas diferentes sobre a mesma mudança;
a revisão só descobriu o problema ao simular um caso que não estava na tarefa.

Exemplo fictício: uma equipe pede a um agente para “corrigir o desconto promocional”. O agente altera o cálculo para todos os clientes com cupom ativo. A mudança compila e parte dos testes passa. Na revisão, alguém percebe que a promoção valia apenas para um segmento específico, durante uma campanha limitada, e não deveria se sobrepor a uma regra de fidelidade já existente.

Nesse caso, pedir ao agente para “corrigir melhor” provavelmente gera outra aposta. A causa principal é requisito. Antes de mexer no código, a tarefa deveria explicitar segmento, período, prioridade entre regras, exemplo de entrada e saída, além da condição de aceite.

Um bom teste prático é este: se uma pessoa revisora não consegue escrever um critério de aceite antes da correção, o problema começa no requisito. O código pode até estar errado, mas a primeira intervenção deve ser na demanda.

Erro de contexto: quando falta informação para decidir a alteração

Contexto não é despejar documentação no modelo. É selecionar o que o modelo precisa considerar para inferir corretamente. A Anthropic define engenharia de contexto como seleção e manutenção das informações disponíveis ao modelo durante a inferência, incluindo instruções, ferramentas, dados externos e histórico, dentro de uma janela limitada.

Em desenvolvimento de software, isso muda a pergunta. Não basta perguntar se a tarefa estava clara. É preciso perguntar se o agente tinha acesso ao que tornava aquela solução correta naquele repositório.

Sinais de erro de contexto:

o agente altera a camada errada da aplicação;
replica um padrão antigo que a equipe já abandonou;
ignora uma decisão arquitetural registrada em outro lugar;
cria uma solução incompatível com dependências próximas;
modifica arquivos fora do escopo porque não recebeu limites claros;
resolve o caso local, mas quebra uma convenção usada no restante do sistema.

Imagine, em outro exemplo fictício, uma aplicação de logística em que as validações de prazo devem ficar em um serviço específico. O agente recebe uma tarefa clara: impedir agendamentos em dias indisponíveis. Sem conhecer a convenção do repositório, ele adiciona a regra diretamente no controlador. O comportamento visível parece correto, mas a solução fere a arquitetura e dificulta manutenção.

A causa principal não é requisito. Uma pessoa conseguiria escrever o critério de aceite. O problema é que o agente não tinha o conjunto certo de informações para decidir onde e como alterar.

A ação correspondente é atualizar o contexto fornecido ao agente: convenções relevantes, decisões de arquitetura, arquivos prováveis, limites de escopo e exemplos internos necessários. Isso não exige documentação extensa por padrão. Exige curadoria. Mais contexto nem sempre melhora a decisão; contexto errado ou desatualizado pode piorá-la.

Esse diagnóstico também muda a conversa sobre uso de IA. Em vez de perguntar apenas “a equipe usa IA?”, faz mais sentido perguntar se ela consegue selecionar, manter e revisar o contexto que acompanha tarefas críticas. A quantidade de ferramentas diz pouco se o processo não transforma erros recorrentes em ajustes verificáveis.

Erro de verificação: quando o processo não consegue barrar a falha

Há casos em que requisito e contexto eram suficientes, mas a alteração ruim passou. A causa principal, então, é verificação.

Verificação inclui testes automatizados, construção automatizada, revisão humana com critérios, critérios de aceite executáveis e integração frequente. A DORA descreve integração contínua como integração frequente ao código principal, acompanhada de construção e testes automatizados. Também orienta que corrigir uma construção quebrada tenha prioridade sobre novas mudanças.

Isso não transforma integração contínua em garantia de qualidade. Um teste mal desenhado pode confirmar o caminho feliz e ignorar o caso que importa. Uma revisão pode focar estilo e deixar passar uma mudança de comportamento. Uma construção pode passar porque não existe checagem para a regra afetada.

Sinais de erro de verificação:

o bug só aparece em revisão manual exploratória;
não havia teste para a exceção relevante;
a revisão aprovou porque o diff parecia pequeno;
o build passava, mas não exercitava o comportamento alterado;
o critério de aceite não foi convertido em checagem objetiva;
a mesma falha reaparece depois de uma correção anterior.

A documentação do GitHub sobre agentes do Copilot descreve recursos com ambientes e permissões distintos e ressalta supervisão humana e revisão das saídas. Para este artigo, a implicação prática é direta: revisão humana não deve ser um carimbo final. Ela precisa ter critérios, evidências e autoridade para interromper a mudança.

Se a falha passou, a próxima correção deve produzir evidência. Pode ser um teste novo, uma checagem de build, um cenário de aceite reproduzível ou uma restrição de escopo mais objetiva. O ponto é evitar que a equipe aceite uma alteração apenas porque agora “parece certa”.

Como decidir a causa principal antes de corrigir o código

Em mudanças reais, quase sempre há causas secundárias. Um requisito ambíguo pode vir acompanhado de contexto incompleto. Uma verificação fraca pode esconder uma demanda mal escrita. Ainda assim, a equipe precisa escolher uma causa principal para agir.

Uma regra operacional ajuda:

se uma pessoa não consegue escrever um teste ou critério de aceite antes da correção, comece por requisito;
se consegue escrever o teste, mas o agente não tinha informação para chegar à solução adequada, comece por contexto;
se o agente tinha requisito e contexto suficientes, mas a falha passou, comece por verificação;
se a alteração misturou correção, refatoração e mudança de comportamento, classifique como inconclusiva até dividir o trabalho;
se a falha reapareceu, investigue o ponto de processo que continuou permitindo o erro.

Esses critérios devem ser usados antes da correção, não depois. Depois que alguém conserta manualmente, a conversa tende a se deslocar para a solução encontrada. A equipe perde a chance de observar o que faltou no sistema de trabalho.

Um registro simples basta:

causa principal marcada: requisito, contexto, verificação ou inconclusiva;
evidência usada para a decisão;
ajuste feito no requisito, no contexto ou na verificação;
critério para reconhecer se o mesmo tipo de erro voltou.

Essa disciplina evita duas distorções. A primeira é culpar sempre o modelo. A segunda é transformar todo erro em dívida de documentação. Às vezes, a tarefa estava clara e o contexto era adequado, mas faltava uma checagem objetiva. Às vezes, os testes estavam bons, mas o agente nunca recebeu a decisão arquitetural relevante.

Como reduzir o tamanho do retrabalho com mudanças menores

Retrabalho cresce quando a mudança é grande demais para ser entendida, revisada e revertida com segurança. Isso vale para código humano e para código gerado por IA, mas fica mais visível quando um agente produz muitos arquivos rapidamente.

A orientação de lotes pequenos do DORA oferece um critério aplicável: unidades de trabalho pequenas, independentes e testáveis ajudam a revisar hipóteses mais cedo. Em uma tarefa assistida por IA, isso pode ser traduzido em quatro limites:

uma hipótese verificável por tarefa;
arquivos esperados ou áreas prováveis de alteração;
comportamento esperado descrito antes da geração;
condição de parada para não misturar correção com refatoração.

Se a tarefa pede “corrigir o fluxo de checkout”, a revisão vira arqueologia. Se pede “impedir que um cupom expirado seja aplicado no cálculo final, sem alterar a regra de frete”, a equipe consegue classificar melhor qualquer falha.

A unidade pequena preserva capacidade de decisão. Quanto menor a alteração, mais fácil dizer se o problema estava no requisito, no contexto ou na verificação.

O que registrar depois de uma correção gerada ou revisada por IA

O registro depois da correção deve ser curto o suficiente para sobreviver à rotina e preciso o suficiente para gerar aprendizado.

Um bom registro responde:

qual era a mudança pretendida;
qual foi a falha observada;
qual causa principal foi marcada;
que evidência sustentou essa marcação;
que ajuste foi feito no requisito, no contexto ou na verificação;
que sinal indicará repetição do mesmo problema.

Se a causa foi requisito, o registro deve melhorar a forma de pedir. Se foi contexto, deve atualizar o conjunto de informações que acompanha tarefas semelhantes. Se foi verificação, deve fortalecer a checagem antes de aceitar nova mudança.

Essa é a diferença entre retrabalho como custo invisível e retrabalho como dado operacional. A equipe reduz recorrência quando aprende onde o processo permitiu a falha.

Regra operacional: quando uma alteração assistida por IA voltar para a fila, marque a causa principal como requisito, contexto ou verificação antes de corrigir o código.

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.

Leituras para continuar

Fontes

PRÓXIMA DECISÃO

Conversar sobre a aplicação na empresa

Conversa sobre o contexto da empresa de software

Conteúdo de dooop. O cadastro permite relacionar esta pauta à jornada do leitor e acompanhar o interesse pelo tema.