Engenharia de ciclo de feedback -

Há algum tempo, ouvi um podcast do Pragmatic Engineer com Peter Steinberger sobre seu fluxo de trabalho de desenvolvimento nativo de IA – aquele em que ele executa de 5 a 10 agentes de codificação em paralelo e envia códigos que não lê pessoalmente. Os números das manchetes são fáceis de fixar, mas o que me chamou a atenção foi a infraestrutura por trás deles. Seu fluxo de trabalho não é bem-sucedido porque ele escreve prompts melhores ou mesmo porque fornece um contexto melhor aos agentes. Funciona porque ele construiu o que chama de “sistemas de circuito fechado”, onde os agentes verificam seu próprio trabalho – compilando, executando, depurando, capturando imagens, acessando chaves de API reais.

Tenho pensado nesse padrão desde então e acho que ele merece seu próprio nome. Aqui está minha hierarquia atual:

Os quatro níveis

Engenharia imediata é onde a maioria das pessoas começa – e onde reside a maior parte do discurso. Como você formula seu pedido? Qual prompt do sistema funciona melhor? Devo escrever “por favor” ou “meu trabalho depende disso, não cometa erros”? Pode ser importante, mas os modelos estão ficando bons o suficiente para inferir a intenção a partir de instruções vagas. Em vez de elaborar as especificações perfeitas e tentar cobrir todas as possibilidades, você pode simplesmente conversar.

Engenharia de contexto é o próximo passo. Trata-se de fornecer ao modelo as informações corretas: um modelo bem elaborado CLAUDE.md / AGENTS.mddocumentação relevante, arquivos cuidadosamente selecionados na janela de contexto. Escrevi sobre algumas de minhas práticas aqui – coisas como usar o modo Plano e incluir os arquivos mais relevantes antecipadamente. A engenharia de contexto leva você muito mais longe do que apenas a engenharia imediata, porque o modelo para de adivinhar às cegas. Também pode preencher as lacunas com muito mais facilidade a partir de práticas existentes do que de suposições.

Mas engenharia de ciclo de feedback é o que separa o código funcional da sorte. É a prática de construir ferramentas e infraestrutura para que os agentes de codificação possam verificar seu trabalho no contexto. Não para parar quando eles fizeram uma quantidade razoável de trabalho e sentirem que está “pronto para produção”, mas para ver evidências concretas de como o código se comporta em uma configuração o mais semelhante à produção possível.

Engenharia de chicotes é a moldura em torno de tudo isso. Birgitta Böckeler define chicote como tudo em um agente, exceto o modelo em si – “Agente = Modelo + Chicote” – e o divide em guias que orientam o agente antes de ele agir (feedforward: seu CLAUDE.mdtipos, linting) e sensores que permite observar as consequências depois (feedback: os loops que abordarei abaixo). Por essa definição, minha “engenharia de loop de feedback” é na verdade a metade do sensor da engenharia de chicotes, feita propositalmente.

Então, por que dar-lhe o seu próprio degrau em vez de dobrá-lo? Porque os três respondem a perguntas diferentes. A engenharia de contexto trata do que acontece em. A engenharia de chicote trata de governar todo o aparato – quais ferramentas o agente pode chamar, o que ele pode tocar, quando deve parar. E o ciclo de feedback é o tecido conjuntivo entre eles: a parte que decide se o agente descobrirá que estava errado. Eu diria que é também onde a maioria dos desenvolvedores obtém o melhor retorno do seu tempo hoje. E para pessoas que usam chicotes de código fechado como Claude Code ou Cursor, o termo engenharia de chicotes pode parecer confuso quando apenas adiciona algumas habilidades ou ganchos.

Como isso parece na prática

A ideia central é simples: você deseja que o agente seja capaz de executar seu código, ver o resultado e iterar. Assim como um desenvolvedor faria. Quanto mais rápido e apertado for o loop, melhor será o resultado.

A camada fundamental – linting estrito, tipos fortes, testes de integração, ganchos git – eu abordei anteriormente. Estas são apostas de mesa. Eles detectam erros de sintaxe e problemas estruturais antes mesmo do agente se comprometer. Adicionar tipos e bibliotecas de validação (como Zod ou Pydantic) é a próxima camada útil que autodocumenta e aplica contratos de dados. Mas eles não podem dizer se o código realmente faz a coisa certa em um sistema em execução e se falhar normalmente.

