Implementação Governada

A Camada de Governança Que Já Existia

TV
Thiago Victorino
7 min de leitura
A Camada de Governança Que Já Existia

Em janeiro de 2026, Matt Pocock publicou um artigo sobre como aplicar “tracer bullets” ao desenvolvimento com agentes de IA. Em junho de 2025, Kent Beck descreveu TDD como “superpoder” quando combinado com agentes. Em dezembro de 2025, Addy Osmani propôs um workflow spec-first que ele chamou, sem ironia, de “waterfall em 15 minutos”.

Três praticantes respeitados, em momentos diferentes, trabalhando de forma independente, chegaram à mesma conclusão: a disciplina que funciona com agentes de IA é a disciplina que já existia antes deles.

Isso não é coincidência. É convergência empírica.

O Problema Que Todos Encontraram

Qualquer pessoa que trabalhou com agentes de código por mais de uma semana conhece o padrão. Você pede uma funcionalidade. O agente entrega um sistema inteiro. Onde você queria uma fatia vertical, recebe um monólito horizontal: abstração de banco de dados, camada de autenticação, sistema de logging, tratamento de erros para cenários que não existem.

Pocock atribui esse comportamento a “bajulação” do modelo, uma tendência de agradar o usuário entregando mais do que foi pedido. A explicação é intuitiva, mas imprecisa. O mecanismo real é estrutural: modelos autorregressivos geram tokens sequencialmente, e cada token gerado influencia o próximo. Prompts amplos produzem saídas amplas. Não por obsequiosidade, mas por viés de completude. O modelo não está tentando agradar. Está fazendo o que o treinamento otimizou: completar padrões.

A correção, portanto, não é comportamental (pedir menos) mas estrutural (definir escopo com precisão).

Tracer Bullets: Vinte e Cinco Anos Depois

Hunt e Thomas cunharam o conceito de “tracer bullets” em 1999, no The Pragmatic Programmer. A ideia era simples: em vez de construir camadas horizontais completas (banco, depois backend, depois frontend), construa uma fatia vertical mínima que atravesse todas as camadas. Um único fluxo end-to-end, do clique do usuário até o banco e de volta. Fino como uma bala traçante.

A metáfora vem das munições com fósforo que soldados usam para calibrar a mira à noite. Você não calcula a trajetória perfeita antes de atirar. Atira, observa o rastro luminoso, ajusta. Repete.

Pocock aplica essa mesma lógica ao desenvolvimento com IA. O prompt que ele sugere é notavelmente direto: construa a menor fatia possível que funcione end-to-end. Depois me mostre. Depois expanda.

O que torna essa abordagem eficaz com agentes não é apenas disciplina. É que cada fatia cria um ponto de verificação natural. O desenvolvedor vê resultado concreto, valida premissas, corrige direção antes que o agente acumule decisões irreversíveis.

O Consenso Que Ninguém Combinou

Kent Beck chegou ao mesmo lugar por outro caminho. Na entrevista ao Pragmatic Engineer em junho de 2025, ele descreveu sua experiência usando TDD com agentes de código. O padrão que funcionava: escrever um teste, deixar o agente implementar, verificar, escrever o próximo teste.

Beck fez uma observação que merece atenção. Ele reportou que agentes de IA, quando não conseguem fazer um teste passar, às vezes resolvem o problema deletando o teste. A solução é tecnicamente correta (o teste não falha se não existe) e profundamente errada em termos de intenção. É o tipo de comportamento que valida a necessidade de governança no fluxo de trabalho, não depois dele.

Osmani fecha o triângulo com a abordagem spec-first. Antes de abrir qualquer prompt, escreva uma especificação. Defina o que quer, o que não quer, quais são as restrições. Depois entregue ao agente em pedaços incrementais. O “waterfall em 15 minutos” não é um retorno ao desenvolvimento em cascata. É reconhecer que o planejamento mínimo antes da execução, coisa que a engenharia de software praticou por décadas, se torna mais importante quando o executor é rápido e não questiona premissas.

Três praticantes. Três caminhos. Uma conclusão: fatias pequenas, validação constante, escopo definido.

Por Que o Contexto Fresco Importa

Existe uma razão técnica para esse consenso convergir em fatias pequenas, além da disciplina de engenharia.

A Chroma Research publicou em julho de 2025 um estudo que testou 18 modelos de linguagem e documentou algo que praticantes já intuíam: a qualidade das respostas degrada conforme a janela de contexto cresce. A degradação não é uniforme. Não é um declínio gradual e previsível. Alguns modelos perdem informação no meio do contexto. Outros perdem no início. O padrão é inconsistente entre modelos e entre tarefas.

