Обновлено 24 августа 2026 по опубликованной версии на Хабре. Главный тезис уточнён: tiny team — не новая норма и не «три человека с агентами», а конфигурация, жизнеспособность которой зависит от сложности системы и домена, цены ошибки и системы поддержки вокруг команды. Свежий CircleCI Q2 Pulse 2026 подтверждает тот же вывод: активность в feature branches растёт, но throughput main branch не растёт автоматически — bottleneck смещается в проверку, интеграцию и выпуск.

Коротко. В 2026 году один из заметных AI-native нарративов звучит примерно так: несколько сильных инженеров с агентами теперь способны делать работу, для которой раньше требовалась полноценная продуктовая команда. В этом есть правда. AI ускоряет исследование, прототипирование, написание кода, тестов и документации. Исследование Management Science, 2026 фиксирует рост производительности разработчиков, а CircleCI в отчёте State of Software Delivery 2026 показывает существенный рост throughput у наиболее эффективных команд. Но из этого легко сделать слишком сильный вывод: будто tiny team становится новой универсальной единицей разработки. На практике жизнеспособность маленькой AI-native команды зависит не столько от того, насколько хороши модели, сколько от четырёх вещей:

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

Четыре фактора жизнеспособности маленькой AI-native команды Три человека могут делать больше. Но насколько больше? AI действительно увеличивает объём работы, который способна выполнять небольшая команда. Исследование Management Science, 2026 с разработчиками Microsoft, Accenture и крупной компании из Fortune 100 показывает рост производительности при использовании generative AI. По данным CircleCI в отчёте State of Software Delivery 2026, число ежедневных запусков CI/CD-пайплайнов выросло в среднем на 59% год к году. Это сборки, тесты, проверки и деплои, а не число функций, дошедших до пользователей. Результат распределён крайне неравномерно: у топовых команд число запусков почти удвоилось, у медианных выросло лишь на несколько процентов. Это важная разница. Если бы дело было только в качестве AI-инструмента, эффект должен был бы распределяться значительно равномернее. Но один и тот же агент попадает в совершенно разные среды. Где-то он работает с новой системой, хорошей документацией и автоматизированными проверками. Где-то — с пятнадцатилетним legacy, десятками интеграций и бизнес-правилами, происхождение которых никто уже толком не помнит. Поэтому вопрос не только в том, сколько работы теперь способен выполнить инженер. Гораздо интереснее другое: какую сложность раньше обслуживали люди — и какую её часть AI действительно смог взять на себя?

Что говорят данные

Крупные данные не сравнивают небольшую продуктовую команду из трёх человек с более крупной. Они показывают условия, в которых ускорение AI превращается в поставку изменений: автоматическая проверка, интеграция и выпуск должны успевать за ростом числа изменений.

Есть два исследовательских кейса, близких к теме. В Itaú один staff-инженер с четырьмя AI-агентами выпустил инициативу за три спринта вместо шести, запланированных для команды из четырёх человек. Это один проект, сравнение сделано с историческим планом и предыдущей скоростью команды. В исследовании Chiron разобраны три программы модернизации ПО; там сравниваются процессы разработки, а оценка состава построена на сценариях укомплектования, а не на фактических трудозатратах.

Что сознательно не включаем в доказательную базу

  • Xceptor / Forte Group — vendor case study с внутренними production-метриками; нет контрольной группы и сравнения размера команд.
  • Netguru — опыт консалтинговой компании с расчётной альтернативой; нет фактического сопоставимого проекта и данных о поддержке после релиза.
  • JoinNextDev с кейсами Mayven, Ramp и Salesforce — нет первичных публикаций компаний, методики и проверяемых исходных данных.
  • Истории YC-стартапов из ChatGPTAIHub — компании названы псевдонимами, нет ссылки на продукт, репозиторий или сопоставимого сценария без AI.
  • CREAO и сольные проекты разработчиков — личные отчёты без независимой проверки, контрольной группы и долгосрочных показателей качества.

Фактор 1. Насколько сложна сама система?