Se essa camada fundamental for principalmente feedforward – guias que mantêm o agente nos trilhos antes de agir – a camada mais interessante é o feedback que informa se o código realmente funcionou: observabilidade semelhante à produção.

Depuração do navegador via CLI – Eu uso o browser-debugger-cli, que envolve o Chrome DevTools em uma CLI em vez de um MCP. O agente pode navegar até uma página, inspecionar o DOM, verificar erros do console, verificar se uma alteração no frontend realmente é renderizada corretamente e até mesmo executar trechos de JavaScript – não apenas se o componente compila
Habilidades de consulta de banco de dados – conhecendo o esquema e sendo apontado para uma CLI pré-autenticada, o agente pode executar consultas em um banco de dados de desenvolvimento para verificar se uma migração foi executada corretamente, se os dados estão sendo gravados no formato esperado ou se uma otimização de consulta realmente melhorou as coisas
Acesso ao log e rastreamento de falhas – quando algo dá errado em tempo de execução, o agente precisa ver o que aconteceu. Rastreando logs de aplicativos, lendo rastreamentos de falhas, entendendo a falha real em vez de adivinhar a partir do código
Rastreamentos OpenTelemetry – em uma configuração de microsserviços, um bug em um serviço pode se manifestar como um comportamento inesperado em outro. Ser capaz de extrair rastreamentos do OTel e correlacioná-los entre serviços significa que o agente pode acompanhar uma solicitação por todo o sistema, e não apenas olhar para o arquivo que ele alterou.
Chaves de API para serviços de desenvolvimento – o agente precisa ser capaz de atingir endpoints reais (de desenvolvimento), e não apenas zombar deles. Nunca vi uma documentação de API que não perdesse algumas peculiaridades que apenas a estimulação e a execução de fluxos de trabalho completos revelariam.

O padrão vai além de “compila?” para “isso realmente funciona como parte do sistema?” Cada uma dessas ferramentas preenche uma lacuna entre o que o agente escreveu e o que acontece em tempo de execução. E, o que é mais importante, todas elas são expostas como habilidades CLI – canalizáveis, combináveis, text-in-text-out – o que nos leva à razão pela qual isso é importante.

Uma vez que os loops estejam sólidos, algo muda na forma como você trabalha. Você pode executar vários agentes em paralelo sem que tudo se transforme em caos, porque você não está mais revisando cada linha – você está contando com os sistemas que revisam o código para você. “Arquitetura acima da revisão de código”, como diz Peter. Também torna a experimentação barata: você pode deliberadamente sub-avisar, dar instruções vagas para ver o que o agente apresenta e confiar nos loops para sinalizar uma curva errada antes que ela se transforme em algo caro.

O que levanta a questão óbvia: qual é a interface correta entre um agente e um ciclo de feedback? Precisamos colocar outros 70 mil tokens de instruções MCP no contexto?

A conexão Unix

Eu penso Ferramentas CLI que podem ser canalizadas e exploradas progressivamente são a interface ideal para atual Modelos de IA, e Peter defende o mesmo. Não porque as CLIs sejam inerentemente superiores às GUIs – muitas vezes não são, para muitos humanos – mas porque as interfaces de entrada e saída de texto são aquilo com que esses modelos são mais fluentes. Em termos de ML, eles são em distribuição: o tipo de interface que o modelo mais viu durante o treinamento. E se alguns modelos posteriormente funcionarem melhor com uma interface diferente, reempacotar APIs agrupadas em CLI não será muito difícil.

Portanto, “progressivamente explorável” significa que o agente pode começar de forma ampla e restrita. git log --oneline dá uma visão geral. Escolha um commit, git show dá detalhes. git diff estreita ainda mais. A cada etapa, o agente recebe feedback e decide onde se aprofundar. A ferramenta não força um caminho específico – ela responde às escolhas. Mas é verdade para a própria interface CLI, executando --help para cada profundidade de comando.

“Pipeável” significa que a saída de uma ferramenta alimenta outra. rg "TODO" --json | jq ... permite que o agente processe os resultados programaticamente. Composibilidade não é apenas design elegante – é alfabetização funcional e uma ótima oportunidade de autogerenciamento de contexto para um LLM.

