Vol. III · Essays on work after AI
Saturday, October 3, 2026
evolving.work
Org Design · Essay № 074

AI Does Not Eliminate Bottlenecks. It Moves Them.

AI does not eliminate bottlenecks.

H Héctor Reinoso Sep 21, 2026 13 minute read Share · Save

The Wrong Debate

The AI-and-jobs debate runs on loop. One side argues AI will replace knowledge workers the way mechanization replaced farmhands. The other argues it will create more work than it destroys, the way every previous technology wave has. Both cite credible data; both cite credible counter-data. After a while you start to wonder whether the people in the debate are trying to resolve it or enjoying the rehearsal.

The rehearsal is the point. Both camps agree on something they shouldn’t: that there is a fixed amount of work in the world. Utopians treat the pie as fixed and growing; dystopians, fixed and shrinking. Neither lands, because the pie isn’t fixed at all. It reshapes around whatever the organization can’t scale at the same pace as everything else.

The right question is not whether AI creates or destroys jobs. It is where the bottleneck moves when AI removes the current one. Acemoglu’s work makes the mechanism precise: automation substitutes labor in routine tasks while reinstating new tasks that require human judgment, and the net employment effect depends on which side moves faster [7]. Substitution and reinstatement happen in the same economy at the same time. Sometimes in the same company, in the same quarter.

This is not a forecast. It is a frame — and it changes how you plan AI adoption, what you hire for, and where you invest capacity.

How Constraint Systems Work

Every organization has a binding constraint — the stage that limits total throughput regardless of how fast everything else moves. If your sales team can close 100 deals a month and your implementation team can onboard 30, you ship 30. Hiring more salespeople does not change the number. Throughput is governed by the slowest stage, with a queue forming behind it.

The example makes the throughput limit visible. Eli Goldratt named the dynamic in The Goal in 1984, older than most software companies — its own quiet joke about how often we re-discover things by giving them new names. What’s new is the speed and the demand-side effects that follow: AI relieves the binding constraint in weeks, not quarters, and that compression breaks the intuition operations managers spent careers building [10].

Relieve the binding constraint and a new one immediately becomes binding. Improve onboarding from 30 to 100, and the question becomes whether support can hold the relationship after the handoff — then whether the product can absorb the feature requests that scale brings.

Brynjolfsson, Rock, and Syverson documented this for general-purpose technologies: productivity benefits are delayed because firms must first invest in complementary intangibles — process redesign, training, governance — before gains appear [6]. “Complementary intangibles” is a polite way of saying the next constraint is organizational, not technical. Those investments determine whether the task-level improvement reaches the organization.

Where the Bottleneck Goes Next

AI removes some constraints, which exposes others — and the new ones often require humans. Start with software, because the data is cleanest. Large engineering organizations deployed GitHub Copilot at scale between 2023 and 2026, expecting faster feature delivery. Developers adopted it at 60–80% regular usage, and code output rose — some teams reported 30–55% faster first-draft generation. Delivery velocity, measured from conception to production, stayed approximately flat. So did business outcomes: shipped features per quarter, incident rates, customer satisfaction [3]. Barry Flack put it plainly: “AI-augmented developers were writing significantly more code. Delivery velocity and business outcomes? Flat.”

This is what constraint-systems thinking predicts. Code production was a constraint, but not the binding one. Code review was. Release engineering was. Architectural decision-making was. Relieve production while leaving review and release unchanged, and you get a longer queue of pull requests behind unchanged reviewer capacity. The team builds faster, the company ships at the same pace, and the friction shows up in Slack threads where senior reviewers quietly drown.

The same pattern shows up at industry scale. WRITER’s 2026 analysis reports that 88% of companies use AI regularly, while only 21% have reached production scale with measurable returns [1]. That 67-point gap is constraint migration in aggregate. Access is no longer the binding constraint — almost everyone has it. What binds now is integration, data quality, change management, and governance. Eide Bailly’s 2026 analysis adds the C-suite layer: 57% feel their company is not fully prepared for AI adoption [2]. Preparedness and governance are the constraints. Not access. Not capability.

