The Moving Bottleneck

Section 01The Claim That Generation Is Scale

On April 24, 2026, Semafor reported that Google CEO Sundar Pichai said 75% of the company's new code is AI-generated. The Semafor article does not give the setting of the remark. The Decoder reports that it came in a Pichai blog post, and says that the company describes the code as generated by AI and then reviewed by human developers. The blog post itself was not retrieved for this paper, so the figure is cited as reported. Paper 81 examined the same claim and asked where the cost of that shift went.

The claim carries an unstated assumption: that the amount of code an organization produces is the amount it can ship, support and be accountable for. If that held, generating more code would be scaling. This paper tests the assumption against each era in turn, beginning with a definition of the thing being claimed.

Section 02Scale Is a Ratio

To scale is to grow output without growing cost in proportion. An organization that doubles its output by doubling its headcount has grown. It has not scaled. The ratio is the point, and the ratio is set by whichever step in the chain of work is the most limited.

That idea is old and general. The Theory of Constraints, introduced in Eliyahu Goldratt and Jeff Cox's The Goal (1984), holds that a system's throughput is limited by at least one constraint, so overall throughput rises only by increasing flow through the constraint. Gene Amdahl's 1967 paper, reprinted in IEEE SSCS News in 2007, argues that sequential work caps the throughput gained from faster processing, the idea later called Amdahl's law. Both are used here as analogies. They do not prove anything about software organizations. They name the question to ask.

Section 03Era 1: The Constraint Is Authorship

In Era 1 the primitive is code written by people, and the outcome is settled by determinism: the same code and the same input are meant to give the same result. That property is valuable, and it is the reason the era scaled as far as it did. It has a cost. A procedure is written for one situation. In the words of MindAptiv's Visual Primer, it is predictable, but it is only one way to do the thing, and when the situation changes people rewrite it.

Output in this era therefore grows with the number of people who author and maintain procedures, and with the coordination between them. Frederick Brooks's The Mythical Man-Month (1975) is the classic account of why adding people does not add output in proportion, and it states what is known as Brooks's law: adding people to a late software project makes it later. The constraint is authorship, and its cost is paid in people.

Code also has to be built, tested, packaged and deployed before it runs, and maintained afterward as languages, dependencies, operating systems and hardware change. Teams carry that work in continuous integration and delivery (CI/CD) toolchains, and the cost recurs with every change to the code. MindAptiv's Elevate page describes the same dependence from the other side: logic written in code is language and toolchain dependent, tied to runtime environments, and requires rewriting or recompilation to adjust.

Governance in Era 1 sits around the code: reviews, tests, change control and audits applied to what people wrote, and to what ran afterward. That arrangement was workable partly because authorship was the limiting step. Nothing arrived faster than a person could write it, so a person could usually read it.

Section 04Era 2: The Constraint Moves to Verification

In Era 2 a model generates the procedures, and the outcome is settled by probabilism: the output is drawn from a distribution and can differ between runs. Generation becomes cheap, which removes the Era 1 constraint. It does not remove the need to know that what was generated is correct, permitted and maintainable. Each output is a new object that has to be checked after it exists.

The evidence on where the constraint lands is recent and uneven, and it is set out here with its limits.

• Review as the named bottleneckA 2026 report from Qodo, fielded by Censuswide from August 7 to 14, 2026 among 500 U.S. developers and 300 U.S. engineering leaders, and announced in a press release dated September 23, 2026, reports that 26% of each group ranked reviewing and validating AI-generated code as the top bottleneck. Qodo's own page also reports that 89% of organizations had experienced an AI-related production incident, and that only 3.7% of engineering leaders say their existing processes are sufficient for quality and governance as agents take on more work. Qodo describes itself as an agentic code review platform, the responses are self-reported, and the sources do not state a margin of error.
• Throughput up, stability downThe 2025 DORA report, drawing on nearly 5,000 technology professionals, observes a positive relationship between AI adoption and delivery throughput and a negative relationship with delivery stability. It states that without robust control systems an increase in change volume leads to instability. The page gives no effect sizes.
• More changes, flat company metricsA report from Faros AI states that engineers merge 98% more pull requests with AI tools while review time rises 91% and company metrics remain flat, across about 10,000 developers on 1,255 teams. Faros sells a platform for observing and governing AI coding, and the page does not give a publication date.
• Individual speed, unsettledA 2025 randomized trial by METR of 16 experienced open-source developers on 246 tasks found that allowing AI increased completion time by 19%. The developers had forecast a 24% reduction. On February 24, 2026 METR described a later study of 57 developers and more than 800 tasks, in which the estimated speedups were 18% for returning developers and 4% for new ones, with confidence intervals that include zero. METR calls that data a likely bad proxy for the real effect, because developers declined to work without AI, and it states that it believes developers are likely more sped up by AI tools now. The 2025 slowdown is therefore not a current finding.

