The Bottleneck Has Moved

When code generation was the constraint, technical skill was the differentiator. Developers who could implement faster, debug quicker, and architect more elegantly commanded premium value. Business understanding was treated as nice to have, a soft skill that complemented the hard skills that actually mattered.

AI code generation is inverting this hierarchy.

The developers I see thriving aren’t the ones who code fastest. They’re the ones who understand what to build, why it matters, and what tradeoffs are acceptable. Technical execution is getting cheaper, if unevenly. Business judgment isn’t getting cheaper the same way, because it rests on unwritten context and on someone answering for the call.

Business Understanding Made Me a Better Developer

I became a better developer as I became more business-minded. Not because I learned new languages or frameworks, but because I developed a different relationship with the work.

Understanding value and customer alignment changed how I approached every decision:

• I stopped building the wrong thing well, which is the most expensive mistake in software
• I could evaluate tradeoffs against actual value, not abstract “best practices”
• I knew when “good enough” was actually good enough
• I understood the cost of delay, and that shipping imperfect beats perfecting endlessly

Code knowledge tells you how. Business understanding tells you what, why, and whether. AI is getting remarkably good at how. It has far less grasp of why, because the why lives in context that is rarely written down, like what a customer will tolerate or what the business can’t afford to get wrong. Models will see more of that context as organizations record more of their work.

What they won’t take on is the accountability. When a tradeoff goes wrong, the business needs a person who made the call and can say why.

That person doesn’t have to be a developer, since product managers already own the why. But judging whether AI’s defaults are right takes two halves: the business context to know what a default should do, and the technical knowledge to see what it actually does. Experience supplies only the technical half, so an experienced developer without the business half still depends on someone else for the why.

Splitting the halves across two people works until they have to meet. Defaults whose cost lands on a customer, like how a payment retry behaves or what a timeout shows the user, wait while one of them asks the other, and the work stalls in the meantime. A product manager paired with a senior reviewer handles the rest without trouble, because those need no business input, such as whether a query is quadratic. The developer who learns the business holds both in one head.

Either person could learn the missing half, but they don’t start in the same place. The technical half comes from years of diagnosing failed defaults, and AI shortens those years only for someone who does the diagnosis personally. For a product manager, that diagnosis would be a second job on top of their own. A developer already has the technical half and already sits where customer-facing defaults get chosen. Learning the business means asking about work already on the desk, so the developer starts closer to the finish.

Tool-Orientation Without Value Is Precarious

At routine tool operation, AI has built-in advantages. It doesn’t tire, doesn’t context-switch, doesn’t forget syntax. If your value proposition is “I can use the tools,” you’re competing on terrain where AI has structural advantages.

This isn’t new wisdom. Tool-orientation has always caused friction when divorced from value and alignment, and developers who understood the business context of their work were already worth more than their output. AI just accelerates the consequences.

The Bifurcation: Two Paths Pull Away From the Middle

The middle is losing leverage, and two paths lead away from it: broad-and-human work and deep-and-mechanical work. That the two paths keep pulling apart is this post’s argument rather than a measured trend. The early data, covered below, shows the door into the middle closing at the entry level, not the people already in it leaving.

The Broad-and-Human Path

This path centers on value judgment, customer alignment, tradeoff navigation, domain expertise, and system thinking. It requires broader context and is tied to the particular customers and domain it serves. Becoming more human means developing empathy, judgment, relationships, and context that machines struggle to replicate.

The Deep-and-Mechanical Path

This path leads toward R&D, algorithms, performance optimization, novel architectures, security research, and low-level systems. It demands narrower focus and extreme depth. Becoming more mechanical means precision, relentless optimization, and working at the frontier where AI assistance runs out.

AI is already a tool on that frontier, and it has started producing new results there too, so the frontier moves as models improve. What stays with the person is deciding which problem to attack and whether a result holds. That is the same judgment over AI’s output the broad path keeps, but it draws on different knowledge. On the broad path it draws on business context. On this one it draws on theory deep enough to judge a new algorithm or exploit.

For those drawn to this path, the bar rises dramatically. Knowing a language well becomes pushing the boundaries of what’s computationally possible. Implementing algorithms becomes inventing them. Using frameworks becomes building them. Following security practices becomes discovering vulnerabilities and designing novel defenses. You compete globally for positions that require genuine innovation, building the substrates that AI and others build products on. This path demands excellence that few can sustain, so it is a narrow way out of the middle rather than a wide one.

The Middle Loses Leverage

The middle is defined by where the time goes, not by seniority: roles that spend most of their hours turning someone else’s spec into code. Between these paths, those roles are losing leverage:

• the coder who implements specs without questioning them
• the integration specialist whose value was knowing API quirks
• the framework expert whose depth was a single ecosystem
• the ticket-taker who translates Jira stories into pull requests

