A Thoughtworks Nomeou o Padrão de Governança de Agentes de Código. Sensores. Veja a Conta do CI.

Dois textos caíram na mesma semana de maio de 2026, escritos por pessoas que aparentemente não leram um ao outro. Birgitta Boeckeler, da Thoughtworks, publicou Maintainability Sensors for Coding Agents. A CloudBees publicou AI Is Writing More Code. Your CI Pipeline Can’t Keep Up.. Um nomeou a arquitetura. O outro quantificou o que acontece quando a arquitetura não existe.

Juntos eles terminam uma frase que o setor vinha balbuciando há um ano: agentes de código não produzem qualidade por acaso, e o CI não é onde se descobre a ausência de qualidade. Qualidade mora numa camada que Boeckeler chama de sensores. CI é a conta que se paga quando essa camada está vazia.

Se você opera agentes de código em produção e ainda não desenhou essa camada, o resto do seu stack de governança é decorativo.

O que Boeckeler de fato nomeou

O texto da Thoughtworks é um estudo de caso, não um manifesto. Boeckeler descreve um projeto real: um dashboard analítico em TypeScript e NextJS integrando quatro APIs externas. O movimento interessante não é o projeto. É o inventário explícito dos loops de feedback que o time construiu para que o agente respondesse a algo além da paciência do desenvolvedor.

Oito sensores computacionais rodavam durante a codificação. Quatro adicionais rodavam em cadência mais lenta. O pipeline de CI repetia todos eles no push, mais validação mais profunda. Os sensores não eram exóticos. ESLint para estilo. Dependency-cruiser para regras de acoplamento entre módulos. Semgrep para segurança e correspondência de padrões. Scripts próprios para sinalizar violações de acoplamento que ferramenta nenhuma de prateleira detecta. Boeckeler cita o trabalho de Vlad Khononov sobre Modularidade como a linhagem do que conta como violação de acoplamento digna de sinalização.

Os dois exemplos que ela dá merecem ser memorizados, porque são exatamente o tipo de débito que agentes de código produzem por padrão:

• Um único parâmetro novo de intervalo de datas alterou mais de quarenta arquivos, porque o agente passou o parâmetro por cada camada em vez de consolidar na fronteira.
• Três rotas terminaram com código duplicado de formatação de resposta, porque o agente gerou cada uma isoladamente sem perceber as outras.

Não são bugs. Passam nos testes. Entregam funcionalidade. São exatamente o tipo de decadência estrutural que revisores humanos capturam em pull requests quando têm tempo, e deixam passar quando não têm. A camada de sensores é o que captura isso quando ninguém está prestando atenção.

O padrão que Boeckeler nomeou tem três propriedades que vale a pena destacar:

• Automatizado. Sem humano no loop na primeira resposta. O sensor dispara, o agente lê a saída, o agente corrige.
• Em camadas. Sensores baratos rodam o tempo todo. Sensores caros rodam no commit. Sensores mais lentos rodam no CI. Custo diferente, cadência diferente, mesmo placar.
• Autoral. Alguns sensores vêm de prateleira. Os valiosos são personalizados, porque codificam a arquitetura que o time de fato escolheu, que é justamente o que fornecedor nenhum entrega pronto.

A palavra importa. Já escrevemos sobre governança de revisão, agentes autoaperfeiçoantes e fluxos de aprovação de orçamento como linhas separadas. Sensores é o substantivo que costura essas linhas. É uma cunhagem da Thoughtworks e a linhagem importa: o termo vem de dentro da consultoria que entregou mais projetos de refatoração corporativa do que qualquer concorrente no planeta. Não é teoria importada de fora; é vocabulário operacional da firma para um problema que ela vem sendo paga para resolver em escala.

O que a CloudBees quantificou

A CloudBees é fornecedora vendendo Smart Tests, então leia os números com o desconto de quem está vendendo. Mesmo com o desconto, o formato dos dados encaixa de forma limpa demais no argumento dos sensores para ser ignorado.

O post da CloudBees relata que usuários diários de ferramentas de IA para código entregam cerca de sessenta e cinco por cento mais pull requests que não usuários. Cerca de um terço das falhas de CI na base de clientes deles são flaky: nenhuma mudança subjacente, basta tentar de novo até ficar verde. Um caso de cliente que eles citam reduziu o tempo de testes de regressão em até oitenta por cento e levou o tempo de pré-commit de seis horas para duas. O número de manchete, na conta do cenário deles: cerca de duzentos e cinquenta mil dólares por ano de desperdício de compute de CI, em um time de cinquenta engenheiros.

Os números são atribuídos ao fornecedor. O mecanismo por trás deles, não. Se seus agentes geram sessenta e cinco por cento mais pull requests e sua camada de sensores é o pipeline de CI, então o CI agora é gargalo, centro de custo e muro de qualidade de fato. Nenhuma dessas três coisas é o que o CI foi desenhado para ser.

O enquadramento da CloudBees, depois de tirar o pitch do produto: o CI era a camada implícita de governança quando humanos escreviam o código. Humanos pré-filtravam antes do push. Agentes de código não fazem isso. Empurram tudo para o CI e deixam o pipeline avisar o que está errado. A economia do agente fecha; a do pipeline não.

