Skip to content

Команда из одной пиццы: почему ИИ делает меньшие инженерные команды более эффективными

Правило команды из двух пицц от Amazon десятилетиями было аксиомой: если нужно больше двух пицц, чтобы накормить команду, команда слишком большая. Но что-то меняется. Директора в традиционных компаниях теперь говорят о командах из одной пиццы. Математика меняется.

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

Исследования подтверждают это

Section titled “Исследования подтверждают это”

Исследование Гарварда и Уортона в P&G обнаружило поразительный факт: отдельные люди, использующие ИИ, показывали такие же результаты, как команды без него. А команды с ИИ значительно превосходили команды без ИИ в создании идей высшего качества.

Прочитайте ещё раз. Один человек с ИИ-инструментами соответствовал output традиционной команды.

Исследование Microsoft WorkLab называет это ростом “агент-босса” — от стажёров до руководителей, каждый будет управлять своим созвездием AI-агентов. Иерархия не уплощается; она расширяется в новое измерение, где люди оркестрируют машинный интеллект.

Как это выглядит на практике

Section titled “Как это выглядит на практике”

Инженерная модель Kilo — один пример. Каждый инженер владеет целой продуктовой областью и метрикой WAU, а не просто кодовой базой. Они управляют командами AI-агентов для распараллеливания работы, которая традиционно требовала бы нескольких человек.

Один инженер. Одна продуктовая область. Один показатель для владения. AI-агенты выполняют параллелизуемую работу.

Внутреннее исследование Anthropic показывает, что их инженеры теперь используют Claude в 60% своей работы, сообщая о 50% росте продуктивности — 2-3x увеличение по сравнению с предыдущим годом. Более показательно: 27% их работы с поддержкой Claude — это задачи, которые иначе не были бы выполнены. Это не просто эффективность. Это расширение возможностей.

Новая ментальная модель: инженеры как менеджеры агентов

Section titled “Новая ментальная модель: инженеры как менеджеры агентов”

Этот сдвиг требует думать о своей команде по-другому. Это не просто “сколько инженеров мне нужно?”, а “каково оптимальное соотношение людей и агентов для этой работы?”

Microsoft уже называет это “человеко-агентным соотношением” — новая метрика, которая будет варьироваться в зависимости от задачи, процесса и отрасли. Не угадаете — упустите ценность ИИ или перегрузите команду. Угадаете правильно — раскроете производительность, продемонстрированную в исследовании P&G.

Ваши лучшие инженеры уже не просто пишут код. Они:

  • Декомпозируют работу на части, подходящие для агентов
  • Проверяют результаты агентов на качество и корректность
  • Оркестрируют параллельные рабочие потоки через нескольких агентов
  • Принимают решения с которыми агенты не справляются
  • Поддерживают контекст, который агенты теряют между сессиями

Это менеджерские навыки, применённые к AI-системам. Должность остаётся “инженер”, но работа больше похожа на координацию.

Что это означает для структуры команды

Section titled “Что это означает для структуры команды”

Традиционное планирование команды: “Этому проекту нужен фронтенд-инженер, два бэкенд-инженера, DevOps-инженер и QA-инженер. Пять человек.”

AI-native планирование команды: “Этому проекту нужны два senior-инженера, каждый из которых может управлять рабочими потоками агентов в своей области, плюс один инженер, фокусирующийся на интеграции и качестве. Три человека с явным распределением агентов.”

Анализ InsideAI News утверждает, что ИИ на самом деле делает небольшие автономные команды ещё более необходимыми, а не наоборот. Когда отдельные участники могут иметь огромное влияние через ИИ-рычаг, накладные расходы на координацию больших команд становятся ещё более дорогими.

Сдвиг в распределении навыков

Section titled “Сдвиг в распределении навыков”

Исследование Galileo об AI-динамике команд подчёркивает, как ИИ размывает традиционные границы ролей. Все разделяют ответственность за продуктовые результаты, создавая кросс-функциональные команды, которые подходят к проблемам холистически.

Но это создаёт новую проблему: инженеры должны теперь развивать экспертизу в анализе продуктовых данных, обеспечении наблюдаемости системы и управлении полным жизненным циклом ПО — навыки, которые выходят за рамки написания кода. Как говорит Charity Majors: “Software engineering — это не про написание кода. Это про решение бизнес-проблем с помощью технологий.”

Инженеры, которые могут эффективно оркестрировать ИИ, становятся мультипликаторами силы. Те, кто не может, рискуют быть обойдёнными меньшими командами, которые могут.

Практические шаги для тимлидов

Section titled “Практические шаги для тимлидов”

Аудит структуры команды. Где вы переstaffите, потому что не учитываете ИИ-рычаг? Команда из 8 человек, делающая то, что могут 4 человека с хорошими AI-workflows, не sustainable, когда конкуренты это поймут.

Явно определите распределение агентов. Не позволяйте использованию ИИ быть спонтанным. Определите, какие рабочие потоки выигрывают от параллелизации агентов, и выделите ресурсы соответственно.

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

Тренируйте оркестрированию, а не просто кодированию. Вашим лучшим инженерам нужно развивать навыки в промпт-инженерии, дизайне агентских рабочих процессов и валидации AI-вывода. Это развиваемые навыки с накопительным эффектом.

Следите за расширением возможностей. Anthropic обнаружил, что 27% работы с ИИ-помощью — это новая работа, которая иначе не была бы сделана. Используют ли ваши команды ИИ, чтобы делать ту же работу быстрее, или чтобы делать работу, которая раньше была невозможна? Второе — это где живёт конкурентное преимущество.

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

Вопрос не в том, происходит ли этот переход. Вопрос в том, ведёте ли вы его или реагируете на него.