Their knowledge doesn’t become useless. Tool-specific knowledge still catches AI’s mistakes with an unfamiliar API, but it becomes the check on the work rather than the work itself. Checking can take fewer people than doing, when the checker knows the domain well enough to spot a wrong default quickly.

Whether checking does take fewer people depends on what review costs, and two studies point in opposite directions. METR’s 2025 randomized trial found experienced open-source developers took 19% longer with AI tools on issues in their own mature repositories. METR cautions against generalizing the result. Its subjects were experts who already write fast in large codebases they know deeply, which is where checking costs the most next to writing.

Ordinary corporate work looks different. Zheyuan Kevin Cui, Mert Demirer, and colleagues ran three field experiments with nearly 4,900 developers at Microsoft, Accenture, and a Fortune 100 company. Developers given an AI coding assistant completed about 26% more tasks, and less experienced developers gained the most.

Read together, the two studies show where the middle shrinks. Where checking costs as much as writing or more, as in METR’s setting, the middle shrinks little. Where checking costs less, each developer covers more work, so the same work needs fewer developers. The experiments don’t show whether firms turn that extra output into more software or into fewer people. At the entry level, the employment data below suggests fewer people.

Economists have seen a middle hollow out before. David Autor’s 2010 paper on job polarization traced how automating routine, rule-based work shrank middle-skill jobs across the U.S. labor market while demand grew at both the high and low ends. The parallel lies in the mechanism, not in what grew at the two ends, since Autor’s low end was service work.

What shrank in Autor’s data was work that followed explicit rules. Turning a spec into code looks like a poor fit at first, because every spec leaves edge cases and failure behavior unstated. But the middle filled those gaps with the conventions of its stack, and AI has learned the same conventions. That makes the gap-filling rule-like, and AI now does it with plausible defaults. What’s left is deciding whether those defaults are right, and that is judgment, the work of the two paths rather than the middle.

Early data on AI points the same way. Erik Brynjolfsson, Bharat Chandar, and Ruyu Chen at the Stanford Digital Economy Lab found that employment declines for young workers concentrated in occupations where AI automates work rather than augmenting it. Where AI does the work rather than assisting with it, entry-level employment falls. The paper sorts whole occupations rather than roles within a team, so it can’t show the split inside one.

These roles don’t vanish overnight. But the leverage shifts. In my own work, one business-aligned architect with AI assistance covers what previously required a team. I lead two development teams now, and on one of them I do all of the development work myself. That covers at least six positions, and quality and velocity on those projects have both improved.

That is one case, not a study, and experience explains part of it. Neither it nor the employment data separates business alignment from experience, so the case that alignment is the multiplier rests on the two-halves argument above.

Both the broad and the deep paths are valid, and neither is easy. But the space between them is compressing.

Position	Valued for	What AI absorbs	What to develop
Broad-and-human	Deciding what to build and which tradeoffs are acceptable	Implementation	Domain expertise, customer alignment, tradeoff judgment
Deep-and-mechanical	Judging which frontier problems to attack and whether new results hold	Routine use of languages, frameworks, and known algorithms	Inventing algorithms, building frameworks, discovering vulnerabilities
The middle	Executing specs and knowing tool quirks	Execution, leaving the checking to fewer people	A move toward either path

Atrophy Is an Old Trade, but the Checking Skill Has to Survive It

There’s a darker worry beneath the surface: what happens to our skills as we rely on AI?

Right now, senior engineers with decades of hard-won intuition can leverage AI as a force multiplier. They know when AI is confidently wrong. They have the architectural judgment to evaluate generated code. They built debugging instincts from years of suffering through problems manually.

But when AI handles something, you tend to get a little worse at handling it yourself. Skills require practice to maintain. Outsource the practice and the skill decays. If AI stalls or regresses, will we still have the competence to engineer without it, or even to continue using it at our current level?

This concern is valid, but it’s also not new.

Could you build a radio if you needed to? Could you manufacture a car, synthesize medicine, or grow enough food to feed yourself for a month? Civilization is dependency. Specialization is the trade. We gave up self-sufficiency for leverage a long time ago.

Technological layers tend to follow the same pattern. A new capability emerges, and early adopters with pre-existing skills use it as a force multiplier. The next generation learns with the tool rather than before it, and the underlying skill becomes specialized knowledge held by few. We don’t mourn that most people can’t forge steel or build semiconductors. We accept that specialists exist and the rest of us build on their work.

AI is another layer in this stack, with one difference. Radios work reliably, and AI is still confidently wrong often enough that its output needs a checker. That checking is the judgment both the broad and the deep paths keep.

Whether the checking skill survives depends on how AI is used. A developer who still does the diagnosis keeps it, and one who hands the diagnosis over loses it. Syntax and recall will atrophy. That’s the trade. What matters is whether you’re positioning yourself to provide value at the new layer, or holding onto skills being absorbed into the substrate.

Most of the people who thrived weren’t the ones who could build radios. They were the ones who understood what to do with radios.

