🧭 Agent-agnostic setup

In module 1.2, we concluded: it’s not worth wait idly the AI improve. But in module 1.1 we saw that model all the time. How do you act now without becoming dependent on a model that will be outdated in three months? Matt Pocock’s answer is to keep your setup agent-agnostic (agent-agnostic).

Agnostic means: your harness — your prompts, your skills, the way your codebase is organized— doesn't depend which AI is inside. In his words: "keep the harness agent-agnostic and apply good fundamentals → it keeps working with the next model." The consequence is powerful: when a better model comes out, you just swap the engine. The car (which you spent time tuning) is still valuable. It’s the opposite of rebuilding everything with every release—and that’s why Pocock says he isn’t a “pundit” (a guesser), he’s just "doing the best with what I have right now."

Optimize is good—but there’s a hidden poison in the word overoptimize. Pocock himself admits the risk, with a line worth remembering: "If I over-optimize around a model... I lose focus on the fundamentals" (if I optimize too much around one model, I lose sight of the fundamentals). When you tailor every prompt, skill, and trick to a model's specific quirks, you create a lock-in: switching becomes so painful that you simply stop switching, even when you should.

The cost shows up in three ways. (1) Rework: a new model comes out, and your “magic” prompts that relied on a quirk of the previous one stop working—you redo everything. (2) Blindness: you get so caught up in a model’s tricks that you don’t notice when another, cheaper one could already do the same thing. (3) Fragility: your setup becomes a house of cards tuned to a single engine. Pocock strikes a balance (the famous 50/50 from module 1.1): smart effort goes into the harness, but the harness can’t be paired with the engine. Optimize the car, not its dependence on the engine.

This is the most important sentence in the entire method, and Pocock repeats it: "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." In other words: people look at the shiny new toy, when what matters is focusing on what has worked for 30-40 years. These are the fundamentals — and by definition, they’re agnostic: no AI model can make them obsolete.

Which ones? Version with git (your project’s “undo button”), write tests (automated proof that the code works), organize the files well, document enough, scope tasks clearly. Notice: none of this has to do with “which AI.” These are engineering principles that applied before AI and will apply afterward. And here’s the key: when your codebase follows these fundamentals, any the model works better with it — including the cheaper ones (you’ll see this clearly in module 1.5). Fundamentals aren’t “the old way”; they’re the foundation that makes the new way work.

Pocock gives a concrete example of the anti-pattern: the vibe coder that "switch tools every week (replit → lovable → …) and never learn any principles." Every week, a new app or model comes out, and people switch: a new dashboard, new shortcuts, a new promise. The problem isn't curiosity — it's that each switch resets the learning. Anyone who never spends enough time with a tool never gets beneath its surface.

Here’s the subtle point Pocock makes a point of emphasizing: "the difference is in APPROACH, not in belief in AI." He no is saying “don’t use AI” or “AI is hype.” Both he and the vibe coder believe in AI—the difference is the way. The vibe coder optimizes for novelty (the tool of the moment); the Pocock method optimizes for fundamentals (the skill that lasts). It’s exactly the trap from module 1.2 seen from another angle: instead of waiting around for the model to improve, the vibe coder chases every new model—and both extremes lead to the same result: never building anything that lasts.

“Hardening” doesn’t mean stopping your growth—it’s the opposite. Pocock and David Ondrej agree on one practical point: actively improve the setup every day (Ondrej mentions things like VPS, Tailscale, etc.) And use the best model. Both things together. The secret is to where you invest that effort in the parts that last (well-written Skills, an organized codebase, fundamentals) — not in tricks tied to an engine that’s going away. You pull every lever in module 1.1, but focus on the ones that are model-agnostic.

There’s even a prudence warning built into the method: Pocock waits about one month before adopting a new model in the production workflow (that’s what he did with Opus 4.5). It’s not fear of novelty — it’s giving yourself time to find out whether the new engine really fits without surprises. A hardened setup means you adopt the best, but at your own pace, without every release becoming an emergency.

Wrapping up: whenever you’re going to adopt a new tool, prompt, or trick, do a filtering question — "will this still hold if I switch models tomorrow?" If the answer is no, you're building dependency, not an asset. The checklist below is the module's practical summary. Copy it, paste it at the top of your project, and run it before every setup decision:

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.