Engenharia com agentes

Ultimamente eu venho ouvindo uma frase que teria sido absurda três anos atrás: "não consigo fazer agora — fiquei sem tokens". Estas são minhas anotações depois de investigar a Zero Token Architecture — a ideia que Kelsey Hightower levou de um post descartável a uma keynote na PlatformCon — e o princípio que quero construir em cima dela: toda chamada de IA é uma decisão de arquitetura, e os custos que mais importam nunca foram os tokens.

Quando agentes escrevem uma parcela significativa do código, meu output deixa de ser código digitado — passa a ser decisões de delegação. Estas são minhas anotações sobre a disciplina humana que faz isso funcionar: dimensionar cada handoff ao review que consigo pagar, o briefing que entrego no lugar de tarefas grandes, e os quatro hábitos que me mantêm conectado a um sistema no qual não estou mais digitando — das ironias de Bainbridge em 1983 a um resultado da METR que desde então inverteu o próprio sinal.

Meus feeds estão cheios de gravações de tela de desenvolvedores assistindo um agente escrever código — e quero nomear essa postura com gentileza: isso é assistir, não produtividade. Fechando a linha de raciocínio de Zero Token Architecture e O Handoff É a Unidade de Design, estas são minhas anotações sobre o plano de controle que um desenvolvedor nunca deveria abandonar: handoffs pequenos e paralelos em vez de accept-all, pesquisa e mapeamento de efeitos colaterais automatizados antes da implementação, e o alerta em formato de Log4Shell sobre entregar código que ninguém entende — com os custos do handoff consciente nomeados com a mesma honestidade que seus benefícios.

A objeção mais afiada a "leia todo diff" é aritmética: agentes escrevem mais rápido do que humanos leem. Minha resposta é parar de discutir review e nomear o que o review de fato era — o ponto de controle da profissão, o único lugar em que observação, decisão e imposição coincidiam. Esse ponto está saturando, e um ponto de controle saturado não desacelera o sistema; ele é contornado e se torna nominal. Estas são minhas anotações sobre o que um ponto de controle exige para funcionar, por que a aritmética quebrou este, e como cada resposta da indústria — agentes revisando agentes, verificar-em-vez-de-revisar, roteamento por risco — é na verdade uma relocação que abre mão de uma propriedade diferente. Sem resposta no final. Três perguntas, em vez disso.

O post anterior perguntou para onde foi o ponto de controle. Aqui está a primeira resposta que estou disposto a defender: ele não desapareceu — parte dele compilou. Fitness functions arquiteturais, apontadas para agentes de código, se tornam o control plane que permite ao desenvolvedor permanecer no comando sem virar o gargalo: julgamento compilado uma vez em gates determinísticos que aplicam a regra na velocidade da máquina, com mensagens de falha escritas como prompt engineering para o loop de retry. Em seguida, a complicação que dá forma ao post inteiro: no momento em que um agente otimiza contra a compilação, o controle compilado vira objeto de ataque — e o design de fitness functions herda uma corrida armamentista, com uma constituição em Kotlin/ArchUnit para tornar tudo concreto.

Toda base de código carrega dois mapas: o que os testes verificam, medido até a segunda casa decimal, e o que os humanos ainda entendem, medido por ninguém. Durante vinte anos o segundo mapa vinha de graça com o git blame — autoria implicava compreensão. Os agentes apagaram esse axioma. Partindo do alerta de Naur, feito há quarenta anos, sobre programas que morrem junto com sua teoria, passando pela pesquisa da curva do esquecimento e por um preprint de 2026 que argumenta que toda a família de métricas baseadas em autoria ruiu de uma só vez, estas são minhas anotações apresentando a cobertura de compreensão: um mapa por módulo, por pessoa, baseado em evidências e que decai com o churn, mostrando quais humanos ainda entendem quais partes de um sistema — com o trabalho anterior mais próximo devidamente nomeado, suas condições de refutação anexadas e o instrumento que constrói esse mapa vindo a seguir.

O post anterior apresentou a cobertura de compreensão como conceito. Este é o relato de campo: o instrumento existe, é open source, e sua primeira execução foi em um repositório que eu mesmo mantenho — uma pequena biblioteca desenvolvida predominantemente por meio de agentes de código. Quatro de seis módulos voltaram escuros. A única entidade que o instrumento reconhece como compreendedora do módulo assinatura é um bot. Este post percorre o mapa real, a execução de calibração que discutiu com a especificação e venceu, o rastro de um módulo escuro, as duas falhas que a primeira execução era obrigada a produzir, e o portão que um pipeline de CI já consegue impor — com uma válvula de emergência cujo uso alimenta o próprio mapa. Os cinco primeiros posts tornaram a camada humana explícita. Este a torna aplicável.