Agentes de Codificação: A Importância dos Sinais que Você Fornece

Leia este artigo em Signadot.

A indústria passou os últimos anos otimizando as capacidades de geração de código dos agentes de IA. O foco tem sido expandir janelas de contexto, ajustar modelos em dados específicos de repositórios e desenvolver estratégias de prompting complexas. Isso, sem dúvida, produziu agentes de codificação mais capazes. No entanto, para a maioria das equipes, essa capacidade de geração de código não se traduziu em ganhos significativos de produtividade.

A maioria das equipes de engenharia está presa em um fluxo de trabalho manual. O agente gera o código, o testa localmente e envia um PR para o desenvolvedor revisar. A implementação do código, a validação de que ele funciona e o feedback sobre quaisquer problemas de integração para o agente acontecem em um ritmo humano. Esse fluxo de trabalho impõe um teto rígido nos ganhos de produtividade que os agentes podem oferecer, transformando os desenvolvedores em um gargalo de validação.

Mas algumas empresas estão permitindo uma verdadeira autonomia para seus agentes e vendo os ganhos de produtividade que a IA promete. Organizações como Stripe, Ramp e as equipes internas da OpenAI e Anthropic chegaram à mesma realização: a qualidade da saída de um agente é diretamente proporcional à qualidade do ciclo de feedback que ele recebe.

“A qualidade da saída de um agente é diretamente proporcional à qualidade do ciclo de feedback que ele recebe.”

Para elevar os engenheiros a arquitetos e ver a velocidade da geração de código agentiva se traduzir em produtividade, as equipes de engenharia de plataformas precisam reconsiderar sua estratégia. Em vez de focar em dar aos desenvolvedores melhores agentes de codificação, a alavanca mais impactante pode ser dar aos agentes uma melhor infraestrutura de feedback.

A lição da engenharia de harness

A OpenAI documentou recentemente como eles construíram um produto de software completo usando o Codex com o princípio orientador de “Humanos dirigem. Agentes executam.” O sucesso deles não foi impulsionado apenas pela inteligência do modelo ou pela engenharia de prompting. Foi impulsionado por um grande investimento no ambiente em que o agente operava.

Uma equipe de apenas três engenheiros gerou um produto funcional com usuários internos e milhões de linhas de código ao projetar ambientes, especificar intenções e construir ciclos de feedback rigorosos. O trabalho principal dos engenheiros mudou de escrever código de implementação para construir a estrutura que permitiu que os agentes verificassem seu próprio trabalho. Essa abordagem é conhecida como engenharia de harness.

A engenharia de harness envolve equipar os agentes com as ferramentas e restrições necessárias para agir de forma eficaz. Os engenheiros da OpenAI escreviam uma docstring e um conjunto de afirmações. O agente então gerava a implementação. Se as afirmações falhassem, o ambiente capturaria automaticamente o traceback, alimentaria de volta ao modelo e solicitava uma nova tentativa. Esse ciclo permite dezenas de iterações sem intervenção humana.

A lição chave aqui é que, para os agentes se comportarem como engenheiros, eles precisam das mesmas ferramentas, ambientes e restrições que os engenheiros em nível de infraestrutura. Ao dar ao agente uma maneira de validar seu próprio trabalho, eles transformaram o modelo de um gerador de código de uma única vez em um engenheiro capaz de iteração. O harness forneceu os sinais que o agente precisava para depurar seu próprio código, verificar sua lógica e entregar software totalmente funcional.

Os Minions da Stripe e o ciclo de feedback

Podemos ver um padrão semelhante na Stripe. A empresa publicou recentemente um post no blog detalhando sua estrutura interna de agentes, Minions. Supostamente, os Minions produzem mais de mil pull requests mescladas a cada semana. A Stripe não alcançou esse volume simplesmente apontando um grande modelo de linguagem para seu monorepo.

A empresa construiu um servidor MCP chamado Toolshed, que expõe mais de 400 ferramentas para seus agentes. Crucialmente, deu aos agentes acesso total ao ambiente de desenvolvimento e construiu etapas de verificação determinísticas no ciclo do agente.

Quando um Minion da Stripe escreve código, o harness o força a passar por um conjunto de etapas de verificação. Começa com operações git, depois passa para linting e formatação. Se o agente gerar código que viole o guia de estilo, o linter o rejeita imediatamente e retorna o número da linha específica. O agente consome essa mensagem de erro e corrige a sintaxe.

O Minion então passa para verificação de tipo e testes. Se um teste falhar, a saída do erro é alimentada de volta na janela de contexto para uma correção. Isso funciona como um sistema de controle de loop fechado, com o próprio ambiente de desenvolvimento fornecendo o sinal de erro. Esse design permite que a organização confie na saída do agente porque o sistema impede que código incorreto saia do contexto local do agente.

A lacuna de verificação

A maioria das equipes de engenharia hoje não opera nesse nível de sofisticação. Elas frequentemente fornecem a seus agentes pouco mais do que um editor de código e uma janela de terminal.

Isso cria uma lacuna de verificação. É como contratar um engenheiro sênior e não dar a ele acesso a ambientes de staging, painéis de monitoramento, infraestrutura de testes ou revisão de código, e esperar que ele contribua de forma eficaz.

Os sinais de feedback disponíveis para um agente definem o teto do que ele pode realizar de forma autônoma. Se um agente só pode ver o texto no editor, ele está limitado a corrigir erros de sintaxe. Se ele pode ver a saída do compilador, pode detectar erros de tipo. Mas para resolver problemas complexos de integração, ele precisa de acesso à mesma rica diversidade de sinais que os engenheiros humanos dependem.

“Os sinais de feedback disponíveis para um agente definem o teto do que ele pode realizar de forma autônoma... Sem esses sinais, os agentes estão propensos a falhas silenciosas.”

Sem esses sinais, os agentes estão propensos a falhas silenciosas. Um agente pode gerar uma consulta SQL que é sintaticamente correta e retorna os dados corretos, mas executa uma varredura completa da tabela, degradando o desempenho em produção. Sem acesso a um plano de explicação ou métricas de execução, o agente não tem como saber que o código que escreveu falha em produção.

Uma hierarquia de sinais de feedback

Para entender o impacto dos sinais de feedback nos agentes, vale a pena mapear a hierarquia. Cada nível fornece ao agente mais contexto e eleva o teto sobre sua autonomia e, por sua vez, sua produtividade.

Verificação de sintaxe e tipo

Este é o nível básico. Qualquer loop de agente competente elimina efetivamente erros de sintaxe e tipo ao iterar contra a saída do compilador ou do linter. No entanto, esses representam a classe mais rasa de bugs. Um programa pode ser sintaticamente perfeito e seguro em tipos, enquanto falha completamente em produção.

Testes unitários

Agentes que podem executar testes unitários locais podem verificar a lógica em isolamento. Isso captura um volume significativo de defeitos lógicos, mas perde a complexidade dos sistemas distribuídos. Um teste unitário pode confirmar que uma função calcula corretamente uma taxa de imposto, mas não pode confirmar que o serviço de imposto...