These sources differ in design, size and interest, and no one of them settles the question. Qodo, DORA and Faros point the same way on one narrow matter: more generated code did not translate straight into more delivered capability, and the step that absorbed the difference was checking. METR points to a separate matter, individual speed, which it now believes has probably risen. That does not conflict with the argument. A faster individual step is the Era 2 case of speeding up a step that is not the constraint. An O'Reilly Radar essay by Archana Rao and Gaurav Savla, published July 16, 2026, reaches a close conclusion from the productivity research: the ceiling is not code authoring speed, and it never was.

Generated code does not skip that pipeline. It is still code, so it is built, tested, packaged, deployed and maintained through the same toolchains as hand-written code, and more of it means more traffic through them. The pipeline is one more place where the queue can form behind cheap generation.

The reason verification cannot simply be automated away is structural, and it is this paper's own argument. If the output is a draw, every draw has to be checked after it exists, and checking is detection. Paper 85 sorted public AI-safety responses by what they act on and found nearly all of them to be detection and containment. The series doctrine, Detection ≠ Determination, applies: a system that finds problems after the fact is limited by how fast it can find them. See also Paper 42, The Verification Tax.

Section 05Era 3: Where the Constraint Would Sit

In plain terms. If people state what they want and the system already knows how to do it safely, the slow steps of writing and checking code mostly drop away, and the slow step becomes stating the want clearly. That is a hypothesis, not a result.

This section is a hypothesis. No organization has been shown to scale in Era 3, and MindAptiv's technical documentation states that only one part of the platform, a GPU optimization tool, runs publicly today. What follows reasons from the design to where the constraint would move. It is not a result.

In the design, the person supplies intent, and Synergy® resolves it to Meaning Coordinates. MindAptiv's account, set out in Paper 87, is adaptive determinism: the same intent resolves to the same governed result, and the execution underneath adapts to the machine. Five consequences follow if the design holds, and each can be examined.

• Authorship per situation would fall awayThe Visual Primer describes software as normally written for the kind of machine it will run on, and Essence as deciding at the moment of running. If one statement of intent serves many machines, the Era 1 cost of rewriting for each situation does not recur. For one part of the platform there are measurements. The Chameleon page reports one executable, with no code changes, running on Nvidia Tesla T4, A10G, A10 and A100-SXM4-40GB GPUs on AWS, OCI and GCP, and on AMD Radeon 8060S integrated graphics at Rowan University's Digital Engineering Hub. It describes AWS and Rowan as independent validators and the OCI and GCP results as tracked. The measured quantities are speed and energy, and MindAptiv publishes them, so they support portability without a rewrite and do not measure the human effort saved.
• Knowledge would be encoded once, not inferred each timeIn MindAptiv's account, once an Aptiv Spec has been created, Essence has what it needs to do what is asked. It does not rely on training data or on inference at the moment of the request. That differs from both earlier eras. In Era 1 a person writes the procedure for each situation. In Era 2 a model produces an answer from patterns in its training data each time, which is why each output has to be checked. In the design, the knowledge is captured in the Spec once and applied the same way afterward. The Spec is not free of inference. MindAptiv's documentation on generating Aptivs describes the Assimilator as an eight-phase pipeline that uses LLM agents together with deterministic validation gates, requires every finding to cite a source, and sends anything that fails a gate to human review. The inference happens when the Spec is created and checked, not when it is run. This is the basis for the next consequence. It also relocates work: the Spec has to be created from authoritative source material, so the quality of that material and of the Spec becomes a place where a constraint can form. The claim is a statement about the design, and the public evidence for it is limited to the one part of the platform that runs today.
• For some workloads, the primitive would not pass through a build and release pipelineIn Era 1 and Era 2 the primitive is code, and code is processed through CI/CD toolchains and then maintained. MindAptiv's documentation on modes describes two postures, chosen per workload. In scan-ready mode the output is a static artifact that behaves like conventional software, and the CI/CD page says it flows through standard toolchains, with version control, build, static analysis, SBOM generation and signing applying as they do today. In adaptive mode the workload runs under governed runtime, and the [.wv] format page says a stream needs no external build step and can be updated without rebuilding or redeploying the surrounding system. The claim here therefore applies to adaptive workloads only, and it relocates work without removing it, because the modes page says adaptive mode requires policies to be authored and monitoring pipelines to consume runtime telemetry. There is a second exception. Code submitted through Elevate is wrapped, not replaced. The Elevate page says source code, scripts, analyzers and models keep running internally, unmodified, and that legacy code transformation into PowerAptivs is available now. The code inside such an Aptiv is still code, so whatever build and maintenance it needs remains with its owner. The page does not describe what happens to those pipelines, and this paper does not claim they disappear. What Elevate adds is the trust boundary: nothing executes inside a [.wv] stream unless it has been validated, whatever its origin. The share of a workload that comes in through Elevate would therefore set how much of the old pipeline cost remains.
• Checking would move from each output to each scopeWhat may run is determined before it runs, against scope the customer configures and a fixed reference, the case for which Paper 75 makes. Checking is then done once per scope and not once per output. That is the structural difference from Era 2, and it is the claim most in need of testing.
• New constraints would appearThe design does not remove human work. It relocates it. People still state the intent, and the Primer says the system asks when something is unclear. People configure the scope. People author the Grok Units that map phrasing to coordinates. People supply the authoritative source material from which Aptiv Specs are created. Where approval of an action requires a person, an approval queue can form, and that would be the Era 3 version of the Era 2 review queue.