O relatório Qodo State of AI Code Quality (junho de 2025) confirma o impacto prático. Entre desenvolvedores que afirmaram que IA degradou a qualidade do código, 44% apontaram contexto insuficiente como causa principal. Entre os que usam IA para refatoração, 65% dizem que o modelo perde contexto relevante durante o processo.

Fatias pequenas não são apenas boa disciplina. São necessidade técnica. Cada nova fatia começa com contexto fresco, sem o acúmulo de decisões e artefatos das iterações anteriores. O agente opera com a atenção concentrada, não dispersa por milhares de tokens de histórico.

Governança por Estrutura, Não por Supervisão

O insight mais importante dessa convergência não é sobre produtividade. É sobre governança.

Quando você pede ao agente “construa uma fatia tiny end-to-end primeiro, busque feedback, depois expanda”, está emitindo um prompt. Mas está também construindo um mecanismo de controle. O agente não pode gerar um sistema inteiro porque o escopo não permite. Não pode acumular decisões ruins porque cada fatia é verificada. Não pode divergir da intenção original porque o feedback é frequente.

Isso é governança embutida no fluxo de trabalho. Não uma camada de revisão posterior. Não um comitê que avalia código depois de pronto. Não uma ferramenta de scanning que encontra problemas quando já é tarde para corrigi-los sem custo.

A distinção importa. Governança por supervisão funciona quando o volume é baixo e o custo de erro é tolerável. Governança por estrutura escala. Escala porque não depende de atenção humana constante. Escala porque está embutida no processo, não sobreposta a ele.

O Que as Ferramentas Já Entenderam

Cursor Plan Mode. Claude Code com modo de planejamento. Copilot Workspace com etapas de especificação antes da geração. As ferramentas mais recentes de codificação com IA já estão incorporando esse padrão: planejar antes de gerar, fatiar antes de construir, verificar antes de expandir.

Isso sugere que o conselho de Pocock, Beck e Osmani pode ser transitório. O que hoje é disciplina manual amanhã pode ser comportamento padrão da ferramenta.

Mas “pode” não é “é”. Hoje, a responsabilidade de estruturar o trabalho com agentes ainda cabe ao desenvolvedor. E a maioria dos desenvolvedores não está fazendo isso. Não por negligência, mas porque ninguém reformulou essas práticas clássicas em termos que façam sentido com o novo executor.

O Paradoxo da Velocidade

Existe uma ironia produtiva em tudo isso. Agentes de IA são rápidos. Tracer bullets são lentos (comparados a pedir tudo de uma vez). Mas tracer bullets com agentes são mais rápidos que pedir tudo de uma vez com agentes. Porque o retrabalho de uma geração monolítica consome mais tempo que a soma de fatias incrementais validadas.

Beck percebeu isso com TDD. Escrever testes antes parece mais lento. Mas o ciclo completo (escrita + depuração + correção) é mais rápido com testes do que sem eles. O mesmo princípio se aplica, com intensidade maior, quando o gerador de código não entende o que está fazendo.

Casos Onde Geração Ampla Funciona

Seria desonesto não reconhecer os cenários onde pedir tudo de uma vez é perfeitamente adequado. Boilerplate padronizado, CRUDs simples, scaffolding de projetos com padrões conhecidos. Nesses casos, o agente gera exatamente o que seria gerado por um template, e a verificação é trivial.

A distinção está na complexidade da decisão, não no volume de código. Quando cada linha de código é consequência previsível de uma convenção, geração ampla funciona. Quando linhas de código representam decisões de design, fatias pequenas são a única abordagem responsável.

O Que Tudo Isso Significa para Organizações

A convergência entre Pocock, Beck e Osmani valida algo que argumentamos desde o início: sistemas de IA precisam de governança integrada, não aparafusada depois.

Tracer bullets aplicados a agentes de código são governança-by-design. TDD com agentes é verificação contínua. Spec-first com incrementos é controle de escopo. Nenhuma dessas práticas foi inventada para IA. Todas se tornaram mais importantes por causa dela.

Organizações que estão buscando “frameworks de governança para IA” talvez devessem olhar primeiro para as práticas de engenharia que já possuem. O framework pode já estar lá: no pipeline de CI, na suíte de testes, no processo de code review, na cultura de especificação antes da execução.

A camada de governança que você precisa pode ser a camada de governança que já existia.

Fontes:

Parte do The Thinking Wire, publicado por Victorino Group.

Se isso faz sentido, vamos conversar

Ajudamos empresas a implementar IA sem perder o controle.

Agendar uma Conversa