Desenvolvimento Orientado a Especificações (SDD): Eliminando Deriva de Código e Alucinações de Múltiplos Turnos com Consenso Formal

1. O Colapso do "Prompt-and-Pray" e do Vibe Coding

Toda equipe de engenharia que adota assistentes de código baseados em IA passa pela mesma fase enganosa de lua de mel. No Turno 1, um desenvolvedor escreve um prompt em linguagem natural e observa um módulo limpo e idiomático surgir em segundos. No Turno 2, um novo endpoint é conectado. No Turno 3, testes unitários são gerados. Tudo parece mágica.

Então chegam o Turno 4 e o Turno 5.

Em qualquer base de código não trivial — repositórios acima de 50.000 linhas, microsserviços distribuídos, fronteiras rígidas de schema ou máquinas de estado multi-tenant — o vibe coding probabilístico ("Prompt-and-Pray") colide com uma parede exponencial de entropia.

Em vez de convergir para uma arquitetura estável, cada turno conversacional introduz uma degradação estrutural silenciosa:

• Deriva Composta de Contexto (Context Drift): Conforme o histórico cresce, restrições arquiteturais iniciais saem da janela efetiva de atenção do modelo (degradação lost-in-the-middle). O modelo esquece que o UserRepository exige soft-delete via deleted_at IS NULL ou que o barramento de eventos exige chaves de idempotência.
• Violações Silenciosas de Invariantes: Para satisfazer o pedido imediato do Turno 5, o modelo altera discretamente a assinatura de um helper compartilhado, enfraquece uma união de tipos TypeScript para any ou contorna um middleware de validação — quebrando três módulos não carregados no contexto.
• Cascatas de Alucinação em Múltiplos Turnos: Quando um teste falha no Turno 4, o desenvolvedor cola o stack trace. O LLM, otimizando para plausibilidade local em vez de corretude global, inventa uma flag de configuração inexistente ou mocka a asserção que falhou em vez de corrigir a causa raiz.
• A Armadilha do Viés de Confirmação: Como o mesmo contexto de modelo que escreveu a implementação defeituosa é encarregado de revisá-la ou corrigi-la, ele herda suas próprias premissas falhas. O modelo racionaliza abstrações quebradas em vez de contestá-las.

Matematicamente, se cada turno conversacional t possui uma pequena probabilidade p_drift de introduzir uma premissa não documentada ou quebrar uma invariante implícita, a probabilidade de a base de código permanecer arquiteturalmente íntegra após k turnos não verificados decai exponencialmente:

P(Integra_k) = Produto_{t=1..k} (1 - p_drift_t) ≈ (1 - p_drift)^k

Mesmo com uma taxa modesta de deriva de p_drift = 0.15 por turno, no Turno 5 a probabilidade de zero regressão arquitetural cai abaixo de 44%. No Turno 10, colapsa para 19%. Em sistemas de produção, vibe coding não é velocidade — é dívida técnica de juros compostos gerada na velocidade de tokens.

2. Desenvolvimento Orientado a Especificações (SDD): Invertendo o Pipeline de Síntese

O Desenvolvimento Orientado a Especificações (SDD) é uma disciplina formal de engenharia que elimina a entropia de múltiplos turnos ao inverter a ordem fundamental de operações na construção de software assistida por IA:

O Axioma do SDD: Linguagem natural é uma entrada inaceitável para síntese direta de código. A intenção deve ser primeiro compilada em um Contrato de Especificação imutável e verificável por máquina antes que uma única linha de código de implementação seja gerada.

Na engenharia de software clássica, métodos formais (TLA+, Alloy, Design-by-Contract) eram historicamente caros demais para a velocidade diária de produto. Na era da síntese de código por IA, contudo, a economia se inverte: gerar código é praticamente gratuito, enquanto verificar corretude e impedir deriva silenciosa é o verdadeiro gargalo.

O SDD resolve esse gargalo introduzindo uma representação intermediária determinística entre a intenção humana (ou de agente) e a emissão de código em AST:

Observe o que muda neste pipeline:

• Zero "bate-papo" aberto sobre código: O agente de implementação nunca precisa adivinhar o que significa "tratar erros adequadamente". O Contrato Conductor define classes exatas de erro, mapeamentos HTTP, políticas de retry e invariantes de rollback.
• Zero autoavaliação: O agente que escreve o código jamais aprova o próprio pull request. A aprovação exige Consenso Formal entre o Verificador de Invariantes em AST, um Revisor Goldfish sem contexto e a execução determinística de testes.

