← cd ..
07/09/2026

% cat The Second Apprenticeship: Surviving AI in Engineering

Watch on YouTube →

Most of what any of us “knows” is borrowed. No one can verify everything, so we trust the people who’ve earned the authority to speak — the experts — and we get on with our day. It’s a good system. It holds right up until the experts contradict each other.

Which is exactly what’s happening to software engineering. Ask what AI is doing to the profession and you get two answers, each stated with total confidence.

Boris Cherny — the brain behind Claude Code — in early 2026:

The title software engineer is going to start disappearing this year. Not shrinking. Disappearing.

Kin Lane, who’s watched this industry from the inside for thirty-five years:

I don’t think I have ever seen so much technical debt being created in such a short period of time during my 35-year career in technology.

The research splits the same way. Stanford economists went through ADP’s payroll data, the largest set in the country, and found employment for developers aged 22 to 25 down nearly 20% since generative AI arrived. A different team went the other direction. They combed over 300,000 AI-written commits across six thousand real repositories, and the machine’s code carried 1.7 times the issues per pull request that human code did — with technical debt up 30 to 40% wherever the tools took hold.

Let’s get to the bottom of it.

Everyone ships slop. I have too.

For three decades I’ve built software as the architect on a team. I’ve worked next to brilliant engineers, green ones, and every shade in between.

The through-line: people produce slop. Everyone does. Some a little, some mountains — me included.

Man-made slop is just the fingerprint of a human mind working a problem. You get the task. You picture how it might look in code, and you start writing. Halfway in, you realize the design won’t hold. A better one surfaces — but you’ve already written a pile of code, you’re attached to it, and the deadline is looming, so you don’t start from a clean sheet. You bend the existing code to serve a new purpose — and it rarely fits perfectly. Do that several times and you’ve got functions, classes, and interfaces that serve no purpose, abstractions that generalize nothing, scaffolding left standing around a building whose blueprint changed mid-construction. Call it laziness if you want — justified by deadlines and emotional attachment. It’s what changing your mind looks like, frozen into code.

The slop machine

Hand the coding to a model and you get slop right back. Partly because the model’s training data was dominated by crappy code. Partly because its reasoning is never aligned with human goals. Whatever the cause — you get slop. The same purposeless abstractions, the same code that looks deliberate but isn’t, the same quiet wrong guess buried three functions deep.

Then there’s the multiplier. An engineer produces slop at human speed. The model does it ten times faster, sometimes a hundred. Same fraction of junk — while vastly more of it per hour.

Slop isn’t dead weight you can delete. Most of it runs — the program wouldn’t compile without it. That’s what makes it dangerous: it executes cleanly while encoding intent that was never real. Eventually, the code becomes the source of truth, and the next person to touch it — human or model — assumes every line is there for a reason. They can’t tell the deliberate from the accidental, so they reverse-engineer a purpose the code never had. Their mental model is now wrong, and everything they build on top inherits the error.

And that’s worse than a hallucination. A hallucination is a wrong guess you can catch and correct. A false premise wired into the source of truth corrupts human and machine reasoning alike: feed either one a falsehood stated as fact, and both reason flawlessly to the wrong conclusion.

The cancer

Worst of all, slop compounds. One superfluous abstraction breeds three, those breed nine — faster than review can keep up. It spreads and kills like cancer: by the time the damage is obvious, it’s woven through everything and can’t be cut out. It’s exactly why AI-managed repositories degrade so fast — the model builds on its own slop, unable to tell it from deliberate code, at machine speed.

And the startup mantra — “ship the mess now, pay the debt down after the round closes” — is a fairy tale. Paying it down is a luxury no team can afford. The day the product lands its first design partners, the race is on — new features, more customers — and cleanup never makes the cut. So the team keeps a debt-ridden product alive on a ventilator. This was true when humans wrote the code; using AI speeds up the rot just like it does the work. The mess you ship is the mess you keep.

Counting on review to catch AI slop? Know its ceiling. A sharp architect can thoroughly review maybe five or six people’s manual work — the algorithms and the data structures, not skim the diff. Past that, things slip. Now run far more AI output through that same reviewer nonstop, and watch them slide into skimming within days. The bottleneck just relocated to your most experienced person, and they can’t read that fast.

And no, an AI code reviewer won’t save you either — that’s sending a madman to catch a madman. The reviewer runs on the same misaligned reasoning as the writer, just as blind to slop dressed as intent. As a first pass, AI review earns its place — style slips, textbook security holes, the routine bugs a tired human misses. As the whole defense, it fails.

