[Bottleneck Shift] When Code Is Nearly Free, Where Has the Bottleneck of Software Engineering Gone? The Transformation of Software Engineering in the AI Era — Learn AI Slowly #173
When Code Is Nearly Free, the Bottleneck Shifts to Requirements, Integration, Validation, and Alignment
When code production becomes nearly free, the bottleneck in software delivery shifts away from “writing code” to: defining the right problem, assembling fragments into a working whole, verifying it’s actually correct, and aligning the organization. This is a replay of the Theory of Constraints in software engineering. Manufacturing walked this path 40 years ago: whenever one step became cheaper, the bottleneck didn’t disappear—it simply moved to the next most expensive step. Understanding this explains a common puzzle: AI coding tools are deployed company-wide, code writing is clearly faster, yet delivery speed hasn’t meaningfully improved.
A CIO from a manufacturing conglomerate showed me his data from the past six months. His IT team—80+ people—fully adopted AI coding tools. On code output alone, per-engineer commit volume and merge speed increased by over 30%. But the business side felt nothing close: a small intelligent scheduling feature still took three months minimum from立项 to launch. He expected a 2x speedup—instead, he only bought “faster code writing.” His blunt summary: “I spent millions on licenses, and all I got was developers busier and business teams more impatient.”
He misunderstood where the bottleneck was. His real bottleneck was something else: every new feature had to pass through MES, ERP, quality inspection systems, shop-floor terminals, plus a set of regulatory reporting pipelines—integration and debugging consumed most of the schedule; meanwhile, AI-generated code faced no formal gatekeeping step between itself and production. No matter how fast the code was written, it was still just lining up behind the wrong bottleneck.
I. What Manufacturing Knew 40 Years Ago: Bottlenecks Move
To understand today, first put on a pair of glasses worn by manufacturing for four decades.
In 1984, Israeli consultant Eliyahu Goldratt, a physicist by training, wrote a novel called The Goal, about how a plant manager on the brink of bankruptcy rescued his factory. The entire book boils down to one sentence: A system’s throughput is determined by its narrowest constraint—the bottleneck.
Widening non-bottleneck steps adds nothing to overall output; only widening the bottleneck itself makes the whole system faster. And as soon as you widen the bottleneck, it immediately shifts to the next narrowest point. This is the Theory of Constraints (TOC).
After 40 years of automation in manufacturing, the history has essentially been a story of “bottleneck relocation.” When CNC machines made cutting cheaper, the bottleneck shifted to tool changeover and quality inspection; when flexible production lines sped up tool changeover, the bottleneck moved to scheduling and supply chain coordination; when MES improved scheduling accuracy, the bottleneck surfaced in demand forecasting and cross-factory dispatching. Every time one segment is automated, the next one rises to the surface. Automation never eliminates bottlenecks—it merely relocates them. This rule is not exclusive to manufacturing. In July 2026, on the a16z podcast Software in the Age of Agents, former Microsoft Windows president Steven Sinofsky arrived at the same conclusion using enterprise software as an example. His exact words: > “The long tail got no shorter. It just got longer in a different way.”
He cited Amazon’s customer service: eliminating phone lines and having chatbots directly reship products seemed to save labor—but instantly triggered a backend demand for root-cause analysis (“How do we prevent this from happening again?”), far more complex than taking calls. The expense reimbursement process is the same: after OCR auto-posts invoices, finance teams shift from “data entry” to optimizing travel performance and dynamic price comparison. The work didn’t vanish—it moved up from “input” to “analysis and decision-making.” A Microsoft veteran and a16z partner, without invoking Goldratt’s theories, reached the same conclusion as manufacturers did 40 years ago. One came from the factory floor, the other from enterprise software—two independent paths converging on the same law.
But we must qualify this law, lest it be mistaken for absolute truth. Some jobs have been permanently eliminated: typists, telephone operators, typesetters—these roles didn’t “move up”; they vanished. The key to distinguishing whether a job gets relocated or erased lies in whether automation-generated surplus capacity spawns new demand (economics calls this the Jevons Paradox), or merely shrinks the original demand. Most work surrounding enterprise core systems falls into the former category: the faster you process accounts, the more granular and numerous the analyses executives demand. Thus, the conclusion here isn’t “how many tasks automation eliminates,” but rather “how to shift people and budgets from the automated layer to the newly emergent one.” (For a full exploration of this long-tail relocation from an enterprise software perspective, see the companion piece, “Enterprise Software Stickiness.”)
This is closer to software than you think. In 2013, Gene Kim transplanted Goldratt’s factory story almost verbatim into IT operations, writing The Phoenix Project: how a CIO used the Theory of Constraints to rescue an IT department on the verge of sinking the entire company. So, “viewing software through the lens of manufacturing bottlenecks” is a validated path—not a makeshift metaphor.
# II. Back to Software: Writing Code Is Becoming the Cheapest Link Three numbers clarify why the cost of code production is trending toward zero.- Copilot: GitHub’s own research found that in files with Copilot enabled, approximately 46% of the code is generated by Copilot. Note the metric: this is the percentage within enabled files, not 46% of all code on GitHub.
- Stripe: Their internally developed coding agent, “Minions,” produces and merges over 1,300 PRs per week (up from 1,000 early on). A critical detail to remember: every PR undergoes manual review before merging. Stripe automated the “writing,” but kept the “approval” in human hands—a point we’ll revisit in Section 4.
- NVIDIA: Jensen Huang has publicly stated that 100% of NVIDIA engineers use AI coding tools like Cursor; “not using AI” is no longer acceptable at NVIDIA.
Stack these three numbers together, and the conclusion is undeniable: the unit cost of producing a line of code is rapidly approaching zero. The sharp question that follows: if writing code is nearly free, why are software products still so expensive, slow, and hard to deliver? The answer lies in the Theory of Constraints: you’ve widened the “coding” bottleneck—but the bottleneck didn’t disappear. It just moved. Where to?
3. The Bottleneck Has Moved to Four Places
This time, the bottleneck is concentrated in four stages—each one AI cannot overcome in the short term.
First: Defining the Right Problem.
AI can write “the feature you said you wanted” in seconds—but it cannot write “the feature you actually need.” Most software projects fail because what gets built goes unused; the core issue is never properly understanding the problem to solve in the first place. As code production becomes cheaper, the most scarce—and most valuable—skill becomes: turning a vague business pain into a clear, solvable, and worth-solving specification (problem formulation). Manufacturing peers know this well: if your process flow or engineering drawings are wrong, no matter how efficiently your workshop runs, you’re just mass-producing scrap.
Second: System Integration.
AI excels at generating “a piece of code,” “a function,” or “a webpage.” But a production-ready system is an integration of hundreds of such fragments—they must exchange data, handle edge cases, maintain consistency, and withstand failures. Generating fragments is cheap; assembling them into a reliable whole is expensive. This cost stems from organizational and architectural alignment—the very issues Conway’s Law and Team Topologies address (see the first two posts in this series). Return to the manufacturing CIO from the opening: his timeline didn’t burn on writing code—it burned on integrating MES, ERP, quality inspection, and reporting systems.
Third: Validation. Code volume has exploded, and reliability is uneven. Who decides “it’s correct”? Testing, code reviews, observability, canary releases—these “validation” efforts have grown in weight, not diminished. This is the most underestimated bottleneck, and the deepest mirror of manufacturing principles. Covered in detail in Section 4.
Fourth: Organizational Alignment. When AI agents join the team, who decides what to do, who reviews it, and who is accountable for the outcome? This is an extension of Conway’s Law and team topologies—organizational alignment itself has become the bottleneck. Series Part 11 will delve into this: when organizational nodes are no longer exclusively human, governance becomes a core competency.
# IV. The Deepest Cut: Validation, and What Toyota’s “Jidoka” Really Teaches UsOf the four bottlenecks, validation is the most frequently misunderstood. Many assume it means “since AI writes fast, just run more tests.” That’s only half right. To understand why validation is becoming more expensive, we must first correctly unpack the most misquoted—and most misapplied—concept from Toyota: Jidoka.
Let’s correct a widespread misconception first. Jidoka is not “replacing humans with AI or machines,” nor is it “turning humans into machines that work nonstop.” Both interpretations are fundamentally backwards.
The word “jidōka” itself holds the answer. In Japanese, “automization” (自動化) means ordinary automation, but Toyota deliberately uses “自働化”—the character “働” includes the “person” radical, emphasizing “automation with a human touch.” Its precise meaning is: When a machine or production line detects an anomaly, it automatically stops, prompting a human to intervene and resolve the root cause before resuming production. Two mechanisms operate in parallel: machines are equipped with built-in anomaly detection and halt themselves; any worker on the line who spots an issue can pull the andon cord, instantly stopping the entire line. Quality isn’t checked at the end—it’s embedded in every process and resolved on the spot.
Here’s a counterintuitive conclusion that directly maps to software: The deeper the automation, the more critical quality checkpoints and human intervention become. Jidōka liberates humans from repetitive tasks and repositions them squarely in the role of detecting anomalies, stopping the line, and resolving root causes. Toyota grants frontline workers the authority to halt the entire production line precisely because it understands: no matter how advanced automation becomes, someone must be empowered to stop it when something goes wrong. This is the true meaning behind the slogan “empowering robots with wisdom”: giving machines the ability to stop and call for human help. Humans remain present—not to operate, but to solve the root cause.
Software is racing down this same path—and doing so urgently. GitClear’s research on AI-assisted code quality has observed signs of increasing duplicate code blocks and rising short-term churn: AI writes fast, but also writes code that “looks right.” When vast amounts of code are never manually line-by-line written, the traditional trust mechanism of “developers just know” breaks down. What you need now is the software equivalent of an Andon cord and stop-the-line mechanism:
- Testing (unit, integration, end-to-end) upgrades from “try to do” to a hard gate: no merge unless it passes.
- Code review shifts focus from “checking style” to “checking intent and boundaries”: What is this code actually trying to solve? Are edge cases covered?
- Observability (monitoring, logging, tracing) becomes standard, because runtime behavior speaks louder than code itself.
- Gray releases / feature flags let AI-generated code be validated at small scale first, and only then rolled out broadly.
Looking back at Stripe’s 1,300 PRs in Section 2: the writing is automated, but the merge gate is entirely reserved for human review. This is the living embodiment of jidoka in software: automate production, but keep validation in human hands—and empower humans with the authority to “stop it.” Production has become cheaper; quality control has become more expensive. This has been an unchanging rule for 40 years.
Five: The Premium of “Problem Definition”—A Skill More Valuable Than Prompting
If validation is the underestimated bottleneck, “problem definition” is the severely undervalued capability. Prompt engineering had its moment in the spotlight, and many now assume that “being good at writing prompts” is the core skill. But prompts are merely the technique for expressing a problem. The truly scarce skill lies one step further: problem formulation—taking a vague business pain point and breaking it down into a clear, solvable, and worth-solving problem. AI cannot do this in the short term, because it must wait for you to first tell it, “What is the problem?”
Manufacturing veterans feel this most acutely. If an engineering blueprint or a production process is misdefined, no amount of downstream efficiency can prevent mass-produced errors. The same applies to software: if requirements are wrong, AI will help you build ten times as many things nobody wants.
Here’s a simple litmus test: Stop competing on coding speed. Start honing problem decomposition clarity. In organizations, this means formally establishing roles for “requirements definition” and “validation & acceptance”—don’t let developers handle them as side tasks. Once AI makes implementation cheap, these two roles see the steepest rise in return.
Six: What Real Bottlenecks Look Like Across Four Industries
Applying the “bottleneck shift” to four industries, the real constraints lie nowhere near coding.
Manufacturing. The central figure is the CIO introduced at the start. Functions like intelligent scheduling, quality traceability, and energy consumption optimization are technically straightforward—many models are already available. The bottleneck lies in integrating and debugging across MES/ERP/quality inspection/reporting systems, and in on-site validation at shop-floor terminals. Code for such projects is often written quickly, but integrating with MES/ERP systems consumes several times more time than coding itself. Only by placing acceptance testing directly at the shop-floor terminals and integration points can defects be caught on the spot, rather than surfacing only after production launch.
Telecom / Service Providers. A single package change or enterprise dedicated line activation must traverse multiple domains: channels, billing, CRM, network provisioning, and field scheduling. AI has accelerated development within each domain, but end-to-end cross-domain integration and consistency validation remain the dominant time sinks. Telecoms face a unique bottleneck: compliance and reconciliation. A billing discrepancy of even one cent is an incident—validation carries heavier weight than in any other industry. For enterprise dedicated line activation, while AI speeds up development in each domain, end-to-end integration plus billing reconciliation still often consumes over half the total project timeline.
Finance. Adjusting a credit risk control or anti-money laundering rule spans across apps, core systems, risk engines, data platforms, and regulatory reporting. The validation weight here is extremely high—one mistake can trigger a compliance incident. The bottleneck lies in explainability, auditability, and traceability: no matter how accurate AI-generated rules are, if they can’t answer the regulator’s question, “Why was this decision made?”, they won’t go live. Anti-money laundering rule iteration is a classic example: AI accelerates rule writing, but the combined time for model explainability reviews and regulatory alignment often consumes over half the entire cycle.
E-commerce. A promotion or big-sale feature spans product, transaction, marketing, warehousing, and customer service. AI enables rapid generation of pages and APIs, but the bottleneck shifts to stress testing, inventory consistency, fraud prevention (anti-scalping), and reconciliation. Systems crash during big sales not because code was written slowly, but because edge cases were never validated. Preparing for a big sale is a microcosm: AI can generate promotional pages in seconds, yet end-to-end stress testing and inventory consistency validation often consume the majority of prep hours.
The common thread across four industries is clear: AI accelerates “writing,” but bottlenecks lie in “assembling, validating, and aligning.” Redirecting the saved development capacity toward these three areas is where real efficiency gains lie.
7. What Happens When You Get It Wrong: Three Most Common Mismatches
First: Equating “writing code fast” with “faster delivery.”
This is the most common illusion. Code is merely one link in the delivery chain; widening it won’t speed up the entire chain—it only piles up more unfinished work downstream. Constraint Theory calls this inventory; in software, it’s unreviewed PRs and untested branches. The result? Developers are busier, business teams are more urgent, but output stays the same—exactly the situation of the CIO mentioned at the start.
Second: Speeding up production while dismantling quality gates.
This is a classic violation of Jidoka. Some believe, “AI writes code fast and well, so we can simplify code reviews or cut testing.” Quite the opposite: the faster production becomes, the tighter you must pull the Andon cord. Removing验收 gates is like running a production line at full speed with no one watching—defects flood into production at an accelerating rate.
Third: Throwing money at non-bottlenecks.
Integration is the bottleneck, yet you buy more AI coding licenses; validation is the bottleneck, yet you hire more developers. Constraint Theory has long made this clear: investing in non-bottlenecks contributes zero to overall throughput—and only makes the financials look worse. The correct sequence? First identify the bottleneck, then direct all resources to it.
VIII. Implications for Decision-Makers
Insight 1: Before buying tools, draw a bottleneck map first.
Break down your last three stalled deliveries: where did the time actually go? Was it stuck in writing code, gluing components together, lacking reviews, or unclear requirements? If you can’t label it, you’re just guessing at the tech layer. A bottleneck map is worth more than any tool procurement list—it can prevent at least half of large enterprises’ ineffective IT investments.
Insight 2: Reinvest saved capacity into requirements and validation.
AI makes development faster, meaning you now have bandwidth to reallocate. Formally assign those people to “requirements definition” and “validation & acceptance” roles—don’t let them keep writing more code. The ROI for these two roles is rising fastest in the AI era.
Insight 3: Install an Andon cord in your software.
The most direct implementation of autonization is setting hard gates in your CI/CD: no merges unless tests pass, reviews must check intent and edge cases, gray releases must start small, and observability must be standard. The more automated production becomes, the tighter this gate must be—it prevents “free code” from becoming “free accidents.”
Insight 4: Reposition people, don’t remove them.
Autonization leads to one conclusion: the deeper the automation, the more critical humans become in roles of judgment, validation, and root-cause resolution. Free people from repetitive tasks and redeploy them into validation and alignment—this is the core organizational design move of the AI era, and the focus of the next few posts in this series.
Nine: You Might Be Wondering
“We’re just piloting AI locally—why do we need to map the entire company’s bottlenecks?”
Even pilots must start with clarity: Is the环节 you’re piloting AI on actually the bottleneck? If the real constraint lies in integration or validation, piloting AI on “code writing” means throwing money at the wrong spot—exactly the third mismatch described in Section 7. Do a small-scale bottleneck diagnosis first; only then will your tool investment be worthwhile.
“Will the validation gate slow down delivery?”
Short-term friction? Yes. Long-term acceleration? Absolutely. Speed without validation isn’t speed—it’s rushing defects into production, where rework costs start at 10x. From automation experience: fixing a defect on the spot costs a fraction of fixing it downstream.
“How does this relate to our AI transformation?”
Directly. The most common pitfall in AI transformation is assuming the bottleneck is in “code writing” or “capacity,” then buying tools to widen that single link. First diagnose the bottleneck—then decide where to spend. That’s why I placed “capability assessment” and “value scenario identification” early in the AI Transformation 7-Step Coaching Framework: Identify the bottleneck before talking about tools.
Reverse self-check (don’t sugarcoat your answer): The last time you got stuck delivering, where did your time actually go—writing code, or piecing things together, validating, and aligning? Of all the code your AI tools generate, how much is actually stable, deployed, and actively used by real users? In your CI/CD pipeline, is there a hard gate that blocks merges if tests fail? If you feel uneasy about even one of these three, don’t rush to buy more AI tools—first, find your real bottleneck.
Next Steps
This is the third of 15 posts in the series “The Transformation of Software Engineering in the AI Era.” We’ve moved from Conway’s Law (organization determines architecture) and Team Topologies (how to design teams) to bottleneck shifts (when code is nearly free, where does the bottleneck go?). The next post (No. 4) shifts to a more practical lens: how to choose mainstream AI coding tools. But the conclusion may be counterintuitive: tool selection is ultimately an organizational decision—choose based on your maturity and governance level, not on “whose code looks coolest.”
Series Note: This series will continuously track the latest evolution of AI coding tools, organizational structures, and software engineering paradigms—such as how Conway’s Law may evolve in the age of AI agents by 2026, or the maturity of emerging tool ecosystems. Follow this series for ongoing insights.
About This Series
“The Transformation of Software Engineering in the AI Era” is a 15-part in-depth research series written for CIOs, CDOs, CTOs, and digital transformation leaders in telecommunications, finance, manufacturing, e-commerce, and other industries. Grounded in 200+ academic papers and industry reports, it provides evidence-labeled decision-making references.
I am a former IBM engineer and ICF-certified coach who has delivered AI and digital transformation projects for telecom operators and large enterprises. What you read here are hard-won, field-tested judgments from walking alongside companies through their real-world pitfalls.
Sources (All Verified)
a16z (2026). Software in the Age of Agents. The a16z Podcast. (Steven Sinofsky, former President of Microsoft Windows, delivers the key insight: “The long tail got no shorter, it just got longer in a different way”—independently corroborating the TOC bottleneck migration law from an enterprise software perspective; primary source—original podcast audio. Position noted: a16z partner / former Microsoft executive, VC stance. Guests verified: a16z Enterprise partner Seema Amble, former Microsoft Windows President Steven Sinofsky (board partner), a16z writer Elena Burger; aired July 2026.)
Goldratt, E. M. (1984). The Goal: A Process of Ongoing Improvement. (Original source of Theory of Constraints (TOC); primary source; novel set in a manufacturing plant.)
Kim, G., Behr, K. & Spafford, G. (2013). The Phoenix Project. IT Revolution Press. (Directly transplants Goldratt’s TOC into IT operations—bridging manufacturing to software; primary source.)
Toyota. Toyota Production System — Jidoka (自働化). toyota-global.com (Jidoka = automation with a human element; involves stopping the line on anomalies + human intervention to resolve root causes; Andon system; primary source.)
GitHub (2022/2024). The Economic Impact of the AI-Powered Developer Lifecycle. (Copilot enables ~46% of code completion within files; metric defined as “enabled within file”; primary source.)
Stripe (2025/2026). Minions: Stripe’s one-shot, end-to-end coding agents. stripe.dev/blog; InfoQ reports 1,300+ PRs weekly, fully manually reviewed (primary + secondary source.)
NVIDIA / Jensen Huang. Public statements affirming that 100% of engineers use AI coding tools like Cursor. (Firsthand testimony.)
GitClear (2025). AI-Assisted Code Quality Research. (Observes increased duplicate code and short-term churn under AI assistance, supporting the claim that “validation is becoming more expensive”; secondary source.)
Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate. IT Revolution Press. (Delivery performance is determined by culture, flow speed, and feedback—not individual coding speed; primary source.)
buymeacoffee
