A IA tornou o código barato. Agora precisamos provar que ele está certo

Um agente recebe uma instrução curta, navega pelo repositório, altera vários arquivos e abre um pull request antes que alguém consiga ler tudo com atenção. O código compila. Os testes existentes passam. A tela parece correta.

Só que a regra de negócio tinha uma exceção não escrita. O endpoint deveria preservar uma fronteira entre tenants. A migration precisava ser reversível. O fluxo exigia aprovação de outro responsável. Nada disso estava suficientemente explícito no pedido original — e nada no pipeline impediu uma interpretação plausível, porém errada.

Esse é o novo gargalo da engenharia assistida por IA. A capacidade de produzir código cresceu rapidamente; a capacidade de demonstrar que o código está correto não cresceu na mesma proporção. A discussão deixa de ser apenas “quanto código um agente consegue escrever” e passa a ser “qual evidência temos de que ele implementou a intenção certa?”.

Plausibilidade não é fidelidade

Modelos generativos são bons em completar lacunas. Quando encontram uma especificação ambígua, normalmente não interrompem o trabalho para pedir uma decisão. Escolhem uma interpretação provável e seguem adiante.

Esse comportamento é útil quando a tarefa é explorar alternativas. É perigoso quando a tarefa envolve contratos, dados, segurança ou regras que não aparecem no nome da funcionalidade.

Uma implementação pode ser tecnicamente coerente e ainda assim estar errada em relação ao produto. Pode usar o padrão arquitetural esperado, mas quebrar uma invariável importante. Pode adicionar testes que exercitam o caminho feliz e deixam de fora os casos de borda. Pode até aumentar a cobertura sem testar o comportamento que realmente oferece risco.

O problema não é simplesmente “a IA alucina”. A questão operacional é mais precisa: o sistema de desenvolvimento permite que uma hipótese seja promovida a fato sem validação suficiente?

A adoção de agentes torna essa pergunta urgente. O Stack Overflow descreveu 2025 como um período de aumento de incidentes e outages, embora ressalve que não é possível atribuir cada incidente diretamente à IA. A conclusão útil para quem opera sistemas não é culpar a ferramenta. É reconhecer que velocidade de produção não substitui controle de intenção, revisão e evidência.

A especificação precisa governar o trabalho

Especificação não é novidade. O que muda é sua função em um fluxo no qual agentes podem implementar, testar, refatorar e documentar em paralelo.

Um documento consultado no início do projeto e abandonado depois não governa esse fluxo. Para ser operacional, a especificação precisa conectar intenção, decisão, implementação e verificação.

Ela deve deixar claro:

• o que precisa ser construído;
• quais comportamentos são obrigatórios;
• quais decisões ainda dependem do dono do produto;
• quais evidências tornam uma story aceitável;
• quem pode aprovar cada etapa;
• quais condições bloqueiam a conclusão;
• como detectar divergência entre especificação e código.

Isso transforma a especificação em um contrato de execução. Uma story não está pronta apenas porque existe um commit ou porque os testes atuais passaram. Ela está pronta quando os critérios definidos foram atendidos e há evidência verificável para sustentá-los.

Essa distinção também melhora o trabalho humano. O desenvolvedor deixa de revisar apenas uma sequência de alterações e passa a revisar a relação entre decisão, contrato e resultado.

Instrução é diferente de mecanismo

“Não altere o schema sem migration reversível” é uma regra útil. Em um arquivo de instruções, porém, continua sendo texto. Um agente pode respeitá-la, interpretá-la de forma incompleta ou não receber aquela instrução no contexto correto.

Governança começa quando a regra tem uma consequência executável. O processo pode bloquear a conclusão da tarefa se não houver migration, marcar a evidência como incompleta ou exigir aprovação explícita antes de seguir.

A diferença é simples:

Uma instrução pede comportamento.

Um mecanismo torna a violação detectável ou impossível de ignorar.

O mesmo vale para separação de responsabilidades. Se a política exige que quem implementou uma mudança não seja a única pessoa a aprovar sua evidência de qualidade, registrar essa regra em um documento não basta. O fluxo de aprovação precisa conhecer os papéis, registrar a autoria e bloquear a combinação proibida.

Esse modelo não elimina julgamento. Ele reserva o julgamento para as decisões que realmente precisam de contexto e automatiza as verificações repetitivas que não deveriam depender de memória ou boa vontade.

O verificador também precisa ser verificado

Um painel cheio de indicadores verdes não prova que o processo está funcionando. Pode significar que tudo está correto. Também pode significar que os sensores não estão lendo o artefato certo, que uma condição nunca é exercitada ou que o mecanismo falha silenciosamente.

Por isso, a qualidade da governança precisa incluir metaverificação. Uma forma conhecida de fazer isso é introduzir violações controladas e confirmar se os verificadores reagem.

Se uma regra exige critério de aceitação, remova esse critério em uma cópia de teste e confirme que a execução é bloqueada. Se uma aprovação independente é obrigatória, simule a aprovação pelo mesmo responsável e verifique se o sistema rejeita o fluxo. Se uma relação de rastreabilidade é necessária, crie uma story sem vínculo com requisito e confirme que ela aparece como órfã.