The Learning Inversion: Judgment Learned in Context

Senior engineers built the checking instinct before AI arrived. Newcomers have to build it alongside AI, and the early evidence says they feel the hollowing first. The same Stanford study found that employment for 22-to-25-year-olds in the most AI-exposed occupations, software development among them, fell relative to less-exposed peers. The drop came through fewer jobs rather than lower pay, while employment for experienced workers held steady.

That raises a question that sounds new but isn’t: how do people develop judgment without grinding through the middle?

The honest answer is that the old path was never as necessary as we pretended. We learned the hard way, spending years on syntax, framework quirks, and theoretical foundations before we were trusted with real decisions. Much of that time went to material we would have learned better once a problem called for it. We learned “computer science” when we needed to learn “this job.” We studied theory for hypothetical problems while the actual problems sat waiting.

This was always a trade-versus-theory problem. Traditional education and career paths optimized for theoretical completeness, not practical judgment. “Learn the fundamentals first, apply later” sounds rigorous, but it mostly meant years of gatekeeping before you got to do the work that actually built intuition.

AI doesn’t just hollow out the middle. It offers a way through.

When coding takes a fraction of the time, you can redirect that effort toward what actually matters: the domain, the users, the constraints, the tradeoffs. You still need to understand security, architecture, concurrency, algorithmic complexity, and system thinking, because those are what let you see that generated code is racy or quadratic. But you can acquire that knowledge in context, while working on actual problems, rather than stockpiling it in advance for scenarios that may never come.

Learning in context still starts from a short map of what can go wrong. That map is the fundamentals just listed, learned well enough to recognize a race or a quadratic loop when one appears. What it skips is mastering each item before any problem calls for it. You study concurrency when the system in front of you has concurrent writers, and you ask why the generated code is safe under them. That is when the lesson sticks. The deep path described earlier is the exception, because inventing algorithms takes exactly the theory that most product work never calls on.

The instinct that lets senior engineers catch AI being confidently wrong came mostly from debugging real failures, not from the years of syntax and theory around them. Newcomers still need those failures, and working on production problems with AI can supply them sooner, because faster building means more cycles of shipping, breaking, and fixing in a year.

More cycles only teach if the newcomer does the diagnosis. In Anthropic’s 2026 randomized trial on coding skill formation, mostly junior developers learning a new library with AI scored 17 points lower on a mastery quiz than those who coded by hand. The AI users who asked it for explanations scored higher than those who let it write the code. Left to default habits, AI means less learning. Newcomers have to question what AI generates and diagnose before asking it for a fix. Under delivery pressure, that takes a team that expects a junior to explain each fix, not just ship it.

All of this depends on getting in the door, and the employment data says the entry tier is shrinking. By the bottleneck argument, a newcomer who can speak to the domain and the user has a stronger case than one who can only produce code. That helps the newcomers who get in. It doesn’t promise that the tier stays as large, or that the juniors inside it get production failures to diagnose. If the tier shrinks too far, the industry stops producing the checkers both paths depend on, and that is the risk this argument leaves open.

For those who do get in, focus on this job, this problem, this domain. Generalist knowledge accumulates naturally from working across diverse problems. It doesn’t require years of abstract preparation.

I say this as someone who took the long path. The grind taught me things, but it also taught me how much of it was unnecessary. My technical skill formed best when it was tied to real customer and product needs. Memorizing syntax had no effect on it, and being able to recall every tool I’d used had very little. That perspective is exactly what lets me tell you to skip the syntax drills and tool trivia we went through. We have a good idea which parts mattered because we suffered through the parts that didn’t.

The middle was always a holding pattern, not a destination. AI just makes that visible.

Invest in Yourself, Not Your Toolkit

If you’re drawn toward the human side of this bifurcation, the answer isn’t to learn more tools or chase the latest framework. The answer is older than AI.

Market yourself, not just your skills. Skills are inputs. Value is output. Organizations don’t need people who can only code; they need people who can solve problems that matter. Position yourself around the problems you solve, not the tools you use.

Become value-oriented, not tool-oriented. Every technical decision exists in a business context. What are we trying to achieve? For whom? What does success look like? What’s the cost of being wrong? These questions matter more than implementation elegance.

This is the human work that AI does least well. It requires empathy, judgment, relationship-building, and context that spans conversations, projects, and years. The tools will keep getting better. Either you’re wielding them toward value, or you’re at risk of being replaced by someone who is.

Sources

1. METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
2. Cui, Demirer, Jaffe, Musolff, Peng, and Salz, The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers (Management Science)
3. David Autor, The Polarization of Job Opportunities in the U.S. Labor Market (Brookings / Hamilton Project, 2010)
4. Brynjolfsson, Chandar, and Chen, Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence (Stanford Digital Economy Lab)
5. Anthropic, How AI Assistance Impacts the Formation of Coding Skills (2026)