The hypothesis, stated plainly, is that in Era 3 the constraint moves from authorship and verification to the clarity of intent, the quality of the Aptiv Spec and its source material, and the quality of the scope and the fixed reference. If that is wrong, the likeliest way is the fifth consequence: the new constraints are as binding as the old ones, and the architecture only changes where the queue forms. That outcome would still be a result worth reporting.

Section 06Updates and the Software Supply Chain

In plain terms. Today a software update is code that someone has to trust. In the design, an update is a permitted change that is certified before it runs, so there is less to tamper with on the way. Some risk remains and moves elsewhere.

The section above is about cost. This one is about integrity, and it follows from the same change in the primitive. In Era 1 and Era 2 an update is code. It is built, signed, distributed and installed, and the receiver runs what arrives. The integrity of the result depends on every step and every dependency in that chain, and a change made anywhere in it reaches every consumer downstream.

Two public cases show the structure. CISA's page on the SolarWinds compromise describes malicious code delivered through trojanized updates to the Orion software. The Hacker News reported in March 2024 that a backdoor, CVE-2024-3094, had been introduced into XZ Utils versions 5.6.0 and 5.6.1 through commits to the project's repository, and that it was found by Microsoft engineer Andres Freund. The mechanisms differ. The structure is the same: a channel the receiver trusted delivered code that the receiver then executed. Era 2 adds more generated code to the same chain, in greater volume, and most defenses in that chain, such as scanning and review, act on code after it exists. That is detection in the sense of Detection ≠ Determination.

This section is a hypothesis, like Section 05. In MindAptiv's design, an update to an Aptiv is not new code to be trusted after it arrives. A codeless update is a change of intent or scope that Synergy® resolves to Meaning Coordinates, and it is certified through SecuriSync™ before it can run. The Elevate page states the rule: nothing executes inside a [.wv] stream unless it has been explicitly validated, regardless of origin. MindAptiv also states that Aptivs are not controllable by code injection or persuasion, and that SecuriSync revalidates, on timelines the customer can set, that Aptivs and users remain trusted after deployment.

If that holds, the supply chain question changes from one kind to another. In Era 1 and Era 2 the question is whether the artifact was tampered with on its way to the receiver. In the design the question is whether the change is permitted under the configured scope and certified before it runs, which is determination before execution, the case Paper 75 makes. In adaptive mode there is no compiled artifact and no dependency tree to poison in transit for an update of that kind, because the update is not code. In scan-ready mode the workload is a conventional artifact, and the CI/CD page and Trust Certification page describe the standard controls that apply to it: SBOMs, signed artifacts and provenance attestations.

