Paradoxo de Jevons na Engenharia de IA

1. Conceito e Essência (Visão Geral e Problema Sistêmico)

O Paradoxo de Jevons na engenharia de IA é um efeito sistêmico no qual a redução do custo e da latência da geração de código não diminui o volume total de trabalho de engenharia, mas o aumenta até o ponto em que o gargalo deixa de ser a inferência e passa a ser a verificação, refatoração, revisão e manutenção da arquitetura. A fórmula clássica de Jevons: o aumento da eficiência no uso de um recurso reduz seu custo unitário e estimula uma maior conversão agregada. Em AI engineering, o recurso não é carvão, mas sim "plausible code change": diff, patch, scaffold, migration, test, PR.

Tecnicamente, o problema é formulado da seguinte maneira:

C_gen ↓  =>  D_gen ↑↑  =>  ReviewLoad ↑↑  =>  ReviewLatency ↑↑  =>  Burnout ↑↑ + TechDebt ↑↑

onde C_gen é o custo marginal para gerar uma draft change aceitável, D_gen é a demanda agregada por mudanças e ReviewLoad é a carga sobre a verificação. Se ReviewLoad exceder reviewer_capacity, o sistema não fica mais rápido; ele se torna mais tóxico.

Na era pré-IA, criar um PR era caro: o engenheiro escrevia o código manualmente, mantinha o contexto na cabeça e só então enviava a mudança para review. A geração de código com IA transforma esse ciclo em um processo de System 1: rápido, imitativo, de alta frequência. O modelo gera o diff em segundos. Mas a revisão é System 2: lenta, semântica, um recurso esgotável. Quando o custo do draft cai pela ordem de magnitude, a equipe intuitivamente aumenta a quantidade de drafts, sem aumentar proporcionalmente a capacidade de verificação semântica.

A mecânica de barateamento da geração une vários fatores de infraestrutura:

• FlashAttention e kernels otimizados reduzem o compute cost para long-context inference.
• RoPE e esquemas modernos de posição permitem trabalhar estávelmente com grandes contextos.
• KV Cache reduz a latency em ReAct loop multi-turno e sessões de agentes.
• Unpadding e dynamic batching reduzem o overhead ao processar prompts de comprimentos variáveis.
• Camadas de retrieval/reranking semelhantes ao ModernBERT oferecem busca de código mais barata, permitindo que o modelo receba mais contexto relevante por menor custo.
• Fast Patching e geração consciente de diffs reduzem o número de tokens necessários para aplicar uma mudança.

Cada um desses fatores melhora individualmente o throughput. Juntos, eles criam uma economia onde "tentar mais uma variante" se torna quase gratuito. Mas um "draft gratuito" não significa uma "mudança gratuita em produção". Uma mudança em produção exige:

1. Entender por que o diff existe.
2. Verificar que ele não quebra invariantes.
3. Confirmar que ele não adiciona dívida técnica oculta.
4. Avaliar o impacto em latency, cost, security e operability.
5. Estar pronto para manter o código no futuro.

A economia da AI codegen é frequentemente medida incorretamente:

Erro crítico no pensamento arquitetural: otimizar tokens/sec e time-to-first-diff, ignorando o time-to-verified-merge. O Paradoxo de Jevons em AI engineering não é sobre a IA gerar mal o código. É sobre o sistema ficar mais rápido na entrada, mas mais lento na saída, porque a verificação humana não escala via GPU.

2. Arquitetura e Mecânica Interna (Taxonomia e Modelo Mental)

O contorno completo da engenharia assistida por IA consiste em três planos:

1. Generation plane — Geração rápida de drafts, patches, scaffolds.
2. Verification plane — Testes, análise estática, review, gates de segurança.
3. Governance plane — Orçamentos, políticas, métricas, rollbacks, limites de ownership.

O paradoxo surge quando o Generation plane escala hardware, enquanto o Verification plane permanece socialmente limitado.

┌────────────────────────────┐
│ Engineer / Product Request │
└─────────────┬──────────────┘
              │ task + constraints + repo state
              ▼
