The Engineer, Not the Programmer

Part II opener draft (working label). The thesis made concrete, and the canonical home of the book’s named distinction supervise, don’t review — previewed in the Version Control chapter, introduced in full here because it’s the operational form of this chapter’s argument. Working title.

The division of labor, stated plainly

Here is the whole book compressed to a sentence: Claude is the programmer; you are the engineer.

Those two words get used interchangeably, and the blurring is exactly what trips people up in the AI era. So let’s separate them and keep them separate for the rest of the book.

Programming is the production of code — turning a decision into working syntax, wiring the pieces, making it run. It is skilled labor, and it is the part Claude is genuinely, astonishingly good at. It is also the part that used to be the bottleneck: for fifty years, the scarce resource in software was people who could produce correct code fast.

Engineering is the judgment around the code — deciding what to build and what not to, defining what “correct” means for this problem, choosing the constraints, weighing the trade-offs, and knowing when the thing in front of you is wrong even though it runs. Engineering is what’s left when the typing stops being scarce.

For most of computing history these two lived in one person because they had to; the same human who exercised the judgment also did the production. AI splits them cleanly for the first time. The typing is no longer scarce — Claude supplies an unlimited amount of it, instantly. What stays scarce is the judgment about whether the typing was the right typing. That is not a smaller job than it used to be. It is the whole job now, concentrated.

This is why the book’s contrarian claim holds. “Anyone can code now” is true and beside the point: the coding was never the hard part for the problems that matter. The hard part was knowing what to build, recognizing when it’s subtly wrong, and steering it back. That part didn’t get automated — it got isolated, and made more visible, and more valuable, because it’s now the only part a human is uniquely supplying.

Why the non-developer is closer than they think

If engineering is judgment rather than production, then the person who already thinks in terms of what to build and whether it’s right — a product manager, a project manager, a domain expert who knows what “correct” means in their field — is standing much closer to the engineer’s chair than they assume.

The archetypal reader of this book can already do the core engineering acts. They can specify: this is what the feature needs to do. They can prioritize: this matters, that doesn’t, ship this first. They can judge an outcome against an intent: I asked for X and this isn’t X. Those are the load-bearing skills. What they lack is not judgment — it’s the vocabulary to express the judgment to Claude, and the pattern-recognition to catch Claude’s specific failures. This book supplies both. It does not need to make you a programmer, because that seat is filled.

The trap is believing the reverse — that to supervise Claude you must first become a junior version of Claude, reading its code and checking its syntax. That belief is not just discouraging; it’s wrong about where the work is. You supervise a chef by tasting the dish and knowing what it should taste like, not by watching every knife stroke. The engineer’s leverage comes precisely from not being down in the production.

Supervise, don’t review

This is the operational form of the whole division, and it deserves its own name because you’ll use it constantly. We met it in passing in the Version Control chapter (Chapter TK, Version Control); here is the full shape of it.

Two very different jobs hide under the innocent phrase “checking Claude’s work,” and conflating them is the single most common way a capable person makes themselves miserable with AI.

• Reviewing is reading the implementation. Line by line: is this code correct, is this the right function, is line 47 sound? It operates at the implementation altitude.
• Supervising is judging by specification and outcome. Did it do what I asked? Does it behave correctly? Did it touch only what it should have? It operates at the specification altitude — the altitude you already occupy as a PM or domain expert.

Your job is supervision. Review you delegate to gates.

That second sentence is the release valve. The newcomer assumes that responsible use of AI means reading every diff — and then, drowning, either burns out trying or quietly abdicates and trusts blindly. Both failures come from accepting review as the human’s job. It isn’t. Review — the line-by-line verification of the implementation — is exactly the kind of mechanical, repeatable checking that machines do better and tirelessly: tests that must fail, type checkers, linters, continuous integration, an automated code-review pass, a style auditor tuned to your conventions. You build those (or have Claude build them), and from then on they read the diffs so you don’t. When an experienced developer sets up an automated review pass, understand what happened: they didn’t stop reviewing — they promoted review from a human chore to a gate. (This is the constructive face of the determinism argument in Chapter 6, Correct by Design: wherever “check the change” can be expressed as code, convert it, and there’s nothing left for your eyes to validate.)

The classical anchor makes the split precise. Software testing has always distinguished black-box from white-box: black-box judges a component by its behavior at the interface, knowing nothing of the internals; white-box inspects the internals directly. Supervision is black-box. Review is white-box. The gates do the white-box work for you — and you, at the interface, judge the behavior. That’s not a compromise or a shortcut; it’s the correct division of a verification problem, and it long predates AI.