• Risk that would remainCertification is only as strong as what it certifies against. The scope the customer configures, the fixed reference, the authoritative source material from which Aptiv Specs are created, and the keys and authority behind certification each become a place where integrity can fail. The design relocates the supply chain. It does not remove it.
• The Elevate exception, againCode submitted through Elevate is still code. The Elevate page says it keeps running internally, unmodified. Its own dependencies and build chain keep their Era 1 supply chain risk, and what Elevate adds is the boundary at which that code is validated before it executes. The share of a workload that arrives as code sets how much of the old exposure remains.
• StatusThe Elevate page lists SecuriSync trust enforcement wrapping and the Synergy codeless creation path as awaiting Synergy Expansion, and states that SecuriSync is in production use today. Nothing in public evidence yet shows a codeless, certified update path operating under attack.

Section 07Universal Intent and Global Markets

In plain terms. What a person wants is the same in any language. If the system works from the want, serving a new language means teaching it new ways of saying things, not rebuilding the product.

A company scales across markets only as fast as it can serve each one in the language its customers use. Where the primitive is code or generated text, that is a cost that recurs per market. In Era 1 the words in an interface, in a contract flow or in a support process are written in one language, and serving another means translating, adapting and then maintaining that version as the original changes. In Era 2 the Engage page describes frontier models as generalizing from a vast share of the world's text, trained once and centrally. That describes a mechanism in which coverage of a language follows the text available for it. This paper does not measure that, and a reader should check current model evaluations for any language that matters to them.

MindAptiv's design starts from a different premise: intent is universal, and language is only how a person expresses it. A person who wants to insure a crop, move money or give consent has the same intent in Wolof, Hausa, Swahili or English. In the design, Synergy® resolves each expression to Meaning Coordinates through Grok Units, and the governed result is determined from the coordinates and not from the words. The Engage page puts the same point as language coverage that grows without retraining: a new language adds Grok Units, not model weights. Grok Units match phrasing to a coordinate with no model inference, so the same expression resolves to the same coordinate each time.

If that holds, adding a market changes character. It is no longer a rewrite of the product for each language. It is the authoring and validation of rules that map how people in that language express intents the system already resolves. Under Engage, native speakers write those rules in plain language, the community validates and versions them, approved rules are deployed under policy without retraining or redeployment, and SecuriSync™ records contributor identity, provenance and rollback. The system is designed so that the governance behind an action is the same in every language.

• Universal intent is not universal contextThe same word can carry different commercial and cultural meaning. MindAptiv's Engage for Africa brief gives credit as an example, understood differently by a Yoruba trader and a Swahili merchant because of trust and context and not vocabulary. The design handles this by scoping matches to context and making them additive, so one community's addition does not change how another refers to something without its approval. The premise is therefore that the intent is shared while its context is governed, not that every language means the same thing by every word.
• The constraint would move to contribution and approvalEntering a new language would depend on how fast qualified native speakers can author rules and how fast the community can validate them. The Engage page says contributions are currently onboarded through direct partnership while governance and validation tooling matures. That makes the present constraint partnership onboarding, and it makes validation capacity the likely constraint at scale. This is the same pattern as in the rest of the paper: the work relocates.
• Scope still differs by marketEach jurisdiction has its own regulatory scope, and the design makes that scope customer configuration. Language does not remove it. A market that shares a language with another may still need a different scope.
• StatusThe Engage page describes a foundation MindAptiv is building with early partners, not a fully self-serve product today. The Engage for Africa brief ties rapid language scaling, which it puts at weeks and not years, to the Synergy Expansion milestone. No public measurement yet shows the effort to add a language under this design.

Section 08What Has Been Shown, and What Has Not

Section 05 notes that only one part of the platform runs publicly today. That states the shortfall and leaves out what the evidence does establish. This ledger states both, using MindAptiv's published pages, and labels each row by who recorded the result. Paper 89 sets out the standard of proof behind the labels.

The independent testing in the first rows covers the execution layer: generating instructions suited to the hardware at hand. It does not cover the governance layer that most of this paper discusses. Evidence for one is not evidence for the other. The reverse also holds: an untested governance claim does not weaken a measured execution result. The figures are published by MindAptiv, and a reader should verify them against the primary evaluation reports.

Section 09Three Eras, Compared

The table sets the three eras against the same axes. The first row uses the terms from Paper 87. The last row states how much evidence stands behind each column.