┌────────────────────────────┐
│ Context Builder            │
│ - code search / ModernBERT │
│ - MCP resources            │
│ - dependency graph         │
│ - policy manifest          │
└─────────────┬──────────────┘
              │ prompt bundle + token budget
              ▼
┌──────────────────────────────────────────────┐
│ Model Runtime                                │
│ FlashAttention | RoPE | KV Cache | Unpadding │
│ ReAct loop / tool calls / draft generation   │
└─────────────┬────────────────────────────────┘
              │ raw diff / patch / files
              ▼
┌────────────────────────────┐
│ Fast Patching + Normalizer │
│ - split large diff         │
│ - enforce patch size       │
│ - add provenance           │
└─────────────┬──────────────┘
              │ CodegenResult
              ▼
┌────────────────────────────┐
│ Verification Plane         │
│ Pydantic AI | Guardrails   │
│ unit/integration tests     │
│ SAST/SCA/secret scan       │
│ reviewer queue             │
└─────────────┬──────────────┘
              │ pass / fail / request changes
              ▼
┌────────────────────────────┐
│ Merge / Deploy / Telemetry │
└─────────────┬──────────────┘
              │ feedback: latency, defects, churn
              ▼
┌────────────────────────────┐
│ Governance Plane           │
│ budgets, quotas, rollback  │
│ review load, tech debt     │
└────────────────────────────┘

Taxonomia dos componentes:

• Request: Tarefa de engenharia, intenção de negócio, restrições, nível de risco.
• Context Builder: Coleta arquivos relevantes, testes, documentação, PRs anteriores. Usa retrieval, embeddings, rerankers.
• Model Runtime: Camada de inferência. KV Cache reduz o custo computacional repetido em sessões multi-turno; FlashAttention otimiza a attention; Unpadding reduz o desperdício no batching.
• ReAct loop: Ciclo agentic reason -> act -> observe. Útil, mas com tokens baratos facilmente gera iterações desnecessárias.
• Fast Patching: Geração de diffs mínimos em vez de reescrever arquivos inteiros. Reduz o custo, mas pode aumentar a quantidade de pequenas mudanças.
• Pydantic AI: Validação da estrutura de saída, por exemplo, CodegenResult, ReviewDecision, PatchPolicy.
• Guardrails: Restrições sobre paths, dependencies, padrões de secrets, camadas de arquitetura, contratos de API.
• Reviewer: Verificação humana de semântica, consequências arquiteturais, segurança operacional.
• CI/CD: Verificação determinística: tests, build, deploy, canary, rollback.
• Governance: Métricas, orçamentos, SLOs, políticas de ownership, contabilidade de tech debt.

Modelo mental do paradoxo:

Unit cost of draft ↓
Perceived risk of draft ↓
Retry frequency ↑
Draft volume ↑
Review queue ↑
Reviewer attention per PR ↓
Acceptance of shallow diffs ↑
Hidden coupling ↑
Future change cost ↑

Não se trata linearmente de "mais código". Trata-se de uma mudança na distribuição da atenção. Quando o draft é barato, os engenheiros começam a enviar mudanças que antes não criavam, pois não queriam gastar tempo. Os revisores respondem formalmente, porque não conseguem acompanhar. A arquitetura erode não por um único mau PR, mas por mil mudanças "plausivelmente aceitáveis".

3. Pipeline Técnico do Ciclo de Vida

O ciclo de vida de uma mudança assistida por IA tem quatro estágios. Cada estágio deve ter um contrato, um orçamento e uma métrica.

1. Formulação / Estado de Entrada

A entrada não é "faça-me uma feature", mas um contrato estruturado:

{
  "task_id": "T-8842",
  "repo": "payments-service",
  "base_sha": "a7f3c91",
  "objective": "Add idempotency key to refund API",
  "risk_tier": "high",
  "allowed_paths": [
    "src/refund/**",
    "tests/refund/**",
    "openapi/refund.yaml"
  ],
  "forbidden_paths": [
    "src/auth/**",
    "infra/iam/**"
  ],
  "constraints": {
    "max_patch_lines": 180,
    "context_budget_tokens": 24000,
    "max_new_tokens": 4096,
    "required_tests": true,
    "require_backward_compatible_api": true,
    "no_new_external_dependencies": true
  },
  "verification_gates": [
    "unit",
    "contract",
    "security",
    "arch_lint",
    "reviewer"
  ]
}

