Everyone can write code now. That is precisely why writing code stopped being the job. What's left is harder, and there is more of it — it just isn't coding. It's architecture.
For seventy years, being a programmer meant being the person who could make the machine do the thing. That skill is now a commodity — a model does it, in any language, for anyone. So the part of the job that was actually scarce was never the typing. It was deciding what to build, getting the requirements right, owning correctness, and holding the whole system in one head. That work didn't shrink when the typing got free. It grew, and it has nowhere left to hide. Every programmer who is still worth hiring is becoming an architect. We are the last generation that got paid to code.
I want to say the uncomfortable thing first, because everything else follows from it: the skill that defined our profession for seventy years just became free. Not cheaper. Free. The ability to take an intention in your head and render it as syntax a compiler will accept — the thing we called "knowing how to program" — is now something a language model does instantly, in any language, for anyone who can describe what they want.
In 2023 Andrej Karpathy compressed the whole shift into one sentence: "The hottest new programming language is English." He wasn't being cute. The barrier to entry that gatekept the entire field — you had to learn the machine's grammar before you could make it do anything — is gone. The gate is open. The crowd is walking through it. And a lot of programmers are reassuring themselves that the crowd will write bad code, so the crowd doesn't count.
That reassurance is the most dangerous idea in our industry right now. It's true that the crowd writes bad code. It's also irrelevant, because so did we — we just had a monopoly on writing it at all. The monopoly is what's ending. And when the thing that made you special stops being special, you don't get to keep your old job and feel superior. You have to find the part of the work the machine still can't do, and go stand there. That part has a name. It's architecture. This is an argument that all of us have to go stand there — or get out of the way.
Be honest about what most of "programming" actually was. It was a tax. It was the hours between knowing what you wanted and having it: fighting the build, looking up the argument order of a function you'd looked up forty times before, translating a clear idea into the dialect of whatever framework you were married to that year. None of that was the value. The value was the idea and the judgment. The typing was the toll you paid to ship the judgment.
We mistook the toll for the road. Because the toll was hard — because it took years to get fluent enough that the syntax stopped fighting you — we decided that fluency was the profession. It was a reasonable mistake. When something is scarce and difficult, you organize your whole identity around being good at it. A generation of us did. We called ourselves by the language we typed in.
Now the toll is zero, and we are standing at an empty tollbooth insisting it was a cathedral.
In 1986 Fred Brooks wrote the most quoted essay in our field, "No Silver Bullet — Essence and Accident in Software Engineering." His claim was that software has two kinds of difficulty, and they are not the same kind of thing. There is accidental complexity — the difficulties that "attend its production but are not inherent": the languages, the tooling, the boilerplate, the grind of expression. And there is essential complexity — "the difficulties inherent in the nature of the software" itself. Brooks bet that no single advance would ever give us an order-of-magnitude gain, because every tool we could imagine attacked the accidents, and the essence would be left standing.
Forty years later, AI is the closest thing to a silver bullet we have ever fired. And Brooks turns out to be right and wrong in the same breath. He was wrong that nothing could melt the accidental complexity — AI melts it almost entirely. He was completely right about what would be left when it did. Because here is the line everyone quotes and no one acts on:
A machine that will write any code you can specify does not help you decide what to specify. It cannot tell you that the requirement you were handed is the wrong requirement. It will not notice that the feature you asked for will quietly corrupt data the business depends on, because it doesn't know the business and you didn't tell it. The silver bullet didn't kill the job. It vaporized everything that was hiding the job — and the job was the essence the whole time. There's nowhere left to stand except in front of the hard part.
Here is the part I find genuinely thrilling, and a little frightening. Walk into any engineering room from the last twenty years and listen for the three sentences that decided what actually got built. They were never about the merits. They were about the constraints:
Every one of those just evaporated. The "right" architecture used to lose to the "shippable" one because the right one cost three sprints we didn't have. The better datastore lost because nobody knew it. The cleaner design lost because the person who could implement it was on another team. These weren't lazy excuses. They were real constraints, and we made real, defensible tradeoffs against them for decades.
But notice what those constraints also did for us: they were cover. They let us ship the mediocre version and feel blameless, because the mediocrity wasn't a choice, it was a circumstance. "We'd have done it right if we'd had time" is the most comforting sentence in software, and we got to say it constantly. Now the time is here. The knowledge is here. The implementation is here.
The lazy reading of all this is that the job got easier — the robot types, we relax. That is exactly backwards. When implementation was expensive, it rationed our ambition. You couldn't afford to ask "is this the best possible design?" because you were too busy making the current design compile. Scarcity did your prioritizing for you. It was an excuse and a mercy at once.
Take the mercy away and the real work arrives, all of it, with no toll left to hide behind. Requirements elicitation — the slow, deeply human work of figuring out what is actually needed, which is mostly figuring out what people mean versus what they said — becomes the whole game, because the machine will faithfully build the wrong thing at superhuman speed. Non-functional requirements — latency, cost, security, operability, the properties that never show up in a demo and always show up in an outage — become your explicit job, because a model optimizes for "passes the prompt," not "survives Black Friday," and will cheerfully ignore every one of them you forget to name. Correctness stops being something you earn by writing the code and becomes something you have to verify in code you didn't write — and you cannot verify what you cannot read. And conceptual integrity — which Brooks, in The Mythical Man-Month, called "the most important consideration in system design" — becomes a daily act of defense, because a swarm of agents each generating locally reasonable code will shred the coherence of a system unless one mind is holding the whole shape and saying no.
That is not less work. That is more hours of harder thinking, traded for fewer hours of easier typing. Thomas Dohmke, then GitHub's CEO, watched a cohort of heavy AI users and described the same migration plainly: they "moved from writing code to architecting and verifying the implementation work that is carried out by AI agents." Birgitta Böckeler, writing on Martin Fowler's site, put her finger on exactly what the model can't bring to that table: it has "no aesthetic disgust at a 300-line function, no intuition that 'we don't do it that way here.'" Disgust and intuition are not accidental complexity. They're the essence. They're the architect.
If you only take one empirical fact from this piece, take this one, because it is the most counterintuitive thing we know about AI and engineering right now. In mid-2025, METR ran a proper randomized controlled trial — 16 experienced open-source developers, 246 real tasks on their own mature repositories. The developers expected AI to make them 24% faster. It made them 19% slower — and afterward, having just been measured, they still believed it had sped them up by about 20%.
Sit with that gap. The feeling of speed and the fact of speed pointed in opposite directions, and the feeling won — for experts, on their own code. Now multiply that across a generation that has never known the friction and so has no instinct to distrust the smoothness. Karpathy named the seductive version of this: "vibe coding," where "you fully give in to the vibes … and forget that the code even exists." It feels like flying. The data on what it leaves behind is already arriving: GitClear, looking at 211 million changed lines, found copy-pasted code climbing from 8.3% to 12.3% of changes while refactored code collapsed from 25% to under 10%. The codebase bloats; nobody moves anything; nobody understands the whole anymore.
This is precisely what happens when coders stay coders and just code faster: they generate more, comprehend less, and the system rots underneath a dashboard that says green. The architect is the person in the room who refuses to be fooled by the smoothness — who measures instead of vibes, who treats "it feels fast" as a hypothesis and not a result. Simon Willison drew the line that separates the two jobs: if a model wrote the code and "you then reviewed it, tested it thoroughly and made sure you could explain how it works to someone else — that's not vibe coding, it's software development." The reviewing, the testing, the being-able-to-explain: that's the architecture. That's the whole job now.
For fifteen years, the defining image of programmers helping programmers was Stack Overflow: a planetary firehose of "how do I do X in language Y." And that entire genre of question is dying — not slowly. A peer-reviewed study clocked the opening of the collapse: roughly a 16% drop in new posts within six months of ChatGPT's release. But the figures that landed in 2026 are the ones that stop you cold: in December 2025, Stack Overflow took in just 3,862 new questions in the entire month — about a 78% fall year over year, and some 98% below its early-2014 peak of more than 200,000 questions a month. The first instinct is to mourn it. I think the more honest reaction is to look at what those questions were.
They were accidental complexity, made social. Fifteen years and tens of millions of questions, and the overwhelming majority of them were the syntax tax wearing a community hat — "what's the incantation," not "what should we build." We constructed a monument to the toll and called it engineering culture. The machine answers those questions now, instantly, and it's welcome to them. They were never the interesting part.
So replace the firehose with the argument we kept deferring. Imagine the energy that went into twenty-five million how-to threads redirected, on every team, into one relentless, specific, ego-bruising argument: what is the best possible version of the thing we are about to build? Not the shippable version, not the version we know how to type — the best one. That conversation used to be a luxury we couldn't afford mid-sprint. It is now the core activity of the profession, and a team that isn't having it, loudly, is a team that has outsourced its judgment to autocomplete.
I mean "architect" as the only role left that the machine can't fill — not a title, not a promotion, not a corner of the org chart. When the typing is free, what remains is judgment: deciding what to build, defining what "done" and "correct" mean, owning the properties that don't show up in a demo, and holding the whole system in one head against a tide of locally plausible code. That used to be a senior specialty you grew into over a decade, after you'd paid your dues at the tollbooth. There is no tollbooth anymore. So it isn't the senior specialty now. It's the entry fee.
The junior who only knew how to code has nothing to sell that a model doesn't sell cheaper and faster. That's not cruelty, it's arithmetic, and pretending otherwise to be kind is the cruelest thing we could do to the people entering this field. But the engineer who can architect — elicit the real requirement, specify the properties that matter, verify the correctness of code they didn't write, and defend the integrity of the whole against an army of eager agents — that person is worth more than they have ever been, because the leverage under their judgment just went vertical. There will not be fewer of us. There is more work than ever. It simply isn't coding.
And yes — I can hear the strongest objection, because it's the one I'd raise myself. Maybe none of this is new. Maybe deciding what to build was always the essence, the seniors always knew it, and AI changed nothing except the price of the boilerplate. Ian Cooper made exactly this case: the "shift up to design" is just Brooks restated; the hard part was never the typing. He's right. That's not a rebuttal to this piece — it's the whole point of it, finally unavoidable. The essence was always the job. The difference is that the constraints used to let us hide from it, and call the hiding "being realistic." The constraints are gone. There is nowhere left to stand except in the architecture, in front of the hard part, with your name on the decision. We were the last people who got paid to know how. Everyone after us only gets paid to know what, and why.
Make peace with it now: you were never a coder. You were always an architect who hadn't run out of excuses yet.
Where the claims come from, in order of appearance: