---
id: "lib-2026-10-13-why-code-reaches-main-more-slowly-with-ai-agents"
type: "library"
title: "Why code reaches main more slowly with AI agents"
title_original: "Почему с AI‑агентами код доезжает до main медленнее"
lang: "RU"
org: "OTUS (Habr)"
source_type: "Practitioner post"
date: "2026-10-13"
week: "2026-W42"
url: "https://nosov.ai/library/lib-2026-10-13-why-code-reaches-main-more-slowly-with-ai-agents/"
original_url: "https://habr.com/ru/companies/otus/articles/1088870/"
tier: "B"
tier_name: "Useful, limited"
tier_reason: "Tech lead and OTUS instructor's careful secondary synthesis of Faros AI, CircleCI and DORA data with his own review-policy practice; the numbers belong to vendor reports and surveys he flags as such, the added value is the queueing frame and controls."
summary_basis: "full-text"
original_minutes: "12"
tags: ["developer productivity", "delivery metrics", "secondary synthesis"]
frames: ["solow-paradox"]
---

# Why code reaches main more slowly with AI agents

Original title: Почему с AI‑агентами код доезжает до main медленнее

Tier B (Useful, limited): Tech lead and OTUS instructor's careful secondary synthesis of Faros AI, CircleCI and DORA data with his own review-policy practice; the numbers belong to vendor reports and surveys he flags as such, the added value is the queueing frame and controls.

Summary based on the full text.

## In short

A Habr post (13 October 2026) on the OTUS education company's blog by Sergey Proshchaev, a Java and Kotlin tech lead in fintech and e-commerce. His argument: agents speed up writing code faster than teams can review, test, integrate and ship it, so the bottleneck moves down the pipeline instead of disappearing. He sets three data sources side by side, notes where they disagree, then proposes controls: small merge requests, fast first response, automated checks first, review depth by risk, and flow metrics that locate the queue.

## Key numbers

- +300.6%: rise in time spent in QA, the largest flow-metric deterioration in Faros AI's "The Speed Trap" (September 2026)
- +125.4%: rise in incidents per month in the same Faros telemetry
- 31.3% to 76.3%: growth in PRs merged without review, six months ago versus now, per Faros
- 70.8%: success rate of builds on main in CircleCI's 2026 report, a five-year low
- 24%: share of DORA 2025 respondents expressing high trust in AI output

## What it reports

- Faros AI 2025 ("The AI Productivity Paradox", 1,255 teams): heavy AI users closed 21% more tasks and merged 98% more PRs, while review time rose 91%, PR size 154% and bugs per developer 9%; no significant company-level effect.
- Faros "The Speed Trap" (18 September 2026, 12 months of telemetry across 4,000 teams): QA time +300.6%, PR size still +71.8% over baseline, incidents +125.4%, PRs merged without review up from 31.3% to 76.3%. Teams using AI review get faster first reviews and lower change failure rates, a correlation.
- CircleCI 2026 (28.7 million CI runs, September 2025): daily runs +59%, feature-branch activity +15% but main -7% for the median team, main success 70.8%, median 72 minutes to green; under 5% of teams grew both.
- DORA: in 2024, 25% more AI use went with an estimated 1.5% lower delivery throughput and 7.2% lower stability; in 2025 the link with throughput turned positive and with stability stayed negative.
- Author's practice: a cap of two open MRs per person cleared queues; agents widen diffs with unrequested refactoring; a risk-tier review policy from CI-only for mechanical changes to a second independent reviewer for auth and payments; a non-blocking CI warning above 400 changed lines.

## How they got it

Desk synthesis of public reports plus the author's own project anecdotes, with a queueing-theory frame: when arrivals outpace service capacity, queues and lead time grow at the scarcest step.

## Limits

- All figures are secondary; the author notes Faros and CircleCI sell delivery tooling and DORA relies on surveys, so he treats direction as reliable and percentages as rough.
- Correlations only; teams with more work may simply adopt AI more.
- CircleCI's main-branch activity measures CI runs, not production releases.
- Ends with promotion of OTUS webinars.

## Why it matters for companies

The useful move is to stop counting PRs and tasks, which agents inflate, and measure where work waits: time to first review response, review rounds, merge to production including QA, queue depth and share merged without review. The risk-tier table is a ready starting policy for any engineering organisation adopting agents. The broader point fits planning beyond software: buying more generation capacity without adding verification capacity grows the queue.

## Key passages in translation

> AI ускоряет генерацию изменений быстрее, чем команда успевает их проверять, интегрировать и доставлять.

AI speeds up the generation of changes faster than the team can check, integrate and deliver them.

> В таких условиях approve может превращаться из результата проверки в способ убрать зависшее изменение из очереди.

Under these conditions an approval can turn from the result of a check into a way to clear a stuck change out of the queue.

> Поэтому следующий шаг после внедрения агентов — не обязательно купить ещё одного. Сначала стоит измерить, куда уже переехала очередь.

So the next step after adopting agents is not necessarily to buy another one. First measure where the queue has already moved.

Original: https://habr.com/ru/companies/otus/articles/1088870/