---
id: "lib-2026-10-28-ai-adoption-where-the-dev-boost-hides"
type: "library"
title: "AI adoption: where the dev boost hides"
title_original: "AI-adoption: где спрятан буст к разработке"
lang: "RU"
org: "Cloud.ru (Habr)"
source_type: "Practitioner post"
date: "2026-10-28"
week: "2026-W44"
url: "https://nosov.ai/library/lib-2026-10-28-ai-adoption-where-the-dev-boost-hides/"
original_url: "https://habr.com/ru/companies/cloud_ru/articles/1085100/"
tier: "B"
tier_name: "Useful, limited"
tier_reason: "Cloud.ru head of development reporting an internal pilot with logged Claude Code sessions and interviews; candid about what it did not measure, but the gains are rough estimates without a baseline, so B rather than A."
summary_basis: "full-text"
original_minutes: "11"
tags: ["enablement", "developer productivity", "claude code pilot", "delegation ladder"]
frames: ["solow-paradox"]
---

# AI adoption: where the dev boost hides

Original title: AI-adoption: где спрятан буст к разработке

Tier B (Useful, limited): Cloud.ru head of development reporting an internal pilot with logged Claude Code sessions and interviews; candid about what it did not measure, but the gains are rough estimates without a baseline, so B rather than A.

Summary based on the full text.

## In short

A Habr post (28 October 2026) by Misha Trifonov, Head of Development at Cloud.ru, based on his GoCloud Tech talk. The team gave 27 developers Claude Code, logged their sessions and interviewed each of them, then placed the work on Boris Cherny's five-level delegation ladder (L0 chat as search, L1 pair programming, L2 agent writes and human checks, L3 agents check agents, L4 agents propose tasks). Gains grew with delegation, but each level brought a new bottleneck: almost-right code, colliding agents, lost agreements, approval fatigue, fragmented attention, and personal harnesses that do not spread to teams.

## Key numbers

- 27: developers given Claude Code access in exchange for documenting and analysing their sessions
- +10% / +20% / ~+80%: estimated efficiency gain at delegation levels L1, L2 and L3 (L3 on test projects only)
- about 2x: rise in merge requests; the author says this measures repository activity, not speed or ROI
- 23 minutes: average time to switch attention between contexts, cited from a University of California study

## What it reports

- L0: no notable gain, since everyone already uses chat and the baseline evens out.
- L1: "almost right" output and the cost of explaining and reviewing pushed some participants back to chat. Fixes: unified context from the tracker, knowledge base and service docs, a company MCP server, a shared library of vetted skills, and peer exchange of what works. Result about +10% for those who adopted it.
- L2: about +20%, with new problems. Parallel agents edited the same files and fought over ports; fixed with git worktree plus feature stands (worktrees do not isolate network, processes or credentials). Agents forgot agreed conditions between sessions; fixed with spec-driven development. Approval prompts led people to switch to "dangerous" mode; fixed with a Docker Sandbox micro-VM.
- Attention: five agents in different states can consume almost two hours just to regain context; the answer is a harness (spec, skills, project rules, sandbox, escalation rules, checks).
- Teams: only a small share of developers saw better teamwork. Two people now build two prototypes and argue over which is better; strong personal harnesses leave with their owners. Proposed: personal, team and company harness layers.
- L3, test projects only: build, tests and static analysis, then a reviewer agent, then escalation to a human. Gain "somewhere around +80%". The author still does not stop reading changes.
- L4: not reached; open questions on what data an agent uses to propose work and who approves it. Generating a proposal and approving it should stay separate actions.
- Open problem: if agents take simple changes and some review, juniors lose the tasks they used to learn on.

## How they got it

Commits, merge requests, tracker tasks and participant interviews were compared. Because products and tasks differed, no single speed-up metric was produced. The author lists what a real speed claim would need: comparable tasks and period, time to accepted result, review and rework effort, post-release quality, plus tool and infrastructure cost for ROI.

## Limits

- The percentage gains are the author's estimates; method and baseline are not described.
- The doubling of merge requests measures activity, as the author states.
- L3 results come from test projects; the +80% figure aligns with what the ladder's author promised, which invites confirmation bias.
- One company, self-selected adopters, corporate blog.

## Why it matters for companies

The post maps where the effort goes when coding agents spread: context plumbing, isolation, specs, sandboxing and shared harnesses, rather than tool licences. Seat counts say little; the relevant measure is how many people work at L2 and above with team-level conventions. The honest section on what the pilot did not show is a good template for any internal claim about AI developer productivity. The junior-training question deserves a plan before agent review becomes routine.

## Key passages in translation

> Продукты и задачи различались, поэтому единую метрику ускорения мы не получили.

Products and tasks differed, so we did not obtain a single acceleration metric.

> MR стало примерно вдвое больше. Эта цифра описывает активность в репозиториях; из нее, конечно, нельзя получить двукратное ускорение разработки или ROI

Merge requests roughly doubled. This figure describes repository activity; it cannot, of course, be read as a twofold speed-up of development or as ROI.

> Генерация предложения и разрешение на его реализацию для меня должны оставаться разными действиями.

For me, generating a proposal and authorising its implementation must remain separate actions.

Original: https://habr.com/ru/companies/cloud_ru/articles/1085100/