♟️ Tactical × Strategic

Before talking about AI, we need a yardstick. Matt Pocock borrows one from John Ousterhout, a Stanford professor and author of "A Philosophy of Software Design". In the book, he divides programming work into two very different modes: tactical programming e strategic programming. These aren’t “skill levels”—they’re ways of thinking about what you're doing right now.

The difference, in Pocock’s own image: the tactical is “winning the battle”—the day-to-day work of writing syntax, find bugs, do commits. O strategic is “winning the war”: it’s the general at the top thinking about what the codebase needs to be and which strategies will increase speed in the long run. The reason of this becoming a topic now: AI has radically changed who does what in each mode. A common mistake is treating the two as the same thing ("it’s all programming") — they call for different mindsets.

A tactical programming is the work you see happening: opening the editor and writing the lines, remembering where the parenthesis goes, running the program, seeing that it broke, hunting down the bug, fixing it, and saving with a commit. It’s the software “factory floor.” For decades, it was here that most programmers spent 80% of their time on — and this was where “who programs well” was measured.

It’s honest, indispensable work: without tactical work, nothing runs. But it has a dangerous trait — it’s mechanical and standardizable. Almost every tactical task has already been done millions of times by someone: creating an endpoint, validating a form, writing a loop. That’s why the reason matters: anything repeatable and well-defined is exactly the kind of thing machines learn to do. The common mistake is confusing “I’m busy typing” with “I’m creating value”—a lot of typing can hide a lack of decisions.

A strategic programming is the opposite of “typing.” It’s thinking before e around of the code: how the codebase should be structured, which interfaces connect the pieces, and which decisions today will speed up (or stall) the team a year from now. In Pocock’s words, it’s "winning the war, not the battle" — the work of the general at the top.

For Ousterhout, the strategic involves design the hard parts first, scope each task well, think through interfaces between modules, plan tests and scenarios, and design a codebase that’s easy to work with. The reason for this to be rare: you can "deliver" without doing any of this—just push tactical code that works today. The cost comes later, in the form of technical debt. O common mistake is putting off strategy “until you have time”: that time never comes, and the codebase decays.

Here's the phrase that gives the module its name. Matt Pocock is direct: "AI has basically eaten tactical programming. It's gone." — the AI basically "ate up" tactical programming, it was over. Not in the sense that the tactical approach no longer exists, but in the sense that is no longer where your value lies: the AI handles the tactical work better and cheaper that you. Remember topic 2? Tactical work is repeatable and well-defined — and that’s exactly what an model where language shines.

The practical consequence is significant: you now have access to a "infinite fleet of tactical programmers" that work 24 hours a day, never get tired, and cost pennies. But — and this is the key point — a fleet is only as good as the person commanding it. The reason for this to push you upward: if tactical work has become cheap and abundant, the bottleneck has become the strategic. O common mistake is continuing to compete on tactical work (“I’ll type faster than AI”)—a race you’ll lose against someone who never sleeps.

If the tactical work has been absorbed, the move is to level up: start operating strategically. Pocock is clear that "strategic programming hasn't changed with AI" — the fundamentals of designing a good system are the same as always. What changed was for the person you delegate the tactical work to: before, you handed the mechanical tasks to junior and mid-level developers; now you delegate for AI. The reason for this to be liberating: you spend less time typing and more time deciding—that's where the real result takes shape. The common mistake is “leveling up” only on your business card (becoming a “leader”) without ever letting go of tactical work in practice; then you become a bottleneck that reviews every line. Real growth means entrust execution and focus on design.

Wrapping up the module: the metaphor of the general at the top is the summary of everything. AI is your tactical force; you’re the strategic general. To delegate effectively to that force—the subject of all of Track 2—Pocock gives Ousterhout’s list: design the hard parts first, scope tasks very carefully, think through the interfaces between modules, think about tests and scenarios, and have enough documentation to point the AI to the right places. Before you “tell the AI to code,” run the checklist below — it’s the practical summary of this module. Copy and paste it when delegating a task:

Antes de mandar a IA codar, pense como GENERAL (estratégico):
[ ] PARTES DIFÍCEIS — qual é o pedaço arriscado? Desenhei ele na frente?
[ ] ESCOPO — a tarefa está nítida e fechada, ou está vaga demais?
[ ] INTERFACES — como este módulo conversa com os outros? Defini o contrato?
[ ] TESTES — quais cenários provam que ficou certo (inclusive os de borda)?
[ ] DOCUMENTAÇÃO — apontei a IA pros arquivos/padrões certos do projeto?
Se respondeu tudo, o tático (a IA) é só execução. Você ganhou a guerra.