Writing Code Got Cheap. The Pipeline Didn't Get Faster.

Key Takeaways

• Faros AI’s telemetry on 10,000+ developers found engineers completing twice as many code changes while company-level metrics stayed flat. Output rose and outcomes did not follow.
• On the same teams, review time rose 91%, pull request size rose 154%, and bugs per developer rose 9%. These are associations from observational data, not proven causes.
• DORA’s 2025 survey of about 5,000 professionals found AI adoption positively related to throughput and still negatively related to delivery stability. The report’s framing: “that acceleration can expose weaknesses downstream.”
• A pipeline cannot move faster than its slowest stage. Making the cheap stage cheaper moves the constraint, it does not remove it.
• The tools for measuring all this are breaking too: METR withdrew its follow-up productivity study because developers would not work without AI.

Take the most flattering number in the agentic SDLC conversation. Faros AI analysed telemetry from more than 10,000 developers across 1,255 engineering teams and put the result on its own report page in one line: “Engineers are completing twice as many code changes, but company metrics remain flat.”

Read that as a manager and it is a paradox. Read it as a systems person and it is closer to a prediction. A lifecycle has stages. Agents made one of them dramatically cheaper. Nothing in that sentence promises the whole lifecycle got faster.

What did the telemetry actually find?

Faros compared each team against itself, taking the two quarters with the lowest AI adoption and the two with the highest. On the report write-up, high-adoption teams completed 21% more tasks and merged 98% more pull requests. They also saw PR review time increase 91%, average PR size increase 154%, and bugs per developer increase 9%.

Faros is careful with the verbs, and so should anyone repeating it. The page describes team-level results as associations, not causes, and states that it observed “no significant correlation between AI adoption and improvements at the company level.” Faros is also a vendor that sells measurement tooling. None of this is a controlled experiment.

What survives the caveats is the shape. More changes entered the system. Each change was bigger. The stage where a person has to read, understand, and accept the change took much longer. And at the level of the company, nothing moved.

Is that a Faros quirk, or a pattern?

A second, independent source points the same way. Google’s 2025 DORA report drew on about 5,000 technology professionals and more than 100 hours of qualitative data. Its throughput finding improved on the prior year: “Unlike last year, we observe a positive relationship between AI adoption on both software delivery throughput and product performance.”

Then the other half: “However, AI adoption does continue to have a negative relationship with software delivery stability.”

The report’s own summary of why is the sentence I would put on the wall: “AI doesn’t fix a team; it amplifies what’s already there.” And elsewhere: “AI accelerates software development, but that acceleration can expose weaknesses downstream.”

Telemetry from one source and a survey from another, different methods, one direction. Output goes up. Stability does not come with it.

Why would a faster stage not make a faster pipeline?

This part is my argument, not a finding, so weigh it as reasoning.

A lifecycle is a sequence: decide what to build, write it, review it, test it, ship it, operate it. A sequence moves at the rate of its narrowest stage. Writing code was never the narrowest one for most teams, which is part of why the job was never typing. Making the writing stage ten times cheaper therefore does one of two things. If a later stage has slack, throughput improves a little. If it does not, work simply queues in front of it.

Review has no slack to speak of. It is done by the same small group of people who already hold the context, it cannot be parallelised past the number of people who understand the system, and it gets harder per change, not easier, when changes arrive larger. That is exactly the pattern in the Faros numbers: more PRs, bigger PRs, longer reviews.

The stability result then reads as the predictable second-order effect. When a stage downstream is saturated, one of two things gives: the queue grows, or the stage is done less carefully. I did not find DORA attributing its stability result to review specifically, so treat review as the likeliest place the strain lands, not a measured cause. Its own framing is the general one: acceleration “can expose weaknesses downstream.”

Where does that leave the “agentic” part?

It moves the question. Teams ask “how do we get agents to write more?” when the constraint says to ask “what does the stage after the agent need to look like?”

That reframes a few common instincts:

• More agent output is not the goal. If review is the constraint, a team that doubles its generation without touching review has bought a longer queue.
• Smaller changes are a control, not a style preference. A 154% rise in PR size is the opposite of what a saturated reviewer needs.
• Verification has to be built, not hoped for. Tests and fast feedback are what let a human review a change in minutes. That is my inference from the Faros numbers, not something either report measured.
• Agents can shift into the later stages too. The same capability that writes the change can write its tests and narrate its diff. That helps only if the checks are ones you wrote and trust, which is the argument of the earlier essay on judgment.

None of it argues against using agents. It argues that “we adopted agents” is not a delivery strategy, because the thing that changed is one stage of several.

Can we even measure this properly yet?

Not cleanly, and the best public attempt just said so.

METR’s early-2025 randomized trial, run on data from February to June 2025, found experienced open-source developers took longer with AI tools. Its follow-up, started in August 2025, was meant to track the effect over time. In its February 2026 update, METR reported an estimated speedup of -4% for newly recruited developers (confidence interval -15% to +9%), and then said it does not trust the data.

The reasons are instructive. METR saw “a significant increase in developers declining to participate” because they “do not wish to work without AI,” which it believes biases the estimate downward. Its time measurements are also unreliable for developers who run several agents at once. METR’s own view is that developers are likely more sped up now than in early 2025, though its data is “only very weak evidence” for how much.

Read that against the Faros result. The cleanest way to measure a speedup, with and without the tool, is breaking because people will not work without the tool. And the measure of time per task stops meaning much once one person is supervising several agents at once. The lifecycle has changed faster than the instruments built to watch it.

What should a team change on Monday?

Find the stage that is now the constraint, and spend on that one.

If review time per change is climbing while generation volume climbs, review is the constraint. Cap change size. Move checks that do not need judgment into automation you wrote. Decide what a human must read and what a test can answer, then hold the line.

Then measure at the level of the pipeline, not the stage. Faros’s own result is the warning: individual output is the easiest number to move and the least informative.

Writing code got cheap. Shipping software still runs at the speed of the part that is not.