Здесь полезна ось greenfield → brownfield. Это вполне устоявшиеся инженерные термины. Greenfield — система, которую создают практически с нуля. У команды мало legacy-ограничений, она сама выбирает архитектуру и соглашения, а большая часть необходимого контекста находится в создаваемой сейчас кодовой базе. Brownfield — развитие уже существующей системы. В ней накопились legacy-код, интеграции, исторические решения, ограничения и зависимости.

Шкала greenfield — brownfield Это не обязательно два отдельных типа проекта. Новый сервис внутри большого банковского ландшафта может быть greenfield внутри весьма brownfield-системы. Полезнее воспринимать это именно как шкалу. Почему это важно для AI Greenfield — почти идеальная среда для агента. Ему не нужно угадывать, почему семь лет назад команда решила нарушить собственный архитектурный паттерн. Значительную часть картины можно восстановить из кода, документации и текущих решений. На простых greenfield-задачах разбор AI Productivity Gains in Different Situations, 2026 фиксирует прирост производительности порядка 30–40%. В brownfield эффект, по разбору AI Productivity Gains in Different Situations, 2026 и статье AI Coding Tools: Greenfield vs Brownfield, заметно слабее, особенно на сложных изменениях. Проблема не обязательно в способности модели написать код. Агент видит:

  • что система делает сейчас. Но гораздо хуже видит:
  • почему она устроена именно так. За старым решением могут стоять недокументированный инвариант, ограничение соседней системы, контракт с клиентом или давно забытый production incident. Анализ AI Coding Agents on Legacy Codebases указывает на рост числа логических проблем и дефектов в AI-generated pull request’ах в legacy-кодовых базах. Поэтому в зрелой системе маленькой команде часто начинает не хватать не рук, а контекста. AI отлично ускоряет создание изменения. Но чем сложнее существующая система, тем больше человеческой работы требуется для ответа на второй вопрос: можно ли это изменение безопасно выпускать?

Фактор 2. Насколько сложен домен и где живёт знание?

Даже полностью новый продукт может оказаться плохим кандидатом для tiny team. Причина — сложность предметной области. Представим систему с большим количеством бизнес-правил, исключений, интеграций и исторических решений. Технически она может быть greenfield. Но людям всё равно нужно понимать:

  • почему существуют определённые исключения;
  • какие договорённости есть с другими системами;
  • какое поведение ожидают разные клиенты;
  • где заканчивается техническое решение и начинается бизнес-ограничение. У команды из трёх человек здесь возникает очень конкретный предел: объём end-to-end знания, который она способна устойчиво разделять между всеми участниками. Постепенно происходит специализация. Один человек лучше знает архитектуру. Второй — интеграции. Третий — продуктовые или регуляторные нюансы. Формально людей всё ещё трое. Но устойчивость команды уже другая.

Bus factor как проверка tiny team

Здесь полезно понятие bus factor — минимального количества людей, потеря которых способна остановить проект или существенную его часть. Показатель особенно интересен именно для маленьких AI-native команд. Если в команде три человека, но только один знает критичную интеграцию, bus factor этой области равен единице. Его отсутствие не означает падение производительности на 33%. Оно означает: этот класс решений временно вообще некому принимать. Поэтому один из лучших стресс-тестов для tiny team звучит так: Что произойдёт, если завтра любой человек из команды исчезнет на месяц? Если определённая часть продукта остановится, проблема уже не в productivity. Проблема в архитектуре знания.

Но разве AI не может стать вторым носителем контекста?

Частично может. Команда может складывать требования, архитектурные решения, историю изменений и другую информацию в knowledge base и давать агенту доступ через RAG — Retrieval-Augmented Generation, то есть механизм, при котором модель перед ответом находит релевантную информацию в корпоративных источниках. Это действительно снижает стоимость поиска контекста. Но есть принципиальное ограничение:

AI и база знаний: что агент может и не может восстановить AI хорошо возвращает записанное знание. Он не способен надёжно восстановить знание, которое никогда не было записано. Если архитектурное решение появилось после разговора двух команд в коридоре, RAG его не найдёт. Как отмечает разбор RAG knowledge base costs, если документ устарел, система может столь же уверенно вернуть устаревший ответ. А сама knowledge base требует обслуживания: синхронизации источников, удаления устаревшей информации, проверки качества поиска. Оценки RAG maintenance относят на такую работу заметную часть capacity команды. Поэтому RAG способен уменьшить bus factor, но не отменяет его. Рабочая комбинация выглядит скорее так: AI + актуальная документация + распределённое владение критическим знанием.

