The bottleneck didn't disappear. It just changed its address.

For eighteen months the story about AI in software was acceleration. The real story is more specific: speed moved, the bottleneck didn't disappear — it shifted downstream into review, QA, and release decisions.

Something interesting happened in the last two weeks of May. Linear — the project management tool beloved by engineers for its speed and minimalism — launched Diffs. Atlassian announced that you can now assign work directly to the Cursor coding agent from inside Jira. GitHub updated its Copilot usage metrics to classify which "AI adoption phase" your engineering team is currently in.

Three independent products. Three different companies. Three different angles on exactly the same problem: the code review queue is backing up — and it is backing up specifically because of AI. This might be the most honest thing the software tooling industry has said in a while. Honest, and slightly ironic.

link01 / The Setup

For the past eighteen months, the dominant narrative around AI in software development has been acceleration. Engineers write faster. Tickets close sooner. Output is up — in some teams dramatically so. That part is true. But it is only half the picture.

CircleCI's 2026 State of Software Delivery added a detail that should give any engineering leader pause: average throughput is up 59% year over year, but on the main branch — where code actually reaches production — the median team's throughput fell 7%. More code is being written. Less working software is shipping. The bottleneck did not disappear when AI arrived. It moved somewhere harder to see.

"More input into a constrained system does not increase output. It increases pressure."

— The Faros AI finding, distilled

link02 / Three Companies, One Problem

When Linear launched Diffs on May 28, their founder Tuomas Artman wrote something worth quoting directly: "Growing PR volumes from coding agents are putting further strain on an already creaking process. So much so that the speed gained from using agents gets swallowed in review." That is a tool company admitting, in their own product announcement, that AI broke something important.

Atlassian's Cursor-Jira integration framing matters more than the feature. Jason Andrews, VP of Engineering Operations at Cisco, described it precisely: "The question we're asking isn't how do we get engineers to use more AI. It's how do we build a system where humans and agents are working from the same context, toward the same goals." Andrews is not a startup founder with a hot take — he manages engineering operations at one of the world's largest technology companies.

GitHub has started classifying engineering teams by AI adoption phase — Code First, Agent First, Multi-Agent — because apparently we now need a taxonomy for how much of a codebase is being written by machines. This is not dystopia. It is just Tuesday in 2026. And OpenAI's Tax AI case study adds one more dimension: the best agentic systems preserve traces, turn corrections into evaluations, and keep human experts accountable for the decisions that matter.

link03 / The Three Moves

What changed in May was not one feature. It was a three-part operating pattern becoming visible across the tooling market. First: asynchronous coding. GitHub's Copilot coding agent moves AI from the editor into the delivery queue — work assigned, executed, returned as a draft PR, without a developer sitting inside the IDE for every step. Second: context consolidation. Atlassian's Cursor-in-Jira and Linear's code intelligence point to the same requirement — agents and humans need the same product context, engineering intent, and acceptance criteria before work begins. Third: evidence-based improvement. OpenAI's Tax AI shows what mature agentic systems look like: corrections become evaluations, traces are preserved, and the system improves through reviewable evidence.

Together, these moves shift the executive challenge from "how much code can AI produce?" to "is the work legible enough for humans and agents to collaborate around it?"

link04 / Why This Keeps Happening

When you speed up one part of a system without adjusting the rest, you do not increase output. You increase pressure at the next constraint. Developers write faster. The PR queue grows. Reviewers cannot absorb the volume. Senior engineers who used to spend time on architecture decisions now spend it reviewing code they did not write, covering edge cases the agent never anticipated. QA receives tickets with missing acceptance criteria — not because engineers are careless, but because the context that should have been defined before work started was never written down.

The agent does not know what "done" means. It only knows what the ticket says. If the ticket is vague, the agent produces output that is fast, confident, and aimed at the wrong target. The speed did not disappear. It transferred downstream, into review debt, QA overload, and release decisions nobody feels confident making.

"AI makes good delivery systems faster. It makes unclear delivery systems louder."

— NetForemost · AI-Native Delivery Watch

link05 / What This Looks Like From the Inside

At NetForemost, we build and support nearshore engineering teams for growth-stage companies in North America and Europe. Over more than 1,200 engagements, we have watched the same failure mode appear across different teams and different stacks. The teams that struggle with AI adoption are not the ones that adopted it too cautiously. They are the ones that added AI tooling to a delivery system that was not designed to absorb the speed. Code generation doubled. Review capacity did not. Acceptance criteria stayed informal.

For distributed and nearshore teams, this failure mode is more expensive. Review cycles that already cross time zones become unreliable when PR volume increases and scope is unclear. A senior engineer reviews a PR in the morning, asks a clarifying question, and waits until the next day for an answer. Multiply that across thirty PRs a week and you have a system that feels like it is moving but is quietly accumulating coordination debt.

The teams that get it right share one characteristic: they treated their delivery system as a design problem, not a staffing problem. Ownership was explicit. Acceptance criteria were written before work started. Review had a defined scope. QA was planned to match output.

link Sources · All verified

• Linear Diffs launch · Tuomas Artman · May 28, 2026
• Cursor in Jira · Atlassian · May 20, 2026
• Copilot usage metrics — AI adoption cohorts · GitHub · 2026
• Building self-improving tax agents with Codex · OpenAI · May 27, 2026
• Faros AI Engineering Report 2026 — AI Acceleration Whiplash
• CircleCI 2026 State of Software Delivery