Supervise, don’t review. Judge Claude’s work by specification and outcome — did it do what I asked, and did it touch only what it should. Delegate the line-by-line reading of the implementation to gates. Reading diffs by hand is where you start, as an apprentice builds instinct; it is not where a practiced operator lives.

What stays yours, and what you hand off

The division draws a clean line. On your side, the irreducibly human engineering judgment:

• What to build — and, more often, what not to build. (Claude’s additive bias, the subject of Chapter 9, Additive Bias and Calling the Question, means the “don’t build that” judgment is one you’ll exercise constantly.)
• What “correct” means — the specification, the acceptance criteria, the definition of done. Claude can propose these; only you can ratify them against the real-world need.
• The constraints — the conventions, the boundaries, the “we do it this way here.” These become the gates.
• Taste and architecture — the shape of the thing, whether an abstraction earns its place, when simpler is better.
• Calling the question — recognizing when the work has drifted and stopping it, the meta-recovery move the pathologies chapter is built around.

On Claude’s side: the production of the code, at volume and speed you can’t match. And on the machines’ side — the gates you set up — the review of that code against the constraints you defined.

Notice that even the thing you’d most expect to keep — “checking the code” — splits across the line. Defining what correct means stays yours forever. Verifying each line against that definition goes to the gates. Hold onto the first; give away the second. People who invert this — who cling to line-review and outsource the definition of correct to Claude’s judgment — have the division exactly backwards, and it’s the most expensive mistake in the book.

The two ways to get it wrong

Because the stance is a middle path, it has a failure mode on each side, and naming them helps you feel when you’re drifting:

Over-review is the newcomer’s error: treating yourself as Claude’s proofreader, reading every diff, trying to verify the implementation by hand. It doesn’t scale, it isn’t where your value is, and it burns you out until you give up — usually landing you in the second error.

Under-supervise is the reaction to the first: since reading everything is impossible, read nothing, accept whatever runs, and hope. This is trust without instruments — the mode that lets Claude’s quiet pathologies accumulate into debt you discover much later.

The stance that avoids both is supervise, don’t review: you don’t read the implementation (that’s the gates’ job), but you do rigorously judge the behavior and the footprint against your specification (that’s yours, and no machine can do it for you, because only you hold the intent). You are neither the proofreader nor the absentee — you are the engineer, operating at the altitude where judgment lives.

Where this goes next

Everything after this chapter is a way of living out this division:

• Correct by Design (Chapter 6, Correct by Design) is how you convert review into gates — the machinery that does the white-box work.
• The Control Stack (Chapter 7, The Control Stack) is how you encode your constraints so Claude and the gates enforce them.
• Additive Bias and Calling the Question (Chapter 9, Additive Bias and Calling the Question) is the catalog of what your supervision is watching for, and the recovery moves when it spots drift.
• Version Control (Chapter TK, Version Control) and Running Claude in Parallel (Chapter TK, Running Claude in Parallel) are the cockpit the supervision happens from.
• The principles (Chapter 5, Principles That Outlast the Tool) are the durable judgments you supply — the scarce input, in a world where the labor is free.

You don’t have to become a programmer. You have to become — or more likely, recognize that you already are — the engineer.

Draft notes (not for the reader)

• This is the canonical home of supervise, don’t review. It was previewed in the Version Control chapter (Part I, read first) with a self-contained definition and a forward-ref here; this chapter gives the full treatment with a light back-ref. If the reading order ever puts this chapter before Version Control, flip the preview/canonical relationship accordingly.
• The principle also has a catalog entry (engineering-principles-catalog.md, #5) for lookup/standalone posting, mirroring how pathologies get both a narrative and a catalog home. Keep the three in sync if the framing shifts: this chapter (narrative), the catalog (reference), the Version Control callout (preview).
• Glossary: when a true alphabetical Appendix A is assembled, add a one-line pointer entry for supervise, don’t review → this chapter. (It does not belong in term-families.md, which is vocabulary-families only.)
• Part placement: drafted as the Part II opener, ahead of the principles chapter, since it states the thesis the principles then instantiate. The TOC’s open question (thesis-chapter vs principles-chapter leads Part II) resolves toward this one leading.
• Tone guard: the chapter must not condescend to the non-dev or over-flatter (“you’re already an engineer!” is a claim to earn, not assert). The PM-on-ramp argument does the work; keep it grounded in the specific acts (specify, prioritize, judge outcome) rather than cheerleading.
• Cross-refs use xref tokens for the renumber pass.

Found something wrong, unclear, or plainly disagreeable? Open an issue