Feedback Sensors: Como Colocar Coding Agents na Coleira

Agentes de código ficaram bons o suficiente para gerar mudanças úteis. Esse é o lado empolgante. O lado perigoso é que eles também ficaram bons o suficiente para gerar mudanças erradas com aparência profissional. Código compila, nomes parecem bons, estrutura parece limpa e o PR vem com testes. Só depois alguém percebe que a regra de negócio foi distorcida.

É por isso que feedback sensors viraram um dos conceitos mais importantes do Radar da Thoughtworks. A ideia é simples: conectar sinais determinísticos e revisões especializadas ao loop do agente para que ele corrija antes de chegar no humano.

Pense em sensores como coleira técnica. Não no sentido de impedir o agente de andar, mas de limitar onde ele pode se perder. Linters, typecheck, testes, cobertura, mutation testing, fuzzing, análise de dependência, browser validation e review agents podem virar feedback imediato. O agente faz, sensor mede, agente corrige.

Esse padrão muda a discussão. Em vez de perguntar "qual modelo é melhor?", começamos a perguntar "qual ambiente faz qualquer modelo errar menos?". Para times de engenharia, essa pergunta é muito mais útil.

---

Feedforward e Feedback

Martin Fowler e Birgitta Boeckeler usam uma distinção excelente em harness engineering: feedforward guides e feedback sensors. Feedforward é o que orienta o agente antes da ação. Feedback é o que observa depois da ação.

Um AGENTS.md, uma skill de testes, um guia de arquitetura, um MCP de documentação e uma referência de API são feedforward. Eles aumentam a chance de o primeiro patch sair certo.

Um linter, um teste, um scanner de segurança, logs de browser, mutation testing e review humano são feedback. Eles dizem o que aconteceu depois que o agente agiu.

Times ruins tentam resolver tudo com feedforward. Escrevem prompts enormes, regras infinitas e instruções detalhadas. Isso ajuda até certo ponto, mas não basta. Agentes ainda erram. Sistemas mudam. Contexto fica obsoleto. Por isso sensores são indispensáveis.

Um agente sem feedback sensor é como um dev que nunca roda teste local e manda PR confiante. Às vezes dá certo. Não é processo.

---

Sensores Determinísticos Primeiro

O melhor sensor é aquele que não discute. TypeScript passa ou falha. Teste passa ou falha. Lint passa ou falha. Build passa ou falha. Esses sinais não são perfeitos, mas são baratos, rápidos e objetivos.

Por isso o primeiro passo é garantir que o agente saiba rodar os comandos certos e interpretar falhas. Parece básico, mas muitos agentes param cedo porque "a alteração foi aplicada" sem verificar. O workflow precisa exigir: depois de editar, rode validação. Se falhar, corrija. Se não conseguir corrigir, reporte exatamente o bloqueio.

Também é importante rodar sensores no momento certo. Se você espera o agente mudar 20 arquivos para só depois rodar teste, o feedback chega tarde. Quanto menor o loop, mais fácil corrigir.

Em projetos TypeScript, eu começaria com npm run lint, npm run typecheck, testes unitários focados e build. Em backend, adicionaria testes de integração e contrato. Em frontend, browser validation. Em sistemas críticos, segurança e mutation testing entram no pipeline.

---

Mutation Testing e Fuzzing Mudam o Jogo

Teste tradicional responde: o código passa nos exemplos que escrevemos? Mutation testing faz pergunta mais dura: se eu introduzir pequenas mudanças no código, seus testes percebem? Quando não percebem, talvez seus testes sejam fracos.

Para agentes, isso é especialmente valioso. Um agente pode escrever testes que apenas confirmam sua própria implementação. Mutation testing expõe essa fragilidade porque força os testes a provar que detectam comportamento errado.

Fuzzing também ajuda em áreas com input complexo. Parsers, APIs públicas, validação, serialização, formatos de arquivo, autenticação e processamento de dados se beneficiam muito. O agente pode não imaginar todos os edge cases, mas o fuzzer pode gerar muitos deles.

O Radar cita ferramentas como cargo-mutants e WuppieFuzz nesse contexto. A mensagem maior não é "use exatamente estas ferramentas". É: agentes precisam de sensores que encontrem erro além do caminho feliz.

---

Browser Como Sensor

Para frontend, o navegador é um sensor riquíssimo. Console error, network error, layout quebrado, clique que não responde, estado loading infinito, contraste ruim, texto sobreposto, responsividade falha. Nada disso aparece olhando só arquivo.

Um agente que altera UI deveria abrir rota real. Não screenshot estático salvo três commits atrás. Rota real, servidor real, viewport real. Ele deve olhar console, interagir com controles, testar mobile e capturar evidência.

Isso vale ainda mais para apps com estado, auth, dados assíncronos e CSS complexo. O diff pode parecer correto e a tela continuar quebrada por hierarquia, z-index, overflow, cache ou contrato de API.

Browser validation como sensor transforma "parece certo" em "foi observado". Para desenvolvimento agêntico, essa diferença é enorme.

---

Review Agents Também São Sensores

Nem todo sensor precisa ser determinístico. Um segundo agente pode revisar arquitetura, segurança, legibilidade ou aderência ao requisito. Isso não substitui humano, mas melhora o material que chega para humano.

