Hey everyone, picture a Tuesday standup on a mid-size product team. Three engineers say their AI assistants helped them clear a pile of tickets overnight. The sprint board looks healthier than Monday. Slack has a burst of new pull request links. Someone jokes that the sprint might finish early for once. By Thursday the joke is quieter. The same pull requests are still sitting in review. A few got polite “will look later” reactions. One large agent-generated change for the auth token refresh path bounced twice because nobody owned the follow-up. The Excel export job that “almost worked” on Tuesday still fails on the Friday finance run. Coding work felt faster that week. Delivery did not feel faster in the same way.
That gap is the story that keeps showing up in 2026. AI coding tools are no longer experimental for most professionals. The interesting question is not whether your team can generate more diffs. The interesting question is whether your review capacity, ownership rules, and downstream practices grew at the same pace. In other words, AI pull requests merge slower than they open, and that is a delivery-system problem, not a typing-speed problem.
Hi, I am Robert Massey, a software engineer and computer science professor with twenty-plus years in the trenches. Coding agents are useful tools. The missing interface is not another seat license. It is review capacity, ownership, and checks that can fail a build.
What the 2026 delivery numbers keep repeating
LinearB’s 2026 Software Engineering Benchmarks Report looked at millions of pull requests across thousands of organizations. A few patterns show up again and again for AI-touched work. See the 2026 Software Engineering Benchmarks Report and LinearB’s notes on AI in software development.
AI pull requests wait much longer before someone picks them up. LinearB reports about a 4.6x longer wait before review, even though review often moves faster once a human starts. Agentic pull requests in particular show long pickup times at the upper end of the distribution, on the order of about 17.6 hours at the 75th percentile versus about 3.4 hours for unassisted work in the same report.
Merge rates tell an even clearer story. Manual pull requests merge within thirty days at roughly 84.4 percent in LinearB’s framing. AI pull requests land around 32.7 percent on the same window. That is not a small taste difference. That is a different traffic pattern in your repository.
Size and ownership help explain the hesitation. AI-assisted changes tend to be larger at the high end of the distribution. Agentic flows also get pointed at backlog cleanup that nobody feels responsible for finishing. Reviewers are more careful when the diff is big, the author of record is fuzzy, and the business priority is soft. That kind of care is healthy for quality. Sitting forever in the queue is not the same thing as care.
I am not treating any single vendor report as gospel. Ranges move with definitions of “AI PR,” sample sets, and time windows. The directional lesson still holds across several 2026 sources: generating code moved ahead of absorbing code.
Adoption is high where typing happens, thinner where mistakes are expensive
Keyhole’s compiled 2026 snapshots of agentic AI across the software development lifecycle show a familiar uneven curve. See Keyhole on agentic AI across the SDLC. Coding and code generation sit near the top of the adoption range, often reported around the mid-80s to about 90 percent of developers using AI for coding in some form. Testing has climbed as well. Planning, CI/CD, and maintenance or incident response sit much lower. Full-lifecycle AI use is still a minority story, with figures around thirteen percent of teams often cited, and true coding-agent deployment still trailing basic autocomplete-style assistants.
That sequencing is rational if you think like an engineer. A generated helper function is easy to reject in a pull request. An agent with authority to promote a build or restart a service can create damage before anyone finishes coffee. Teams trust tools more when a wrong answer is cheap to catch.
Here is the twist that matters for ROI conversations. Several 2026 summaries argue that measured returns concentrate less in raw generation and more in places like assisted code review and incident response, even though those stages trail coding in raw adoption. Black Duck’s mid-2026 enterprise survey reported AI coding hitting about 97 percent enterprise adoption and framed governance as the ROI multiplier (Black Duck, June 2026), while also describing a familiar redistribution of work: productivity gains arrive with bottlenecks in manual review, security testing, and rework. AI does not delete engineering labor in most teams. It mostly moves labor into later stages.
If your dashboard only counts commits, open pull requests, or “AI acceptance” inside the editor, you can celebrate a local win while the delivery system absorbs the cost. The same delivery lesson shows up when teams spec the non-negotiables before coding agents generate features.
A workplace example without the hype
Take a concrete ticket: bump the shared authentication client and fix every caller that breaks. An agent can open a pull request in an afternoon. It will rename a few methods, update a couple of imports, and paste a confident summary.
What still needs a human engineer is the boring middle of the job. Which services still use the old refresh path behind a feature flag? Which integration tests mock the old clock behavior? Who owns the mobile client that will fail silently if the token lifetime changes? Who is on call if Friday’s deploy spikes 401s after hours?
Those questions are software engineering. The assistant is a fast junior pair for mechanical edits. You still own the system boundaries, the test strategy, and the merge decision. When teams skip that ownership, the Tuesday stand-up looks magical and the Friday finance export looks cursed. Seniors already learned a version of this when they use AI to learn the system instead of skipping the practice.
Why AI pull requests merge slower, and what to change
Treat review capacity as a first-class constraint. If AI doubles open pull requests, either shrink change size, raise reviewer staffing for that lane, or throttle how many agent-opened changes enter the queue at once. Unbounded generation into a fixed review budget is how pickup times explode.
Give every AI-assisted change a human owner whose job is to land it or close it. Orphan pull requests tend to rot in the queue. LinearB’s own qualitative notes point at unclear ownership as one reason AI merges lag. Make ownership boring and explicit in the template.
Separate metrics for unassisted, AI-assisted, and agentic work. Mixing them into one “velocity” chart hides the queue. Track pickup time, acceptance or merge rate within a fixed window, change size, rework, and change-failure or incident signals alongside coding speed. If time-to-open drops and time-to-merge stays flat, you did not buy delivery. You bought a taller stack of diffs.
Invest next where verification is strong and consequences are clear. Assisted review checklists, better test generation for known modules, and incident helpers that draft timelines from logs can pay off without handing production promotion to an unsupervised agent. Keep CI/CD and production actions behind human approval until your runbooks and rollback paths are boringly reliable.
Teach newer engineers the same lesson seniors already learned the hard way. Typing speed is not the scarce skill. Judgment about interfaces, failure modes, and when to say no is the scarce skill. AI makes the first draft cheaper. It does not retire the need to understand what you are shipping.
Keep the tool. Grow the system.
AI coding assistants are useful in daily work, and I use them myself. Plenty of working professionals use them every week. The 2026 evidence is not an argument to throw the tools out. It is an argument to stop mistaking an open pull request for a shipped outcome.
If your team wants the speed to show up in production, grow the parts of the lifecycle that absorb change: review, ownership, tests, release discipline, and incident readiness. Measure those stages with the same seriousness you measure autocomplete wins. That is ordinary engineering with a faster keyboard, not a different profession.
If this article helped, drop a comment with the first workflow you want to try this week. Support the shenanigans buying me a coffee on Ko-fi, and follow Attune IT on YouTube or me on X.