Campos-chave:

• risk_tier: Define a profundidade da verificação.
• allowed_paths: Limita o blast radius.
• max_patch_lines: Evita mega-PRs gerados por IA.
• context_budget_tokens: Controla o custo e a qualidade do retrieval.
• verification_gates: Lista de verificações obrigatórias.

2. Transformação

O Context Builder forma o prompt bundle:

def build_context(request: CodegenRequest) -> PromptBundle:
    relevant_files = code_search(
        query=request.objective,
        repo=request.repo,
        top_k=12,
        reranker="modernbert-code-v2"
    )
    dependency_graph = load_dependency_graph(request.repo, request.base_sha)
    policy = load_policy(request.repo, request.risk_tier)

    return PromptBundle(
        task=request,
        files=relevant_files,
        graph=dependency_graph,
        policy=policy,
        token_budget=request.constraints.context_budget_tokens
    )

Neste estágio, é importante não apenas dar mais contexto ao modelo, mas fornecer-lhe um contexto limitado, estruturado e validado. Sem isso, cresce o risco de long-context degradation: o modelo vê muitos arquivos, mas perde os invariantes.

3. Execução / Inference

O modelo gera o diff através do ReAct loop ou direct patch generation:

from pydantic_ai import Agent

agent = Agent(
    model="openai:gpt-5.2",
    output_type=CodegenResult,
    system_prompt=CODEGEN_SYSTEM_PROMPT
)

result: CodegenResult = agent.run_sync(
    prompt_bundle.render(),
    tools=mcp_tools,
    guardrails=[
        patch_size_guard,
        allowed_paths_guard,
        secret_detector_guard,
        dependency_policy_guard
    ]
)

Saída esperada:

{
  "patch_id": "P-10492",
  "task_id": "T-8842",
  "diff": "diff --git a/src/refund/api.py b/src/refund/api.py\n...",
  "changed_files": [
    "src/refund/api.py",
    "tests/refund/test_idempotency.py"
  ],
  "tokens_used": {
    "input": 18420,
    "output": 2140
  },
  "cost_usd": 0.0214,
  "p95_latency_ms": 1420,
  "confidence": 0.82,
  "guardrail_flags": [],
  "verification_plan": [
    "unit",
    "contract",
    "security"
  ]
}

Fast Patching aqui significa gerar um diff mínimo, mas não necessariamente uma mudança mínima. Se o modelo fizer 40 pequenos PRs em vez de um architecturalmente coeso, o throughput aumenta, mas a carga de review também.

4. Processamento de Feedback

Após a geração, começa a verdadeira engenharia:

def verify_patch(result: CodegenResult, request: CodegenRequest) -> VerificationDecision:
    structural = validate_structure(result)
    security = run_security_gates(result.diff, request)
    tests = run_required_tests(result, request)
    architecture = check_architecture_rules(result, request)
    reviewer_load = estimate_review_load(result)

    return VerificationDecision(
        patch_id=result.patch_id,
        structural_ok=structural.ok,
        security_ok=security.ok,
        tests_ok=tests.ok,
        architecture_ok=architecture.ok,
        reviewer_load_score=reviewer_load.score,
        merge_allowed=all([
            structural.ok,
            security.ok,
            tests.ok,
            architecture.ok,
            reviewer_load.score < request.risk_tier.review_threshold
        ])
    )

O resultado do review deve ser um sinal estruturado, não apenas "LGTM":

{
  "patch_id": "P-10492",
  "verdict": "request_changes",
  "review_minutes": 34,
  "semantic_risk": 0.71,
  "reviewer_load_score": 0.83,
  "issues": [
    "idempotency key not validated against tenant_id",
    "contract test missing for duplicate request",
    "error response changes public API shape"
  ]
}

O Paradoxo de Jevons é controlado exatamente neste estágio: se o reviewer_load_score não estiver incluído no SLO, o sistema gerará mais mudanças do que consegue verificar com segurança.

4. Cenários Práticos de Uso em Produção

