AI native команды: 59% роста у лучших, 4% у остальных и четыре фактора разрыва

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

Термин AI native команды (когда процессы и взаимодействие сразу выстроены вокруг ИИ-агентов и инструментов) всё чаще звучит рядом с историями вроде Lovable: 100 млн долларов годовой повторяющейся выручки за восемь месяцев при 45 сотрудниках. Сэм Альтман говорит о «единороге из одного человека», медиа фиксируют «tiny-team moment» Кремниевой долины. Автор разбора, Марат, работающий с полусотней команд в финтехе, предлагает отложить восторги и посмотреть на ограничения. Источник анализа опубликован в авторском материале Марата.

Что показали исследования, а что нет?

• Рост сборок, а не фичей. CircleCI в отчёте State of Software Delivery 2026 зафиксировал рост числа ежедневных запусков CI/CD-пайплайнов (сборки, тесты, проверки и деплои) на 59 % год к году у лучших команд. У медианных команд рост составил 4 %. У нижнего квартиля роста не было. Показатель отражает интенсивность разработки, но не показывает, сколько функций дошло до пользователей.

• Один инженер вместо четырёх, но с оговоркой. В бразильском банке Itaú один staff-инженер с четырьмя ИИ-агентами выпустил инициативу за три спринта вместо шести, запланированных для команды из четырёх человек. Это единственный проект, а сравнение сделано с историческим планом.

• Сценарии, а не факт. В исследовании Chiron разобраны три программы модернизации ПО. Оценка состава построена на сценариях укомплектования, а не на фактических трудозатратах.

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

Четыре ограничения для AI native команд

Сложность самой системы: greenfield против brownfield

Greenfield (система с нуля) и brownfield (развитие существующей системы с накопленным кодом, интеграциями и историческими решениями) находятся на одной шкале, а не в двух разных мирах.

В greenfield ИИ-агент видит контекст прямо в коде и документации. В brownfield агент понимает, что система делает сейчас, но не понимает почему она устроена именно так. За странным кодом может стоять недокументированный инвариант, ограничение соседней системы, договорённость с клиентом или аварийная заплатка пятилетней давности.

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

Сложность предметной области и где живёт знание

Даже полностью новый продукт может не подходить для AI native команды малого размера. Система с десятками бизнес-правил, исключений и интеграций требует доменного эксперта (человека, который понимает, почему существуют конкретные исключения, какие договорённости есть с соседними системами и где техническое решение заканчивается и начинается бизнес-ограничение).

У команды из трёх человек со временем появляется специализация: один знает архитектуру, другой интеграции, третий продуктовые или регуляторные нюансы. Формально людей трое, но если кто-то выпадает, команда не «снижает производительность на 33 %», а перестаёт справляться с целым классом задач.

Стресс-тест, который предлагает Марат: «Что произойдёт, если завтра любой человек из команды исчезнет на месяц?» Если часть продукта фактически остановится, проблема не в производительности, а в архитектуре знания.

Цена ошибки

Этот фактор Марат выделяет отдельно. Чем дороже сбой (финтех, медицина, инфраструктура), тем больше проверок нужно до релиза. AI native команды из двух-трёх человек физически не могут обеспечить тот же объём ревью и тестирования, что и команда с выделенными ролями.

Система поддержки вокруг команды

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

Как оценить свою команду по этим факторам?

1. Определите, где ваш продукт на шкале greenfield и brownfield. Если больше половины работы связана с легаси-кодом и внешними интеграциями, AI native команда из двух-трёх человек рискует не справиться с контекстом.
2. Проведите стресс-тест bus factor (фактор автобуса, что будет, если ключевой человек выбывает): уберите мысленно каждого участника на месяц. Если какая-то область знаний полностью исчезает, вы уже за границей безопасного размера.
3. Оцените цену ошибки в вашем домене. В блоге или маркетинговом лендинге откат дешёвый. В платёжной системе или медицинском сервисе одна ошибка стоит месяцев работы.
4. Проверьте, есть ли у вас автоматический CI/CD-пайплайн (конвейер сборки, тестирования и доставки кода). Без него рост скорости от ИИ не дойдёт до пользователей.

Сравнение с российскими реалиями

В России и СНГ концепция AI native команд пока звучит реже, но стартапы уже экспериментируют. Из доступных инструментов для ИИ-разработки в РФ работают YandexGPT и GigaChat, однако агентные возможности (когда модель сама выполняет цепочку действий) у них пока ограничены по сравнению с тем, что описывают зарубежные кейсы. Для авторов и предпринимателей 50+ главный вывод простой: если вы собираете команду вокруг ИИ-инструментов, четыре фактора Марата работают одинаково что в Сан-Франциско, что в Москве или Алматы.

Что делать с этим прямо сейчас, по ролям

Автору Дзена. Если вы работаете с ИИ-инструментами для текста, проверьте себя по фактору «сложность домена». Чем больше вы разбираетесь в теме, тем эффективнее ИИ как помощник. Без экспертизы вы получите быстрый, но ненадёжный черновик.

Маркетологу. Четыре фактора Марата можно использовать как чек-лист при оценке подрядчиков: если AI native команда из двух фрилансеров обещает закрыть сложный проект с интеграциями, задайте вопрос про bus factor и цену ошибки.

Предпринимателю в РФ и СНГ. Концепция маленьких команд с ИИ-агентами работает, но не универсально. Прежде чем сокращать штат, пройдите стресс-тест и оцените, где знание распределено между людьми, а не зафиксировано в документации.

Частые вопросы

AI native команды из двух-трёх человек действительно заменяют большие отделы?

В узких условиях, да. По данным кейса Itaú, один инженер с четырьмя ИИ-агентами уложился в три спринта вместо шести. Но это greenfield-инициатива с низкой доменной сложностью. Для brownfield-систем с накопленным контекстом замена не работает: ИИ не знает историю решений, а проверка остаётся на людях.

Какой минимальный размер команды безопасен?

Универсального числа нет. Марат предлагает вместо магического числа использовать четыре фактора: сложность системы, сложность домена, цена ошибки и система поддержки. Если по любому из них вы в зоне риска, уменьшать команду опасно вне зависимости от того, насколько продвинуты ваши ИИ-инструменты.

Где взять данные, чтобы оценить эффект ИИ на свою команду?

Отчёт CircleCI State of Software Delivery 2026 даёт ориентир по интенсивности разработки. Для контент-команд прямых аналогов пока нет, но принцип тот же: измеряйте не скорость черновика, а скорость готового результата, прошедшего проверку и публикацию.