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
- 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.
- 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.