None of this is just my read. Over a long career I’ve gathered a wide circle of friends in senior engineering, product, and technical-leadership roles, and I’ve heard the same story from them, over and over.

If you run engineering, you’ve felt the far side of all this from the manager’s chair: your sharpest architect’s week swallowed by review, quality that swings with whoever picked up the ticket, a team that ships faster and rots the codebase faster. No hiring plan or tighter review policy touches it.

The line the machine can’t cross

Look past the style nits and null checks to what review is really chasing. The issues that matter are all places where the code drifted from what was originally meant. That original intent — data structures, dependencies, interfaces, the functional decomposition — is just another word for architecture. That’s what the machine can’t get right. It’s what most engineers can’t get right either. This is an old divide: the few who can match a product with the right architecture from the get-go — one that survives real traffic, business pivots, and whatever else reality throws at it — and everyone else, the machine now among them.

Architecture isn’t a rulebook. I learned that the hard way. For years, I handed my teams the canon — Clean Code, the Gang of Four, the whole shelf, eventually a book of my own, Become an Awesome Software Architect — and drilled them on it. They got the patterns. What they never got was when to reach for a pattern and when to leave it alone. That’s the judgment. Not their fault — mine. I thought architecture could be taught. Now I think it’s earned. You need the books; you can’t reason about what you can’t name. But books alone aren’t enough. Theory turns into judgment only when practice wires it into the brain, over decades and a whirlwind of wildly different projects.

That’s what the tired 10,000-hour cliché was fumbling toward. The number came from Gladwell, riffing on Anders Ericsson’s study of violinists — but Ericsson’s real finding was never about hours. It was deliberate practice: focused, uncomfortable drills aimed straight at your weak spots. Hours alone build nothing; the right experience — hard, varied, repeated — is what builds the judgment. Breadth beats tenure. Building ten different systems teaches what ten years on the same one never will: each new problem forces a call the last one didn’t.

So what is all that judgment actually about? Strip architecture to the studs and it’s a series of decisions with one aim: holding down the cost of the system across its whole life — building it, running it, and above all changing it. That cost includes what goes wrong, too: the blast radius when something fails or the scope blows up. That’s the goal, not the method. The canon is just the box of building blocks; the judgment is knowing which ones this problem needs and how to put them together. And that depends on the business, the product, the team’s depth, the timeline, how much risk you can carry. Thinking like an architect is holding all of it at once and making the right trade-offs — which is why the work runs so far past technology, into economics, product, and the people you’re building with and for.

The survival skill

None of that judgment is displaced by AI. The business remains the same, and so does the goal. What changed is how the code gets made, and that changes plenty. The new coders are AI agents: they work at a junior-to-mid level, run ten to a hundred times faster than any person, and fail in ways no human would. They follow rules better than anyone you’ve ever hired, and they bury the reviewers under more code than anyone can read. Reviewing it thoroughly can be more work than writing it in the first place. And through agentic tooling they unlock product capabilities that didn’t exist before: whole workflows the system can run on its own. They come with failure modes no one has seen, built on patterns no book describes and no veteran has practiced.

A few examples. When people wrote the code, you optimized for fewer lines and fewer hands; now you optimize for a uniform, readable surface — every file built the same way, defaults and options spelled out — so a reviewer takes it in at a glance. You make the code carry its own intent, in comments where the language can’t, because the next reader is a model with no memory of why. And since a full rewrite now costs a fraction of what it did, the spec becomes the artifact you defend above the code itself. Even object-oriented design comes into question. Its abstractions were built to save writing and suit human reasoning, sometimes at the cost of review. Now that reviewability and reducing blast radius from changes outrank fewer lines, many core OOP techniques become liabilities.

All of that — and much more — lands back on the architect. AI forces over a dozen big shifts, each cutting against the grain of a career. A habit that once defined good work is now to be relearned. That’s a second apprenticeship — and the field is only a year or two old, its ground still shifting, and almost no one is even close to finishing.

What AI can’t do is make the judgment call. The means you can write down as rules; the judgment you can’t — it’s tacit. Knowledge like that isn’t transferred, it’s trained: grown in a mind over years of practice, which is exactly why I couldn’t hand it to my teams. Could you just train the model on it, the way you’d train a person? There’s nothing to train on. There are oceans of code but almost none of the reasoning behind the decisions. Rationale is rarely documented; it lives in the architect’s head.

