Meu Agente Entregou 3 PRs em uma Noite. 40% das Minhas Mensagens Foram Correções.

Meu agente de codificação baseado em IA enviou três pull requests em uma única noite, mas 40% das 30 mensagens que enviei foram correções.

A sessão produziu um cliente MCP, um Azure AI Agent e um M365 Copilot Agent. Verificações automatizadas aprovaram os três PRs, e eu nunca editei uma única linha de código. No entanto, a transcrição conta uma história diferente: de um total de 710 mensagens, eu digitei 30, e 12 delas redirecionaram o agente de volta ao caminho certo. A "taxa de direcionamento" (steering rate) — a parcela das minhas mensagens que foram correções — ficou em 40%.

Como o pipeline foi estruturado

  • Claude elaborou um plano de implementação de alto nível.
  • DeepSeek V4-Flash atuou como o orquestrador, revisando o plano.
  • Codex gerou o código real.
  • O orquestrador inspecionou o código e abriu os pull requests.

O papel pretendido do orquestrador era puramente de conexão — ele deveria resolver conflitos entre componentes, não escrever o código em si. Na prática, o agente produziu 3.500 linhas de código nos três PRs em aproximadamente 40 minutos, mas também falhou em duas classes de erros recorrentes.

As duas famílias de erros

  1. Violações de fluxo de trabalho — o orquestrador ocasionalmente assumia a etapa de codificação, ignorando seu papel de "cola" (glue) e escrevendo os detalhes da implementação por conta própria.
  2. Falhas de recuperação de contexto — apesar das instruções explícitas, o agente selecionou o SDK ou a versão errada. A informação correta estava no contexto do prompt, mas o modelo falhou em apresentá-la no momento certo.

Essas não são lacunas na capacidade de raciocínio; são bugs de engenharia na forma como o fluxo de trabalho é restringido. Mesmo um modelo de linguagem mais capaz ainda precisaria de uma regra rígida e impossível de ignorar que prenda o orquestrador às suas funções de não-codificação e force a seleção correta do SDK.

O que mudei para domar o agente

Parei de assumir que o sistema inferiria seu papel a partir da lista de etapas. Adicionei uma declaração direta: “Você é um orquestrador. Você não implementa.” Foram necessárias cinco mensagens corretivas para que a instrução fosse assimilada, após as quais o agente respeitou o limite.

Também apertei a lógica de recuperação de contexto. Quando a ferramenta errada aparecia, eu a tratava como um bug no pipeline de recuperação, em vez de uma alucinação, e reescrevi o prompt que fornece os detalhes do SDK para tornar a versão correta impossível de ser ignorada.

Lições práticas para o desenvolvimento aumentado por IA

  • Conte suas próprias mensagens. Um alto volume de PRs aceitos pode mascarar um processo quebrado. Sua contagem de correções é um indicador antecedente de onde o processo está falhando.
  • Declare o papel explicitamente. Agentes não extrapolam a identidade a partir de uma lista de verificação; eles precisam de uma instrução clara e fixa sobre quem são e o que podem fazer.
  • Trate erros de escolha de ferramenta como bugs de engenharia. Se o agente ignorar um SDK especificado, a culpa reside no mecanismo de entrega de contexto, não no "conhecimento" do modelo.
  • Converta erros em habilidades reutilizáveis. Deixei o agente gerar uma rotina de validação a partir de seus próprios erros, transformando uma falha em uma salvaguarda futura.

O que está em jogo de forma mais ampla