AI writes the code. Who steers the system?
A tweet about how we learn sent me down a rabbit hole, and it landed on something I keep seeing in my own work: when the machine writes the code, the value moves to whoever can define, guide and judge the system.
For most of software's history the job rewarded one skill above all: turn a specification into correct code, by hand, fast. We memorized syntax, internalized edge cases, and took quiet pride in being reliable human compilers. That skill is being commoditized in front of us. Coding agents now produce the boilerplate, the tests, the refactors — the manual execution — faster and more consistently than I can by hand.
Which raises an uncomfortable question. When the execution is automated, what exactly are you for?
This started, of all places, with a piece by Dan Koe about how we learn. I pulled the thread — his essay, then the older ideas underneath it — and it named something I'd felt for a while. The engineers pulling ahead right now aren't the ones who memorized the most. They're the ones who can frame a problem well, hold the whole system in their head, and steer.
The compiler mindset is now a liability
We were trained to treat knowledge as something to hoard. School rewarded it: study for hours, recall on demand, fill in the blank. In engineering it shows up as trying to keep every API, flag and library in your head so you feel competent in the room.
That instinct is now working against you, for a reason Fred Brooks named forty years ago. In No Silver Bullet (1986) he split the difficulty of building software in two: the accidental — fighting your tools, syntax, ceremony — and the essential — working out what to build, the design, the constraints, the trade-offs. His argument was that we'd already wrung most of the accidental complexity out, so the real work was, and would stay, essential.
AI has now driven the accidental complexity close to zero. Andrej Karpathy put the endpoint bluntly: "the hottest new programming language is English." The limiting factor stopped being whether you can express an idea in a particular syntax; it became whether you can express the idea clearly at all.
So memorizing syntax to feel sharp is polishing the part that just got cheap. Understanding — how the pieces relate, where a design will bend, what a trade-off actually costs — is the part that got more valuable. If you freeze up in an architecture discussion, it's usually not a gap in intelligence. It's that years of training taught your brain to compile instructions instead of building models.
Learning is a feedback loop, not a download
Here's the idea from Koe's essay that reframed it for me. Cybernetics — Norbert Wiener's 1948 science of control and communication — takes its name from the Greek kybernētēs: the helmsman. A helmsman doesn't memorize the ocean. He fixes a destination, reads the current state, measures the gap, and corrects — over and over.
Learning works the same way, and the order matters: output first, input second. A concrete goal produces an error signal — the gap between where you are and where you want to be — and that error signal is the only thing that tells your brain what's worth keeping. Read a system design with a real problem in hand and you retain the pattern that closes your gap; read it "to learn it" and it evaporates by morning.
This isn't only a nice metaphor. It's the generation effect in cognitive science: information you produce to solve a problem is retained far better than the same information re-read (Slamecka & Graf, 1978), and its close cousin, the testing effect, shows that retrieving a fact strengthens the memory more than re-studying it. Flashcards feel like studying; building something that forces you to recall is studying. It's also why an hour of doomscrolling leaves you drained — endless input, no error signal, nothing that needed keeping.
The practical residue is small: keep a buffer for the why, not the how. Not code snippets a model can hand back to you in context — the mental models, the trade-offs, the shape of a decision ([System X] → latency vs. consistency). Store what a search can't return.
Where the human leverage actually is
Steve Jobs liked to close launches on an image of two street signs meeting: "technology alone is not enough — it's technology married with liberal arts, married with humanities, that yields the results that make our hearts sing" (iPad, 2011). In the agentic era that stops being a nice sentiment and turns into a job description. When implementation costs fall toward zero, leverage moves to taste, framing and point of view — the things that decide what to build and whether it's any good.
Concretely, my loop now has three moves, and only the middle one belongs to the machine:
- Frame it. Before opening an editor, define the problem, the constraints, the attack surface, the real trade-off between speed, security and scale. A vague frame just produces vague code, faster.
- Delegate the execution. Hand the framed spec to the agent and let it do the mud — boilerplate, tests, the syntax.
- Judge and steer. Be the comparator. Inspect the output, find the structural flaw, run the edge case that breaks it, correct the direction, repeat. It's the same discipline as turning a prompt into a loop.
That last move is the whole game, and it's exactly where AI stops being enough. Addy Osmani, who runs Chrome's developer experience at Google, calls it the 70% problem: agents get you 70% of the way fast, but the last 30% — edge cases, security, integration, the parts that decide whether it survives contact with production — still belongs to an engineer who understands how the system actually works. His warning is worth sitting with: developers who lean on AI without that understanding ship "house of cards" code, and review is quietly becoming the new bottleneck. The tools amplify judgment. They don't supply it.
The takeaway
Stop grading yourself on how much you can recall. Memory was never the moat, and now it's the cheapest thing in the stack. The moat is being able to frame a problem, hold the whole system at once, and tell — with judgment — the difference between output that's correct and output that's merely plausible.
AI can write the code. Someone still has to steer the system. Increasingly, that's the job.