The constraint can also migrate to a different axis entirely: trust, governance, accountability. When AI handles decisions, accountability has to be redistributed. Legal review, security testing, traceability, human oversight — the structural requirements of operating AI responsibly — consume real productivity gains. Jim Delaney named it in 2025: “The gap between what AI can technically do and what the business can tolerate creates friction that can be thought of as a Trust Tax. The promised leverage is consumed by oversight” [8]. Recent Philosophy & Technology work sharpens it: automation bias is not simply overreliance — it is a redistribution of authority organizations must consciously redesign [11].

Skip the redesign and the work appears to flow while latent risks accumulate, until an error exposes the gap and the executive team is suddenly very interested in what the AI was doing all along. The migration is not a failure — it is the predictable behavior of a constraint system under pressure.

The Three-Person Company That AI Turned Into Ten

The clearest version lives in a story — a composite drawn from patterns seen across multiple early-stage B2B SaaS companies. The org chart is illustrative; the dynamics are not.

Three founders. Strong product. Their binding constraint is demand generation — not enough qualified pipeline, and a team too small to produce marketing content at volume. They identify the constraint correctly. They deploy AI for content, SEO, email campaigns, and outbound prospecting.

Inside 90 days they are producing roughly ten times more content at higher outbound cadence. Within a quarter, qualified lead volume is up about 4x, and they close customers at a rate they had not seen before. By the standard metric — “did AI solve the marketing bottleneck?” — the deployment is a success. Champagne, slides, the inevitable LinkedIn post.

Then the constraint moves.

The next bottleneck is not marketing production. It is implementation, because each new customer needs setup. It is customer success, because more customers mean more renewals and expansions. It is fulfillment, because feature requests surface faster. It is finance and operations, because billing, contracts, and basic compliance become real at a scale that had been invisible. The work the company was good at is suddenly bottlenecked by the work it never built capacity for.

So they hire. By month 18, they are ten people. The headcount growth is not a sign that AI failed — it is a sign that AI succeeded, unlocking growth that produced new work in every adjacent function. The roles being added are not the ones AI replaced; they are the ones AI’s success created downstream.

The example illustrates the combination: AI can both reduce roles in one area and create demand for human capacity in another, simultaneously, inside the same company. That is constraint migration plus demand expansion — Acemoglu’s reinstatement effect at the firm level. The bottleneck did not vanish; it moved downstream and enlarged the organization required to operate at the new throughput [12].

If it’s this consistent and predictable, why does it keep surprising people?

Why This Keeps Being Surprising

The answer is structural. Teams measure what they deployed AI against — code output, content produced, leads generated, tickets triaged — because those metrics are directly connected to the tool. End-to-end throughput is someone else’s number, measured after a lag, in a different reporting line. By the time the divergence shows up, the deployment has been declared a success and attention has moved on. The post-mortem rarely happens, because nothing technically failed.

Organizations also add AI on top of capability they were not using. A 2026 CXO Partners analysis of mid-market deployments found most companies use only 10–15% of the capabilities in their existing platforms [4]. The binding constraint was never that the company lacked tools — it was that it could not absorb the tools it already had. Layering AI on top only amplifies that.

The change-management gap is the underinvested constraint. WRITER’s 2026 analysis found organizations with strong change-management programs are 6x more likely to succeed with AI [5], yet 54% of executives cite cultural resistance as a top barrier [9]. Once the deployment is finished, the binding constraint is no longer technology — it is whether the organization can behave differently.

The diagnostic is simple: when the local dashboard is green and the end-to-end dashboard is flat, the constraint has migrated. The dashboards have not.

Pushback: Does AI Sometimes Eliminate Multiple Constraints at Once?

Constraint migration is not the only thing that happens. Sometimes AI does compress multiple constraints at once, and the migration story understates what AI can do in those cases.

The pushback deserves a serious response. GitHub’s controlled experiment found developers completed coding tasks 55% faster with Copilot — a narrow workflow, but one where the gain did not cleanly produce a new downstream bottleneck. McKinsey’s 2023 generative AI analysis estimated $2.6–4.4 trillion in annual economic potential across 63 use cases, lowering cost curves broadly, not just relocating scarcity. In standardized, low-stakes, modular work — content generation, basic code, data entry, structured customer service — AI can collapse several constraint layers at once, because the cost of error is low.

