Reincarnated as a Junior Developer and Everyone's Mad the New Grads Don't Know How to Code, But You Guys Took Away All the Bugs ~The Errors Were the Whole Job~
There Is No Construction Phase
Construction has an architect and it has a laborer.
The architect has the vision. The laborer has the hammer. Two people, two educations, two lives. A laborer does not become an architect. It isn't that the path is hard, it's that the path doesn't exist. Get a five year degree and sit for licensure, or stay on the site.
Now look at the junior developer's job. A junior gets handed a ticket somebody else wrote, to build one small corner of a feature somebody else scoped, and a senior reviews every line before it merges. Hands, not vision. That's the laborer's seat, or as close as software has to one. And the person sitting in it is the person who, three years later, decides how the whole system is shaped. Same job, bigger word in front of it. Junior, senior, staff, principal. And then at some point somebody just starts calling you an architect. One escalator, running the entire way, both ends considered a good job.
Why?
The usual explanation is that software is flatter than other industries, or younger, or more of a meritocracy. All three are true.
But I would also note that software doesn't have a construction phase. It had one, and it got automated around 1954, before anyone working today was born.
Make, Eleven Seconds, 1954
In construction, design produces a blueprint. Construction turns the blueprint into a building. That second step is slow, physical, expensive, and needs a hundred pairs of hands.
In software, design produces source code. Construction turns source code into a running program. That second step is make. Eleven seconds, no cost.
Jack Reeves wrote this in 1992, in an essay called What Is Software Design?, and nothing since has been more clarifying. Source code is not the raw material. Source code is the blueprint. The build is the site.
So everything anyone does with a keyboard happens on the drawing side of the line. The intern's CSS fix. The junior's null check. All of it is design.
There is no manual labor in software. The parts that feel like it, the migration script, the test suite, the incident at two in the morning, are shot through with the deciding; try writing instructions for any of them complete enough that the person following along decides nothing, and you'll find you've written the program. The role you're actually looking for, where somebody executes finished instructions without judgment, is occupied, and has been since before you were born, by a machine. So the architect-and-laborer split did happen here, long ago. And that leaves every human in the profession today doing some version of the architect's job.
Cathedrals, Shovels, Eleven at Night
Once you see that, the question flips.
Everyone asks why software lacks the split. But historically, the split is the anomaly. Master masons built the cathedrals, and the man who designed the vault was a man who had cut stone. Separating the architect from the builder is a Renaissance idea that nineteenth century licensing boards hardened into law. It isn't physics. It's a settlement, and it held for reasons that come out of the material.
Buildings need bodies. Hundreds, moving heavy things at once, and you cannot staff that with masters because there aren't enough and you couldn't afford them. So the design has to be executable by cheaper, more interchangeable people. The division falls out of the weight of the stone. Software has no version of this, which is why adding people to a late project famously makes it later.
Buildings are permanent. A bad load path kills a family and can't be hot-fixed at eleven at night, so design gets front-loaded, stamped, gated by law before anyone picks up a shovel. Software iterates for free. You find out what the design was by building it, then you build it again.
And a blueprint is smaller than the building. The drawing doesn't say where every nail goes, because a competent framer already knows. The document can be incomplete and still work.
Software has no such document. There is nothing shorter than a program that fully determines what the program does. Any specification detailed enough to leave the person downstream no decisions to make is the code. Write it all out and you'll find you've written a program, in a worse language, and now you need a compiler for it.
Which is where the three usual explanations come back.
Software is flatter because nobody ever needed a hundred hands, so nobody ever had to be made cheap and interchangeable. It is a meritocracy in one narrow and specific sense: the laborer's work and the architect's work are the same activity, so anyone doing the first is already visibly doing the second, and there is no way to be good at the hammer without demonstrating something about the vision. And it is young, which is the one that ends up mattering most, because a profession's gates get built late.
The Empty Result Set
If no specification is ever complete, the person receiving it has to fill the gaps. Not sometimes. Always. Somebody at the bottom of the org chart, holding a ticket that says add pagination, is deciding what happens on an empty result set, whether the cursor is stable, what the thing does when rows change mid-scroll. None of that was written down. They decide it anyway, in about forty seconds, probably wrong.
That is the escalator. Not mentorship, not promo cycles, not a career ladder somebody in HR drew on a slide.
You don't learn that a boundary is in the wrong place by reading about boundaries. You learn it by putting one in the wrong place and then living inside your mistake for two years while every new feature has to cross it sideways. There's no book version of that, and no code review that transfers it. Senior is not a knowledge tier. It's a scar tier.
The incompleteness of the spec is what does the cutting. Hand someone gaps every day and they will decide wrong, carry it, and decide a little less wrong the next time. The wrong decision is the cut. The two years living inside it is the scar. And that's the entire apprenticeship.
Specs Thrown Over a Wall
Roughly once a decade, out of a sincere desire for cheap hands and expensive brains, this industry tries to manufacture the split.
CASE tools in the eighties, draw the design and generate the system. UML and model driven architecture, where the model is the truth and code is a downstream artifact. The offshore body shop, architects here and coders there and a wall to throw specs over. Low code, always, forever, again next year.
Officially they failed for the reason above: the spec would have to be as detailed as the code, so the split never made sense. But be precise about what failed, because offshoring didn't. Offshoring is bigger today than it has ever been. What failed was the wall. The spec showed up with holes in it, because every spec shows up with holes in it, and the coder in the body shop had two options: stop and wait weeks for an answer to cross the wall, or make the call. They made the call. Badly at first, then less badly, because incomplete specs cut everyone who touches them, over there same as here.
Then look at what the offshore industry did over the next twenty years. It did not stay a room of instruction-followers. The coders became engineers, the engineers became architects, the body shops moved up the value chain into design and product work, and the big offshore firms now sell the judgment, not the typing. There are principal engineers in Hyderabad. The wage gap survived. The judgment gap didn't.
Monday Afternoon
One question left over from construction: what actually keeps the laborer out? It was never that vision is some separate holy skill he doesn't have. It's paper. A license, a board, a stamp, a word he is not allowed to say out loud.
Software has none of that. No bar exam, no guild, no protected word, no gate. You can call yourself an architect on a Monday afternoon and nobody on earth has standing to stop you.
The German String Is Twice as Long
There is one obvious objection to all of this, and it's a good one.
Frontend. The designer builds the wireframes and the mocks in Figma. The frontend developer turns them into a website. Vision on one side, hands on the other, hand the pages over the wall. That looks exactly like the thing this essay just spent two thousand words claiming can't exist.
So test it against the criterion. Does the mock leave the implementer no decisions?
It isn't close. A mock is the happy path at three fixed widths. It does not say what happens at 900px versus 901px. It does not say what the empty state is, or the error state, or the loading state. It doesn't say what happens when the German string is twice as long as the English one, or what the focus order is, or what the screen reader announces, or what the thing does when a user double-clicks and fires the request twice. The designer drew maybe five percent of the state space.
The frontend developer decided the rest, ticket by ticket, and nobody ever called it design.
Which means frontend developers were never laborers. They were designers whose design work was invisible. Nobody ever thanked anyone for an empty state. That's the body shop story again: handed something with holes in it, they made the calls, and the calls turned out to be the job.
But the objection is still doing something important, because it points at the mechanism.
Why did frontend get treated as construction when backend never did? Because a mock looks finished. It's a picture of the output. Nobody ever mistook a UML diagram for a running system, but everybody mistakes a Figma file for a website. The medium lies about how compressed it is. And wherever a spec looks complete, the industry starts treating the people downstream of it like labor.
So watch what happened to the one corner of software where that pseudo-split actually formed. Bootcamp flood. Entry-level saturation. And in the pay data, a specific shape: staffing firms with real placement volume report the mid-level band softening after the 2024 and 2025 layoffs and never fully recovering, while senior comp went up, with genuine premiums for the people who own accessibility, performance, or a design system. The top of the market got scarcer and better paid. The middle got hollowed out.
That is the escalator breaking in the middle, showing up in a salary band.
Now add the AI half. The designer skips the developer and ships the site themselves. And for a landing page this works, because a landing page genuinely is mostly the happy path. Low state, disposable, nobody has to maintain it in four years.
But the instant the thing has state, the designer inherits everything the mock didn't say. The empty state. The race condition. The audit. The component that got copy-pasted five times because nobody was tracking that it already existed. They have not skipped the design work. They have absorbed it, without the scars. Either the artifact stays trivial, or the designer slowly becomes the frontend developer, gets cut, and the escalator quietly reassembles itself underneath them.
And the tell is in the money. That same placement data lists, as a current tailwind for senior frontend pay, the slow death of the "we'll just outsource the frontend" experiment: companies hiring senior engineers at the top of the band to repair the broken design systems and unmaintainable component libraries it left behind.
The wall failed. Again. In the exact place it looked most plausible. And the cleanup is being paid for right now, at senior rates.
Frontend isn't the counterexample. It's the pilot study, and the results are in.
Fifty-Two Engineers and a Danish Study
Which matters, because AI hands every ticket the same thing that broke frontend: an answer that looks finished. Every task comes with a mock stapled to it now, not just the ones with a Figma file.
So there are two worries going around.
The first: this is another attempt to buy cheap hands. Same pitch as the last four, better demo.
The second: juniors aren't learning to design, because when the ticket says add pagination, nobody sits there for forty seconds and decides wrong anymore. They ask, something answers, the answer is fine, nobody gets cut.
The second one is why the first one finally works.
In January 2026, Anthropic published a randomized controlled trial on skill formation. Fifty-two mostly junior engineers learned an unfamiliar Python library, half with AI assistance and half without. The AI group scored 17% lower on the comprehension quiz, roughly two letter grades, and did not finish meaningfully faster. The largest gap was in debugging, which is to say: in recognizing that code is wrong and understanding why.
The detail that matters is smaller than the headline number. The group that learned more hit a median of three errors along the way. The AI group hit one. The errors were the curriculum. Not the code, not the finished task. The friction.
The study also found that how you use the thing matters enormously. Participants who asked conceptual questions and stayed cognitively in the loop scored above 65%. Participants who delegated generation and moved on scored below 40%. Same tool. Same task. The difference was whether anyone got cut.
Meanwhile the pipeline that produces the cutting is closing. Stanford's Digital Economy Lab, working from ADP payroll records, found employment for 22 to 25 year olds down 16 to 20% in the most AI-exposed occupations, with senior employment roughly flat. Forrester projects a 20% drop in CS enrolment as students read the signal and go elsewhere. For what it's worth, a Danish study using similar methods found near-zero effects, so the employment picture is contested in a way the repository data below is not.
Thursday, Fast Fashion, Stories at Parties
Here's what's supposed to happen next: quality collapses, everyone notices, the industry corrects.
That is not what the repositories show.
GitClear and GitKraken analyzed 623 million code changes from 2023 through 2026. Duplicated blocks are up 81%. Refactoring moves, the signature of someone reshaping code rather than bolting more onto it, are down 70%. Error-masking constructs, code that catches a failure without evaluating why it happened, are up 47%.
And then the one that really makes you stop and think. Long-term maintenance, meaning changes that touch code last modified more than a year ago, has fallen 74% since 2023. It's now under half a percent of all changes.
Nobody is going back. The codebase grows outward in fresh v1 features while its older strata sit frozen, un-refactored, un-consolidated, quietly calcifying until something snaps.
Partly that's because starting over has gotten cheaper than understanding what's already there. Why spend an afternoon working out what a module does when the model can regenerate something like it by lunch? So code is becoming fast fashion: cheap to produce, worn briefly, discarded instead of repaired, piling up where nobody looks. It feels efficient the same way fast fashion feels cheap, which is to say the cost didn't go away, it moved somewhere without a line item. And repair is a skill. Like every other skill in this essay, it only forms in people who are made to do it.
That is what the quiet failure looks like. When a wall failed before, it failed loudly. The project didn't work, everyone knew whose fault it was, you clawed it back in-house and told the story at parties for years. What you get now is a system that runs, passes its tests, ships on Thursday, and that no living person understands the shape of. Nobody notices the boundary is in the wrong place, because noticing that is exactly the skill the numbers above say is not being formed.
Every previous wall dissolved because the people underneath it kept building anyway, and kept turning into architects. Take away the daily forced dumb decision, take away the three errors, and the dissolving stops. The wall holds. Nobody downstream will design anyway. They never learned how. It will not occur to them that there was anything to decide.
C, Memory, Civilization
This alarm has been raised at every abstraction step and has been wrong nearly every time. The assembly people said C would produce a generation who didn't understand the machine. They were right, and it didn't matter. Nobody manages their own memory now and civilization held.
So what's actually different?
Every prior abstraction removed a layer and left the deciding intact. You stopped writing assembly and kept making design decisions, just from higher up. This one doesn't remove a layer. It removes the deciding, at whatever layer you happen to be standing on.
That's the claim. It might be wrong. Maybe prompting is simply the new layer, real design is happening up there in the spec and the review, and anyone worried about this is the assembly guy, sour about the future. And the productivity skeptics keep having to revise anyway: METR's famous finding that experienced developers were 19% slower with AI while believing they were 20% faster has since been walked back by METR itself, on selection-bias grounds, and they now think current tools probably do help. The perception gap survived. The number didn't.
But notice that the productivity fight, in either direction, never actually touches the argument. Even if every claimed gain is real, productivity and apprenticeship are different systems. Speeding up the first says nothing about what's happening to the second, and the honest position right now is that the first question is unsettled while the second looks worse the more carefully anyone measures it.
Twenty-Two, Reviewing Diffs
None of this is a plan. There is no room where someone decided to deskill the juniors so the wall could finally go up.
There are a thousand teams making individually reasonable calls about velocity this quarter. Hiring a junior costs a senior 20 to 30% of their time for months, and the senior is already drowning in review. The math pencils out in every single room. The catch is that every company gets its seniors from a pool that some other company paid to train, and this year, all at once, everybody has decided to be the other company. A tragedy of the commons.
If you're early in this career, the study above is your instruction manual, and it's one sentence long: decide first, ask second. Write your wrong answer before you ask for the right one. The 65% group and the 40% group had the same tool and the same task; the difference was that one of them kept the forty seconds and the other gave it away. Your errors are not the obstacle to the curriculum. They are the curriculum, and you are the only person in the building who can still enroll yourself.
If you run a team, you can't ban the tool and shouldn't. But you decide what a ticket asks for. A ticket that asks for a diff produces a reviewer. A ticket that asks for a decision, what should happen on the empty result set, and why, produces an engineer, and the model can write the code afterward. And if you own hiring, the arithmetic has a second page: the companies that kept their pipelines through the 2008 freeze owned the mid-level market by 2012, and the ones keeping them now are quietly buying the 2031 senior market at today's prices.
So the question isn't whether code gets easier to write. It's whether anyone is still getting cut.
Whether the twenty-two year old whose entire first year is reviewing generated diffs will ever become the person who decides what gets built, or whether they'll spend a career reviewing, incompetent and unpromotable, waiting for a scar that never comes.
The escalator was the best thing about this job even though nobody earned it. It exists because our laborer got automated before any of us showed up, and because nobody ever got around to building a gate.
They still haven't. That was never the risk. And an escalator that stops isn't even a disaster; a stopped escalator is just stairs, and stairs still work. The problem is quieter than stopping. The stairs are rotting, one reasonable quarter at a time, and the people standing at the top are the last ones who remember climbing them.