Core Argument: AI has dramatically accelerated cognitive production while leaving coordination, judgment, and context-building at human speed. The result is not acceleration but fragmentation. Bottlenecks migrate to integration points we have not designed for. The path forward requires building epistemic scaffolding, deliberate backpressure, and systems that treat human judgment as the scarce resource it has/will become.

I. The Herbie Problem

In The Goal, Eli Goldratt [1] describes a troop of Boy Scouts hiking single file. One boy, Herbie, is slower than the rest. No matter how fast the other scouts walk, the troop's throughput is governed by Herbie. You can optimise the fast hikers all you want. It changes nothing.

This is the Theory of Constraints reduced to a walk in the woods. The slowest node governs the system. Value concentrates at the binding constraint. Everything else is noise.

Now imagine you give everyone except Herbie rocket boots.

The fast scouts blast ahead. Gaps open up. The line stretches until it breaks. Herbie is still walking at Herbie speed, but now the distance between him and the scout ahead is a hundred metres instead of two. The troop hasn't accelerated. It has fragmented.

This is roughly what we have done with AI.

II. The Asymmetric Acceleration

We have dramatically accelerated certain cognitive operations—generation, pattern matching, synthesis, first-draft production—while leaving others at human speed. Judgment. Trust-building. Context accumulation. The slow nodes are still slow. But the gap between them and the fast nodes has widened in ways that break existing workflows.

The result is not the acceleration we expected. It is the migration of bottlenecks to places we have not designed for.

III. The Merge Conflict as Microcosm

I now run multiple AI agents working on the same codebase using git worktrees. This allows parallel feature development. Agent A builds the authentication module. Agent B builds the reporting dashboard. Agent C refactors the database layer. In theory, this is three times the throughput.

In practice, it creates merge conflicts—not just syntactic conflicts that tooling can resolve, but semantic ones. Agent A assumed the user table had one shape. Agent C changed it to another. Agent B built reports against the old schema. When these branches converge, the conflict is not "which line of code wins." The conflict is "which architectural assumption wins, and how much dependent work must be thrown away."

The resolution requires something AI does not have: the accumulated context of why certain choices were made, which constraints are negotiable, what the downstream consequences are. That knowledge lives in my head, built up over time. The merge conflict is the visible symptom. The invisible cost is all the work that must be re-specified and regenerated once I pick a direction.

An objection presents itself: could these constraints not have been specified earlier? Surprisingly, no. As a system takes shape, domain constraints and architectural choices emerge through the building process itself. They did not exist in the spec because I did not think of them when writing the spec. The happy path is how all specifications start with obvious edge-cases. The sharper edges surface as we build. The spec reshapes. There are now multiple happy paths and some paths we never want to tread. Some of this discovery happens during v1; some when users arrive; some at scale; some when users with competing interests demand features.

Case Study: The Literature Review System

How a simple status field cascades into architectural decisions

When I was creating the front-end design for a literature review system, I had to make choices on the status of the project (e.g., setup, papers-under-review-by-ai, paper-under-review-by-research-team, conflict-resolution). This opens a new choice: should we allow the research team to review papers prior to an AI review of abstracts? If so, the UI layer blocks humans from doing the work. This cascades to the database layer—the flags have to be set into the logs. Now what if an LLM call does not work and the AI committee does not finish cleanly?

Some of these questions seem like they could have been anticipated. But in reality, many are slowly figured out as we build out the system. Now there are cascading effects from front-end to middleware to back-end to logging, and specific decisions must be made on tolerance to failure. No spec anticipated these interdependencies because they emerged from the act of building.

The AI generated the code faster than I could have. But I am still the constraint. Worse, I am now a more expensive constraint, because I am resolving conflicts in code I did not write, trying to reconstruct intent I was not present for.

A caveat: software development may be an extreme case. Code has unusually high semantic interdependence—a change in one module ripples through others in ways that written documents or creative outputs do not. The merge conflict phenomenon manifests most acutely where work products must cohere structurally, not merely coexist. But the underlying principle—that accelerating production shifts the burden to integration—applies broadly, even if the severity varies by domain.

IV. The Hidden Load-Bearing Structure

J.E. Gordon, the materials scientist whose Structures [2] remains the definitive lay introduction to engineering mechanics, observes that design is "a sort of game in which we try to spot the weakest link in a load-bearing system. The more complicated the structure, the more difficult and unreliable this becomes."

AI makes systems more complicated—not by adding complexity, but by hiding it. When I write code myself, I know where the weaknesses are because I put them there. When AI writes code, the weaknesses are distributed across a surface I never fully inspected.