The eras overlap in practice. Paper 20 states that Era 3 does not begin by discarding Era 1 or Era 2, and a single company can sit in all three at once for different workloads. The columns describe where a given workload's constraint sits, and not what kind of company a firm is.

Section 10Locating Your Own Constraint

The practical use of the argument is a short test that an organization can run on its own work. The questions are ordered, and the first matters most.

• The goal questionWhat is the work for? A constraint is a constraint only relative to a goal. If the goal is governed output, not volume, then a step that raises volume without raising governability has not helped.
• The queue questionWhere does finished work wait? Find the step that has a backlog. That is the candidate constraint, and it is rarely the step that has just been sped up.
• The doubling questionIf output doubled tomorrow, which cost would double with it? Headcount points to authorship, review hours to verification, and approvals or configuration to a constraint of the third kind.
• The timing questionIs checking done per output after it exists, or per scope before it runs? The first scales with output. The second may not, and that is the property to test.

The test describes structure. It does not recommend a mode, and an honest answer may be that the constraint sits where it always did.

Section 11What This Paper Does Not Claim

It does not claim that any Era 3 organization has scaled, or that MindAptiv has. Sections 05, 06 and 07 are hypotheses. MindAptiv's technical documentation states that only one part of the platform, a GPU optimization tool, runs publicly today, and nothing here is a measurement of Essence® in production. Section 08 sets out what the evidence does establish.

It does not claim that Era 3 removes supply chain risk. It claims that the risk would sit in different places, and Section 06 names them. The two incidents cited there are examples of a structure, and this paper does not claim that Essence® would have prevented either.

It does not claim that intent is the same in every culture, or that Era 3 removes the cost of entering a market. It claims that the cost would move to authoring, validating and governing language rules, and to configuring scope per jurisdiction. The market-size and outcome figures on MindAptiv's Engage for Africa page are not used in this paper, because the page does not give sources for them.

It does not claim that AI coding tools do not help. The 2025 DORA report observes a positive relationship between AI adoption and delivery throughput, and METR states that developers are likely more sped up now. The sources above show that generation is not the same as delivered capability, and they do not show that generation has no value.

It does not claim that the statistics are settled. They are reported as stated on the pages cited, retrieved on October 14, 2026, and they come from sources of different kinds. Qodo and Faros AI sell developer tooling and their figures are self-reported or vendor-analyzed. METR describes its own recent data as unreliable, and its 2025 slowdown finding is superseded. The Faros page does not state a publication date, and Faros has since listed a newer report that this paper did not read. The Google figure is cited from secondary reports. A reader should verify any figure from the primary source before relying on it.

It does not claim that Era 1, Era 2 and Era 3 are strict stages or that a company belongs to one. They overlap, and the table describes workloads.

It does not claim the framing is original. Goldratt's Theory of Constraints, Amdahl's argument and Brooks's observations predate it, and the O'Reilly Radar essay cited in Section 04 reaches a close conclusion about Era 2 from different evidence. Goldratt, Brooks and Amdahl were checked against secondary descriptions and a reprint and not against the original books, so no page numbers are given. The paper's addition is to tie the constraint to the era and the goal, and to ask where it moves under determination before execution. That addition is the hypothesis in Section 05.

It does not claim that a mode, or a constraint, predicts commercial success. An organization can find its constraint and still fail, or ignore it and still thrive. Paper 87 makes the same point about mode labels.

Section 12Conclusion

Generating more is not scaling. Scale is output growing without a proportional growth in cost, and it is set by the constraint in the chain of work. Speeding up a step that is not the constraint leaves the total where it was.

In Era 1 the constraint is authorship, and output grows with the people who write. In Era 2 generation is cheap and the evidence, uneven as it is, points to verification as the step that absorbs the difference. In Era 3, if the design holds, checking happens per scope before execution, and the constraint would move to how clearly intent and scope are stated. That last step is a hypothesis, and this paper has said what would confirm or refute it. The same design would change the supply chain question, from whether an artifact was tampered with in transit to whether a change is permitted and certified before it runs. It would also change the cost of entering a market, from a rewrite per language to the authoring and governance of language rules against intents that are shared.

The practical question is the same in every era: where does finished work wait, and what would double if output did? An organization that asks it before choosing a mode is more likely to find the step that limits it. Speed ≠ Scale.