Subscribe

Do AI coding agents actually make senior engineers faster?

Microsoft measured 24% more merged pull requests, but longer merge times and doubled reviewer workload complicate the productivity claim.

Do AI coding agents actually make senior engineers faster?

Microsoft measured 24% more merged pull requests from regular agent users. Merge times also grew, and reviewer workload roughly doubled. The terminal looked fast. The engineering system started wheezing. Claude wrote the feature, added tests and drafted the pull request before I finished an espresso. Bellissimo. Then I opened the diff. Forty minutes later, I was reconstructing assumptions the PR never documented, checking whether the tests proved anything useful and wondering why Claude had created a second abstraction for something the codebase already handled. The implementation looked finished. My afternoon disagreed. Microsoft’s early-2026 rollout of Claude Code and GitHub Copilot CLI gives us a serious number: regular users merged 24% more pull requests per engineer per day over four months. Reviewer workload roughly doubled, human-review coverage fell from 89% to 68%, and AI-authored PRs took 22% longer overall to merge, according to the Microsoft research summarized by TechRepublic. That gets much closer to answering whether AI coding agents actually make senior engineers faster. I’m bored by demos where code appears in a terminal while a stopwatch runs. Senior engineering includes everything that happens after the magic typing animation.

My take: AI manufactures the visible artifacts of senior engineering at wild speed. The context and accountability then land on the humans who already had too much work.

PR volume is a gorgeous bad dashboard

Microsoft measured a 24.0% increase in merged PRs per engineer per day, with a likely range from 14.5% to 33.7%. The researchers also ran a placebo test by pretending the rollout had happened earlier. No similar jump appeared during the fake rollout period.

That is meaningful evidence. After years of AI productivity claims based on eight developers completing a JavaScript task while somebody times them, four months of enterprise telemetry feels almost luxurious.

The seniority result matters too. Individual contributors and principal engineers saw similar gains. Agents clearly helped experienced developers write and submit more code.

I was too confident about the opposite before reading the study.

Microsoft measured merged PRs per engineer per day. Its metric did not capture customer impact, security or long-term maintainability. A PR is a reviewable container, and producing more containers can make a dashboard look fantastic while the delivery system sounds like my old Fiat climbing a hill outside Ivrea.

A separate enterprise study followed 802 developers and 196,212 pull requests at a mid-sized company between January 2024 and April 2026. The CTO had announced a public “2x mandate” in mid-2025, using merged PRs per engineer per month as the scoreboard.

The dashboard delivered. Throughput rose from 21.2 to 44.3 merged PRs per active developer, reaching 2.09 times the pre-mandate baseline.

Then the invoice arrived. AI-authored PRs took roughly 20% longer after the first human review and 22% longer overall to merge. Human-review coverage also dropped while automated AI review expanded.

After 20 years of shipping products through Ad Astrum, I become suspicious whenever one operational metric starts behaving too beautifully. My publishing infrastructure once showed a gorgeous surge in referrer traffic. When I reconciled it against Google Search Console, roughly 99% of that “audience” was bots.

Lovely chart. No readers.

PR volume creates the same temptation. Leadership rewards the cheapest stage of the pipeline, so everybody generates more units for somebody else to inspect. I could achieve similar managerial brilliance by judging a restaurant according to plates leaving the kitchen without checking whether they reached a table.

Very efficient. Nobody ate.

Polished PRs can counterfeit experience

Agent-generated pull requests look eerily competent. I get a clean description, plausible naming, passing tests and a confident explanation of how the implementation fits the repository.

I appreciate all of it. I also know that execution polish can impersonate architectural understanding long enough to get through the first five minutes of review.

On July 13, 2026, Kartik Ghanshyambhai Pansuriya, Ehsan Ghorbani, Deepak Singh and Eman Abdullah AlOmar published research on predicting acceptance and review effort for human and agent pull requests. Their tree-based models predicted PR acceptance with F1 scores above 0.95 using information available when the PR was submitted.

The inputs included textual clarity, metadata, repository context, timing signals and lightweight diff statistics. The researchers wrote that “acceptance prediction is feasible from early signals”, with text quality and metadata among the strongest predictors.

Machines can generate many of those signals for pennies. A tidy PR description once suggested that somebody had organized the work in their head. Today it may mean somebody typed /pr and went to refill a water bottle.

Review effort was much harder to predict. Comment counts and time-to-merge depended heavily on reviewer availability, local workflow and team-specific habits. The model could identify an artifact that looked mergeable while struggling to estimate how much human attention it would consume.

The surface is legible. The organizational cost appears when a senior engineer opens the diff.

Another study examined 567 Claude Code PRs across 157 open-source projects. An impressive 83.8% eventually merged, yet only 54.9% went through without further changes. Humans revised the remaining 45.1%, especially around bug fixes, documentation and project-specific standards.

Those studies do not prove that junior developers receive a larger speed boost than senior developers. I’m making an inference from two decades of running engineering work: agents reproduce many visible markers that companies associate with seniority, so less-experienced engineers can produce work that looks unusually polished.

The reviewer still has to discover whether the choices survive contact with the codebase.

I catch myself falling for the presentation too. I’ll see a generated test suite with neat fixture names, comprehensive-looking cases and a wall of green checkmarks. My pulse drops for three seconds. Then I remember that the same model wrote both the implementation and the exam.

Plausibility is excellent theater.

One principal engineer, infinite queue

Maliha Noushin Raida and Daqing Hou studied 25,264 agentic PRs across 2,361 popular GitHub repositories for their July 2026 paper, Early Adoption of Agentic Coding Tools by GitHub Projects. Most contributions did not pass through an elaborate human-agent collaboration system.

One person handled them.

A single developer reviewed or modified the agent’s contribution in 78.9% of the dataset. Once the researchers included PRs that one reviewer accepted unchanged, one-person oversight covered close to nine out of ten cases.

Raida told Help Net Security that the pattern held even in busy projects: “Even among the most active small repositories (i.e., small teams with more than 30 agentic PRs), the majority of agentic PRs continued to follow a single-reviewer workflow.”

She added: “This suggests that increased agentic activity did not necessarily lead to more distributed review practices.”

I’d tape that above every engineering leader’s agent-adoption dashboard. Generation scales horizontally. Trust keeps arriving at one human desk.

Adoption is early enough that most teams have barely touched the ceiling. The median repository in Raida and Hou’s dataset generated only one or two agentic PRs over three months. Just 25 projects reached a pace comparable to a working developer under the reference benchmark.

Most companies are celebrating the first extra cars entering the motorway. The tollbooth still has one employee.

Single-reviewer PRs merged at 81.2%, compared with 80.3% for multi-reviewer or committer workflows. Raida put it plainly: “The merge rate … was very similar between the two collaboration patterns: 81.2% for single-reviewer pull requests and 80.3% for multi-reviewer/committer pull requests.”

That finding says little about later reverts, follow-up fixes or how well the code held up over time. The study measured acceptance within its window. Adding reviewers also creates coordination overhead; filling a Zoom call with seven people has never automatically produced wisdom.

The operational problem remains: creating another contribution now costs almost nothing, while human review stays concentrated.

Senior engineering has always included a mountain of invisible work. I recognize the abstraction that will become a trap. I remember the customer promise buried in a three-year-old Slack thread. I know why an ugly workaround exists because I watched the cleaner solution fail in production.

GitHub’s contribution graph has no square for scar tissue.

When I worked across the hub hardware, mobile app and cloud behind ALYT, a code change could cross boundaries that looked unrelated inside any single repository. A clean local implementation could still create a product-level disaster. The danger lived between components, beyond whatever line-count metric management had discovered that quarter.

A senior engineer working on a laptop, surrounded by code snippets and AI tools, illustrating productivity in tech.

Legacy code eats the demo for lunch

The enterprise data showed the strongest AI-related output growth in newer repositories. Legacy codebases saw little lift, and the difference did not depend strongly on seniority. Principal engineers and individual contributors followed similar patterns.

The repository mattered more than the title on the engineer’s email signature.

New codebases usually have cleaner conventions and fewer hidden dependencies. Mature systems contain half-finished migrations, undocumented customer exceptions and architectural compromises that survived because every “obvious” replacement started a different fire.

I grew up in Ivrea, the town of Olivetti, and studied computer engineering at Politecnico di Torino. Engineers there taught me a very Italian lesson: when an old machine has one strange metal bracket, assume somebody learned a painful reason for keeping it.

Legacy software is mostly strange metal brackets.

According to Codacy’s analysis, figures from LinearB’s 2026 Software Engineering Benchmarks Report show that agentic AI PRs had review pickup times 5.3 times longer than unassisted PRs. AI-assisted PRs waited 2.47 times longer.

Those figures come from LinearB and are cited by Codacy rather than drawn from Codacy’s own dataset. Still, the pattern matches Microsoft’s observed review pressure. Completed-looking diffs arrive faster than humans can acquire enough context to judge them.

Trust remains low. Stack Overflow’s 2025 developer survey put trust in AI accuracy at only 29%. Plausible code can take longer to inspect than obviously broken code because syntax errors announce themselves. A subtle mismatch with billing logic waits quietly until Friday evening.

My nonna would disown me for comparing software review to fish, but here we are. A chef recognizes spoiled fish immediately. A beautiful fillet with one suspicious smell takes longer because dinner now depends on a judgment call.

Generated code creates the same verification problem. I have to evaluate the intended behavior, its fit with the architecture and whichever edge cases the test suite conveniently forgot.

Addy Osmani and Jason Gorman have called the result comprehension debt: the widening gap between the code a team owns and the code its humans genuinely understand. The bill arrives when requirements change or production breaks and everybody has to rediscover reasoning that no person actually performed.

In a mature product, my advantage rarely comes from keystroke speed. It comes from knowing which innocent change wakes up the billing system, breaks an enterprise integration or destroys Sunday lunch with a production incident.

Where agents genuinely earn their keep

Microsoft found large, persistent gains, and frequent agent users did exceptionally well.

Developers using agents at least five days per week saw a lift above 50%. Engineers using them three days per week gained roughly 15%, and the overall effect persisted through the four-month study.

That is serious acceleration. Pretending otherwise would make me look ridiculous.

Tool choice mattered inside Microsoft too. During comparable weeks, Copilot CLI users saw roughly 2.2 times the PR lift of Claude Code users. Microsoft’s researchers warned that their internal environment makes the result unsuitable as a universal product ranking, so I’ll resist turning one company’s telemetry into Champions League standings.

Mature engineering organizations also seem capable of controlling the risk. Gearset CEO Kevin Boyle wrote in TechRadar Pro that “Seventy-six percent of enterprise teams are reviewing AI-generated work at least as rigorously as human-written work.”

That figure includes 33% applying stricter checks. Meanwhile, 82% of surveyed teams used AI during the build stage, dropping to 58% during release when production exposure is higher.

Good. Teams are assigning agents to work where mistakes are easier to catch, then tightening human control near production.

I see credible acceleration when the task is bounded, the repository is clean, the tests carry meaning and somebody has planned review capacity. Under those conditions, I can delegate boilerplate, migrations or contained feature work and spend the saved hours on decisions that require context.

I use agents this way constantly. Asking one to scaffold repetitive plumbing feels wonderful after twenty years of writing variations of the same code.

A food processor makes a chef dramatically faster at chopping onions. I still want the chef choosing the fish and running Saturday service.

Piano, amico.

Buy verification before another pile of licenses

I treat review capacity as engineering infrastructure. Before I buy another pile of agent licenses, I want reviewer pickup time, merge latency after first review, PR size and production incidents on the dashboard.

I also want rework rates. License usage tells me how enthusiastically the team generates code. It says very little about software reaching customers safely.

CircleCI’s 2026 data, cited by Codacy, covers more than 28 million CI workflow runs across over 22,000 organizations. Feature-branch throughput rose, while median main-branch throughput fell nearly 7%. Main-branch success dropped to 70.8%.

Activity increased. Safe delivery failed to keep pace.

A minority of teams escaped that trap. They increased main-branch throughput by 26% while feature-branch activity rose 85%. Codacy attributes the difference to stronger automated checks, cleaner review signals and clearer merge policies.

I’d move senior judgment upstream before an agent generates a giant diff. The engineer should write the execution plan, constraints and acceptance criteria first, then ask another human to inspect the risky assumptions. Reviewing a ten-line plan is cheaper than reverse-engineering intent from 1,400 generated lines.

I keep PRs small enough for a tired human to understand. “The agent produced all of this together” explains how the mess happened. It does not earn the mess a single merge button.

Deterministic tools should handle formatting and linting. Type checks, secret detection, dependency scanning, SAST, coverage requirements and complexity thresholds should run before a senior engineer opens the PR.

That leaves humans to inspect architecture, business behavior, reversibility and cross-team impact. I refuse to spend senior attention hunting for a missing semicolon in 2026. We have machines for that, grazie.

Pansuriya and his co-authors found acceptance highly predictable, while review effort remained difficult to forecast because availability and team workflow mattered so much. Even a strong model lives inside a messy company full of calendars, incidents and people trying to eat lunch.

For founders, I’d replace the “2x developer” dashboard with one harsher metric: production outcomes per hour of senior review.

If agent output doubles while senior review hours triple, the company financed its impressive demo with the attention of its most expensive people.

Accountability will have a human price tag

By July 2028, nearly every serious engineering team will have access to coding agents with broadly comparable capabilities. Model quality will keep moving, but agent availability will stop creating much competitive advantage. Most companies will have more code-generation capacity than they can safely verify.

The scarce engineer will understand the system deeply enough to approve a change and accept responsibility when it reaches production.

Companies measuring PR volume will think they hired an army of synthetic developers. Many will have built a factory with ten assembly lines and one quality inspector.

Whenever an AI rollout claims a 30% productivity gain, I want reviewer hours, merge latency, rework and production outcomes on the same slide. If the gain vanishes there, senior engineers funded the launch by wearing noise-canceling headphones and quietly losing the will to live.

By 2028, code generation will be a commodity line in the software budget. The engineer willing and able to sign their name under “ship it” will cost more every year.

Frequently asked questions

Do AI coding agents actually make senior engineers faster?

AI coding agents can increase senior engineers’ pull-request output, but they do not automatically improve end-to-end delivery speed. Microsoft measured 24% more merged pull requests among regular users while AI-authored pull requests took 22% longer overall to merge and reviewer workload roughly doubled.

Why do AI-generated pull requests take longer to review?

AI-generated pull requests can look polished while leaving assumptions, architectural fit, business behavior and edge cases for humans to verify. Review effort also depends on reviewer availability and team workflow. Faster code generation therefore creates more reviewable artifacts without expanding the scarce human capacity needed to approve them.

Where are AI coding agents most useful?

AI coding agents provide the clearest acceleration on bounded tasks in clean repositories with meaningful tests and planned review capacity. They are useful for boilerplate, migrations, repetitive plumbing and contained feature work, while humans retain responsibility for architecture, business behavior, reversibility and cross-team impact.

Sources

Related reading