The conditional matters. Constraint migration holds most reliably in complex, high-stakes, or novel work — strategy, implementation, customer trust, compliance, governance — where each layer requires judgment that scales with complexity, not compute. Where errors are expensive and outcomes ambiguous, the constraint migrates to human judgment downstream, because nothing else can absorb the failure cost.

The variable is not AI’s capability. It is the failure cost of the domain. The same team running AI on a marketing blog is in one regime; running it on contract review for high-value enterprise deals, in another. The first might compress multiple constraints. The second will move them. So assess which domain you are actually operating in, not the one you wish you were.

One scope note. This piece is about constraint migration inside organizations. The same dynamic operates at the industry level — when AI commoditizes a capability that was a competitive moat, the binding constraint for the whole industry shifts — and at the labor-market level. Both are real, both worth their own treatment. This holds at the organizational layer, where the decisions are actionable.

What to Do: Mapping the Constraint Migration

The framework is short. The discipline is not.

Identify the current binding constraint before deploying AI — not the most visible pain point or the most enthusiastic use case, but the stage where queues form and downstream capacity sits idle. Measure cycle time, queue length, and wait time at each stage of your value chain first. The team that proposes the use case rarely owns the binding constraint; that mismatch produces most “efficient noise” projects.

Map the next two to three downstream constraints before relieving the current one. For each, ask what happens if throughput doubles, and which stage runs out of slack first. Validate with the people who do that work — they know what is going to break, and are often the last consulted.

Assess the Trust Tax. Legal review, compliance, auditability, human override, error-correction — throughput variables, not checkboxes. If the Trust Tax exceeds the efficiency gain, the deployment creates a new constraint instead of relieving one. Build the governance in parallel with the capability.

Plan the transition to the next constraint before the current deployment finishes. The performance valley — when the old bottleneck is gone but the new one is not yet addressed — is where most deployments get read as failure. Set a trigger threshold, pre-build the hiring or redesign, and communicate the expected migration, so the dip is anticipated rather than read as proof the technology does not work.

Measure end-to-end throughput, not local AI efficiency. A large gap between the two is the diagnostic that the constraint has migrated; local metrics are leading indicators, not the headline measure.

You probably already have an instinct for one binding constraint in your business. The next two are the ones you have not mapped yet — and mapping them before deployment is the difference between constraint migration as a managed staircase and as a serial surprise. The staircase compounds. The surprise erodes the political capital that would have funded the next deployment.

Before the Next Deployment

One move for this week, before the next deployment: name the binding constraint it is meant to relieve — out loud, in writing, the constraint and not the use case. Then name the next two constraints that will become binding once the first is relieved. If you cannot, that is your answer about whether you are ready to deploy.

AI does not create a world without bottlenecks. It creates a world where bottlenecks migrate faster.

The old question was whether AI takes jobs or makes them. The new one is whether your organization can move as fast as the constraint does.

References

AI strategyAI transformation
About the author
Héctor Reinoso writes about how organizations should be designed when intelligence becomes abundant. He works on enterprise AI adoption inside a large industrial organization, after 25 years as a strategy consultant and transformation executive across four continents. Harvard MBA, industrial engineer, and still writes the code he writes about. More →
Continue reading
Org Design · Oct 2, 2026

When Coding Gets Cheaper, the IT Handoff Gets Harder to Justify

If your supplier uses coding agents while you still specify and verify the work, it is time to reconsider what you are outsourcing.
Org Design · Sep 26, 2026

The Myth of the 50-Agent Founder

The fantasy of a solo founder running a company with 50 agents misunderstands what agents do to cognitive load.
Org Design · Sep 24, 2026

When Time Collapses, What Breaks First?

Time was an invisible governance system in organizations, not just a constraint.
Org Design · Sep 18, 2026

The More Abstract the System, the Harder It Is to Fix

Abstraction is how organizations scale: metrics replace direct observation, processes replace individual judgment, dashboards replace frontline presence.
Strategy · Aug 11, 2026

Compute Is Not Free Lunch

Don't ask what AI costs — ask what your people can do with it.
Strategy · Aug 3, 2026

The Fixed Pie Fallacy

When AI collapses execution cost by 10x, the rational response is not to do the same work with fewer people — it is to do dramatically more work.