For quality agentic software engineering, steering AI takes a rare pairing in one person: an architect who earned the judgment the slow way, and who has re-tooled for a world where coding is cheap, review is king, and half the old means must be questioned. Almost nobody has it yet. And that gap is about to get a lot of people fired.

Nowhere left to hide

For decades, the industry hid mediocre engineers inside big teams. They put in the years, collected the title, and shipped confident slop the whole way — years of the wrong experience, mistaken for seniority. Technologically, it was survivable because slop used to be expensive to produce; there was a cap on the damage one person could do. Headcount accounting covered the financial side. AI just removed the cap. It generates that same slop — the load-bearing bloat, the intent that was never real — faster and cheaper than humans ever could.

And you can’t review your way out of it. I was never a fan of PR reviews. The very existence of the process is an admission that a person’s work isn’t expected to stand on its own. To me, reviewing work of a seasoned pro in detail, beyond upskilling a new hire, or security and compliance checks, is a disgrace — a quiet fall of the craft. AI hollowed the ritual out further, burying a reviewer under volumes of code, and collapsing any honest review into a skim that catches almost nothing.

One thing nags at me, though, and I don’t have a clean answer for it. If AI automates the junior work, the ladder loses its bottom rungs — so where do the senior architects of ten years from now come from? The path that dragged me through the grunt work is now being automated away. And that hands the reviews their one real justification: run as teaching rather than gatekeeping, a review is how you turn a junior into the architect the machine still can’t replace. The expensive and inefficient ritual of reviewing PRs may be the last place where the training pipeline survives.

That’s tomorrow’s problem. Today’s is more pressing. If your edge was producing code that looks right to the reviewer and passes the happy-path test, that edge is now a commodity, sold by the token. Doing the work of quality — deciding correctly, catching the wrong assumption early, knowing which corner is safe to cut and which one pages you at 3 a.m. — was always a different job. It’s the one that survives. It may be the only one that does.

The judgment stays with you. What the machine brings is the opposite gift — the one thing people were always bad at. Humans can’t reliably run on rules. AI is the rule-follower we never had.

Rules as a method

So give it rules. That’s the whole approach: treat AI not as an oracle you hand the keys and pray to, but as a tireless, literal developer you steer with surgical precision. A rule isn’t judgment. The judgment stays with you. It’s something narrower: a behavior clean enough to define exactly, so a literal machine can enforce it without fail. If it can’t be pinned down cleanly, don’t bother — you’ll get unpredictable results, worse than none. Rules can hold the slop at bay, forbidding the purposeless abstractions before they’re conceived. They separate the decisions the model makes on its own from those that stay yours. Rules make the code reviewable: uniform, explicit, readable at a glance. And they keep the spec logically whole — each fact checked against the others, no gaps, no contradictions, no ambiguities.

So how do you build them? Some are fences you set up front — bright lines the machine may never cross. The rest you grow the way you’d train a sharp junior: let it work, watch where it drifts, and freeze each correction into a rule it can’t break again. Here’s what both look like in my own work.

The crudest rules are just fences. On my projects, AI does not invent an interface without my sign-off. It does not create a class on its own authority. It does not decide, quietly, between a discriminated union with a switch and a virtual function that hides the behavior — those are my calls, and I’ve told it so.

Once the crude guardrails are set, the real work starts — and it’s specification, not code. I have the model make silent coding runs: it actually writes the code, but asks nothing and commits nothing; instead it captures every ambiguity, assumption, and conflict the spec left open, and reports them back for me to resolve. Its rules then hold each of my answers up against the rest — my earlier answers, the project’s ground truths, its goals — and flag anything that doesn’t fit. Sometimes I ask for options to choose from; either one is the answer I was looking for, or it’s food for thought. When my answers clear the consistency checks, another silent run turns up the next round of questions. That’s most of my day. The coding itself happens overnight, the model running straight through, having all the answers on hand.

Do I review the generated code? Of course. But I don’t just point at a problem and have it patched. I explain the rationale behind the issue and ask the model to generalize the fix into a rule, which I check before it’s recorded. Then, instead of fixing that one spot — the vibe-coder’s reflex — I have the agent hunt down every violation of the new rule across the codebase, surface the offenders, explain each change, and apply them. Each round, the model codes better than the last, and the rules travel from project to project. Running a small “strike force” armed with the method makes me far more productive than I’ve ever been with a large traditional development team. Works solo, too.