01. Equipe de Plataforma com AI codegen para templates de serviços

Situação: A plataforma possui 120 microsserviços. A equipe implementa AI codegen para criar service scaffolding, config, health checks, OpenAPI stubs, CI templates. O custo unitário do scaffold cai de 4 horas para 15 minutos. Após uma semana, o número de PRs aumenta 300%.

As métricas iniciais parecem positivas:

median time-to-first-diff: 4h -> 12m
cost per scaffold generation: $0.03
p95 inference latency: 1.6s
PR volume: +310%

Mas após 3 semanas:

p95 review latency: 2d -> 6d
reviewer utilization: 55% -> 108%
defect escape rate: 0.7% -> 2.9%
churn within 14d: 8% -> 27%

Causa: A IA gera rapidamente templates "plausivelmente funcionais", mas não assume responsabilidade pela operability de longo prazo. Cada scaffold adiciona:

• Novas dependencies;
• Novas config keys;
• Novos CI jobs;
• Novas alert rules;
• Nova surface area para segurança;
• Novos compromissos de suporte.

Decisão arquitetural:

1. Introduzir risk_tier para scaffold: low, medium, high.
2. Limitar max_patch_lines e max_files_per_pr.
3. Exigir contract tests e security baseline.
4. Automatizar golden paths: não gerar código no vácuo, mas preencher slots de templates verificados.
5. Introduzir quota de revisor: não mais que N high-risk PRs por revisor por dia.
6. Medir cost per verified service, não cost per generated diff.

Conteúdo da política:

{
  "policy_id": "platform-scaffold-v3",
  "max_patch_lines": 220,
  "max_files_per_pr": 18,
  "required_tests": ["unit", "contract", "security"],
  "forbidden_paths": ["infra/iam/**", "secrets/**"],
  "reviewer_quota": {
    "high_risk_pr_per_day": 4,
    "medium_risk_pr_per_day": 8
  }
}

Resultado: O throughput torna-se sustentável, pois o sistema deixa de converter geração barata em dívida gratuita.

02. Equipe de Produto com vibe coding para MVP

Situação: A equipe constrói rapidamente um MVP. Engenheiros usam IA para gerar UI, API, migrations, test fixtures. Em 2 semanas, o produto parece pronto. Em 6 semanas, a equipe não consegue alterar com segurança nenhum módulo.

Sintomas:

• Cada arquivo contém variações de IA geradas da mesma lógica;
• Existem três versões do mesmo auth helper;
• Contratos de API não estão sincronizados com os types do frontend;
• Testes são gerados para a implementação, não para a especificação;
• Camadas de arquitetura são violadas por "soluções rápidas";
• Context degradation: engenheiros não lembram por que cada diff existe.

Causa técnica: Codegen de System 1 cria código localmente plausível, mas não mantém invariantes globais. No vibe coding, o Paradoxo de Jevons manifesta-se como uma explosão de mudanças "desnecessárias, mas plausíveis".

Decisão arquitetural:

1. Introduzir module boundary contracts.
2. Proibir patches de IA que alterem mais de um módulo sem review arquitetural.
3. Usar Pydantic AI para validar DTOs, respostas de API, configs.
4. Adicionar architecture lint como gate de CI.
5. Armazenar obrigatoriamente intent metadata: por que o diff existe, qual contrato ele implementa.
6. Introduzir weekly debt budget: não mais que 20% das mudanças sem testes ou com alto risco semântico.

Exemplo de contrato de módulo:

class UserSessionContract(BaseModel):
    user_id: UUID
    tenant_id: UUID
    issued_at: datetime
    expires_at: datetime
    scopes: set[Literal["read:profile", "write:profile"]]

    @model_validator(mode="after")
    def validate_expiry(self):
        if self.expires_at <= self.issued_at:
            raise ValueError("expires_at must be after issued_at")
        return self

Se a IA gerar session logic sem validação via contrato, o patch é rejeitado antes do review. Isso reduz a quantidade de mudanças "lixo", sem matar a velocidade.

03. Migração em massa ou refatoração via AI Fast Patching

