🧭 Setup agent-agnostic

No módulo 1.2 a gente concluiu: não vale a pena esperar parado a IA melhorar. Mas no módulo 1.1 a gente viu que o modelo muda o tempo todo. Como agir agora sem ficar refém de um modelo que vai virar peça velha em três meses? A resposta do Matt Pocock é manter o seu setup agent-agnostic (agnóstico ao agente).

Agnóstico significa: o seu harness — seus prompts, suas skills, a forma como o seu codebase está organizado — não depende de qual IA está dentro. Nas palavras dele: "mantenha o harness agent-agnostic e aplique bons fundamentos → continua funcionando no próximo modelo." A consequência é poderosa: quando sair o modelo melhor, você só troca o motor. O carro (que você passou tempo afinando) continua valendo. É o oposto de reconstruir tudo a cada lançamento — e por isso Pocock diz que ele não é um "pundit" (palpiteiro), só está "fazendo o melhor com o que tenho agora."

Otimizar é bom — mas tem um veneno escondido na palavra overotimizar. O próprio Pocock confessa o risco, com uma frase que vale gravar: "If I over-optimize around a model... I lose focus on the fundamentals" (se eu otimizo demais em torno de um modelo, perco o foco nos fundamentos). Quando você molda cada prompt, cada skill e cada truque pro jeitão específico de um modelo, você cria um lock-in: trocar passa a doer tanto que você simplesmente não troca, mesmo quando deveria.

O custo aparece de três formas. (1) Retrabalho: sai modelo novo, e seus prompts "mágicos" que dependiam de uma manha do anterior param de funcionar — você refaz tudo. (2) Cegueira: você fica tão envolvido em truques de um modelo que não percebe quando outro, mais barato, já faria o mesmo. (3) Fragilidade: seu setup vira um castelo de cartas afinado num único motor. Pocock equilibra (o famoso 50/50 do módulo 1.1): o esforço inteligente vai pro harness, mas o harness não pode ser casado com o motor. Otimize o carro, não a dependência do motor.

Essa é a frase mais importante do método inteiro, e Pocock a repete: "People are focused on the wrong thing — the big shiny new thing — when in fact just focus on the stuff that's been working for 30-40 years." Traduzindo: o povo olha pro brinquedo novo e brilhante, quando o que vale é focar no que funciona há 30-40 anos. Esses são os fundamentos — e eles são, por definição, agnósticos: não há modelo de IA que os invalide.

Quais são? Versionar com git (o "botão de desfazer" do seu projeto), escrever testes (provas automáticas de que o código funciona), organizar bem os arquivos, documentar o suficiente, escopar tarefas com clareza. Repare: nada disso tem a ver com "qual IA". São princípios de engenharia que valiam antes da IA e valem depois. E aqui mora o pulo do gato: quando seu codebase respeita esses fundamentos, qualquer modelo trabalha melhor nele — inclusive os mais baratos (você vai ver isso direitinho no módulo 1.5). Fundamentos não são "o jeito antigo"; são a base que faz o jeito novo funcionar.

Pocock dá um exemplo concreto do anti-padrão: o vibe coder que "troca de ferramenta toda semana (replit → lovable → …) e nunca aprende princípio nenhum." Toda semana sai um app ou modelo novo, e a pessoa migra: novo dashboard, novos atalhos, nova promessa. O problema não é a curiosidade — é que cada troca zera o aprendizado. Quem nunca fica tempo suficiente numa ferramenta nunca desce abaixo da superfície dela.

Aqui vem a sutileza que Pocock faz questão de marcar: "a diferença é de ABORDAGEM, não de crença em IA." Ele não está dizendo "não use IA" nem "IA é hype". Tanto ele quanto o vibe coder acreditam em IA — a diferença é o jeito. O vibe coder otimiza pela novidade (a ferramenta do momento); o método Pocock otimiza pelo fundamento (a habilidade que fica). É exatamente a armadilha do módulo 1.2 vista de outro ângulo: em vez de esperar parado o modelo melhorar, o vibe coder corre atrás de cada modelo novo — e os dois extremos têm o mesmo resultado: nunca construir nada que dure.

"Blindar" não é parar de evoluir — é o contrário. Pocock e David Ondrej concordam num ponto prático: melhore o setup ativamente, todo dia (Ondrej cita coisas como VPS, Tailscale, etc.) E use o melhor modelo. As duas coisas juntas. O segredo é onde você investe esse esforço: nas peças que ficam (skills bem escritas, codebase organizado, fundamentos) — não em truques colados a um motor que vai embora. Você puxa todas as alavancas do módulo 1.1, mas mira nas que são agnósticas.

Existe até um pré-aviso de prudência no método: Pocock espera cerca de um mês antes de adotar um modelo novo no fluxo de produção (foi o que ele fez com o Opus 4.5). Não é medo de novidade — é dar tempo de saber se o motor novo realmente cabe no encaixe sem surpresas. Setup blindado = você adota o melhor, mas no seu ritmo, sem que cada lançamento vire uma emergência.

Fechando: toda vez que você for adotar uma nova ferramenta, prompt ou truque, faça uma pergunta de filtro — "isto continua valendo se eu trocar o modelo amanhã?". Se a resposta for não, você está construindo dependência, não patrimônio. O checklist abaixo é o resumo prático do módulo. Copie, cole no topo do seu projeto, e rode antes de cada decisão de setup:

VISTORIA DE AGNOSTICISMO — rode antes de cada decisão de setup
Pergunta de filtro: "isto continua valendo se eu trocar o modelo amanhã?"

[ ] MODELO trocável? Mudar de IA é editar 1 linha de config — ou refazer tudo?
[ ] SKILLS portáteis? Funcionam em Claude Code, Codex etc. — ou só num app?
[ ] FUNDAMENTOS no lugar? git + testes + organização + docs + escopo claro.
[ ] PROMPTS sem manha? Pedidos claros em inglês/português simples,
    não truques que dependem de um modelo específico.
[ ] CODEBASE organizado? Qualquer modelo (até o barato) navega fácil.
[ ] RITMO próprio? Adota modelo novo quando comprovado (~1 mês), não no hype.

3+ "não" = seu setup está casado com um motor. Blinde antes de otimizar.