Что такое «пульт управления концом» и зачем считать команду через ИИ-ускорение
«Пульт управления концом» - это метафора автора разбора на Хабре для инструмента, который считает штат и фонд оплаты труда компании при заданном ИИ-ускорении. Внутри вся жизнь команды разложена на три части: работу над продуктом, координацию и переделки на стыках. Пульт нужен, чтобы увидеть главное: если ускорить одну часть работы, вся остальная арифметика меняется нелинейно.
Ответ модели укладывается в два числа. При ускорении ×3,2, цене координации κ = 0,03 и снижении доли переделок с 35% до 15% команда из 30 человек для нового продукта сжимается примерно до 4,2 человеко-эквивалента. Та же команда на унаследованной системе даёт около 12,5 человеко-эквивалента: legacy сопротивляется ускорению сильнее.
Для вендора расчёт выглядит жёстче. Если выпуск остаётся прежним, малый штат сокращается со 125 до 71 человека, крупный - с 3000 до 1476. Переключение на расширение выпуска возвращает часть людей в продажи, поддержку и внедрение. Все эти числа - следствие допущений конкретной модели, а не замеров на выборке компаний, и держать это в голове нужно с первой строки.
Модель W: формула, которая считает людей и фонд оплаты труда при ИИ-ускорении
W = n · (1 - r) / (1 + κ · (n - 1))
- n - размер команды, то есть сколько людей работает над задачей.
- κ - цена координации: насколько дороже становится согласование с каждым новым участником.
- r - доля переделок после вычета координационных затрат, то есть часть работы, которая уходит в мусор на стыках.
- W - результат в человеко-эквивалентах. Умножьте его на среднюю стоимость специалиста и получите ориентир по ФОТ.
Смысл знаменателя простой: чем больше команда, тем больше времени съедает согласование. Подставьте n = 30 и κ = 0,03, и множитель координации даст 1,87, то есть почти половину полезной работы отберут стыки ещё до того, как в дело вступит ИИ. Числа 4,2 и 12,5 из примера выше выходят уже с поправкой на ускорение и на профиль работы: новый продукт и унаследованная система считаются по-разному.
Модель считает человеко-эквиваленты, а не «головы» в штатном расписании. Это ориентир для сценариев, не прогноз. Если подставить свои n, κ и r, картина почти наверняка будет другой, и это нормально: ценность модели в том, что она показывает чувствительность результата к каждому параметру.
Как разложить работу на продукт, координацию и переделки
Три части работы в «пульте» разделены не для красоты. ИИ-ускорение бьёт в первую очередь по работе над продуктом: генерация кода, черновики, тесты, разбор документации. Координация и переделки на стыках при этом не исчезают автоматически.
Логика жёсткая: если у человека растёт число эпиков, растёт и объём кода на ревью, и количество согласований. κ и r в модели не константы природы, а переменные, которые определяют, сколько сэкономит ускорение. Именно поэтому в разборе отдельно приводятся данные Faros о росте числа эпиков на человека на 66% и времени ревью впятеро: узкое место переезжает из написания кода в его приёмку.
Что означают ускорение ×3,2, κ = 0,03 и переделки с 35% до 15%
Это настройки автора модели, а не универсальные константы отрасли. Ускорение ×3,2 - допущение о том, во сколько раз ИИ ускоряет работу над продуктом. κ = 0,03 - принятая цена координации. Снижение переделок с 35% до 15% - допущение о том, что ИИ помогает сократить долю работы, которая возвращается на переделку после стыковок.
Менять эти значения можно и нужно. Другой вопрос, что результат поедет: если ваш продукт живёт в легаси-коде с плотной координацией, κ окажется выше, а снижение переделок скромнее. Тогда 4,2 человеко-эквивалента превратятся в куда менее впечатляющее сокращение.
Сколько людей останется: примеры для нового продукта и унаследованной системы
Оба сценария посчитаны при одних настройках: ускорение ×3,2, κ = 0,03, переделки с 35% до 15%. Разница только в типе системы.
| Сценарий | Команда до | Человеко-эквиваленты после |
|---|---|---|
| Новый продукт | 30 | около 4,2 |
| Унаследованная система | 30 | около 12,5 |
Разрыв в три раза объясняется не магией ИИ, а свойствами системы. В legacy больше координации и переделок на стыках, код сложнее менять, и ускорение упирается в ограничения, которые модель фиксирует через κ и r.
Почему унаследованная система сжимается слабее нового продукта
В унаследованной системе выше цена координации и доля переделок, поэтому даже при том же ускорении человеко-эквивалентов остаётся больше. 12,5 против 4,2 - это не аргумент против поддержки legacy, а напоминание, что ИИ-ускорение не отменяет сложность системы.
Обратная сторона: отлаженный годами код и локальные модели для чувствительных задач остаются активом, который ИИ не переписывает с нуля. Подробнее об этом в разборе что остаётся ценным в IT, когда нейросети есть у всех.
Что это значит для вендора: сокращение штата при сохранении и расширении выпуска
| Тип вендора | Штат до | Штат после при сохранении выпуска |
|---|---|---|
| Малый | 125 | 71 |
| Крупный | 3000 | 1476 |
Сценарий «сохранить выпуск» самый неприятный для людей и самый простой для расчёта: продукт уже продаётся, объём работ не растёт, а ИИ позволяет делать тот же объём меньшим составом. Сокращение здесь арифметическое следствие модели, а не прогноз конкретной компании.
Куда возвращаются люди при переключении на расширение выпуска
Второй сценарий мягче. Если вендор выбирает рост выпуска, часть высвобожденных ресурсов уходит в продажи, поддержку и внедрение. Разработка ускоряется, а клиентов, интеграций и вопросов от пользователей становится больше, и кто-то должен этим заниматься.
Это качественный сдвиг структуры: доля инженерных ролей падает, доля клиентских растёт. Условие сохранения выпуска, при котором посчитаны 71 и 1476 человек, в этом сценарии уже не действует.
Почему ускорение написания кода не равно ускорению поставки: данные Faros и CircleCI
Автор модели приводит два набора данных, которые объясняют, куда уходит выигрыш. По данным Faros, число эпиков на человека выросло на 66%, а время ревью - впятеро. По данным CircleCI, пропускная способность основной ветки у медианной команды упала на 6,8%.
Расшифровка простая. Инженер с ИИ-ассистентом выдаёт больше кода, и этот код нужно проверить, свести с чужими изменениями и довести до продакшена. Ревью, согласование и интеграция не ускоряются вместе с генерацией, поэтому в модели W параметры κ и r не падают до нуля, а если процесс настроен плохо, могут даже вырасти.
Методологию и контекст этих замеров источники не раскрывают, поэтому переносить 66% и 6,8% на конкретную команду без проверки не стоит. Их роль здесь в другом: показать направление, в котором смещается узкое место.
Ревью как новое узкое место
Ревью - это координационная работа, и она плохо масштабируется ускорением. Чем больше эпиков на человека, тем больше объём проверки, и тем сильнее один ревьюер тормозит остальных. Это ограничение модели, а не её побочный эффект: она изначально исходит из того, что ускорение продукта не отменяет затраты на координацию.
Практический вывод для тимлида: смотреть на длину очереди на ревью и на время от коммита до продакшена, а не на скорость генерации кода. Если очередь растёт, ускорение погасит само себя.
Три механизма, которые определят экономику софтверных вендоров
Автор разбора описывает три силы, от которых зависит, что произойдёт с рынком ПО. Джевонс: удешевление производства софта может увеличить общий спрос, а не сократить его, потому что дешёвое производство открывает задачи, за которые раньше никто не платил. Насыщение: рынок может насытиться быстрее, чем компании успеют перестроиться под новые издержки. Вычитание спроса моделями: ИИ-модели закрывают часть задач, под которые раньше покупали софт, и этот спрос уходит из выручки вендоров.
Механизмы тянут рынок в разные стороны. Джевонс расширяет его, насыщение сужает окно возможностей, вычитание спроса моделями отрезает часть выручки. Для конкретного вендора итог зависит от того, попадает ли его продукт в зону, которую модель закрывает сама.
«Парадокс испуганного рынка»: почему страх ускоряет насыщение
Формулировка автора: страх потери бизнеса заставляет компании ускорять производство и приближать насыщение. Компания вкладывается в ИИ-ускорение, чтобы не отстать, и вместе с остальными ускоряет выпуск. Чем быстрее выпускают все, тем быстрее рынок насыщается и тем меньше остаётся пространства для дифференциации. Логика отказа от инноваций и цена такого решения разобраны в статье можно ли отказаться от ИИ сегодня.
Это концепция автора, а не подтверждённый закон рынка. Проверить её можно по поведению вендоров: если страх действительно гонит всех в одну сторону, выпуск растёт быстрее выручки, и это видно в метриках удержания.
Что происходит с монетизацией: NRR, расходы на ПО и малые команды
По данным SBI, которые приводит автор разбора, медианный NRR снизился со 110,5% до 107,1%. NRR показывает, сколько выручки приносят те же клиенты год к году: 107% означают медленное расширение, 110,5% - заметно более быстрое. Падение на 3,4 процентного пункта меняет экономику подписки: вендор растёт медленнее при тех же затратах на привлечение.
Прогноз Gartner из того же разбора: расходы на ПО в 2026 году составят $1,468 трлн, а доля малых команд к 2029 году вырастет с 15% до 60%. Расходы на ПО растут, но это не гарантия роста выручки конкретного вендора: деньги могут уходить в модели и инфраструктуру, а не в подписки на прикладные продукты. Оба прогноза относятся к 2026 и 2029 годам и могут не сбыться.
Почему малые команды становятся нормой
Если команда из 30 человек сжимается до 4,2 человеко-эквивалента, экономика малых команд меняется: меньше координации, ниже ФОТ, быстрее решения. Прогноз Gartner про рост доли малых команд с 15% до 60% к 2029 году укладывается в эту логику. Как меняется единица конкуренции и почему часть универсальных SaaS теряет смысл, разобрано в статье ИИ снижает стоимость реализации.
Для вендора это значит, что модель монетизации придётся пересматривать. Подписка с расчётом на расширение клиента плохо сочетается с NRR 107,1% и клиентами, которые сами собирают нужное на моделях. Вариант, который укладывается в расчёт: продавать результат и внедрение, а не места в лицензии.
Ограничения модели: где расчёт работает, а где может обмануть
Модель стоит на допущениях автора: ускорение ×3,2, κ = 0,03, снижение переделок с 35% до 15%. Реальные проекты не обязаны совпадать с этими значениями, и чувствительность результата к ним высокая. Данные Faros, CircleCI, SBI и Gartner приведены без методологии и контекста, поэтому их стоит читать как указание направления, а не как норму.
Эффект на вендора посчитан при условии сохранения прежнего выпуска. При переключении на расширение выпуска часть людей возвращается в продажи, поддержку и внедрение, и сокращение уже не такое глубокое. Прогнозы Gartner относятся к 2026 и 2029 годам: это прогнозы, а не факты.
Ещё одно ограничение лежит вне арифметики. Модель ничего не говорит о качестве выпущенного продукта и о цене ошибки: генеративный ИИ уверенно выдаёт правдоподобные ответы там, где нужна проверка причин и следствий. Об этом в разборе почему генеративный ИИ путает причинность.
Как использовать модель без ложной точности
Считайте сценарии, а не прогнозы. Подставьте свои n, κ и r и прогоните три варианта: базовый, оптимистичный и пессимистичный. Посмотрите, насколько меняется W при сдвиге κ на 0,01 и при снижении переделок на 10 процентных пунктов. Если результат скачет в разы, модель показывает неустойчивость вашего процесса, а не численность будущей команды.
Проверяйте допущения замерами: время ревью, доля задач, вернувшихся на переделку, длина очереди на согласование. Цифры 4,2 и 12,5 не универсальны, а структура расчёта переносится на любую команду.
Что делать тимлиду и руководителю продукта: практические выводы
- Найдите узкое место до того, как ускорять работу. Если очередь на ревью уже растёт, ускоренная генерация кода добавит работы, а не сократит сроки.
- Разделите работу на продукт, координацию и переделки и оцените каждую часть. Разные части требуют разных инструментов и разного числа людей.
- Посчитайте человеко-эквиваленты и ФОТ по своей команде с честными κ и r. Если координация дорогая, сначала сокращайте её, потом ускоряйте продукт.
- Определите, какие клиентские функции вырастут при расширении выпуска. Продажи, поддержка и внедрение забирают людей обратно, и это стоит планировать заранее.
- Проверьте модель монетизации с учётом медианного NRR 107,1% и роста расходов на ПО. Подписка на места и на расширение клиента требует пересчёта.
- Держите в уме качество результата. Ускоренный выпуск дефектов ускорением не считается, а проверка причин и следствий остаётся за человеком.
Модель полезна одним: она превращает разговор о том, как встроить ИИ в разработку, в арифметику по трём параметрам и показывает, где вы теряете людей и деньги. Дальше начинается работа с реальными замерами вашей команды, и никакая формула её не заменит.