This observation requires qualification. Large human-written systems also have uninspected joints, and no single engineer knows every line. What distinguishes AI-generated code is the rate at which uninspected surface area accumulates and the absence of the incidental learning that occurs when humans write code slowly. When I write a function, I understand it because I wrote it. When AI writes ten functions in the time I would write one, I understand none of them at that depth. The load-bearing structure has more joints, and the ratio of inspected-to-uninspected has shifted unfavourably.

This is fine when the structure is not under stress. It becomes a problem when merge conflicts stress the joints I did not know existed.

V. The Selection Bottleneck

The merge conflict example is local, but the pattern is general. Wherever AI accelerates one part of a system while leaving another at human speed, you get the same phenomenon: backpressure, inventory accumulation, and constraint migration.

Consider front-end design. AI tools can generate ten UI mockups in the time it used to take to sketch one. This feels like acceleration. But someone still has to choose between them. A designer, a product manager, a stakeholder—some human has to look at ten options and decide.

This decision was never the bottleneck before, because generation was slow enough to match it. You would sketch one concept, discuss it, refine it, sketch another. Production speed and evaluation speed were naturally coupled.

Now they are decoupled. I can generate ten options before the meeting starts. The meeting still takes an hour. And now we spend that hour not refining one concept, but choosing between ten. The human evaluation bottleneck was hidden. AI made it visible by overwhelming it.

Worse: having ten options often makes the decision harder, not easier. Each option is plausible. The differences are subtle. The stakeholder is not equipped to evaluate nuances of interaction design. So they ask for an eleventh option that combines elements of three others. Which I can generate in minutes. Which creates an option twelve, thirteen, fourteen problem.

The constraint has not moved from generation to selection. It has metastasised. Selection was always the constraint—we just could not see it because generation was slow enough to be the apparent limit. The UI design case illustrates a principle that holds wherever production and evaluation are separated: when you can generate options faster than you can evaluate them, options accumulate rather than resolve.

VI. The Paradox of Adding Resources

Will Larson's An Elegant Puzzle [3] is an insightful book of hard-won wisdom about engineering management and captures a counterintuitive truth: "you can often slow a team down by shifting resources to it, because doing so creates new upstream constraints".

This seems wrong until you see it happen. You add engineers to a struggling team. Now more code is being written. But the architect who reviews all changes is the same person. The test infrastructure has the same capacity. The deployment pipeline has the same throughput. The new engineers pile up work that queues behind the old constraints.

AI is the ultimate case of adding resources. You have added, effectively, infinite junior engineers who can produce code, drafts, designs, and analysis at superhuman speed. But the review layer, the coordination layer, the decision layer—those are still human-scale. The queue just got longer.

VII. Flow Control and Organisational Memory

The early internet engineers understood something we have forgotten. In the development of ARPANET, documented in Katie Hafner and Matthew Lyon's Where Wizards Stay Up Late [4], the network used RFNMs—"Request for Next Message" is like a maître d' announcing "your table is ready." You could not send a continuous stream because downstream nodes could not absorb it. The system throttled itself by design.

The analogy is imperfect: networks have explicit, measurable capacity limits, while organisational capacity is tacit and negotiated. But the core insight transfers. Systems that lack backpressure mechanisms accumulate unprocessed inventory.

Modern organisations adopting AI have not built in backpressure. The AI generates continuously. The humans downstream absorb what they can and drop the rest. But "dropping" AI output is not like dropping a network packet. It is like dropping institutional memory. That draft proposal that no one reviewed? It contained a decision that will surface again in six months, and no one will remember it was already made.

VIII. The Chokepoint Problem

Consider what happens when a few people in an organisation adopt AI tools aggressively while the layers they interface with have not.

The early-adopters become translators—ironically, the very act of being an early adopter means they must slow down to communicate with others. These augmented humans can produce analysis, documentation, and proposals at high speed. But they cannot deliver them into use at high speed, because the receiving layers cannot process them. If the augmented humans send a sixty-page technical specification, the receiver must also be augmented to read it. So someone steps back and produces a one-page summary, then answers questions in a meeting, then produces the relevant excerpt, then schedules another meeting. The AI accelerated production but not coordination. The augmented early adopters must act as buffers.

Furthermore, domain expertise still enters the system through human conversation. The constraints that matter—why we cannot use that vendor, what happened the last time we tried this approach, which executive will block that proposal—live in the heads of people who communicate in meetings at calendar speed.

Tim Marshall's Prisoners of Geography [5] offers the apt metaphor that is in the new again (Jan'2026): the Strait of Hormuz, twenty-one miles wide at its narrowest, carrying twenty percent of the world's oil. Iran's strategic leverage comes not from what it has, but from what it can block. In AI-augmented organisations, humans on critical coordination paths become such chokepoints—not because we are slow in absolute terms, but because we are slow relative to AI-generated flow. Everything that requires judgment, verification, or cross-functional coordination passes through a human.

