Закон Брукса в 2026: AI ломает «Мифический человеко-месяц» или нет?
Фредерик Брукс опубликовал «Мифический человеко-месяц» в 1975 году. Его главный тезис — «добавление людей в опоздавший проект делает его ещё более опоздавшим» — пережил пять десятилетий методологической моды: водопад, agile, DevOps. В 2026 году AI-ассистенты подняли индивидуальную продуктивность инженера на 30-55% в контролируемых исследованиях (GitHub/Microsoft Research, 2024-2025). Естественный вопрос: AI наконец сломал закон Брукса?
Короткий ответ: нет. Чуть менее короткий: AI ускорил именно ту часть инженерной работы, которая никогда не была узким местом, и почти не затронул ту, которая им является.
{/* truncate */}
Что именно говорит закон Брукса
Закон Брукса — это одно предложение, но за ним стоят две независимых наблюдения.
Первое: стоимость онбординга. Новый инженер не пишет код в первый день. Он потребляет время существующих инженеров — вопросы, code review, парное программирование — прежде чем начнёт приносить положительную отдачу. В опоздавшем проекте эта нагрузка приходит ровно тогда, когда команда меньше всего может её себе позволить.
Второе: коммуникационный оверхед растёт квадратично. Количество уникальных парных каналов общения в команде из n человек равно n × (n-1) / 2. С ростом n стоимость координации растёт быстрее, чем мощность команды.
Эти два эффекта складываются. Добавьте человека в опоздавшую команду из 10 — и вы получаете онбординг плюс 11 новых каналов коммуникации. Проект замедляется.
Математика коммуникационного оверхеда
Таблица, которую видел и забыл каждый инженерный руководитель:
| Размер команды | Парных каналов | Добавится при +1 человеке |
|---|---|---|
| 5 | 10 | 5 |
| 10 | 45 | 10 |
| 20 | 190 | 20 |
| 50 | 1 225 | 50 |
| 100 | 4 950 | 100 |
Переход от 20 к 50 человек добавляет 1 035 новых парных каналов — рост координационной поверхности в 6,4 раза при росте численности в 2,5 раза.
Реальные команды не работают по схеме full mesh — они собираются в squads, tribes, гильдии. Но базовое притяжение никуда не девается. Закон Конвея превращает это из мысленного эксперимента в архитектурное ограничение: оргструктура протекает в дизайн системы, и команда, которая не умеет координироваться, выпускает код, который тоже не собирается чисто.
Что AI действительно изменил
Прирост продуктивности от AI-ассистентов реален и хорошо задокументирован.
GitHub Research (2024) провёл контролируемое исследование с 95 профессиональными разработчиками: задача — написать HTTP-сервер на JavaScript. Пользователи Copilot справились на 55,8% быстрее контрольной группы. Исследование продуктивности Microsoft с 4 867 разработчиками в Accenture, крупном consumer-SaaS и ANZ Bank зафиксировало рост числа завершённых задач на 26% в неделю. Экономисты Стэнфорда и MIT, работавшие с Mercado Libre, зафиксировали прирост объёма pull request'ов от индивидуальных разработчиков на 30-40% после внедрения Copilot.
Разные методологии, разные компании, разные языки — но направление совпадает. AI измеримо ускоряет ту часть инженерной работы, где отдельный разработчик печатает код в редакторе.
Это именно та часть, которая не была узким местом.
Что AI НЕ изменил
Пять категорий инженерной работы, где AI-ассистенты практически не дают эффекта:
| Активность | Эффект AI (исследования 2024-2025) | Почему AI помогает меньше |
|---|---|---|
| Соло-кодинг (greenfield) | +30-55% | Чёткая задача, узкий контекст, AI отлично справляется |
| Парное программирование | +20-30% | Часть boilerplate ускоряется, время разговоров — нет |
| Code review (несколько ревьюверов) | +5-10% | Доминирует чтение и суждение, не печать |
| Кросс-командные архитектурные решения | ~0% | Нужен контекст, который AI не видит (политика, история, ограничения) |
| Онбординг нового инженера в существующий код | +5-15% | Генерация документации помогает; передача неявных знаний — нет |
Прирост концентрируется в соло-кодинге с чётким скоупом. Кросс-командная координация — реальное узкое место в опоздавших проектах — почти не двигается.
DORA 2024 State of DevOps Report делает это явным: в командах, внедривших AI-инструменты, индивидуальная пропускная способность выросла, но стабильность доставки и командная пропускная способность показали смешанные сигналы. Некоторые команды стали отгружать чуть медленнее, потому что выросший объём PR перегрузил пропускную способность code review.
Узкое место опоздавшего проекта — не кодинг
За десять лет работы с инженерными командами (и три года эксплуатации платформы delivery performance) паттерн в опоздавших проектах удивительно стабильный. Сроки сорвались не потому, что инженеры медленно печатают. Они сорвались, потому что:
- Зависимость от другой команды материализовалась на два месяца позже
- Продуктовое решение переворачивали трижды посреди разработки
- Незадокументированное ограничение интеграции всплыло на 8-й неделе
- Старший инженер ушёл и унёс с собой критическую модель домена в голове
- Регуляторный или security review встал в очередь за 11 другими
Исследования DORA, Stripe и McKinsey сходятся: в проектах, срывающих сроки, 60-70% потерянного времени уходит на координацию, принятие решений, переделки из-за изменений требований и очереди ревью — не на написание кода. McKinsey в follow-up «Developer Velocity» 2024 года оценил, что разработчики тратят на написание/изменение кода около 30-40% времени; остальное — на всё, что вокруг.
AI сжимает 30-40%. Он не сжимает 60-70%.
Когда AI частично обходит закон Брукса
Честная версия: закон Брукса слабее в условиях, где стоимость координации структурно низкая.
Greenfield-проекты с чёткими модульными границами. Новый человек приходит в микросервис со строгими API, отгружает ценность на первой неделе. AI ускоряет печать; архитектура снимает большую часть необходимости в координации.
Async-first культура с сильной письменной документацией. Каналов общения много, но пропускная способность каждого высокая, потому что всё записано. Новый инженер сам онбордится по докам, а AI заполняет вопросы на уровне кода.
Хорошо покрытый тестами код. Изменения, сгенерированные AI, валидируются тест-сьютом до того, как попадут к человеку-ревьюверу. Очереди ревью остаются короткими.
Команды, которые явно ограничивают координационную поверхность. Сквады по 6-8, чёткие границы владения, никаких cross-squad PR review без изменения интерфейса. Квадратичность Брукса остаётся линейной, потому что команда отказывается работать по схеме full mesh.
В таких условиях добавление людей в опоздавший проект менее катастрофично, чем предсказывал Брукс. AI помогает новичкам быстрее разобраться с тем, что AI способен прочитать.
Когда закон Брукса всё ещё работает жёстко
И наоборот, AI не спасает, когда:
- Опоздавший проект — это монолит без тестового покрытия — новые инженеры не могут отгружать безопасно
- Узкое место — единственный носитель доменного знания, чьи знания не записаны
- В команде синхронные ритуалы принятия решений (большие стендапы, design review-комитеты)
- Интеграционная поверхность регулируется (финтех, медтех, телеком) — очереди ревью внешние и не сдвигаются
- В кодовой базе глубокие неявные конвенции, которые AI имитирует синтаксически, но не семантически
В работе с клиентами из регулируемых отраслей мы видим этот паттерн стабильно. Добавление трёх инженеров в опоздавший финтех-проект не ускоряет его — оно добавляет три новых ревью в уже перегруженную очередь compliance-офицера.
Что показывают реальные данные 2026
Мы собираем IDE-heartbeat телеметрию по 100+ B2B компаний на PanDev Metrics — время кодинга, focus-блоки, скорость переключения между проектами, паттерны активности на одного инженера. По нашему датасету видны две вещи.
Первое: с Q3 2024 по Q1 2026 внедрение AI-инструментов (измеренное как активное время в Cursor, Copilot Chat и AI-ассистированных IDE-режимах) увеличило долю «активного кодинга» в день у индивидуального разработчика в среднем на 18%. Инженеры с AI-ассистентами логируют больше сфокусированных часов кодинга.
Второе: в командах от 20 инженеров соотношение времени кодинга и времени координации (митинги, ожидание ревью, async-треды) практически не сдвинулось. Индивидуальный кодинг стал продуктивнее, но потолок командного выхода остался там, где предсказывал Брукс.
Честная оговорка: у нас пока нет строгих longitudinal данных по второму порядку — как именно AI смещает нагрузку с кодинга на очереди ревью. Двенадцать месяцев — мало. Гипотеза о смещении правдоподобна и согласуется с DORA 2024, но для подтверждения нужны 24-36 месяцев трассировок.
PanDev Metrics показывает этот разрез прямо в CTO Dashboard: представление time-allocation разбивает день каждого инженера на активный кодинг, context switching, ожидание ревью и idle-периоды. Если хотите проверить гипотезу Brooks-vs-AI на своей команде — сигнал лежит именно там.
Контр-тезис
Что упускает большинство статей «AI сломал закон Брукса»: AI-ассистенты сделали проблему времени кодинга менее интересной, а значит координационный оверхед теперь занимает ещё большую долю общего времени проекта, чем в 1975 году.
Если раньше кодинг занимал 40% времени проекта, а координация — 60%, и AI сокращает кодинг на треть, то кодинг становится ~30%, а координация — ~70%. Закон Брукса не ослаб — его диагностическая сила выросла, потому что соотношение сместилось в ту самую сторону, о которой Брукс предупреждал.
Что это значит для инженерных руководителей
Три операционных следствия:
- Для опоздавших проектов прекратите измерять «инженерную пропускную способность» изолированно. Отслеживайте глубину очередей на ревью, деплое и аппрувах. Именно там в 2026 году накапливается срыв сроков.
- AI-инструменты — индивидуальный мультипликатор, а не командный. Закладывайте AI-прирост в индивидуальные KPI. Не предполагайте, что командный lead time упадёт на тот же процент.
- Стоимость онбординга по-прежнему реальна. AI помогает новичкам быстрее читать код; он не даёт политический контекст, историю решений и неявное знание «мы это пробовали в 2023». Планируйте ramp-up так же, как планировал Брукс.
FAQ
Что говорит закон Брукса? Добавление людей в опоздавший софтверный проект делает его ещё более опоздавшим. Сформулировал Фредерик Брукс в книге «Мифический человеко-месяц» (1975) на основе опыта руководства проектом IBM OS/360.
Закон Брукса актуален в эпоху AI? Да, возможно даже больше, чем раньше. AI ускоряет индивидуальный кодинг на 30-55%, но координационный оверхед — реальная причина срыва сроков — почти не сдвинулся. Соотношение «время координации к времени кодинга» только выросло.
Сколько коммуникационных каналов в команде из 10 человек?
Сорок пять. Формула: n × (n-1) / 2, для n=10: 10 × 9 / 2 = 45 парных каналов.
Что такое «мифический человеко-месяц»? Тезис Брукса о том, что человеко-месяцы нельзя использовать как единицу планирования — добавление людей не сокращает календарное время пропорционально из-за стоимости онбординга и коммуникационного оверхеда. Единица мифическая, потому что притворяется, будто люди и время взаимозаменяемы там, где не являются.
Можно ли ускорить опоздавший проект в 2026? Иногда. Обойти закон Брукса можно через сокращение скоупа, удаление зависимостей или улучшение координационной поверхности (лучше доки, меньшие батчи ревью, async-решения). AI помогает уже имеющимся инженерам отгружать быстрее, но добавление новых людей в опоздавший проект обычно всё ещё его замедляет.