You can't review what you can't build

When “coder” swallowed “engineer”

Somewhere along the way the industry started using two words as if they meant the same thing. Coding and engineering. Learn to code, get an engineering job. The bootcamp taught syntax and called its graduates engineers. The interview tested whether you could invert a binary tree on a whiteboard, not whether you could decide where one service should end and the next begin.

Fred Brooks warned against exactly this collapse in 1986. He split the difficulty of software into two kinds. Essence: deciding what the system is, how the parts fit, whether the design holds. Accident: the labor of writing that down in some language. He was blunt about which one is the actual work:

“I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.” Fred Brooks, No Silver Bullet, 1986

For a while the two halves stayed distinct, and the distinction had a name. As one much-quoted line puts it: all software engineers can program, but not all programmers can engineer software. Architecture, separation of concerns, the contracts that don't shatter when another team ships, the algorithm that survives ten times the load, the tooling that catches the bug before the customer—that was engineering. Typing the result out was coding. Swizec Teller, describing a five-month project, gave away which was which:

“The 2 hours I've spent coding on this 5 month project were downright relaxing.” Swizec Teller, Coding is the easy part

But en masse, quietly, the hard half got demoted to a nice-to-have. Ship first, architect never. A generation learned to produce working code without ever being asked to defend a design, and came to believe—reasonably, given what was rewarded—that producing working code was the profession. Then a machine arrived that could produce working code on command, and the confusion stopped being academic.

Same tool, opposite results

Hand the same coding assistant to two people and you get two different objects back. Not because the model changed—because they did.

The architect who still thinks in boundaries asks for a thin interface, reads the diff, rejects the version that smuggled database logic into the view, names the seams, and walks away with cleaner separation than they'd have bothered to hand-type on a Friday afternoon. The AI made their judgment cheaper to apply, so more of it made it into the code.

The coder who was never taught to think past the function that runs takes the first plausible block, wires it in, and ships. There was no boundary in their head to ask for, so none appears—and now there's three times as much unstructured code as before, delivered in an hour. Same prompt box. One person got a force multiplier; the other got a faster way to dig the hole. This is what the largest study of AI in software teams found and named outright:

“AI's primary role is as an amplifier, magnifying an organization's existing strengths and weaknesses. The greatest returns on AI investment come not from the tools themselves, but from a strategic focus on the underlying organizational system.” DORA, State of AI-assisted Software Development 2025

A survey of 669 developers on one enterprise assistant caught the split cleanly: 57% felt the tool made them more effective, 43% felt it made them less. Identical tool, opposite verdicts. The variable was never the model. As one engineer put the whole thing:

“Writing code has never been the hard part. Thinking clearly about systems is. AI does not reduce complexity—it accelerates the consequences of ignoring it.” Why AI Makes Bad Engineers Worse and Good Engineers Unstoppable

The judgment you can't fake at review time

Here is the mechanism underneath the split, and it's the whole point of this piece. An AI hands you a block of code that runs. Now someone has to answer the questions that were always the real job: are these the right boundaries? Does this abstraction earn its keep, or is it clever for its own sake? Will this contract hold when the other team changes their side? Is this the algorithm that survives production, or the one that looked fine on the happy path?

Answering those is an act of architectural judgment—the exact skill the profession spent a decade treating as optional. And you cannot fake it at review time. You cannot approve a design you couldn't have arrived at yourself; you'll just approve that it compiles. So the engineer who never built the judgment can't evaluate the output, and does the only thing left: accepts it. The tool didn't fail them. It faithfully executed a request that no one in the loop was equipped to check.

Worse, leaning on the tool erodes the very judgment you'd need to supervise it. In one study, developers who used AI assistance to work through an unfamiliar library scored 17% lower on a comprehension test afterward than those who worked it out themselves—faster to a result, thinner in understanding. The capacity to review keeps quietly draining out exactly as the volume of code to review goes up. A Hacker News thread put the endpoint starkly: AI-generated code arrives already looking like legacy code, because the model holds no lasting theory of your system. Which is only fatal if the human holds no theory either—and increasingly, the human doesn't.

Notice what this argument is not. It isn't that AI is incapable of good structure. It has read more well-factored open-source libraries than any person ever will, and it will produce a clean interface the moment someone who recognizes one insists on it. The capability is sitting right there. What's missing isn't in the model. It's the person who knows what to ask for and can tell whether they got it.