ИИ ускоряет разработчиков, но замедляет команды. В чём ловушка?

Каждый разработчик с ИИ-ассистентом пишет код быстрее — но скорость релизов команды от этого не растёт. Разбираемся, почему индивидуальный прирост продуктивности съедается издержками координации, и что с этим делать.

ИИ-агенты масштабируют индивидуальную скорость разработчика напрямую, но скорость команды — это то, что остаётся после вычета переделок, ожиданий и согласований. И если ничего не менять в процессах, последние три слагаемых растут быстрее первого.

Скорость одного ≠ пропускная способность команды

Представьте трёх разработчиков, три ИИ-ассистента и один репозиторий. Каждый разработчик теперь генерирует код, тесты и рефакторинги заметно быстрее, чем раньше. Но релизы выходят с той же периодичностью, очередь на код-ревью растёт, а одни и те же факты о кодовой базе «открываются» заново каждый день.

В этом нет парадокса. Просто индивидуальная выработка и командная пропускная способность — это разные величины. Дать каждому участнику более быструю пишущую машинку — значит получить больше страниц. Но не обязательно лучшую книгу, написанную быстрее и совместно.

Удобная метафора, не претендующая на точную формулу:

командная пропускная способность ≈ сумма локальных ускорений − переделки − ожидания − согласования

ИИ-агенты увеличивают первое слагаемое. Но если ничего не менять в организации работы, три последних тоже растут — потому что в параллели летит больше задач, которые создаются быстрее людьми, не имеющими полной картины действий друг друга.

Что говорит исследовательская литература

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

METR, 2025 год. В исследовании с участием опытных open-source-разработчиков, работавших над зрелыми кодовыми базами, которые они хорошо знали, участники выполняли измеряемые задачи медленнее с помощью ИИ — хотя сами ожидали ускорения. Условия были специфичными, и обобщать это на тезис «ИИ замедляет» нельзя. Более узкий и полезный вывод: субъективное ощущение скорости и реальное время выполнения задачи могут расходиться. Это важный сигнал для тимлидов, которые оценивают эффективность внедрения ИИ-инструментов по внутренним ощущениям команды, а не по метрикам.

DORA Report, 2025 год. Отчёт Google о практиках DevOps трактует ИИ как амплификатор: он усиливает и сильные стороны, и dysfunction (дисфункции) организации. Если координация в команде слабая, рост объёма параллельной работы с ИИ-агентами делает эту слабость дороже, а не дешевле.

Пять издержек координации, которые съедают прирост

Все пять проблем, перечисленные ниже, не новы. ИИ не изобретает их — он увеличивает частоту и объём, с которым они возникают.

1. Дублирование исследований. Один агент в одном чате «выясняет», что staging-база данных сбрасывается каждую ночь, или что модуль нужно сохранять обратно совместимым во время миграции. Этот факт достался непросто — но он живёт только в одной сессии. Следующий агент, на другой машине, выводит то же самое заново. Или worse — выводит противоположное. Команда платит за один и тот же урок многократно.

2. Стратегический дрейф (Decision Drift). Кто-то принимает решение: «Переходим на целые центы, никаких float-ов для денег». Решение правильное, произнесено вслух один раз — и три агента, которые этого не слышали, тихо делают три разных выбора. Никто не возражал. Решение просто не переместилось туда, где оно нужно.

3. Неопределённость ответственности. Когда все работают быстро, вопрос «кто сейчас занимается рефакторингом платежей?» перестаёт иметь очевидный ответ. Два человека берутся за одну задачу — или ни один, потому что каждый думал, что другой уже занят.

4. Потеря контекста при передаче. Работа перемещается между утренней и дневной сессией, между ноутбуком и CI-сервером, между разработчиком и коллегой, который его подменяет — или между разными ИИ-агентами (Claude Code, Codex и т.д.). Каждый переход роняет контекст: принятое решение, недоделанная задача, открытый вопрос, файлы, которые кто-то редактировал на середине.

5. Конфликты и распутывание. Два агента редактируют пересекающиеся части одного файла в двух ветках. Git честно сообщает о конфликте — после того как обе стороны проделали работу. Конфликт создан часами ранее, когда ни одна сторона не знала, что другая приступила. И кто-то тратит половину дня на распутывание.

Общая черта

Все пять проблем — это не проблемы возможностей модели. Более умный или быстрый агент не решает их сам по себе. Это проблемы координации, и они могут усугубляться именно тогда, когда индивидуальная работа ускоряется.

Аналогия с законом Брукса

