Alexandre Izefler

agentes

O gap que o spec não fecha

Especificações reduzem a distância entre intenção e comportamento, mas dois gaps inerentes fazem da produção o único verificador final. O assurance-revision loop como prática madura para engenharia agêntica.

Alexandre Izefler
agentesverificaçãoai-native

O gap que o spec não fecha

O spec foi bem escrito. Os testes passaram. A CI ficou verde. O deploy foi feito.

E a produção encontrou algo que nenhum desses passos viu.

Isso não é sinal de processo quebrado. É a estrutura do problema. Krentsel, Zaharia, Stoica e coautores da UC Berkeley publicaram em setembro de 2026 um paper que coloca esse fenômeno em termos precisos: há dois gaps inerentes em engenharia de software agêntica, e nenhum deles desaparece com especificações melhores. A produção é o único verificador final, não por falta de rigor, mas por um limite estrutural do que verificação pré-deploy consegue cobrir.

O que toda spec deixa para trás

O Requirement Gap existe porque especificações representam a intenção dos stakeholders. Elas não a capturam por inteiro.

Sempre há casos de borda não documentados. Sempre há ambiguidade que parece resolvida no papel até o usuário tentar algo que quem escreveu o spec não imaginou. Isso não é falha de quem especificou. É o limite epistemológico de qualquer representação.

Um mapa útil é incompleto por definição. Mapas completos não existem. A analogia vale para specs: uma especificação suficientemente detalhada para cobrir todos os casos ainda contém brechas, porque o mundo real tem variação que nenhum documento finito consegue antecipar na totalidade.

Spec-driven development reduz esse gap de forma significativa. A Ambiguity Tax que Nguyen e Nguyen formalizam no SDAD, o custo gerado por especificações vagas que agentes interpretam de formas divergentes, diminui quando a spec é precisa. Mas gap menor não é gap fechado. Essa distinção importa.

O ambiente que o teste não reproduz

O Model Gap é o segundo problema. O ambiente de teste é um modelo do ambiente de produção. Você simula a carga, simula as integrações, trabalha com dados representativos. O modelo pode ser muito bom. Ainda assim é uma aproximação.

Dados reais têm distribuições que conjuntos de teste não reproduzem com exatidão. Usuários reais combinam funcionalidades em sequências que o time não previu durante a especificação. Integrações externas têm comportamentos que mocks não simulam com fidelidade total.

Nos sistemas agênticos, esse gap se amplifica. A composição de múltiplos agentes cria padrões emergentes difíceis de prever em ambiente controlado. Um agente que funciona corretamente em staging pode interagir com outros de formas que só aparecem sob condições reais de carga e distribuição de dados. A superfície de comportamento possível cresce mais rápido do que a capacidade de cobri-la com testes.

O paradoxo do throughput agêntico

Happy Bhati formalizou em setembro de 2026 o que chamou de SDLC Agêntico Throughput Paradox. Agentes geram código em velocidade sem precedente histórico, mas os ganhos "se atenuam drasticamente entre escrever código e disponibilizar software confiável."

A pergunta de engenharia precisava mudar. Focar em volume de código gerado é a métrica mais visível, mas Bhati argumenta que ela perdeu relevância como indicador central. O que importa é quanto valor production-qualified o sistema entrega por hora de revisão e por unidade de risco operacional.

Essa reformulação tem implicações práticas diretas. A Verification Tax, o custo de tornar código agêntico confiável o suficiente para produção, é uma variável de engenharia tão relevante quanto a taxa de geração de código. As duas não crescem na mesma proporção: geração de código escala com modelos melhores, a capacidade de verificar contra a realidade de produção tem um teto diferente.

Na minha leitura, esse é o lado subestimado do paradigma 70/30. Quando só os 70% são medidos, os 30% de intenção, especificação e validação parecem constantes. Mas quando a geração cresce, a carga sobre os 30% cresce junto. E a parte mais pesada desse 30% é exatamente a verificação contra a realidade de produção, não a verificação contra o ambiente de teste.

O loop que a produção alimenta

O paper de Krentsel et al. propõe um caminho mais honesto do que tentar fechar os gaps antes do deploy: o assurance-revision loop. Usar evidências de produção para revisar especificações, modelos de ambiente e critérios de avaliação quando o comportamento real diverge do esperado.

Monitoramento de produção e ciclos de aprendizado existem há décadas. O que muda no contexto agêntico é a necessidade de tornar esse loop explícito, estruturado e conectado diretamente às especificações que alimentam os agentes.

Quando o agente gera comportamento que passou em todos os testes e falhou em produção, a pergunta certa não é "como o teste falhou?". A pergunta é qual parte do Requirement Gap esse comportamento revelou, e como a spec precisa ser atualizada para que a próxima iteração cubra esse caso.

Os 30% de intenção, especificação e validação não terminam no momento do merge. Eles continuam à medida que a produção descobre o que o spec não conseguiu antecipar. O loop fecha a distância que os gaps deixam, não de uma vez, mas sprint a sprint.

Spec-driven development é necessário. A crença de que uma especificação suficientemente boa elimina a surpresa de produção é o que os dados não sustentam. O Requirement Gap e o Model Gap são inerentes. Eles diminuem com rigor e continuam existindo.

Ter um sistema para aprender quando a produção revela o que o spec não prometeu é o que separa equipes que acumulam conhecimento de equipes que reinventam o mesmo incidente.

Referências