The great unbundling

The bundle

For twenty years, "software engineer" meant a specific bundle. You wrote code, understood systems, collaborated with a team, debugged production, reviewed pull requests, mentored juniors, translated product requirements into technical decisions. Senior meant you did all of it better. Staff meant you did it across teams.

The bundle held together because each skill reinforced the others. Writing code taught you to review code, and reviewing it taught you how the system actually behaved under pressure. That understanding, in turn, taught you which technical bets to make. A generalist running 7/10 across the board beat a specialist at 10/10 in one dimension, because software development was collaborative and drowning in context.

Companies optimized everything around this archetype. Hiring, leveling, career ladders, all built for the well-rounded "full stack" engineer you could drop into any team and expect contributions within a sprint.

AI is pulling it apart.

The split

In The leadership variable I wrote about where value goes as AI commoditizes low-cognition work. This one is about where the people go. Remove the bottom of the stack and the roles built on top of it start splitting along a depth-breadth axis. One role becomes two, sometimes three.

On one side: the builder. Broad, AI-augmented, shipping end-to-end. 4% of public GitHub commits now come from Claude Code alone, doubling monthly, projected to hit 20% by year-end. On my own teams, engineers write essentially zero lines of code by hand. Agents do the implementation; humans do the direction, review, and judgment. The builder doesn't need to know how the database works internally. They need to know what's worth building and whether the output is good enough.

On the other side: the systems engineer. Deep, specialized, understanding the machinery at a level AI can't touch. Tracing retry semantics through three services. Knowing why that particular cache invalidation strategy was chosen in 2019 and why changing it will break something nobody tests for. Their value is years of accumulated judgment about how complex systems actually behave.

And sometimes: the versatile specialist who does both. The ones who can go deep in any field they touch, not just skim the surface. More on that later.

The same fission is happening to every role in a software organization.

Designers are splitting into taste specialists and builder-designers. AI generates options faster than any human can sketch, so the discovery-to-mockup-to-iterate loop is collapsing. The judgment to pick the right direction still matters. So does the ability to build the thing yourself. Engineering managers are splitting into people leaders and agent orchestrators. The 40% of EM time spent on sprint mechanics, status aggregation, cross-team coordination is getting absorbed. Coaching and career development still need a human. So does the technical judgment to direct AI workflows. Product managers face the same fracture. Upstream strategy survives. Downstream ticket-writing gets absorbed by engineers who can now specify and ship without a translation layer.

The architect might be the one role that stays intact. Gregor Hohpe describes it as inherently about making other folks smarter, understanding the second and third-order consequences of technical decisions across an organization. AI is bad at that.

Why the middle

David Autor, Frank Levy, and Richard Murnane described this mechanism in 2003: technology substitutes for cognitive and manual tasks that follow explicit rules, while complementing nonroutine problem-solving. The middle of the skill distribution gets hollowed out. Autor's follow-up work confirmed it with two decades of employment data: a U-shaped curve where high-skill and low-skill work grew while middle-skill work shrank.

The same thing is happening to software engineering, just faster.

The routine, transferable, "professional" work that justified a full-time mid-career position is exactly what AI automates best: turning specs into implementations, iterating on wireframes, aggregating status, writing specifications. All real skill, but the kind you can describe in a prompt. The 5/10 to 7/10 band of cognitive complexity, structured enough for AI to handle, complex enough that it used to require a salaried professional.

The mid-career squeeze: the middle of the skill distribution is automated

The extremes thrive. The middle gets squeezed.

Acemoglu and Restrepo frame this as two competing forces: displacement (capital replaces labor in existing tasks) and reinstatement (new tasks emerge where labor has comparative advantage). Roles don't vanish. They split and reconstitute around new boundaries.

The printing press fractured the "scribe" (writer, calligrapher, copyist, editor, archivist) into a dozen new specialties: printers, typesetters, proofreaders, bookbinders, illustrators, publishers. The scribes who thrived were the ones who had something worth printing.

The data

At the Pragmatic Engineer Summit in February 2026, staff+ engineers reported the highest AI agent adoption at 63.5%, followed by directors/VPs at 51.9%, regular engineers at 49.7%, and EMs at 46.1%. The most senior and the most junior are moving fastest: staff+ engineers know what to ask for, and new grads have never worked without these tools.