This would be manageable if the chokepoint were stable. But it is not. Different people adopt AI at different rates. Different roles have different amounts of irreducible human judgment. The person who was a steady performer becomes a bottleneck because they cannot work with AI tools. The junior engineer who can becomes load-bearing. The senior architect who built the system becomes the constraint on changing it.

In Goldratt's troop, Herbie was a known quantity. You could design around him. In an AI-augmented organisation, Herbie changes every sprint.

IX. The Balancing Loops

Donella Meadows, in Thinking in Systems [6], describes what happens to growing systems: "Any physical, growing system is going to run into some kind of constraint, sooner or later. That constraint will take the form of a balancing loop that in some way shifts the dominance of the reinforcing loop driving the growth behavior."

AI feels like a reinforcing loop. More capability leads to more output leads to more capability. But balancing loops are coming. They take the form of review queues, merge conflicts, decision fatigue, coordination overhead, and trust deficits. These loops are not bugs in the AI deployment. They are the system's equilibrium-seeking dynamics asserting themselves—the tendency of any flow-based system to develop resistance proportional to throughput when downstream capacity is fixed.

The question is whether the balancing loops will be designed or emergent. Designed balancing loops look like deliberate throttling, review gates, and scope boundaries. Emergent balancing loops look like burnout, quality collapse, and projects that ship but never work.

X. The Disrupted Equilibrium

The deeper problem is that AI has disrupted the natural equilibria that human organisations evolved over decades.

In the old equilibrium, humans worked at human speed. Bottlenecks formed, people learned about throughputs and built their own systems around them. People slowed down when queues built up. The system throttled itself through informal mechanisms: longer email response times, delayed meetings, "we'll get to that next quarter." The constraint was stable, visible, and negotiable.

AI disrupts this by injecting high-velocity work into a system with human-velocity coordination. The AI generates faster than humans can integrate. But integration is where coherence emerges. Integration is where architectural decisions get reconciled. Integration is where the tacit knowledge that makes a system hang together gets applied.

Skip integration, and you get code that compiles but does not cohere. You get proposals that are plausible but not aligned. You get decisions that are made but not coordinated.

XI. The Three Constraints

What are the actual constraints in an AI-augmented system?

The Epistemic Constraint (Constraint 1)

When content generation costs nothing, verification costs everything. Anyone can produce a plausible document, a convincing analysis, a professional-looking report. Distinguishing real from fake, correct from plausible, aligned from confabulated—that requires either human judgment or epistemic scaffolding we have not built.

Peter Zeihan, in The End of the World is Just the Beginning [7], draws an analogy to oil markets: "Any sudden change in supply or demand rapidly ripples throughout the entire system" because of price inelasticity. Epistemic credibility has a similar property. You cannot quickly spin up more warranted belief. A system's credibility balance goes negative when people stop believing the outputs; the ripples propagate everywhere and propagate chaoticaly. Every document is suspect. Every decision is second-guessed. Coordination costs spike because no one can rely on anything.

AI increases the supply of content while holding the supply of warranted belief constant. The ratio shifts. Verification becomes the scarce resource. What we need is not merely "trust infrastructure" but epistemic scaffolding. Specifically, systems that provide warrant for belief, that make the grounds for accepting a claim visible and auditable. This is the philosophical core: justified belief requires not just truth but proper grounding.

The contrast is worth noting. AI output can be accepted with minimal scrutiny only in high-trust environments. That is, where track records are established, verification mechanisms exist, and the cost of deception is high. In low-trust environments, every output must be checked. Ironically, it is AI technology that itself ends up creating this trust deterioration by flooding the zone with plausible content. The relationship is not linear: as warranted belief declines, coordination costs rise disproportionately, because each node in a decision chain must independently verify rather than rely on upstream attestation.

The Context Constraint (Constraint 2)

AI can process explicit information: documentation, code, data. It cannot process the tacit knowledge that makes explicit information meaningful.

Tacit knowledge includes: why the documentation is wrong, why that API is documented but deprecated, why that team will never approve that approach, what happened the last time someone tried this, which parts of the codebase are load-bearing and which are vestigial. This knowledge accumulates through experience. It cannot be completely or reliably transferred through prompting, though extended dialogue and iterative refinement can surface portions of it.

When I resolve a merge conflict, I am applying tacit knowledge. I know which branch represents the direction we actually want to go. I know which architectural assumptions are up for debate and which are settled. I know who will be affected by this choice and whether they will care.