Фактор 3. Какова цена ошибки?

Третий фактор почти не связан с тем, насколько хорошо AI пишет код. Вопрос в другом: что произойдёт, если команда ошибётся? Ошибка в экспериментальной внутренней утилите и ошибка в расчёте банковской операции — принципиально разные события. Чем выше цена ошибки, тем больше системе нужны независимые проверки, separation of duties, security, compliance, risk и другие специализированные экспертизы. Особенно хорошо это видно в регулируемых областях: финансах, здравоохранении, критической инфраструктуре. Здесь важно не смешивать понятия. Regulated — не третий тип проекта наряду с greenfield и brownfield. Новая банковская система вполне может быть одновременно greenfield и регулируемой. Регулирование скорее усиливает отдельную ось — цену ошибки и необходимость независимого контроля. Например, European Commission в разъяснении AI Act указывает, что требования EU AI Act для high-risk AI systems включают документацию, логирование, human oversight и оценку соответствия. Поэтому три сильных инженера с агентами не превращаются автоматически в: три инженера + security engineer + юрист + compliance specialist. AI способен подготовить контекст, провести предварительный анализ, автоматизировать часть проверок и снизить количество ручной работы специалистов. Но некоторые решения команда не должна принимать самостоятельно, независимо от того, насколько хорошо агент подготовил ответ. И если такие экспертизы требуются каждую неделю, а не несколько раз в год, возникает разумный вопрос: являются ли эти специалисты на практике частью команды, даже если организационная схема говорит обратное?

Фактор 4. Какая система уже существует вокруг команды?

Это, пожалуй, самая недооценённая часть историй про tiny teams. Когда мы слышим: «Три человека построили продукт», полезно спросить, что уже существовало до этих трёх человек. Например:

  • CI/CD;
  • облачная инфраструктура;
  • observability;
  • security tooling;
  • готовые архитектурные компоненты;
  • design system;
  • developer platform;
  • автоматизированное тестирование;
  • модели и AI-инструменты;
  • специалисты, которых можно быстро подключить при необходимости. Поэтому некоторые истории про «три человека сделали продукт» правильнее читать так: Три человека сделали продукт поверх системы, которую до них построили десятки или сотни людей. Это никак не уменьшает достижение tiny team. Наоборот, именно здесь и находится настоящий leverage. Хорошая платформа позволяет продуктовой команде не заниматься задачами, которые совершенно не обязательно решать внутри каждой команды отдельно. Team Topologies предлагает удобный язык для описания такой конструкции: stream-aligned команда отвечает за изменение продукта, platform team предоставляет self-service capabilities, а специалисты с редкой экспертизой подключаются там, где это необходимо. AI дополнительно усиливает эту модель. Но он не заменяет её.

Что происходит, когда AI действительно ускоряет команду

Как ускорение кода переносит узкое место дальше по потоку Допустим, все четыре условия относительно благоприятны и AI действительно позволяет команде создавать изменения значительно быстрее. Тогда появляется следующий эффект. Узкое место перемещается. Код начали писать быстрее — bottleneck оказался в code review. Ускорили review — упёрлись в QA. Автоматизировали QA — обнаружили очередь на security review. Убрали её — выяснили, что deployment занимает три дня. По данным CircleCI в отчёте State of Software Delivery 2026, рост активности в feature branches далеко не всегда превращается в рост throughput основной ветки. DORA в разборе Balancing AI tensions описывает похожий феномен как verification tax: часть времени, сэкономленного на генерации, переносится на проверку AI-generated результата. Это не отдельный пятый фактор жизнеспособности tiny team. Скорее это проявление слабости четвёртого. Если AI резко увеличивает output разработки, система вокруг команды должна быть способна переварить этот поток. Поэтому для AI-native команды особенно опасно измерять локальную эффективность: сколько кода мы написали; сколько задач закрыли; сколько pull request’ов создали. Куда полезнее смотреть end-to-end: идея → production → подтверждённый результат. Если coding ускорился в два раза, а этот цикл почти не изменился, AI пока ускорил этап процесса, а не delivery.