Brynjolfsson, Li, and Raymond studied 5,172 customer-support agents and found AI increased productivity by 15% on average, but the gains were wildly uneven. Less experienced workers improved in both speed and quality. The most experienced workers saw small gains in speed and small declines in quality. Peng et al. found the same asymmetry in a GitHub Copilot trial: junior developers adopted faster and gained more. Developers above the median tenure showed no statistically significant productivity gain at all.

The mid-career engineer whose identity is "I write clean, well-tested code" faces the hardest version of this transition, and it shows in team sizes too: the two-pizza team of six to ten is shrinking to one-pizza of three or four, with sharper specialization at both ends.

Depth or breadth

Dell'Acqua, Mollick, et al. ran a field experiment with 758 BCG consultants and found two winning patterns. "Centaurs" divided work strategically between themselves and AI. "Cyborgs" integrated AI into every step of their process. Both outperformed. The folks who failed used AI without a clear sense of where it helped and where it didn't.

The builder path. Go broad. Ship across disciplines. Your moat is taste, speed, and the ability to evaluate AI output in domains you couldn't have touched before. The career looks less like a ladder and more like a portfolio: breadth of shipped work, not depth of technical pedigree.

The systems path. Go deep. Understand your domain at the level AI can't replicate. Your moat is judgment accumulated over years of working inside specific, complex systems. The bar keeps rising because AI handles everything below it.

The trap: staying in the comfortable middle. The "solid senior engineer" who writes good code, reviews PRs competently, mentors adequately, contributes to architecture discussions when invited. That profile was valuable because it was reliable and abundant. When AI gets reliable and abundant too, that's a rough position to be in.

There's a third path: the versatile specialist. Some engineers go deep and build. They develop real expertise in their circle of competence and use that depth as leverage, building faster and with better judgment than either archetype alone. The best engineers I've worked with did both. Their depth gave them confidence to move broadly. Their breadth gave their depth context.

Tim Brown at IDEO called this T-shaped: deep vertical expertise crossed with broad horizontal range. The vertical comes first. The strongest version goes further, closer to what some call E-shaped: multiple verticals of real depth, connected by broad horizontal range. An engineer who's deep in distributed systems and deep in data modeling brings something qualitatively different to a problem than someone who's deep in only one. Each vertical reinforces the others. The more domains you've gone deep in, the faster you pattern-match in the next one.

In Range, David Epstein studied "wicked" learning environments and found that people who sampled broadly early and specialized later outperformed early specialists. They built structural analogies across domains that narrow experts couldn't see. Tetlock's forecasting research points the same way: "foxes" who drew on diverse mental models outpredicted "hedgehogs" locked into one framework, even hedgehogs with better information. Both are arguments for breadth. But when AI makes breadth cheap, the calculus changes. Breadth without depth is dilettantism. Depth without breadth is tunnel vision. The versatile specialist's path, the way I see it: depth first, then range. Ideally, depth in more than one place.

One thing that cuts across all three types: high agency. The builders who ship the most aren't just broad, they take ownership and push through obstacles. The systems engineers who matter most don't wait to be asked, they go find the problem. The best versatile specialists are relentless about closing gaps between depth and execution. The path matters less than whether you actually walk it.

What this means if you lead a team

Your team is becoming a mix of builders, systems engineers, and versatile specialists. They need different tools, different evaluation criteria, and different career paths.

Hiring. The interview that tests "write a clean implementation of X in 45 minutes" selects for the middle, the exact skill being automated. Builders need to show taste and product judgment. Systems engineers need to show deep reasoning about complex systems. Versatile specialists are hardest to interview for: you're looking for someone who can go deep on a systems question and talk through product tradeoffs in the same conversation. You should be able to assess all three.

Leveling. The builder who shipped five products this quarter, the systems engineer who found one critical race condition, and the versatile specialist who redesigned the data pipeline and shipped the migration tool are all Staff-level performers. They look nothing alike on traditional metrics. Forcing them into the same rubric means undervaluing at least two of them.

Team composition. Two or three builders who move fast across the stack, one systems engineer who understands the deep architecture, and if you can find one, a versatile specialist who connects the two. AI fills the remaining space. The ratio depends on whether you're building new product or maintaining critical infrastructure.

Performance evaluation. The builder who ships fast with AI looks "not technical enough" by traditional standards. The systems engineer who spends weeks on one investigation looks "not productive enough." The versatile specialist looks like they can't pick a lane. All three assessments are wrong. They come from evaluation systems designed for the old bundled role.

The middle will not hold.

If this resonates, I'd like to hear how it's playing out on your side. Reach out on X or LinkedIn.