Situação: A equipe realiza uma migração de legacy API para new API em um monorepo. A IA gera 4.000 patches durante a noite. Cada patch é pequeno: substituir endpoint, atualizar client, adicionar test. À primeira vista, um caso de uso ideal.

Riscos:

• 4.000 PRs não são 4.000 mudanças; são 4.000 pontos de review.
• Patches pequenos podem ser semanticamente perigosos.
• O modelo pode "esquecer" edge cases em caminhos de 1%.
• Drift de versão de dependências pode passar despercebido.
• Ordem de merge cria conflitos ocultos.
• Rollback é complexo, pois as mudanças estão dispersas.

Decisão arquitetural:

1. Usar batched Fast Patching, mas com merge budget.
2. Agrupar patches por blast radius: uma migração lógica por PR, não um diff mecânico.
3. Adicionar semantic tests, não apenas snapshot tests.
4. Usar canary deploy por tenant / feature flag.
5. Manter um migration ledger: cada patch deve ter proveniência, owner, evidência de verificação.
6. Medir regression rate per 1000 patches, rollback count, post-merge defect age.

Exemplo de entrada no ledger:

{
  "migration_id": "MIG-2026-04",
  "patch_id": "P-10492",
  "logical_change": "replace legacy refund endpoint with idempotent v2",
  "blast_radius": "payments-service/refund",
  "tests": ["unit", "contract", "e2e"],
  "canary_percent": 5,
  "rollback_target": "a7f3c91",
  "verified_by": ["ci", "reviewer-42", "security-bot"]
}

Em produção, essa abordagem transforma a AI codegen de um gerador de ruído em uma ferramenta de transformação gerenciada.

5. Armadilhas, Erros Comuns e Segurança

Principais Riscos de Implantação

1. Review bottleneck migration
   Em vez de economizar tempo, a IA transfere o tempo da escrita de código para o review. A equipe vê diffs rápidos, mas merges lentos.

2. AI slop accumulation
   Código plausível que não é ruim em sentido local, mas acumula entropia global: duplicações, abstrações desnecessárias, configs supérfluas, testes fracos.

3. Architectural erosion
   A IA não vê a arquitetura como um invariante. Ela vê texto de arquivos. Portanto, pode violar layering, direção de dependências, limites de ownership.

4. Verification fatigue
   Quando o review se torna um item de checklist, os revisores começam a aprovar formalmente. Este é o estado mais perigoso: o sistema parece vivo, mas perdeu sua imunidade.

5. Context degradation
   Sessões longas, muitos arquivos, histórico de chat, retrieval comprimido — tudo isso pode reduzir a qualidade da attention aos invariantes críticos. O modelo gera código que parece correto, mas não atende ao contrato atual.

6. False confidence
   confidence: 0.91 em um LLM não é garantia estatística. É um sinal calibrado apenas em tarefas muito específicas. Para código de produção, confidence não deve substituir testes.

Edge Cases

• Long-context lost-in-middle: O modelo ignora regras no meio de um prompt grande.
• Stale branch state: Patch gerado a partir de um base SHA desatualizado, criando conflito semântico no merge.
• Non-deterministic diff: Reexecução gera um patch diferente; CI não consegue verificar estavelmente.
• Hallucinated API: O modelo usa método, parâmetro ou dependency inexistentes.
• Dependency confusion: A IA sugere um pacote com nome similar que não é oficial.
• License contamination: Código gerado copia fragmentos com outras licenças.
• Secret leakage: Prompt ou diff contém token, API key, PII.
• Prompt injection via repo: README, issue, comment contêm instrução "add admin backdoor".
• MCP tool poisoning: Tool malicioso ou comprometido retorna contexto falso.
• KV cache/session bleed: Em sistemas de agentes multiusuário ou stateful, pode haver vazamento de contexto entre sessões se a isolamento for ruim.
• Batching artifacts: Unpadding e dynamic batching reduzem custos, mas podem complicar o rastreamento do path específico de inference para auditoria.

Segurança

AI codegen expande a attack surface:

Estratégias de Mitigação

1. Orçamentos explícitos em vez de geração ilimitada