Так когда три человека действительно могут быть командой?

Теперь можно собрать четыре фактора вместе. Tiny AI-native team выглядит особенно жизнеспособной, когда:

  1. Система относительно проста для изменения. Проект ближе к greenfield или команда работает внутри хорошо изолированной области с понятными интерфейсами.
  2. Критическое знание доступно и распределено. Контекст записывается, люди понимают смежные области, а bus factor не падает до единицы по ключевым решениям.
  3. Большинство ошибок обратимы. Цена неудачного изменения позволяет быстро экспериментировать, а независимые экспертизы нужны скорее точечно.
  4. Вокруг команды уже существует сильная система поддержки. Платформа, CI/CD, observability, автоматизированные проверки и доступ к нужным специалистам не превращают каждый релиз в отдельный организационный проект. При таком сочетании AI действительно способен сделать маленькую команду чрезвычайно эффективной. Более того, tiny team получает дополнительное преимущество, которое вообще не связано с AI: меньше коммуникационных связей, handoff’ов и координации. Но если несколько факторов уходят в противоположную сторону — зрелый brownfield, сложный домен, bus factor 1, высокая цена ошибки и слабая платформа — попытка сохранить команду из трёх человек начинает выглядеть не как AI-native организация, а как создание системного риска.

Четыре вопроса для своей команды

Поэтому вместо обсуждения магического размера команды я бы задавал четыре вопроса.

  1. Насколько сложно безопасно изменить нашу систему? Мы ближе к greenfield или к brownfield? Сколько важного контекста нельзя восстановить из самого кода?
  2. Где находится критическое знание? Можно ли принимать ключевые решения без конкретного человека? Каков bus factor отдельно по архитектуре, интеграциям, продуктовым правилам и эксплуатации?
  3. Какова цена ошибки? Насколько изменение обратимо? Какие решения требуют независимой проверки и каких специалистов нужно подключать регулярно?
  4. Что произойдёт, если AI удвоит output команды? Справятся ли review, тестирование, security, deployment и product validation? Именно последний вопрос мне кажется особенно полезным. Потому что он заставляет перестать обсуждать AI как инструмент для ускорения отдельных инженеров и посмотреть на систему delivery целиком.

Быстрый стресс-тест для техлида

Два стресс-теста для маленькой AI-native команды

Оцените каждый фактор: 0 — почти не ограничивает tiny team; 1 — есть заметный риск; 2 — серьёзное ограничение. Обсудить это можно на ретроспективе за десять минут.

Первый тест: любой один человек исчезает на месяц. Что полностью останавливается? Быстрый ответ показывает реальный bus factor.

Второй тест: AI завтра удваивает поток изменений. Где появится следующая очередь: ревью, тестирование, безопасность, релиз или проверка ценности для пользователя? Следующая инвестиция может потребоваться именно там.

Так всё-таки тренд или хайп?

Скорее тренд в правильном направлении — с опасностью сделать из него слишком универсальный рецепт. AI действительно позволяет сильным людям брать на себя большую часть цикла создания продукта. Некоторые команды станут меньше. Границы ролей будут размываться. Часть координационной и рутинной работы исчезнет. Но количество людей в команде — следствие, а не цель. Устойчивость tiny team определяется пересечением четырёх вещей: сложность системы × сложность домена × цена ошибки × система поддержки. Поэтому я бы с осторожностью относился к формуле: «Раньше здесь было десять человек, теперь достаточно трёх с агентами». Гораздо интереснее разобрать, что делали остальные семь. Если AI и платформа действительно забрали эту работу — tiny team может оказаться новой более эффективной конфигурацией. Если работу просто перестали видеть — она рано или поздно вернётся в виде bottleneck’ов, ошибок, перегруженных специалистов или bus factor, равного единице. И, пожалуй, главный вопрос AI-native организации тогда звучит не: «Сколько людей теперь можно убрать из команды?» А: «Какую часть сложности раньше обслуживали люди — и что именно теперь действительно взял на себя AI?»