Strategic vs Tactical Programming
Your thesis that "AI is eating tactical programming" has a name, an author, and a toolkit. This lesson gives you all three.
The distinction
In A Philosophy of Software Design (2018), Stanford professor John Ousterhout splits all programming into two mindsets:
Tactical programming optimizes for one thing: make the current task work, as fast as possible. Each shortcut is individually reasonable. Nothing about it looks wrong in the moment.
Strategic programming starts from a different premise:
Working code isn't enough. … The most important thing is the long-term structure of the system. — John Ousterhout, A Philosophy of Software Design, ch. 3
Here is the part that matters for you: your AI is the most prolific tactical programmer ever built. Its objective in every session is "make this prompt's outcome pass your test." That is the literal definition of tactical work. It will never, on its own, pay a cost today for your benefit in six months — unless you, the strategic layer, demand it. That's the job you're training for.
Why tactical work fails slowly, then suddenly
Ousterhout's key claim: complexity is not caused by one big mistake. It is incremental — an accumulation of small, individually-defensible shortcuts. Which means you can't catch it by spotting a disaster. You catch it by recognizing its three symptoms:
The tell: you ask the AI for a small tweak and it touches eight files, or the same value/logic lives in several places.
The tell: the AI's explanation of "how this works" keeps getting longer; you can't predict what a change will affect.
The tell: "the fix worked, but something unrelated broke." If this happens twice in one area, that area is complexity-sick.
These three symptoms are your first piece of senior equipment. You cannot read the code — but all three symptoms are observable from outside the code, through exactly the loop you already run: discuss, prompt, test outcome. You've been collecting the evidence all along; now you have names for it.
The investment mindset
Ousterhout's prescription is not "design everything up front." It's an investment rate: spend roughly 10–20% of total effort on design — before and after the code works. His estimate is that this pays for itself within months, because tactical speed is borrowed, not free: the codebase slows down as complexity compounds, and eventually every feature costs more than it should.
For an AI-directed workflow, "investment" translates concretely: time spent on the plan before prompting, and time spent asking the AI to simplify after the test passes — the two moments where you, not the AI, add the value. Lesson 0002 will build the first of these into a habit.
Check yourself
Classify each scenario. Immediate feedback, no grades, retry freely — the effort of retrieving is what makes it stick.
Practice on your real work
In your next AI coding session, before accepting any proposed approach, ask the AI one question: "What does this approach make harder to change later?" Then judge its answer against the three symptoms.
Bring one example back to your teacher (the agent): the feature, the AI's proposal, its answer, and your verdict. That conversation becomes your next learning record.
Primary source
Watch Ousterhout's talk at Google, "A Philosophy of Software Design" (~1 hour, free). It covers this lesson's ideas from the author himself. If it lands, the book is short and worth owning.