A camada de sensores conserta a economia. O agente recebe feedback localmente, no sensor mais barato que pega o problema. O CI roda a verificação cara em código que já passou pelos baratos. O tempo de pré-commit cai porque os testes lentos param de ser a primeira linha de defesa.

Dois textos, um argumento

Leia o ensaio da Thoughtworks sozinho e a camada de sensores soa como prática artesanal. Leia o post da CloudBees sozinho e o estouro do CI soa como problema de ferramenta que o fornecedor vai resolver vendendo o produto dele. Leia os dois juntos e o argumento fica mais nítido.

Sensores são a disciplina. CI é a fatura não paga quando a disciplina não existe.

A implicação de engenharia é estrutural. Se você está escalando agentes de código e sua única maquinaria de feedback é o pipeline de CI, você terceirizou sua revisão de arquitetura para uma fila. A fila é lenta, a fila é cara, e a fila não captura violações de acoplamento porque violações de acoplamento passam nos testes. O agente entrega o diff de quarenta arquivos e três handlers de rota duplicados, e o pipeline diz verde. Você descobre o débito três meses depois, quando uma mudança de feature toca sessenta arquivos em vez de seis.

A implicação de liderança é financeira. Duzentos e cinquenta mil dólares por ano de desperdício de compute de CI em um time de cinquenta engenheiros é um número real, e é a parte visível da conta. A parte invisível é o débito estrutural que o pipeline não pegou porque sensor para isso não existia. Esse débito aparece no gráfico de velocidade seis meses depois como “a base de código ficou mais difícil de mudar”. Ninguém atribui isso à ausência de um sensor de acoplamento em fevereiro. A rubrica não existe.

A arquitetura de sensores é a rubrica que evita a rubrica que não existe.

O que construir, concretamente

A lista do projeto de Boeckeler é um kit inicial funcional. Espere levar três semanas para inventariar e levantar o primeiro corte.

Inventarie os sensores que você já roda. A maioria dos times tem ESLint, Prettier, um checador de tipos, testes unitários e testes de integração. Liste-os. Marque quais rodam pré-commit, quais rodam no push, quais rodam no CI. Você quase certamente não tem um sensor de acoplamento. Você quase certamente não tem uma regra Semgrep personalizada para a arquitetura que seu time decidiu três anos atrás.

Adicione a camada à qual o agente vai responder primeiro. Uma configuração de dependency-cruiser que falha quando um arquivo novo importa por cima de uma fronteira arquitetural é projeto de um dia e resolve o problema do diff de quarenta arquivos descrito por Boeckeler. O agente vai bater e reescrever. Você não precisa ensinar a arquitetura ao agente; precisa dar ao agente um sensor que apita quando a arquitetura é violada.

Adicione um sensor de acoplamento para suas três dores principais. Quais três coisas o seu engenheiro sênior sinaliza em toda revisão de código? Formato de resposta duplicado? IDs como strings que deveriam ser tipos nomeados? Acesso direto ao banco a partir de controllers? Escreva uma regra Semgrep para cada uma. Rode no commit. Os sensores agora ensinam ao agente o que o seu engenheiro sênior teria dito.

Reorganize as camadas do seu CI. Com os sensores locais disparando, o CI deixa de precisar ser o primeiro muro. Tire os sensores mais baratos do CI e coloque-os no pré-commit. Corte do CI o percentual da duração atual que era gasto pegando coisas que agora dá para pegar localmente. O cenário da CloudBees sugere cinquenta por cento de redução. Mesmo um quarto disso é dinheiro real.

Audite a dieta de feedback do agente. O que seu agente de código vê hoje quando comete um erro? Se a resposta é “o output dos testes, se ele lembrar de rodar os testes”, essa é a primeira coisa a corrigir. As saídas dos sensores precisam ser legíveis pelo agente como feedback estruturado, não enterradas em scroll de terminal.

Faça isso agora

Bloqueie quatro horas nesta semana. Pegue o diagrama do seu pipeline atual de CI. Adicione uma coluna à esquerda chamada “sensores que rodam antes do CI”. Se a coluna está praticamente vazia, você encontrou o trabalho de arquitetura. Imprima o texto de Boeckeler e leia com a sua liderança de plataforma. Imprima o post da CloudBees e leia com quem controla o orçamento de CI. Eles estão lendo o mesmo problema por pontas opostas.

Os times que vão escalar agentes de código em 2026 não serão os que tiverem mais agentes autônomos. Serão aqueles cujos agentes respondem ao maior número de sensores antes que o pipeline tenha chance de falhar.

---

Fontes

• Thoughtworks. “Maintainability Sensors for Coding Agents.” Maio de 2026.
• CloudBees. “AI Is Writing More Code. Your CI Pipeline Can’t Keep Up.” Maio de 2026.

A Victorino ajuda organizações de engenharia a projetar a arquitetura de sensores e a economia de CI para desenvolvimento de IA governado: contato@victorino.com.br | www.victorino.com.br