A lógica é próxima à do mutation testing: não basta observar testes passando; é preciso testar se eles falham quando deveriam. O mesmo princípio se aplica ao processo de desenvolvimento. Um sensor confiável é aquele que demonstrou capacidade de detectar uma violação relevante.

Sem esse exercício, governança pode virar teatro: muitas regras, muitos checks e pouca certeza de que algum deles realmente protege o sistema.

Evidência precisa carregar seu grau de certeza

Nem toda frase de uma especificação tem o mesmo status.

“Os usuários reclamam que o checkout está lento” é um relato. “O checkout apresentou determinado tempo em uma medição específica” é uma observação mensurada. “Uma consulta sem paginação pode explicar parte do problema” é uma hipótese.

Misturar as três frases como se fossem fatos produz uma documentação convincente, mas frágil. O agente pode tomar uma hipótese como requisito. O líder pode priorizar um risco não confirmado. O time pode encerrar uma investigação sem nunca validar a causa.

Um fluxo confiável precisa distinguir pelo menos:

• fato apurado, sustentado por arquivo, linha, medição ou decisão registrada;
• resposta do dono, quando o contexto de negócio não pode ser inferido do código;
• estimativa, identificada como estimativa;
• questão aberta, que ainda precisa de resposta;
• inconclusivo, quando não há dados suficientes para afirmar algo.

Essa classificação não é burocracia. Ela evita que a ausência de evidência seja confundida com evidência de ausência. Também torna explícito onde o time precisa parar de gerar código e voltar a investigar.

O objetivo não é autonomia sem controle

A narrativa mais simples sobre agentes é: modelos melhores geram mais autonomia e reduzem a necessidade de pessoas. Para sistemas relevantes, o caminho tende a ser menos linear.

Quanto mais responsabilidade delegamos aos agentes, mais importante se torna uma camada independente de controle. Essa camada precisa responder perguntas concretas:

• qual era a intenção registrada;
• quais decisões estavam autorizadas;
• quais evidências sustentavam a tarefa;
• quem aprovou o resultado;
• quais verificações foram executadas;
• quais verificações ficaram inconclusivas;
• se a implementação continua compatível com o contrato.

Isso não significa submeter cada linha a uma comissão. Significa tornar auditáveis as decisões que podem alterar comportamento, dados, segurança e fronteiras arquiteturais.

O agente pode ser rápido. A plataforma de engenharia precisa ser rigorosa sobre o que conta como concluído.

Do diagnóstico ao código executável

O Spec-Driven Development ganha força quando a especificação não termina em um documento, mas produz artefatos que entram no fluxo do time: contratos, critérios de aceitação, regras de governança e sensores de progresso.

Essa abordagem também precisa funcionar sobre sistemas existentes. Antes de pedir a um agente que modernize um serviço, é necessário saber onde estão os hotspots, quais dependências formam ciclos, quais integrações não têm timeout ou tratamento de erro evidente e quais decisões são sustentadas por fatos do repositório.

Sem esse diagnóstico, a especificação pode organizar uma intenção baseada em premissas erradas. Com diagnóstico rastreável, o plano consegue separar o que foi observado, o que foi decidido e o que ainda precisa ser validado.

É esse o papel de uma fundação de engenharia orientada por evidência: não prometer que o código será correto por definição, mas reduzir o espaço para afirmações sem lastro e tornar as divergências visíveis antes que virem incidente.

Um caminho prático para o time

A transição não precisa começar com uma plataforma nova. Um time pode testar o modelo em uma única mudança de risco moderado:

1. Registre a intenção e as invariantes que não podem ser quebradas.
2. Separe fatos, decisões do dono, hipóteses e perguntas abertas.
3. Defina critérios de aceitação que possam ser verificados.
4. Declare quem implementa, quem revisa e quem aprova.
5. Gere evidência junto com a implementação, não depois dela.
6. Adicione pelo menos uma violação deliberada para testar cada verificador importante.
7. Compare a especificação com o resultado antes de marcar a tarefa como concluída.

Depois, observe onde o processo falhou. Se a regra só existia no prompt, transforme-a em check. Se o check não detectou a mutação, corrija o próprio check. Se uma afirmação não tinha evidência, marque-a como inconclusiva em vez de completar a lacuna com confiança artificial.

O objetivo é construir um sistema em que velocidade e prudência não dependam de um agente perfeito.

Confiança continua sendo o recurso escasso

A IA reduziu o custo de produzir código. Isso é valioso, mas não resolve o custo de entender o sistema, decidir corretamente e demonstrar que a mudança preservou as propriedades importantes.

O próximo avanço do SDD não será apenas escrever planos melhores. Será conectar especificações a contratos, autoridade, verificações e evidências — e provar que os próprios mecanismos de verificação funcionam.

No ArchGenerator, essa ideia aparece como a ligação entre diagnóstico e kit SDD executável: o repositório é analisado com evidências rastreáveis, incertezas são declaradas e o resultado pode virar especificações, contratos, governança e sensores para orientar a execução. A ferramenta não substitui o julgamento do time nem conserta o código sozinha. Ela ajuda a tornar a decisão verificável antes de transformá-la em trabalho.

O código ficou barato. A confiança ainda precisa ser construída, medida e defendida a cada mudança.