ИИ ускоряет разработчика — но замедляет команду. В чём подвох?

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

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

Ловушка индивидуальной скорости

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

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

Формула, если можно так выразиться (не для подсчёта, а для понимания структуры проблемы):

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

Когда вы добавляете агентов, первое слагаемое растёт. Если ничего не менять в процессе, растут и три последних — потому что в параллельной работе оказывается больше кода, produced быстрее, людьми, которые не видят контекст друг друга. Вопрос для тимлида не «как сделать всех быстрее?», а «какое из трёх вычитаемых — моё настоящее узкое место?»

Независимое исследование, которое стоит учитывать

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

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

Второй — отчёт DORA за 2025 год, в котором ИИ описывается как усилитель: он масштабирует и сильные, и слабые стороны организации. Если координация слабая, ИИ делает её дефицит более болезненным — просто потому, что в полёте оказывается больше параллельной работы.

Пять скрытых издержек координации

Ниже — пять типов накладных расходов, которые «съедают» индивидуальное ускорение на уровне команды. Ни один из них не нов, но ИИ повышает их частоту и интенсивность.

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

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

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

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

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

Что объединяет все пять пунктов: это проблемы координации, а не возможностей модели. Более мощная нейросеть или более быстрый агент их не решают. И они могут усугубляться именно тогда, когда индивидуальная работа ускоряется.

Закон Брукса и закон Конвея — рифма, не повторение

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

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

Пять принципов, которые реально помогают

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

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

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

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

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

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

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

Если на несколько вопросов вы ответите «нет», значит, вы платите скрытый налог на координацию, который не отображается ни на одном дашборде.

1. Когда агент одного разработчика узнаёт что-то неочевидное о кодовой базе, может ли агент другого разработчика получить этот факт завтра, не спрашивая человека?
2. Если кто-то принял решение в 16:00, будет ли агент, стартующий в 17:00 на другой машине, ему следовать?
3. Может ли кто-нибудь прямо сейчас сказать, какие файлы или модули активно редактирует коллега?
4. При передаче работы между машинами или людьми перемещается ли незаконченная часть и открытые вопросы — или только закоммиченный код?
5. Прежде чем агент начнёт редактировать модуль, есть ли дешёвый способ узнать, что коллега уже начал?
6. Переобъясняют ли ваши агенты один и тот же контекст («деньги — целые центы», «auth не трогаем на этой неделе») в начале каждой сессии?
7. Когда два человека заканчивают, как часто вы обнаруживаете пересечение только на этапе merge?
8. Ваша «командная память» — это документ, который кто-то должен помнить обновить и указать агенту, — или то, что агенты читают и пишут сами?
9. Может ли новый участник (или новый агент) получить текущие решения команды, открытые задачи и «кто за что отвечает» примерно за один шаг?
10. Переводится ли индивидуальная скорость в больше отгруженной и согласованной работы — или в больше переработки и ревью?

Важная оговорка: это статья от вендора

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

Сам Vibsync честно признаёт ограничения: заявка на файл — это рекомендательный сигнал, а не жёсткая блокировка; инструмент не заменяет ревью и branch protection. Git остаётся source of truth.

Тем не менее, структура аргумента типична для vendor content: сначала диагностика проблемы, затем — единственный продукт в качестве решения. Пять принципов координации, перечисленные выше, ценны сами по себе и не требуют покупки конкретного инструмента. Их можно реализовать через внутренние процессы, документацию, shared-каналы в Slack, или через аналогичные инструменты конкурентов.

Что на самом деле важно вынести

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

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