В 2026 году из каждого утюга звучит тезис: несколько сильных инженеров с агентами теперь способны делать работу, для которой раньше требовалась полноценная продуктовая команда.
Далее подобные микро‑команды в 2–3 человека я буду называть tiny teams.
Эти команды часто ставятся рядом с концептом AI-native - это когда взаимодействие и процессы сразу выстроены с прицелом на AI-агентов и инструменты.
Его подогревают прогнозы Сэма Альтмана о «единороге из одного человека», заголовки о tiny‑team moment Кремниевой долины и истории вроде Lovable: $100 млн ARR за восемь месяцев при 45 сотрудниках. В такой подаче tiny team выглядит чуть ли не как будущее разработки и почти панацея.
В этом есть частичка правды. AI ускоряет исследование, прототипирование, написание кода, тестов и документации. Полевые исследования фиксируют рост производительности разработчиков, а CircleCI в State of Software Delivery 2026 показывает существенный рост throughput у наиболее эффективных команд.
Но отсюда легко сделать слишком сильный вывод: будто tiny team из трёх‑четырёх человек становится новой универсальной единицей разработки.
Почему направление вообще выглядит разумным? AI позволяет одному человеку закрывать больше частей delivery‑цикла и уменьшает потребность в узкой специализации и передаче из рук в руки. Поэтому часть продуктовых команд действительно может становиться меньше и автономнее. Но насколько далеко можно зайти в уменьшении команды, определяется четырьмя ограничениями.
Мне кажется, полезнее смотреть не на магическое число людей, а на четыре фактора, которые определяют жизнеспособность маленькой AI‑native команды:
сложность системы;
сложность домена и распределение знания;
цена ошибки;
система поддержки вокруг команды.
Привет, меня зовут Марат, я отвечаю за эффективность 50 команд в финтехе и сегодня мы детально разберем 4 фактора, влияющих на жизнеспособность концепции маленьких ai-native команд.
Во‑первых, что говорят исследования про микро‑команды?
CircleCI зафиксировал рост числа ежедневных запусков CI/CD‑пайплайнов на 59% год к году. Это сборки, тесты, проверки и деплои. Показатель отражает интенсивность разработки; он не показывает, сколько фичей в итоге дошло до пользователей. У медианной команды число запусков выросло на 4%, у нижнего квартиля роста в принципе не было.
Крупные данные показывают условия, в которых ускорение AI превращается в поставку изменений: автоматическая проверка, интеграция и релиз должны успевать за ростом числа изменений
Я намеренно убираю кейсы, которые описаны в case‑study вендоров, антропиков и компаний, которые делают деньги на создании инструментов для ai‑разработки (слишком много ангажированности и пиара — но внизу есть список таких статей). На мой взгляд, есть два исследовательских кейса, близких к теме. В Itaú один staff‑инженер с четырьмя AI‑агентами выпустил инициативу за три спринта вместо шести, запланированных для команды из четырёх человек. Это один проект, сравнение сделано с историческим планом и предыдущей скоростью команды. В исследовании Chiron разобраны три программы модернизации ПО; там сравниваются процессы разработки, а оценка состава построена на сценариях укомплектования, а не на фактических трудозатратах.
1. Насколько сложна сама система?
Здесь удобно использовать ось greenfield → brownfield.
Greenfield — система, которую создают практически с нуля: мало legacy‑ограничений, команда сама выбирает архитектуру, а большая часть контекста появляется прямо сейчас.
Brownfield — развитие существующей системы с накопленным кодом, интеграциями, историческими решениями и ограничениями.
Это именно шкала (не два взаимоисключающих типа). Например, новый сервис может быть greenfield, но жить внутри огромного brownfield‑ландшафта.
Для AI разница принципиальна.
В greenfield агент видит значительную часть необходимого контекста прямо в коде и текущей документации. Ему не нужно угадывать, почему семь лет назад кто‑то нарушил собственный архитектурный паттерн.
А вот в brownfield все сложнее: агент хорошо видит, что система делает сейчас, но не понимает почему она устроена именно таким образом.
За странным кодом может стоять недокументированный инвариант, ограничение соседней системы, договорённость с клиентом или production incident пятилетней давности.
Поэтому в зрелых системах маленькой команде зачастую начинает не хватать не рук, а контекста.
AI может очень быстро написать изменение. Но человеку всё ещё нужно понять, можно ли это изменение безопасно выпускать.
И чем больше такой работы остаётся на людях, тем слабее аргумент «раньше здесь было десять человек, а теперь достаточно трёх».
2. Насколько сложна предметная область и где живёт знание?
Даже полностью новый продукт может оказаться плохим кандидатом для tiny team. А все из‑за сложности предметной области.
Представим систему с десятками бизнес‑правил, исключений и интеграций. Технически она может быть greenfield. Но кому‑то всё равно нужно понимать (доменному эксперту):
почему существуют определённые исключения;
какие договорённости есть с соседними системами;
какое поведение ожидают разные клиенты;
где техническое решение заканчивается и начинается бизнес‑ограничение.
У команды из трёх человек здесь возникает ограничение, которое плохо видно на метриках а‑ля количеству закрытых задач: объём end‑to‑end знания, который команда способна устойчиво разделять между участниками.
Со временем появляется специализация.
Один лучше знает архитектуру.
Другой — интеграции.
Третий — продуктовые или регуляторные нюансы.
Формально людей всё ещё трое. Но сбей кого‑то автобус (bus factor) — команда перестанет работать (а не как считают менеджеры, топящие за tiny teams — снизится производительность на 33%). Ну, скорее какой‑то класс задач команда просто не сможет выполнять.
Хороший стресс‑тест для tiny team поэтому звучит так:
Что произойдёт, если завтра любой человек из команды исчезнет на месяц?
→ Если какая‑то часть продукта фактически остановится, проблема уже не в productivity. Проблема в архитектуре знания.
А если сложить весь контекст в RAG?
Думал я еще в начале этого года. Это в целом казалось панацеей, когда был бум context‑engineering'a. Частично это помогает.
Ключевое ограничение: AI хорошо возвращает записанное знание. Он не восстанавливает знание, которое никогда не было записано.
То есть, если решение появилось после разговора двух команд, которого нигде нет, агент его не найдёт. Если документ устарел, система может столь же уверенно вернуть устаревший ответ.
Казалось бы, всего‑навсего (аналитики тут усмехнутся) надо поддерживать актуальной базу знаний? Да, но сюда как будто приходится выделять целого бизнес‑эксперта, и пока совсем непонятно — станет ли это эффективным решением. Потому что по заветам того же context engineering, для того чтобы RAG выдавал адекватные ответы, надо выверять кучу данных, чтобы они не конфликтовали и были полными — а у каждой команды это разные уровни детализации.
Поэтому RAG снижает зависимость от отдельных людей, но не отменяет её.
Рабочая комбинация скорее выглядит так:
AI + актуальная документация + распределённое владение критическим знанием.
3. Какова цена ошибки?
Следующий фактор почти не связан с тем, насколько хорошо агент умеет писать код.
Вопрос проще: что произойдёт, если команда ошибётся?
Ошибка во внутреннем прототипе и ошибка в банковской операции — разные события.
Чем выше цена ошибки, тем больше системе нужны независимые проверки: безопасность, комплаенс, риски, юридические истории, дополнительное тестирование или человеческий надзор.
Регулирование просто резко повышает цену определённых ошибок и количество решений, которые команда не должна принимать самостоятельно.
Поэтому три инженера с агентами автоматически не превратятся в три инженера + инфобез + юрист + специалист по рискам.
Пусть AI собирает контекст, проводит предварительный анализ, автоматизирует проверки и уменьшает число ручных операций. Но если специализированная экспертиза нужна почти в каждой задаче, эти люди фактически становятся частью delivery‑системы команды — даже если оргструктурно они в другом отделе говорит иначе.
И тогда вопрос «сколько человек в tiny team?» становится немного искусственным. И еще вопрос: а руководитель тех специализированных людей вообще согласен выделять вам ресурсы быстро, чтобы не становиться бутылочным горлышком.
4. Какая система существует вокруг команды?
Это, на мой взгляд, самая недооценённая часть историй про маленькие AI‑native команды.
Когда мы слышим: «Три человека построили продукт», полезно спросить, что существовало вокруг этих трёх человек.
Например:
CI/CD;
observability;
облачная инфраструктура;
developer platform;
тулинг инструментов безопасности;
автоматизированное тестирование;
готовые компоненты;
архитектурные стандарты;
специалисты, которых можно быстро подключить;
продолжите список чем хотите.
В итоге, по моим наблюдениям, читать tiny teams надо как «Три человека сделали продукт поверх системы, которую до них построили десятки людей».
Это все равно круто и не умаляет достоинств такого сетапа команды, я бы даже сказал — это отличная демонстрация того, что надо правильно выстраивать топологию команд — создавать платформенные команды, узкоспециализированные сервисные там, где это ускорит остальные.
Хорошая платформа снимает с продуктовой команды работу, которую не обязательно повторять внутри каждой команды отдельно. +AI снимает ещё один слой рутины.
И вот тогда tiny team действительно становится возможной.
Что произойдёт, если AI действительно ускорит команду?
Предположим, условия благоприятны и AI позволяет разработчикам делать в два раза больше изменений.
Тогда мы сталкиваемся с классической локальной оптимизацией:
Ускорили coding → горлышко сместилось на проверку кода.
Ускорили проверку → упёрлись в тестирование.
Автоматизировали тестирование → ждем безопасников
Разобрались с безопасниками → релиз у нас три дня
Ускорили релиз → маркетологи еще не написали анонс новых фичей
и так далее.
CircleCI показывает похожую картину: рост активности в фиче‑бранчах не обязательно превращается в сопоставимый рост количества изменений в основной ветке. DORA описывает это как verification tax: часть времени, сэкономленного на генерации, переезжает в проверку результата.
Короче говоря, если AI увеличивает output разработки, система вокруг команды должна уметь этот поток переварить. Поэтому в AI‑native разработке ещё менее полезно измерять:
количество написанного кода;
количество pull request’ов;
локальную скорость разработки.
Гораздо интереснее смотреть end‑to‑end: идея → production → подтверждённый результат.
Когда tiny team действительно жизнеспособна?
Теперь можно собрать четыре фактора вместе.
Tiny AI‑native team выглядит особенно убедительно, когда:
1. Систему относительно просто безопасно менять.
Проект ближе к greenfield или команда работает внутри хорошо изолированной области.
2. Критическое знание доступно и распределено.
Контекст фиксируется, а bus factor не падает до единицы по ключевым областям.
3. Большинство ошибок обратимы.
Можно быстро экспериментировать, а независимые экспертизы требуются точечно.
4. Вокруг команды существует хорошая система поддержки.
Платформа, CI/CD, observability и автоматизированные проверки не превращают каждый релиз в организационный проект.
При таком сочетании AI действительно может сделать маленькую команду чрезвычайно эффективной.
Кроме того, у tiny team есть преимущество, вообще не связанное с AI: меньше коммуникационных связей, передач из рук в руки и координации.
Но если ситуация обратная — сложный brownfield, сложный домен, bus factor, высокая цена ошибки и нет поддерживающей платформы — маленький размер команды превращается из преимущества в источник хрупкости.
Я техлид, хочу понять мне подойдет Tiny Team или нет
А вот и практика — стресс‑тест, чтобы примерить модель на свою команду.
Можно провести десятиминутную диагностику. Поставьте каждому фактору оценку:
0 — почти не ограничивает tiny team
1 — есть заметный риск
2 — серьёзное ограничение
Дисклеймер: это не научная история, это просто (как на вашем любимом сайте) тест на подсветку фактора, который делает команду хрупкой. Провести можно на ретро.
Стресс‑тест № 1
Любой один человек исчезает на месяц. Что полностью останавливается?
Если ответ находится быстро — вы нашли свой реальный bus factor.
Стресс‑тест № 2
Завтра AI удваивает output разработчиков. Что станет следующим бутылочным горлышком?
Проверка кода? QA? Безопасность? Выкатка? Валидация гипотез на проде?
Возможно, следующая инвестиция вашей команды вообще не должна быть в AI.
Так всё‑таки тренд или хайп?
Это тренд, но не универсальный рецепт: AI расширяет количество изменений, которые которые может выкатить сильная, автономная команда. Да еще и убирает часть координационной рутины. Но размер команды — следствие контекста: сложность системы и домена, цена ошибки и платформа поддержки определяют, можно ли безопасно уменьшать состав.
Что сознательно исключено из доказательной базы
Эти истории помогают увидеть гипотезы и практики, но не отвечают на главный вопрос статьи: насколько tiny team эффективнее сопоставимой классической команды. Поэтому не используем их как доказательство:
Xceptor / Forte Group — vendor case study с внутренними production‑метриками; нет контрольной группы и сравнения размера команд.
Netguru — опыт консалтинговой компании с расчётной альтернативой; нет фактического сопоставимого проекта и данных о поддержке после релиза.
JoinNextDev с кейсами Mayven, Ramp и Salesforce — нет первичных публикаций компаний, методики и проверяемых исходных данных.
Истории YC‑стартапов из ChatGPTAIHub — компании названы псевдонимами, нет ссылки на продукт, репозиторий или сопоставимого сценария без AI.
CREAO и сольные проекты разработчиков — личные отчёты без независимой проверки, контрольной группы и долгосрочных показателей качества.