Agentic Spec-Driven Development book cover #1 Best Sellerin Software EngineeringAmazon, Summer 2026

In a mature rule system, this compounds: you can ask for a new feature, send the model off to build it, and get it back with almost no technical questions and no engineer in the loop. The full methodology behind it — record-keeping, real-time conflict detection, dry runs, and more — is written up in the Agentic Spec-Driven Development book for anyone who wants it.

get-on-amazon #1 Best Sellerin Software EngineeringAmazon, Summer 2026

The leverage isn’t personal. When the rules hold the line instead of the reviewer, a new hire’s output clears the same bar as your principal engineer’s — the standard stops depending on who wrote the code. The senior-review bottleneck eases. The reasoning that used to live in one architect’s head now lives in the spec, in the open, where the team and AI can both use it. A few architects steering machines under a shared rulebook out-build a large, uneven team at a fraction of the cost. That’s not a productivity trick; it’s a new shape for an engineering org.

Are engineers extinct?

So — is AI the end of engineering, or a slop machine? I’ve walked the whole span of that argument myself, from Kin Lane’s end of it toward Cherny’s. Two years ago, when capable AI coding first arrived, I stood squarely on Kin Lane’s side: watching the machine throw off technical debt faster than anything I’d seen in my entire career, certain it was a debt engine and little else. Getting off that side took two years — of hard practice on my part, and of the models leaping forward on theirs, especially over the last ten months. I still didn’t land all the way over with Cherny; I don’t believe the engineer disappears. But I landed close. Here’s where I came out: the engineer doesn’t vanish, but the field narrows — to fewer architects, of much higher quality and much greater leverage.

The pure coder — the mediocre developer I described earlier, whose whole edge was producing plausible code — is finished. AI does that job faster, cheaper, and without the ego. That role isn’t shrinking; it’s being erased.

Once code costs almost nothing to produce, the scarce thing is judgment: what to build, how it should hold together, which trade-offs to accept. That was always the architect’s work. The age of AI is the age of the architect.

Don’t mistake that for immunity. The architect who won’t retool drowns right beside the coder. Point a machine you haven’t learned to steer at a real codebase and it will bury you in plausible, deliberate-looking slop — produced at machine speed, shipped under your name. The title won’t save you. You have to master the new craft — the rule-setting, the fencing, the spec discipline — and it’s a second apprenticeship many veterans haven’t even started.

I’m not the only one landing here. Charity Majors put it in one line:

AI demands more engineering discipline. Not less.

The data says the same, coldly. That Stanford study didn’t only catch the youngest developers losing ground as coding work got automated — the youngest cohort is down about 20% since generative AI arrived. In the very same high-exposure jobs, it caught engineers over thirty gaining ground, up 6% to 12%. One cohort got automated; the other got amplified. Same AI, opposite fates — decided by whether a real architect was holding the reins.

So the news isn’t grim — it’s the best of your career, if you move. Learn the new craft and you become the thing the market is starved for: an architect who can turn a machine loose on a real system and still get quality out of it.

But you don’t get there by “coding with AI” and tallying the tokens you burned. That’s the treadmill the productivity studies keep catching people on — feeling twenty percent faster, learning nothing. You get there the only way judgment was ever built: drills, the uncomfortable kind. Drive yourself through a stack of real projects, greenfield and brownfield alike — new systems where you set the architecture from a clean sheet, and old ones where you make the machine work inside the code it didn’t write. That’s the deliberate practice. No shortcut, and no book that replaces the doing.

So — who’s right? Both, at the very same time, because they were referring to different people. Cherny reports from inside the fence, where a real AI-savvy architect steers the machine on a greenfield project. Kin Lane, the debt study, the security scans — those come from outside, where the machine runs wild. The argument was never about AI. It was about which side of the fence you’re standing on.

The window is still open

I don’t think we’ve seen the half of what the machine can do, yet. The tools are a year or two old, the ground is still shifting, and the frontier is wide open. The people putting in the work now — while the craft is still forming — are the ones who’ll invent it. That’s a rare chance: not to just adopt a discipline, but to help write one from scratch.

And because it’s this early, honest people will read all this differently. If you think I’ve got it wrong, or have your own take to share, or a question to ask — say so. I read every comment, and I’d rather have the argument than the echo.

Good luck out there.

References