Há algo deliciosamente irônico aqui. A filosofia Unix – pequenas ferramentas que fazem uma coisa bem, conectadas através de fluxos de texto – data da década de 1970. Acontece que é quase perfeitamente adequado para agentes de IA meio século depois. Talvez isso não seja uma coincidência. Tanto os pipes Unix quanto os agentes de IA operam em texto. Ambos se beneficiam de interfaces combináveis e previsíveis. Ambos lutam com formatos binários proprietários e GUIs modais.

Para os criadores de ferramentas, a implicação é clara: se você deseja que sua ferramenta funcione bem com agentes de IA, faça-a funcionar bem como CLI. Saída estruturada. Limpar mensagens de erro. Comandos combináveis. Execução rápida. Estas não são ideias novas – são ideias antigas que de repente se tornaram muito mais valiosas.

O circuito interno e externo

Quase tudo até agora é sobre o laço interno: o agente executa seu código, lê o resultado e o alimenta diretamente em seu próprio contexto, tudo em uma única sessão. Aperte esse loop e a saída ficará melhor. Mas há um loop mais lento e mais amplo em cima dele, e é onde a composição realmente acontece.

O laço externo é o que transforma a lição duramente conquistada em uma sessão em algo com que toda sessão futura começa. Um agente gasta meia hora descobrindo que uma API específica trunca silenciosamente cargas úteis acima de um determinado tamanho ou que uma migração precisa de um sinalizador específico nesta versão do banco de dados. No loop interno esse conhecimento vive e morre dentro da janela de contexto. No loop externo, isso é refletido no final da sessão, destilado e gravado de volta no conhecimento compartilhado que o próximo agente carrega antecipadamente – uma nova habilidade, uma nota no CLAUDE.mduma entrada em uma base de conhecimento da equipe.

IA da Mozilla cq é a abordagem mais limpa que já vi. É um padrão aberto para aprendizagem compartilhada de agentes: os agentes armazenam descobertas como “unidades de conhecimento” estruturadas – peculiaridades de API não documentadas, soluções alternativas, correções – e consulte a loja antes de tentar novamente uma falhaentão eles param de redescobrir os mesmos becos sem saída de forma independente. UM /cq:reflect O comando explora uma sessão concluída em busca de lições que valem a pena manter, classifica-as de acordo com o quão generalizáveis elas são, verifica se há duplicatas e propõe novas unidades para você aprovar. A loja pode residir localmente no SQLite ou sincronizar com toda a equipe. Seu próprio enquadramento o nomeia exatamente: separe o ciclo interno de resolução do problema do ciclo externo de consolidação do que você aprendeu.

A parte interessante é como os dois loops se unem. A lição destilada de hoje se torna a de amanhã guia – feedforward, em termos de aproveitamento – de modo que o circuito externo melhora silenciosamente o interno ao longo do tempo. É o mesmo círculo que uma boa equipe já administra: alguém depura um problema complicado, escreve-o e a próxima pessoa não precisa começar do zero. Estamos apenas ensinando os agentes a fazerem suas próprias anotações.

A melhor parte

O que eu gosto nessa abordagem é que a engenharia do ciclo de feedback não é apenas uma sobrecarga específica da IA. Observabilidade, registro estruturado, correlação de rastreamento, testes de navegador, verificação de banco de dados, interfaces claras, mensagens de erro úteis – essas eram boas práticas de engenharia muito antes de alguém solicitar um modelo de linguagem. A diferença é que agrupá-las como habilidades acessíveis por CLI também as torna disponíveis para os agentes. Os ciclos de feedback que ajudam um agente a depurar um problema entre serviços são os mesmos que ajudam um desenvolvedor na primeira semana a entender como o sistema realmente se comporta.

Portanto, se você está se perguntando onde investir seu tempo à medida que as ferramentas de codificação de IA melhoram: menos tempo elaborando o prompt perfeito, mais tempo criando ferramentas que permitem aos agentes – e humanos – ver o que realmente está acontecendo. Os prompts e os equipamentos do agente de codificação mudarão à medida que os modelos evoluem. O valor de um ciclo de feedback restrito não será. E se a bolha da IA estourar no próximo mês, você terá bases de código fáceis de testar que você mesmo pode recuperar ou usar modelos locais para tarefas menores. Caso contrário, os loops internos e externos continuarão se acumulando e seus agentes ficarão um pouco menos esquecidos a cada sessão.

E pelo amor de Deus, não instale o OpenClaw conectado a todos os seus dados e serviços pessoais…