Фред Брукс decades назад заметил: добавление людей в запаздывающий проект может сделать его ещё более запаздывающим, потому что пути коммуникации растут быстрее, чем руки. ИИ-агенты — не люди, и это не буквальное повторение «закона Брукса». Но структура проблемы похожа: у команды теперь больше быстрых источников кода, и если коммуникационные пути вокруг них не масштабируются, координация может поглотить локальные приросты.

Связанная, но ограниченная аналогия — закон Конвея: когда решения фрагментируются между людьми, которые не общаются, эта фрагментация может проявиться в архитектуре системы, которую они строят.

Пять принципов, которые снижают издержки

Решение — не замедлять разработчиков. Суть в том, чтобы координация, которая раньше происходила неявно в маленькой синхронной команде, стала явной — потому что нельзя рассчитывать, что каждый агент прочитал Slack-канал или видит контекст чужой приватной сессии.

1. Разделённые решения транспортируются. Когда кто-то устанавливает правило («v1 API заморожен на 90 дней»), оно должно попасть туда, где каждый агент может его извлечь при старте, а не остаться в одном чате. Решение принимается один раз и становится доступно всем.

2. Ответственность видна. «Кто за что отвечает» — это живая, общая картина, а не то, что реконструируется опросом уже после того, как два человека столкнулись.

3. Передачи явные. Перемещение работы между сессией, машиной, человеком или инструментом должно нести с собой решение, недоделанную задачу, открытый вопрос и область активных файлов — а не только закоммиченный код.

4. Координация до редактирования, а не после. Самый дешёвый момент поймать конфликт в одном файле — до того, как второй агент приступил, когда это пятисекундная проверка, а не распутывание merge-конфликта.

5. Git остаётся источником истины. Ничто из вышеперечисленного не заменяет ветки, ревью и CI. Координация располагается до этих страховочных сетей, чтобы им было меньше что ловить. Код — в Git; быстрые решения и координация — рядом с ним.

Диагностика: десять вопросов к своей команде

Пройдитесь по этим вопросам применительно к вашей команде. Каждый ответ «нет» — это скрытая издержка координации, которую вы, вероятно, платите, не видя на дашбордах.

1. Когда агент одного разработчика выясняет что-то неочевидное о кодовой базе, может ли агент другого разработчика получить этот факт завтра, не спрашивая человека?

2. Если кто-то принял решение в 16:00, будет ли агент, стартующий в 17:00 на другой машине, ему следовать?

3. Может ли кто-то прямо сейчас сказать, какие файлы или модули активно редактирует коллега?

4. При передаче работы между машинами или людьми транспортируются недоделанная часть и открытые вопросы — или только закоммиченный код?

5. Прежде чем агент начнёт редактировать модуль, есть ли у него дешёвый способ узнать, что коллега уже приступил?

6. Начинают ли ваши агенты каждую сессию с повторного объяснения одного и того же контекста («деньги — целые центы», «не трогаем auth на этой неделе»)?

7. Когда два человека заканчивают, как часто пересечение обнаруживается только на этапе merge?

8. «Память команды» — это документ, который кто-то должен помнить обновить и подсунуть агенту, или то, что агенты читают и пишут сами?

9. Может ли новый участник команды (или новый агент) получить текущие решения, открытые задачи и распределение ответственности примерно за один шаг?

10. Переводится ли рост индивидуальной скорости в рост отправленной и согласованной работы — или в рост переделок и ревью?

Если вы ответили «нет» на несколько вопросов, ваше узкое место — не скорость написания кода. Это координация, и это более решаемая проблема, чем кажется, потому что большая её часть сводится к тому, чтобы сделать неявный контекст явным и общедоступным.

Критическое замечание о коммерческом контексте

Важно отметить, что эта статья первоначально опубликована в блоге Vibsync — компании, которая продаёт именно слой координации для ИИ-агентов (общую память команды, доску задач, механизм «захвата» файлов). Это не делает анализ неверным — пять описанных издержек координации реальны и хорошо знакомы любому, кто работал в команде из нескольких людей с активным использованием ИИ-ассистентов. Но framing статьи естественным образом ведёт к выводу, что решение — в продукте Vibsync, и это стоит держать в голове.

Предлагаемые пять принципов координации корректны и без привязки к конкретному инструменту. Большинство из них можно реализовать дисциплиной: вести журнал решений, обновлять доску задач, договариваться о явной передаче контекста. Vibsync автоматизирует эту дисциплину — но это не единственный путь.

Что это значит на практике

ИИ-ассистенты для кодирования — Copilot, Claude Code, Cursor, Codex и другие — действительно ускоряют индивидуальную работу разработчика. В этом мало сомнений: генерация boilerplate-кода, подсказки по архитектуре, написание тестов, рефакторинг — всё это стало быстрее. Но скорость команды определяется не слож