Hard Compiler & Linter Gates

1. Visão geral do conceito e o problema sistêmico

Os modelos de IA tendem a escrever código que parece impecável visualmente, mas falha durante a tentativa de compilação. Se o desenvolvedor aceitar o diff sem uma verificação automática rigorosa:

• Acumulam-se quebras ocultas de tipos (Type Mismatches) no projeto.
• Importam-se módulos que foram removidos há três meses.
• Violam-se os acordos de limpeza de código (Dead Code, variáveis não utilizadas, regras de formatação conflitantes).

As Deterministic Linter Gates transformam o linter e o compilador em censores implacáveis. O agente não tem permissão para deixar seu código no repositório até que exit_code == 0 seja confirmado pelo sistema de verificação.

2. Taxonomia arquitetural e modelo mental

┌─────────────────────────────────────────────────────────────┐
│                 DETERMINISTIC GATE PIPELINE                 │
├─────────────────────────────────────────────────────────────┤
│ AGENT PROPOSES PATCH                                        │
│   • Writes code directly or via unified diff                │
├─────────────────────────────────────────────────────────────┤
│                          │                                  │
│                          ▼ TRIGGER HARNESS                  │
│   1. Format & Lint: `biome check --write`                   │
│   2. Strict Types: `tsc --noEmit --strict`                  │
│   3. Security Audit: `pnpm audit --audit-level=high`        │
├─────────────────────────────────────────────────────────────┤
│                          │                                  │
│                 ┌────────┴────────┐                         │
│                 ▼                 ▼                         │
│           [ EXIT CODE 0 ]   [ EXIT CODE != 0 ]              │
│                 │                 │                         │
│                 ▼                 ▼                         │
│          COMMIT & PROCEED   AUTOMATIC GIT ROLLBACK          │
│                             & FEED ERROR BACK TO AGENT      │
└─────────────────────────────────────────────────────────────┘

3. Cenários práticos de engenharia em produção

01. Proibição de any e supressão de erros

Na configuração do Biome / ESLint, ativa-se uma regra estrita:

{
  "rules": {
    "suspicious": { "noExplicitAny": "error" },
    "correctness": { "noUnusedVariables": "error" }
  }
}

Se o agente tentar usar any para contornar rapidamente um erro de tipagem, o gate rejeita imediatamente a alteração com uma exigência clara: "Especifique uma discriminated union exata em vez de any".

02. Proteção contra caminhos de importação quebrados

O gate executa uma verificação de resolução de módulos. Se o modelo alucinar e chamar import { helper } from '@/lib/helpers', que não existe no sistema de arquivos, o compilador captura isso em 40 milissegundos, impedindo que o código chegue ao commit.

4. Armadilhas, erros comuns e segurança

• Loop de feedback lento (Slow Feedback Loop): Se a verificação levar 45 segundos, o agente trabalhará extremamente devagar. Execute a verificação apenas nos arquivos alterados (tsc --build ou staged-files check) em vez de recompilar todo o monorepo.
• Ciclo de auto-sabotagem: Se o linter exigir um formato específico, enquanto o prompt do sistema do agente instruir a escrever de outra maneira, o agente e o linter entrarão em conflito eterno. As configurações de formatação devem ser extraídas exclusivamente dos arquivos de configuração do projeto (biome.json, .prettierrc).

5. Conclusão estratégica para o engenheiro de 2026

Gates de compilação rígidos libertam o humano do papel de "compilador vivo". Quando ferramentas automáticas com tolerância zero a erros garantem a integridade do código, o vibe coding deixa de ser uma aposta arriscada e torna-se um processo de engenharia disciplinado.