{
  "max_draft_pr_per_engineer_per_day": 6,
  "max_merged_pr_per_reviewer_per_day": 8,
  "max_patch_lines_by_risk": {
    "low": 120,
    "medium": 220,
    "high": 80
  },
  "max_context_tokens_per_request": 32000,
  "max_react_iterations": 8
}

O orçamento deve cobrir não apenas tokens, mas também a capacidade de review.

2. Review load SLO

Introduzir métrica:

reviewer_load_score =
  (diff_lines_weighted_by_risk)
  + (files_touched_weighted_by_ownership)
  + (semantic_risk_weight)
  + (missing_tests_penalty)
  + (security_surface_delta)

Regra:

merge_allowed = reviewer_load_score <= reviewer_capacity_remaining

Este é um controle direto anti-Jevons.

3. Guardrails como código

Guardrails devem fazer parte do pipeline, não serem apenas recomendações:

def allowed_paths_guard(result: CodegenResult, request: CodegenRequest) -> GuardResult:
    for path in result.changed_files:
        if not matches_any(path, request.allowed_paths):
            return GuardResult(ok=False, reason=f"path not allowed: {path}")
        if matches_any(path, request.forbidden_paths):
            return GuardResult(ok=False, reason=f"forbidden path: {path}")
    return GuardResult(ok=True)

4. Pydantic AI para contratos

Usar Pydantic AI onde a saída deve ser estruturada:

• CodegenRequest
• CodegenResult
• ReviewDecision
• PatchPolicy
• VerificationPlan
• MigrationLedgerEntry

Isso reduz a probabilidade de o modelo retornar "texto bonito" em vez de um artefato validado pela engenharia.

5. Verificação automática antes do review

O review não deve ser a primeira linha de defesa. Antes dele, devem passar:

• Unit tests;
• Contract tests;
• Integration tests;
• Property-based tests;
• SAST;
• SCA;
• Secret scan;
• Architecture lint;
• Dependency policy;
• Performance smoke;
• Migration dry-run.

O review humano deve verificar aquilo que não pode ser checado deterministicamente: intenção arquitetural, correção de produto, consequências operacionais.

6. Architectural fitness functions

Usar verificações:

- dependency direction must not violate layer map
- public API changes require contract diff
- no new cross-module private imports
- no new secrets in config
- no unowned files in production paths
- no duplicate helper implementations above threshold

Tais fitness functions tornam a architectural erosion mensurável.

7. Provenance e audit trail

Cada mudança assistida por IA deve ter:

{
  "patch_id": "P-10492",
  "model": "gpt-5.2",
  "prompt_hash": "sha256:...",
  "context_hash": "sha256:...",
  "base_sha": "a7f3c91",
  "tools_used": ["mcp:github", "mcp:ci"],
  "guardrail_results": [],
  "reviewer_id": "u-42",
  "verification_evidence": ["ci-run-8821", "security-scan-991"]
}

Sem proveniência, é impossível investigar regressões ou incidentes.

8. Rate limiting e circuit breaker

Se a latência p95 de review exceder o SLO, o sistema deve automaticamente:

• Reduzir o número permitido de draft PRs;
• Aumentar o limiar de test coverage;
• Restringir paths de alto risco;
• Exigir pair review;
• Bloquear batch migrations até que a fila estabilize.

Isso é análogo ao backpressure em sistemas de streaming.

9. Red teaming AI codegen

Testes regulares:

• Prompt injection via README;
• Resposta maliciosa de MCP tool;
• Dependency alucinada;
• Secret em diff gerado;
• Snippet contaminado por licença;
• Patch violando arquitetura;
• Modificação de caminho de auth de alto risco.

O resultado do red teaming deve integrar a release policy.

10. Mudar as métricas de sucesso

Métrica incorreta:

lines generated per hour

Métricas corretas:

verified changes per reviewer-hour
defect escape rate per 1000 AI-assisted merges
time-to-verified-merge p95
reviewer load saturation
architecture violation count
rollback rate per AI-assisted deploy
cost per production-ready change

O Paradoxo de Jevons em AI engineering é vencido não quando a equipe gera mais código, mas quando o sistema se torna capaz de verificar com segurança mais mudanças por unidade de atenção.