Graduating without scars

Every senior engineer you respect has a story, and the story has a shape. It's 2am, or a demo day, or a Black Friday. Something they wrote is on fire. There is no adult in the room, because they just discovered that they are the adult in the room. They spend six hours inside the guts of a system, printing things, bisecting things, doubting everything they believe, and at hour six they find it: one line. Their line. Written by them, three weeks ago, with total confidence.

Ask them what they learned that night and they'll tell you about the bug. But that's not what they learned. What they learned was a new relationship with their own code — a permanent, full-body understanding that everything I write is a claim about reality, and reality checks claims.

You cannot get that from a blog post. (I'm aware of the irony. Keep reading anyway.)

The apprenticeship was never about the code

Here's a thing that was true for fifty years and stopped being true about two years ago: the way you became a deep engineer was by writing shallow code and then personally suffering its consequences.

The loop was brutal and perfect. You wrote something naive. It broke. Crucially — and this is the part that's gone — it broke on you. You had written every line, so the debugging session doubled as a guided tour of your own misunderstandings. Each 2am disaster carved one wrong belief out of your head and replaced it with a scar. Ten years of scars, and congratulations: you now have the thing we call judgment, which is mostly a library of ways you've personally been wrong.

Peter Naur gave this a formal name back in 1985: the program, he argued in "Programming as Theory Building," isn't the text — it's the theory in the builder's head, and the theory is built by building. Not by reading. Not by reviewing. By constructing the thing, watching it meet reality, and revising your model when reality disagrees. John Ousterhout's A Philosophy of Software Design runs on the same fuel: his whole method for teaching design is making students build systems, receive brutal feedback on the complexity they created, and rebuild — because design sense, he argues, cannot be transmitted as rules, only grown through iterations of consequence.

Theory building requires friction. We just shipped an industry-wide friction-removal machine.

What the new loop looks like

Now run the 2026 version of a junior engineer's formative years:

1. You get a ticket.
2. You describe it to a model.
3. Code appears. It's pretty good! Genuinely — often better than what you'd have written.
4. It passes CI. You ship it.
5. Three weeks later it breaks at 2am and — here's the fork in history — you debug it with the model too. You paste the stack trace. The model suggests a fix. The fix works. You go back to sleep.

Notice what never happened. You never held the broken thing in your head. You never built the theory, watched it fail, and rebuilt it. You experienced the outcome of a debugging session without the transformation of one. It's the difference between climbing a mountain and being shown a photo of the view. The photo is accurate! You just aren't any stronger.

Repeat that loop for the five years that used to constitute an apprenticeship, and you get something new in the history of the profession: an engineer with five years of experience and zero scars. Fluent, productive, credentialed — and never once left alone with a broken system and their own wrong model of it.

THE PAIN WAS THE CURRICULUM. We removed the pain and kept issuing the diplomas.

"Okay boomer, they said this about compilers too"

Fair challenge, and it deserves a real answer. Yes — every abstraction wave triggered this exact panic. Assembly programmers said C would rot brains. C programmers said garbage collection would. Everyone said Stack Overflow would. And each time, the panic was mostly wrong, because the abstraction removed drudgery while leaving the conceptual work — and the conceptual work was where the scars came from. You stopped hand-allocating registers, but you still designed the system, still broke it, still debugged it yourself at 2am.

This wave is different in one specific, checkable way: it's the first abstraction that does the conceptual work too. It doesn't just save you from typing the retry loop — it decides that there should be a retry loop, where it goes, and what it assumes. The prior waves compressed the labor between your ideas and the machine. This one is happy to supply the ideas.

And there's early empirical reason to think the self-assessment problem is real. METR's 2025 randomized trial put experienced open-source developers on real tasks in their own repositories, with and without AI assistance — and found the AI-assisted developers were measurably slower, while estimating they'd been sped up by roughly 20%. Veterans. On code they knew deeply. If experts with decades of scars misjudge what the assistant is doing to their own performance, what exactly do we expect from a first-year who has never had an unassisted baseline to compare against? They don't just lack the skill — they lack the ability to notice lacking it.

The ten-year problem hiding inside the two-year win

Here's the uncomfortable arithmetic for your org chart. The industry's supply of deep debuggers — the people you page when the incident is genuinely weird — was never produced on purpose. It was a byproduct. A slow, unmanaged fermentation process running in every junior's on-call rotation. Nobody budgeted for it because it was free.

GitHub's own Copilot research celebrates, reasonably, that developers complete scoped tasks dramatically faster and report less frustration — their controlled study measured a 55% speedup. Take it at face value. Now ask: frustration at what? At exactly the grinding, confusing, model-revising friction that was manufacturing your next decade of senior engineers. The 55% is real and it's this quarter's. The cost is real and it's 2031's — it arrives on the day your systems have grown too weird for the model, the genuinely novel incident hits, and you reach for a deep debugger from a cohort that was never given the chance to become one.

(Self-aware aside: the seniors are fine, which is part of why nobody's alarmed. Everyone currently senior got their scars under the old regime. The shortage is invisible for exactly one generation — like a country that stops training doctors and doesn't notice until the current ones retire.)

You can't reinstall the pain. So what's left?

Let's be honest about the options. You will not ban assistants; that's competitive suicide and your juniors would rightly ignore you. Artificial suffering — "no Copilot Fridays" — has the energy of a corporate trust fall and roughly its efficacy.

What actually transfers, though, is consequence visibility. The old 2am scar worked because it forcibly connected an engineer to what their code did in reality. That connection can be rebuilt deliberately instead of traumatically: put every engineer — especially the ones who've never been burned — in front of the live behaviour of the functions they shipped. Not dashboards of the whole system; their functions. This thing you generated on Tuesday: here's its error rate, here's its latency drifting, here's the moment it stopped being called at all. (This is, quietly, the most educational thing runtime telemetry does — in CodeNSM's fleet we routinely watch a shipped-and-forgotten function become a teaching moment the week its behaviour diverges from its role's baseline. The scar arrives by instrument instead of by pager.)

It's not the mountain. But it's the closest thing to it that scales: reality, delivered continuously, in small doses, attached to your own name.

Because the alternative isn't that the new cohort stays shallow forever. It's that their first real scar comes at thirty-five, on a system carrying your revenue, with no senior left who remembers how to bleed.