3. Contratos Conductor: Anatomia de uma Especificação Executável

No ecossistema Benni Master OS, o subsistema Conductor governa o Desenvolvimento Orientado a Especificações. Um Contrato Conductor não é uma lista vaga de desejos em markdown — é um artefato de especificação estruturado e versionado por hash que trava quatro dimensões antes do início da síntese:

1. Contratos de Fronteira e Interface: Schemas exatos de entrada/saída, definições estritas de tipos, variantes de erro e limites de módulos.
2. Invariantes de Estado e Efeitos Colaterais: Declarações explícitas de qual estado pode ser mutado, o que deve permanecer idempotente e qual I/O externo é permitido ou proibido.
3. Trava de Escopo (Scope Lock — Allowlist / Denylist): O conjunto exato de arquivos e símbolos que o agente sintetizador tem autorização para tocar. Qualquer diff fora do escopo declarado é rejeitado automaticamente antes da revisão.
4. Critérios de Aceite e Reality Lock: Asserções verificáveis por máquina e comandos determinísticos de teste que provam que a implementação corresponde à especificação.

Considere um exemplo concreto: uma equipe de engenharia precisa adicionar um manipulador idempotente de ingestão de webhooks para eventos de faturamento. No vibe coding, o desenvolvedor escreve: "Adicione um endpoint de webhook Stripe que atualize assinaturas de usuários e registre falhas." Em 4 turnos, a IA pode esquecer a verificação de assinatura criptográfica, omitir transações de banco de dados ou introduzir uma condição de corrida em entregas duplicadas.

No Conductor SDD, a especificação é compilada primeiro como um contrato imutável:

contract_id: "spec-billing-webhook-v1"
scope_lock:
  allowed_files:
    - "src/billing/webhook_handler.py"
    - "src/billing/models.py"
    - "tests/billing/test_webhook_handler.py"
  forbidden_mutations:
    - "src/auth/**"
    - "migrations/**"

interface:
  entrypoint: "handle_billing_webhook(payload: bytes, sig_header: str, db: AsyncSession) -> WebhookReceipt"
  errors:
    - "InvalidSignatureError -> HTTP 401"
    - "MalformedPayloadError -> HTTP 400"
    - "TransientStorageError -> HTTP 503 (acionar retry)"

invariants:
  - id: "INV-01"
    rule: "Assinatura criptográfica HMAC DEVE ser verificada antes da desserialização JSON."
  - id: "INV-02"
    rule: "event_id duplicado DEVE retornar 200 OK de forma idempotente sem mutar o estado da assinatura."
  - id: "INV-03"
    rule: "Atualização da assinatura e inserção no ledger de event_id DEVEM ocorrer dentro de uma única transação atômica."
  - id: "INV-04"
    rule: "Zero segredos brutos, tokens ou PII podem aparecer em logs estruturados de erro."

acceptance_gates:
  - "pytest tests/billing/test_webhook_handler.py -v"
  - "ast_invariant_check --contract spec-billing-webhook-v1"

Quando esse contrato é travado, o agente sintetizador não possui margem para improvisação arquitetural. Cada invariante (INV-01 a INV-04) torna-se um alvo binário de verificação.

4. Comparação Formal de Fluxo: Vibe Coding vs. Conductor SDD

Para quantificar por que o SDD escala em repositórios corporativos enquanto o prompting em múltiplos turnos entra em colapso, compare os dois paradigmas ao longo de todo o ciclo de vida do software:

5. O Modelo Elephant-Goldfish (EGM): Verificação Cega Zero-Contexto

Mesmo com uma especificação rigorosa, um modo de falha sutil permanece quando um único agente de IA escreve e verifica o código: viés cognitivo compartilhado.

Se o Agente A consome 40.000 tokens explorando um repositório, lendo soluções legadas, elaborando um plano e escrevendo uma implementação, o Agente A desenvolve visão de túnel. Quando questionado "Seu código satisfaz todas as invariantes?", a atenção do Agente A está saturada com suas próprias justificativas. Ele deixará passar um await ausente, um caso de borda em INV-02 ou um cast silencioso porque ele tinha a intenção de que o código funcionasse.

Para derrotar o viés de confirmação, o Benni Master OS aplica o Modelo Elephant-Goldfish (EGM) — uma arquitetura de consenso formal em dois papéis:

Papel 1: O Elefante (Contexto Sistêmico e Síntese)

O Elefante retém a memória arquitetural de longo horizonte da base de código: grafos de dependência, restrições legadas, histórico de design e relações entre módulos. O Elefante redige o Contrato Conductor e sintetiza o diff de implementação.

Papel 2: O Goldfish (Revisor Cego Zero-Contexto)

O Goldfish é instanciado em um contexto completamente isolado e sem histórico. Ele nunca viu o rastro de raciocínio do Elefante, seus rascunhos ou suas tentativas anteriores. O Goldfish recebe exatamente duas entradas:

1. O Contrato Conductor Imutável (a especificação e suas invariantes).
2. O Git Diff / Artefato AST Resultante (a implementação).

O mandato do Goldfish é adversarial e estritamente objetivo: Provar que o diff satisfaz todas as invariantes do contrato ou rejeitá-lo com contraexemplos exatos por linha.

+-------------------------------------------------------------------------+
|                  PROTOCOLO DE CONSENSO ELEPHANT-GOLDFISH                |
|                                                                         |
|  [AGENTE ELEFANTE]                                                      |
|   - Memória completa do codebase e histórico de design                  |
|   - Compila Spec + Sintetiza Diff                                       |
|           |                                                             |
|           +---> Produz: (1) Contrato Conductor  (2) Code Diff           |
|                                  |                     |                |
|                                  v                     v                |
|                     [BARREIRA DE INFORMAÇÃO: ZERO VAZAMENTO]            |
|                                  |                     |                |
|                                  v                     v                |
|  [AGENTE GOLDFISH (Subagente Zero-Contexto)]                            |
|   - Vê APENAS Contrato + Diff (Sem raciocínio ou desculpas do Elefante) |
|   - Audita cada regra INV-xx de forma adversarial                       |
|           |                                                             |
|           +---> REJEITA (Contraexemplo) ---> Retorna ao Elefante        |
|           +---> APROVA (Consenso Formal) ---> Segue para AST e Testes   |
+-------------------------------------------------------------------------+

Por que essa barreira é tão eficaz? Porque um Goldfish não pode ser convencido pelo raciocínio prévio do Elefante. Se o Elefante escreveu acidentalmente if event_id: em vez de verificar o bloqueio transacional do banco, o próprio contexto do Elefante pode "lembrar" que queria uma transação e ignorar o bug. O Goldfish, vendo apenas INV-03 e o diff bruto, aponta imediatamente: "VIOLAÇÃO INV-03: subscription_repo.update() e event_ledger.insert() executam em commits implícitos separados; nenhum bloco transacional atômico envolve ambas as chamadas."

Matriz de Gates de Consenso EGM

6. Checagem de Invariantes em AST Antes da Execução de Código

Esperar que testes em tempo de execução capturem deriva estrutural é lento e incompleto — testes exercitam apenas os caminhos que cobrem explicitamente. O SDD adiciona uma Camada Determinística de Verificação via Árvore de Sintaxe Abstrata (AST) que inspeciona a estrutura do código antes que ele seja executado.

Ao analisar arquivos Python, TypeScript ou Rust gerados em suas ASTs nativas, o verificador prova propriedades estruturais em milissegundos com custo zero de tokens de LLM:

• Fidelidade de Assinatura e Tipos: Verifica se funções exportadas correspondem exatamente aos nomes de parâmetros, anotações de tipo e tipos de retorno declarados no Contrato Conductor.
• Aplicação de Fronteiras de Importação: Garante que módulos de domínio não importem camadas de infraestrutura proibidas (por exemplo, impedindo que um serviço de domínio puro importe requests, subprocess ou os.environ diretamente).
• Limites de Fluxo de Controle e Complexidade: Sinaliza condicionais profundamente aninhadas, cláusulas except: nuas, erros engolidos ou recursão irrestrita que violem padrões de confiabilidade em produção.
• Provas de Ordem de Operações: Para invariantes de segurança como INV-01 ("Verificar assinatura HMAC antes do parse JSON"), um visitante de AST comprova estaticamente que verify_hmac(...) domina json.loads(...) em todos os caminhos de controle dentro de handle_billing_webhook.

Veja como um verificador leve em AST Python captura com precisão uma alucinação clássica de IA — um LLM inserindo um except Exception: pass silencioso ou chamando json.loads() antes da verificação da assinatura:

import ast
from typing import List