AI does not know these things. So either I remain the bottleneck, or I hand off to AI and accept that the decision is (will be) made without context. Again, one can argue that if only the AI was provided the context, it can get it done. But, this is just makes my point stronger - the context was sitting as tacit knowledge and effort has not been made to make that explicit; something that only humans can do.

The Energy Constraint (Constraint 3)

The literal constraint is well documented. AI scaling has hit walls that are not algorithmic but physical: power, cooling, permitting, construction. A company can train a new model in weeks. Getting a new hundred-megawatt substation approved takes years. The bottleneck has migrated from software to infrastructure.

The organisational constraint is less discussed but equally real. All organisations have a metabolic rate. A speed at which they can digest change, make decisions, and execute. AI can produce strategies, proposals, and plans far faster than any organisation can metabolise them. The output piles up. The decision queue grows. Eventually the organisation starts ignoring proposals because there are too many to evaluate, which means the AI-generated work was wasted.

XII. Three Principles

Three principles emerge from these examples:

One: abundance in one resource creates scarcity in its complements. If AI makes content generation abundant, value migrates to whatever generation depends on: epistemic warrant, accumulated context, coordination capacity, energy. This is not a temporary adjustment. It is the new equilibrium.

Two: coordination costs scale disproportionately with epistemic deficit (knowledge gaps). In high-trust environments, you can accept AI output with minimal verification. In low-trust environments, which AI itself creates by flooding the zone with plausible content, every output must be checked, and each checkpoint adds friction. The relationship is superlinear: declining trust compounds through decision chains.

Three: specificity is the only durable advantage, though durability itself is limited. General AI capability is a race to the bottom. Everyone has access to the same models. The differentiator is specific context: this codebase, this organisation, this market, this set of relationships. Specificity resists commoditisation because it cannot be generalised (though over time, tacit knowledge does become explicit, and specific advantages erode). The competitive question is whether you can accumulate context faster than it diffuses.

XIII. The Implication

The implication is uncomfortable: you cannot introduce AI into a system without rethinking the system.

If you add AI to a workflow designed for human-speed generation, you will overwhelm human-speed evaluation. If you add AI agents to a codebase designed for human-scale coordination, you will create merge conflicts faster than humans can resolve them. If you add AI to an organisation designed around tacit knowledge transfer through apprenticeship, you will produce people who can generate senior-looking output without senior-level understanding.

The bottleneck does not disappear. It migrates. And unless you have mapped where it will migrate to, you are not optimising. You are randomising.

XIV. Redistributing the Load

The responsible path forward is not to slow down AI adoption. It is to redesign systems for the new constraint landscape.

This means building in backpressure: throttling AI output to match human evaluation capacity, accepting that generating ten options is often worse than generating two.

It means investing in epistemic scaffolding: verification systems, provenance tracking, explicit confidence intervals. If you cannot establish warrant for AI output, you cannot use it for anything that matters. The goal is not to trust AI but to make the grounds for trusting specific outputs visible and auditable.

It means protecting context accumulation: finding new ways to transfer tacit knowledge when the grunt work that used to build it is being skipped, recognising that the junior engineer who ships features with AI assistance may not be learning what they need to know.

It means accepting that humans will remain the constraint for decisions that matter, and designing systems that make that constraint sustainable rather than overwhelming.

In The Goal [1], the solution to Herbie is not to leave him behind. It is to redistribute the load. Take weight out of his pack. Put the heaviest items on the fastest hikers. Herbie still sets the pace, but the pace itself increases.

We need to do something similar with AI. Not pretend humans are not the constraint. Acknowledge that we are, and then systematically reduce the load on human judgment where we can, so we have capacity for the judgments where we cannot.

This is not a technical problem. It is a design problem. And we are only beginning to understand its shape.

References

[1] Goldratt, E.M. and Cox, J. (1984). The Goal: A Process of Ongoing Improvement. North River Press.

[2] Gordon, J.E. (1978). Structures: Or Why Things Don't Fall Down. Penguin Books.

[3] Larson, W. (2019). An Elegant Puzzle: Systems of Engineering Management. Stripe Press.

[4] Hafner, K. and Lyon, M. (1996). Where Wizards Stay Up Late: The Origins of the Internet. Simon & Schuster.

[5] Marshall, T. (2015). Prisoners of Geography: Ten Maps That Tell You Everything You Need to Know About Global Politics. Elliott & Thompson.

[6] Meadows, D.H. (2008). Thinking in Systems: A Primer. Chelsea Green Publishing.

[7] Zeihan, P. (2022). The End of the World is Just the Beginning: Mapping the Collapse of Globalization. Harper Business.