In short: Speed up coding with AI and the engineering bottleneck moves to the next least scalable step: verification, integration, operations, architecture, governance and, last, human judgment. This is Constraint Migration. In Faros AI's 2026 telemetry, median review time rose more than fivefold as coding sped up. The CTO's job is to design one stop ahead of the constraint.
Where did your bottleneck go?
Faros AI's 2026 engineering report followed about 22,000 developers across 4,000 teams as AI coding tools spread. Tasks completed per developer went up. So did the time a pull request waited for review, with the median up by roughly 441%.
The same data shows what happens when a queue has nowhere to go. Pull requests merged with no review at all rose by 31%, and the ratio of incidents to pull requests more than tripled. These are Faros's own telemetry figures, so read them as a strong signal from one vendor's dataset.
The response most organisations reach for is sensible. Review is the queue, so put agents on review. It works for a while. Then the queue reappears in the pipeline or in production, and a new programme starts there.
Most AI programmes in 2026 are optimising the stage the constraint has just left.
Why do bottlenecks move instead of disappearing?
Eliyahu Goldratt described the mechanism forty years ago in The Goal. A system runs at the pace of its narrowest step, and speeding up any other step only builds inventory in front of it. Widen the narrow step and a different one becomes the limit. The rules written to protect the old limit then start to hold the system back, a trap Goldratt called inertia.
Applied to software delivery, I call this Constraint Migration. When you relieve the constraint in an engineering system, it resurfaces at the next least scalable step, and it keeps travelling each time that step is relieved. AI is the strongest relief engineering has ever had, so it produces the most migration.
I spent fifteen years watching this happen one wave at a time, and I've Seen This Bottleneck Before tells that story. This piece is about the mechanism itself, and about where it sends the constraint next.
Where does the constraint go after coding?
The constraint travels in three directions at once. They all end in the same place.
Figure 1. Constraint Migration on the AI Engineering Production System. Relieve Build and the constraint moves downstream, upstream and across, then converges on human judgment.
Downstream, it follows the code. Verification is the first stop. In Sonar's 2026 survey of more than 1,100 developers, 38% said reviewing AI-generated code takes more effort than reviewing a colleague's, and only 48% always check AI-assisted code before committing it. Review capacity was sized for human output. It now meets machine output.
Integration and environments come next. CircleCI's 2026 report, drawn from more than 28 million workflow runs, found average throughput up 59% while median-team main-branch throughput fell 7%. Main-branch success dropped to 70.8%, its lowest in over five years. More change enters the pipeline, and less of it lands.
Operations and observability follow. New Relic's 2026 survey found 78% of teams reporting more production incidents once AI-generated code shipped. Whatever the upstream stops let through is paid for here, by whoever is on call.
Upstream, it climbs into design, intent and planning. When code becomes cheap, architecture becomes expensive. GitClear's analysis of 211 million changed lines found that in 2024 copy-pasted code outgrew moved, refactored code for the first time, with duplicated blocks up eightfold. Agents meet every unresolved ambiguity in an architecture at volume and at all hours, and they tend to resolve it by adding code.
The climb continues above architecture. In recent agentic delivery work, the hardest stop I have seen teams clear was getting intent right in the product requirements and the solution design. Agents built what the documents said. The documents lacked the context and the policies that experienced engineers used to carry in their heads and apply without being asked. Missing context turned into missing requirements, and missing policies turned into rework.
Above intent sit planning and organisation design. When too many initiatives run at once, when they cannot ship without each other, or when teams are cut across the flow of value, the constraint can sit there before a line of code is written. In those organisations faster coding moves almost nothing, which is why measurement has to cover the whole product system.
Across the system, it becomes governance. Every agent that relieves a stop is one more thing to govern. In Redis's 2026 research, governance tooling was the most-cited single barrier to production-ready agents. Sixty per cent of organisations rated themselves ineffective at governing what their agents can reach, while 58% said they were confident it was well governed. This is the input-side front of the Absorption Gap, covered in The Second Absorption Gap.
All three directions end at human judgment. Someone has to decide what the business meant, whether a change is safe, and who answers for it when it is not. At this stop, adding agents adds load, because every agent's output still needs a person accountable for it.
Why doesn't adding agents at the bottleneck fix it?
The reflex is to put an agent wherever it hurts. Review is slow, so add review agents. Tests lag, so generate them. On-call is drowning, so add an incident agent. Each move is locally rational, and each one works at its own stop.
Each move also does two things nobody budgeted for. It pushes the constraint one stop further along. It also adds a new population of agents that has to be supplied with context and governed. Constraint migration and agent proliferation are the same movement, seen from two sides.
Draw it on the AI Engineering Production System and the pattern is plain. The agent workforce spreads stage by stage, close behind the constraint, until it reaches the stop agents cannot own. The constraint arrives at human judgment carrying everything the agents produced on the way.
Figure 2. Agents follow the constraint. Each round of agents relieves one stop and hands the constraint to the next, until it reaches the one stop agents cannot own. (Simplified to the downstream path.)
Why is this faster than every wave before it?
In my own career the constraint moved six times in fifteen years. Each move needed a funded programme: a new pipeline, a test platform, an API layer, an operating-model change. The organisation had a year or two to redesign around each new stop.
Agents change that clock. Capacity can now be added to almost any stage with a configuration change and a quarter of adoption, and the constraint moves as fast as that capacity arrives. CircleCI's quarterly data gives a sense of the pace: main-branch success sat at 70.8% in its first-quarter 2026 data and 76.7% by the second. A single stop can now shift inside one quarter.
Budgets, org charts, role definitions and governance still change on an annual cycle. I call the pace at which the constraint moves migration speed, and in most organisations I see it now exceeds the speed of redesign. The result is an organisation built around last year's bottleneck. That is the Absorption Gap at the level of the operating model.
Faros adds a finding that should unsettle any mature engineering organisation. Teams with strong practices before AI saw the same quality deterioration as less mature ones. Good practice built around yesterday's constraint offers little protection against tomorrow's, which is Goldratt's inertia at a new speed.
How do you know where the constraint is now?
Stage speed is the wrong instrument. It improves most at the stage the constraint has just left, which is why local dashboards look their best at the moment the system is moving its problem somewhere else.
Start instead with where work waits: the queue time in front of each stage, from intent and design through review, integration, release and operations. Then follow the yield, meaning the share of generated change that reaches production and stays healthy. The ratio that ties them together is validated business value per unit of human intervention.
That ratio fits Constraint Migration for a specific reason. Human judgment is where every direction of migration ends, so a metric that divides by human intervention measures the terminal constraint directly. It rises when the whole system absorbs more. It stays flat when you have only moved the queue. The 30-day test in The Absorption Gap is a practical way to start measuring it.
What does a CTO do differently?
At migration speed, chasing the constraint is a race you lose. The alternative is to design one stop ahead of it. In practice that comes down to four habits.
Check the next stop before you relieve this one. Goldratt's word was subordinate: every other step serves the constraint. Before scaling coding agents, ask whether verification can absorb what they will produce. Before adding review agents, ask whether the pipeline can take the extra merges.
Retire the controls built for the old constraint. Many ceremonies, handoffs and approvals exist to ration scarce human coding time, and some of them should go. Others, around intent, policy and release, matter more than they used to, because the volume of change has risen.
Give constraint-sensing an owner. Someone should be able to say, this month, where the constraint sits and where it is heading. The job cuts across all five dimensions of MAMOS (methods, architecture, management, organisation and skills), which is why it rarely has a name or a budget.
Put redesign on the migration clock. A quarterly operating-model review tied to where work waits will beat an annual reorganisation tied to the budget cycle.
Designing one stop ahead is what turns the AI Engineering Production System from a diagram into a management practice. The map tells you where the constraint will go. The organisation still has to get there first.
The question to ask this quarter
Every AI business case promises that some stage will get faster, and most of them will deliver. The better question is what that speed does to the stop after it.
Where is your constraint this quarter, and who in your organisation would notice if it moved?
Read further
The thesis in full: Redesigning engineering production for the agentic era
The model behind this piece: the AI Engineering Production System
The concept page: the Absorption Gap
The lived proof of the pattern: I've Seen This Bottleneck Before
The output-side original: The Absorption Gap
The governance front: The Second Absorption Gap
Verification as a capability: Quality Engineering
FAQ
What is Constraint Migration in software engineering?
Constraint Migration is the movement of the binding bottleneck through an engineering system as each step is relieved. When AI speeds up coding, the constraint resurfaces at the next least scalable step, such as verification, integration, operations, architecture or governance, and ends at human judgment. The idea extends Goldratt's Theory of Constraints to engineering systems where AI can add capacity to almost any stage.
Is Constraint Migration just the Theory of Constraints?
In lineage, yes. Goldratt showed that relieving a constraint moves it, and warned that rules built for the old constraint become the next limit. Two things are new with AI. Capacity can be added to almost any stage in a quarter, so the constraint moves far more often, and the agents added at each stage form a workforce that must itself be supplied with context and governed.
Why hasn't adding AI code review fixed our delivery speed?
AI code review relieves the verification stop, and the constraint then moves to the next least scalable step, usually the delivery pipeline, production operations or the design inputs. CircleCI's 2026 data shows the pattern: average workflow throughput rose 59% while median-team main-branch throughput fell 7%. Before relieving review, check whether integration and operations can absorb the extra merges.
How do I find where my engineering bottleneck is right now?
Find where work waits. Measure the queue time in front of each stage, from intent and design through review, integration, release and operations. The stage with the longest and fastest-growing queue is the current constraint, and repeating the check each quarter shows where it is heading. How busy a team feels is a poor guide, because the busiest team is often the one just upstream of the real constraint.
Where does the bottleneck end up once most engineering work is automated?
The engineering bottleneck ends at human judgment: deciding what the business meant, whether a change is safe, and who is accountable when it is not. Agents can prepare and check that judgment but cannot own it, so each additional agent adds load at that stop. This is why validated business value per unit of human intervention is the more useful measure, since it tracks the terminal constraint directly.