"Full-stack developer" has been a contested title for years. Critics say no one can be an expert across the whole stack. They're right about expertise and wrong about relevance. The question was never whether one person could master every layer. It was whether one person could be productive across every layer: productive enough to ship a complete feature without waiting on anyone.
That distinction matters more now than it ever has.
The stack got bigger
In 2014, full-stack meant HTML, CSS and some jQuery on the front, Rails, Django or Express on the back, PostgreSQL underneath, and Heroku or a VPS with a few shell scripts to ship it. One person could hold that in their head.
Today's stack is a different animal. React or Vue with TypeScript, server components and streaming. REST or GraphQL, serverless functions, background jobs. Relational, document, key-value and vector stores, plus caches and queues. Containers, orchestration, CI/CD, observability, infrastructure as code. OAuth, supply-chain security, compliance. Nobody is an expert in all of it, and nobody needs to be.
Full-stack means no handoffs
The full-stack developer worth hiring isn't the one who knows everything. It's the one who can take a feature from idea to production alone: design the data model and write the migration, build the endpoint, build the UI that consumes it, write the tests, deploy it, and watch it after launch. They don't need to be the best at any single layer. They need to be competent enough at each one to stay autonomous.
The best of them are T-shaped: broad across the stack, genuinely deep in one or two areas, and honest about where they lean on others.
The reason companies want them hasn't changed. Every handoff between specialists adds delay, coordination overhead and room for misalignment. A change that waits in three queues for three people to load the same context is a tax, and it compounds. An engineer who owns a feature end to end removes whole categories of that cost.
Fig. 1From relay to ownership
Top: the specialist relay. Bottom: one engineer plus AI. Hover a box.
We were never paid to write code
Here's the part our industry hasn't absorbed yet. Developers were never paid to write code. They're paid to solve problems. Code was just the most visible way to do it, and for decades the fastest route from problem to solution ran through someone's fingers.
So we optimized the fingers. We built tools, practices and muscle memory around writing code faster: snippets, keyboard shortcuts, vim motions drilled until they're reflex. We even turned the people who could write code fastest into rockstars.
AI coding tools are starting to take those instruments away. They close the gap between knowing a concept and writing production code for it. A backend engineer who has never shipped serious React can build a polished UI. A frontend developer can write a competent migration. The threshold for being productive in a layer you don't specialize in is falling, and that hands the advantage to whoever can see the whole problem and own it end to end.
That will be a great struggle for some and a great opportunity for others. The engineers whose identity is the keystrokes will feel the floor move. The ones who always cared more about the problem than the typing are about to get more leverage than they've ever had.
The new full-stack developer isn't the one who knows the most. It's the one who needs the fewest handoffs.
Updates
April 2026: made the bet explicit. The original piece argued that full-stack is about autonomy, not expertise. As AI coding tools spread, that argument turned into a prediction, and I added it to my predictions record: by the end of 2025, AI would redefine the role, and the engineers who thrive would be the ones who orchestrate AI, reason about systems end to end and ship complete features, rather than memorize APIs. Breadth would beat depth. The section above on AI and on what we're paid for was written into the piece as part of these updates; the original 2024 text didn't mention AI.
October 2026: the window closed. I was about half right.
The direction held. In Stack Overflow's 2025 survey, 84% of developers were using or planning to use AI tools, and 51% of professionals used them daily. Google's 2025 DORA report, from about 5,000 technology professionals, put adoption at 90%. By Stack Overflow's 2026 survey, 66% of developers using AI worked in coding agents, and the share working as an organization of one rose from 4% to 10%. Shopify told teams they must "demonstrate why they cannot get what they want done using AI" before asking for headcount. The people who only type known patterns are feeling it: Stanford's Digital Economy Lab finds employment for 22-to-25-year-olds in AI-exposed jobs about 19% below trend.
"Breadth beats depth" didn't hold up as cleanly. Developers mostly use AI inside layers they already know.
Fig. 2What developers use AI for (2026)
Percent, as reported in Stack Overflow's 2026 results. AI is mostly used inside familiar layers.
Source: Stack Overflow Developer Survey 2026
The productivity evidence is mixed too. METR's 2025 trial found experienced developers took 19% longer with AI while believing they were 20% faster; its 2026 follow-up pointed toward a modest speedup but gave an unreliable signal. DORA's conclusion is that AI is a "mirror and a multiplier": it amplifies what a team already is.
What I'd say now: AI didn't make breadth win. It made judgment win: knowing what to build, owning the outcome, and directing the tools. That's the argument I picked up in The Great Bifurcation. The handoff tax is still real, and the engineers who remove it are still the most valuable people on a team. They just aren't winning because they type in more layers.