Faros: median code review time up 441% in teams using AI agents

Faros telemetry covering 22 000 developers shows that in teams with high AI adoption, median code review time rose 441%, and pull requests were merged without any review at all 31% more often. People spend the time the agents save on new tasks and on checking other people's code. In September, a Habr author messaged acquaintances who had started working with AI agents a couple of months earlier and asked how it was going.

He expected stories about speedups, and he got some: one person stopped parsing logs by hand, another started taking on frontend, backend and DevOps tasks. But most answers were about something else: the volume of review had grown sharply, far more information was passing through their heads, and by evening they had no energy left for their own project. Hence the question: is this a temporary dip or the new normal?

Developers spend the saved time themselves

Researchers at Berkeley Haas spent eight months observing a US technology company of roughly 200 people (HBR published the results). With generative AI, employees work faster, take on broader tasks and finish later, even though nobody demands it. Prompts go out during lunch, during calls and while a file loads. Over time, the early productivity gain gives way to declining quality and turnover.

The Faros data matches this observation: people simply stop being able to keep up with checking the stream of changes. A BCG study clarifies the cause of the fatigue. When AI takes over routine work, burnout falls. When the job turns into constant supervision of an agent, decision fatigue and the urge to quit grow. Developers write less code but do more task framing, checking and decision-making, and most of them were never specifically trained for that.

It gets worse first: the learning curve and misleading impressions

The most-cited study on slowdown is the July study by METR (a lab that measures AI's real effect on work). 16 experienced open-source developers solved tasks in their own repositories, and with AI it took them 19% longer. Before the experiment they expected a 24% speedup, and afterward they still believed they had sped up by 20%. Participants had used Cursor for only a few dozen hours, and the authors state explicitly that they cannot rule out a learning effect beyond 50+ hours.

A repeat measurement six months later showed a speedup of about 18% among the ten participants who returned. The confidence interval includes zero, though, and the authors themselves call the signal unreliable: many people refused to work without AI, which skewed the sample. In the METR survey, people put the benefit at roughly double, and in earlier measurements they overestimated the effect by an average of 40 percentage points.

The author's conclusion: without the skills and a prepared project, AI really can slow you down, and your impressions lie. Those who quit at the bottom of the dip conclude, "AI doesn't work." Those who get through it conclude, "I can't go back." The middle is the dangerous place: a person sees ten agents in their feed that cleared a backlog overnight, installs another framework and five MCP servers, runs agents in parallel and slips into a mode of constant anxiety.

Trust equals verifiability: the order of adoption

The 2026 Stack Overflow survey shows where the line sits: 6% of developers trust AI for important decisions, but almost half trust it if they can verify the result. Without fast automated verification, you are left with two exhausting extremes: reading every line, or taking "done" at its word and untangling the consequences a week later. A sensible stance is the team lead's: control the "trunk and branches" (architecture, billing, the data model, critical tests) and don't touch every leaf.

In a poll in the author's Telegram channel, only 2 of 32 respondents named tool choice as their main problem, while 19 named organizing knowledge. The order he arrived at:

• engineering fundamentals; without them you can't tell a working change from a plausible one;
• task framing with acceptance criteria before any code is written;
• a feedback loop: types, linter, tests, browser, logs, so the agent can check itself;
• extensions (skills, MCP, plugins) only after that;
• project knowledge, a plan for large tasks and review against requirements;
• parallel agents last of all.

A skipped stage costs more later. A typical mistake is jumping straight into Spec-Driven Development, orchestrators and five agents. Newcomers end up with specs 3–5 times larger than the code, which nobody reads, burned-through limits and a sense of working with a black box. Installing extensions blindly is also a supply-chain risk: in February 2026, Koi Security found 341 malicious skills out of 2 857 in the ClawHub marketplace.

The way you learn matters too. In an Anthropic experiment, juniors learning a new library with AI scored 50% on the test versus 67% without AI. But those who asked the agent conceptual questions and worked through errors themselves scored 65% and higher.

The author's bottom line: the dip will pass, but the volume of checking work won't; that is the new normal. You can reduce the load by handing routine checks to tools and to a second agent with a clean context, keeping only the critical parts for yourself, and not keeping more agents open than you can check. The author will present his talk on this topic at the online conference AI Dev Live on November 12.