O risco é criar teatro de agentes concordando entre si. Se o review agent usa o mesmo contexto ruim, o mesmo modelo e a mesma instrução vaga, ele pode apenas validar o erro com outro texto. Para funcionar, ele precisa de papel diferente, critérios específicos e, idealmente, ferramentas diferentes.

Exemplo: agente implementador altera código. Sensor determinístico roda testes. Review agent recebe diff, requisito original e checklist de arquitetura. Ele não reescreve tudo. Ele aponta riscos. O implementador corrige. Só depois o humano revisa.

Esse fluxo reduz carga do revisor humano, mas mantém responsabilidade. O humano continua decidindo merge.

---

Como Montar Um Harness De Feedback

Um harness simples pode ter quatro camadas.

Primeira: sensores rápidos locais. Lint, typecheck, testes unitários relevantes. Rodam sempre, dentro do loop do agente.

Segunda: sensores contextuais. Teste de contrato, browser validation, análise de dependência, checagem de migração. Rodam quando a tarefa toca área específica.

Terceira: sensores caros. Mutation testing, fuzzing, e2e completo, análise arquitetural profunda. Rodam para PRs maiores ou áreas críticas.

Quarta: revisão humana. O humano recebe diff, resultado dos sensores, riscos pendentes e explicação do agente. Isso é muito melhor do que receber apenas "pronto".

O segredo é não tentar rodar tudo sempre. Sensor demais mata fluxo. Sensor de menos deixa erro passar. O harness precisa ser proporcional ao risco da mudança.

Uma forma simples de começar é criar uma matriz por tipo de mudança. Mudança de texto roda lint e build. Mudança de componente roda lint, typecheck e browser validation. Mudança de API roda contrato e integração. Mudança em auth roda segurança e revisão humana obrigatória.

Essa matriz vira instrução para o agente e expectativa para o time. Quando o PR chega, o revisor não precisa perguntar "você validou?". O resultado dos sensores já deve estar no resumo.

Sensores Também Educam o Agente

O valor dos sensores não é só bloquear erro. Eles também ensinam o agente. Um erro de typecheck mostra contrato real. Um teste quebrado mostra comportamento esperado. Um screenshot quebrado mostra falha que o diff não revela.

Quanto mais claro o sensor, melhor a autocorreção. Mensagem de erro confusa gera correção aleatória. Mensagem objetiva gera patch menor. Por isso vale investir em testes com nomes bons, linters configurados sem ruído e scripts que falham com explicação útil.

Essa é uma diferença importante entre "ter CI" e "ter harness para agente". CI tradicional fala com humano. Harness agêntico precisa falar com humano e com modelo. O output precisa ser interpretável por máquina o suficiente para guiar a próxima tentativa.

---

Métrica Boa Não É Throughput

Um alerta do Radar que eu gosto: coding throughput como medida de produtividade está em Caution. Faz sentido. Se agente cria mais linhas, mais PRs e mais commits, isso não significa que o time ficou melhor.

Com agentes, métrica ruim fica ainda mais perigosa. É fácil aumentar volume. Difícil é reduzir retrabalho, regressão, tempo de review, bugs pós-deploy e dívida cognitiva.

Feedback sensors ajudam a medir o que importa. Quantas falhas foram pegas antes do humano? Quantas correções automáticas ocorreram? Quantos PRs chegaram com validação completa? Quanto caiu o rework rate? Quantos bugs escaparam?

Essa é a maturidade real: não celebrar que o agente escreveu mais, mas que o sistema entregou melhor com menos retrabalho.

---

Principais Aprendizados

• Feedback sensors observam ação do agente e disparam correção.
• Sensores determinísticos são a primeira linha: lint, typecheck, testes, build.
• Mutation testing e fuzzing ajudam a encontrar teste fraco e edge cases.
• Browser validation é sensor essencial para frontend.
• Métrica de sucesso deve ser qualidade e retrabalho, não volume de código.

---

Conclusão

O futuro do desenvolvimento agêntico não será decidido apenas por modelos melhores. Será decidido por harnesses melhores. O time que cria bons trilhos, bons sensores e bons loops de correção vai extrair mais valor até de modelos medianos.

Feedback sensors são uma forma prática de manter agentes úteis sem fingir que eles são infalíveis. Eles deixam o agente tentar, errar pequeno, receber sinal e corrigir antes de ocupar tempo humano.

Esse é o equilíbrio que vale buscar: autonomia com observabilidade, velocidade com verificação, IA com engenharia.

---

Fontes e Referências

• Thoughtworks Technology Radar Vol. 34
• Harness engineering for coding agent users - Martin Fowler
• cargo-mutants
• WuppieFuzz
• CodeScene
• DORA metrics - Google Cloud

---

Sugestão de Imagens

Capa (feedback_sensors_coding_agents_cover.png): agente no centro com sensores ao redor: lint, tests, typecheck, browser, security, mutation, fuzzing, human review.

Inline 1: diagrama feedforward vs feedback.

Inline 2: pipeline: agent patch -> fast sensors -> contextual sensors -> expensive sensors -> human review.