class WebhookInvariantVisitor(ast.NodeVisitor):
    '''Verificador estático em AST provando INV-01 e banindo supressão silenciosa de exceções.'''

    def __init__(self) -> None:
        self.hmac_line: int | None = None
        self.json_parse_line: int | None = None
        self.violations: List[str] = []

    def visit_Call(self, node: ast.Call) -> None:
        func_name = ast.unparse(node.func)
        if "verify_hmac" in func_name and self.hmac_line is None:
            self.hmac_line = node.lineno
        if func_name in {"json.loads", "orjson.loads"} and self.json_parse_line is None:
            self.json_parse_line = node.lineno
        self.generic_visit(node)

    def visit_ExceptHandler(self, node: ast.ExceptHandler) -> None:
        if node.type is None:
            self.violations.append(f"Linha {node.lineno}: Cláusula 'except:' nua proibida pelo contrato.")
        if len(node.body) == 1 and isinstance(node.body[0], ast.Pass):
            self.violations.append(f"Linha {node.lineno}: Supressão silenciosa ('pass') proibida.")
        self.generic_visit(node)

    def verify(self, source_code: str) -> List[str]:
        tree = ast.parse(source_code)
        self.visit(tree)
        if self.json_parse_line is not None:
            if self.hmac_line is None or self.hmac_line > self.json_parse_line:
                self.violations.append(
                    "VIOLAÇÃO INV-01: Desserialização JSON ocorre antes da verificação criptográfica HMAC."
                )
        return self.violations

Essa passagem de 30 linhas em AST executa em menos de 2 milissegundos, não pode ser persuadida por nomes criativos de variáveis e elimina permanentemente uma classe inteira de regressões de segurança e confiabilidade antes mesmo de o executor de testes iniciar.

7. Reality Lock: Separando Intenção de Evidência Observada

Um modo de falha generalizado em agentes autônomos de código é o relato otimista: um agente edita um arquivo, executa uma checagem parcial ou mockada e declara "Todos os testes passaram e a produção está pronta."

O Conductor SDD impõe o Reality Lock — um protocolo epistêmico rigoroso em todo o ciclo de engenharia:

• Intenção é o que o usuário solicitou.
• Plano é o Contrato Conductor compilado.
• Dispatch é a execução limitada atribuída a um worker ou subagente.
• Execução é a mutação real de arquivos e geração de AST.
• Evidência Observada é o stdout/stderr bruto e o código de saída da execução de testes pós-edição, somados ao digest SHA-256 do artefato verificado.

Sob o Reality Lock, nenhum agente tem permissão para declarar conclusão a menos que a evidência observada tenha sido capturada após a edição final. Se um único caractere mudar em um arquivo, todos os recibos de teste anteriores são invalidados, e os gates de AST e Reality Lock devem ser reexecutados.

8. Implementando SDD na Sua Organização de Engenharia

Adotar o Desenvolvimento Orientado a Especificações não exige substituir suas linguagens, frameworks ou pipelines de CI/CD atuais. Exige mudar onde o rigor de engenharia é aplicado:

1. Congele o Contrato Primeiro: Para qualquer funcionalidade que toque mais de dois arquivos ou altere estado persistente, exija um Contrato Conductor escrito (interfaces, invariantes, trava de escopo) antes de acionar qualquer agente de código.
2. Isole Seus Revisores: Nunca peça para a mesma sessão de chat que escreveu um diff de 400 linhas auditá-lo. Instancie um agente Goldfish novo e sem contexto apenas com o contrato e o git diff.
3. Automatize Invariantes Estruturais com ASTs: Codifique os comentários recorrentes de code review da sua equipe (imports proibidos, fronteiras transacionais, regras de log, tipagem estrita) em visitantes leves de AST no CI.
4. Exija Reality Lock em Cada Merge: Exija recibos criptográficos ou imutáveis de CI comprovando que todos os gates de aceite passaram exatamente no commit SHA sendo integrado.

A era de tratar assistentes de código de IA como máquinas caça-níqueis conversacionais acabou. Organizações que dominam o Desenvolvimento Orientado a Especificações, Contratos Conductor e Consenso Formal Elephant-Goldfish conquistam tanto a velocidade da síntese autônoma quanto a confiabilidade da engenharia de sistemas formais.

Pronto para arquitetar sistemas de IA com deriva zero? Explore a Academia de Engenharia Benni OS ou acesse a Plataforma Benni OS.