Последние полтора года в индустрии сложилась новая модель компании. Я её слышал под полудюжиной имён — AI-native, AI-first, tiny team, agentic startup, composable team. Под каждым названием — одно и то же устройство: PO/founder, tech lead, по одному senior-инженеру на компетенцию, и AI-агенты вместо всего остального. Команда из 3–7 человек выкатывает продукт, на который пять лет назад нужно было 30–50.
Эта модель работает. Cursor, Midjourney, Levels.fyi, Gumroad после layoffs — реальные примеры, не маркетинг. Но у неё есть свойство, о котором редко пишут: AI-native компания умножает не только скорость, но и накопление технического долга. Без методологии она проживает первые шесть месяцев в три раза быстрее обычного стартапа, а следующие восемнадцать — в три раза мучительнее.
Эта статья — разбор модели и условий, при которых она выживает.
Это продолжение блока «методология + AI»: зачем методология при AI, как ревьюить AI-код, как настроить инструменты, язык для AI-кодинга в команде. Здесь — на какой формат команды этот стек ложится естественнее всего, и где он становится не приятным дополнением, а условием выживания.
Что такое AI-native компания
Определение я даю короткое: компания, в которой рутинные функции в разработке выполняют AI-агенты, а не люди. Не «команда использует Copilot», это сейчас все. А «команда сознательно не нанимает junior-разработчиков, отдельных QA, отдельных системных аналитиков, технических писателей и code reviewers, потому что эти роли закрывают агенты».
Типовой состав:
- PO/founder — продукт, требования, приоритизация.
- Tech lead/архитектор — решения по доменной модели, стеку, границам сервисов, нефункциональным требованиям.
- По одному senior-инженеру на ключевую компетенцию — backend, frontend, data, devops. Не «по три», а «по одному». Каждый — самостоятельная единица.
- AI-агенты — всё остальное. Claude Code и подобные пишут код, генерируют тесты, делают первый проход review, собирают спеку из брифа, обновляют документацию, чинят миграции, делают мелкие рефакторинги.
Что важно: в этой модели нет junior-разработчиков. Не потому, что их «вытесняет AI», а потому, что в маленькой команде нет ресурса на их выращивание. Раньше senior закрывал сложное и оставлял junior учиться на простом — теперь простое забирает агент, и junior-у остаётся ноль контекста для обучения. Поэтому в AI-native компанию приходят сразу senior-ы.
Скорость, с которой такая команда движется, удивляет даже тех, кто следит за индустрией. Продукт, который раньше шёл 18 месяцев со штатом 30 человек, выкатывают за 4–6 месяцев командой в 5–7 senior-ов плюс агенты.
Как устроена разработка внутри
Если разложить типичный спринт AI-native команды по операциям, картина такая.
Постановка задачи. PO формулирует требования в свободном виде. AI-агент (через специальный скилл вроде ucp-spec-design или аналог) превращает это в формальную спецификацию: API, доменные сущности, последовательности, граничные случаи. Spec ревьюит tech lead, не senior-инженер — это его уровень принятия решений.
Реализация. Senior-инженер открывает спеку и работает с агентом в формате «ведущий — исполнитель». Агент пишет код по существующим паттернам репозитория, инженер направляет архитектурно. Объём кода, который инженер физически набирает руками, сокращается в 5–10 раз. Объём кода, который проходит через его голову, — почти не сокращается, потому что весь сгенерированный код приходится прочитать и осмыслить.
Code review. Первый проход делает агент-ревьюер по чек-листам (как это работает). Он ловит нарушения стиля, выдуманные импорты, отсутствие тестов на краевые случаи, забытую идемпотентность. Второй проход — человек, и он смотрит на то, что агент по определению не видит: соответствие доменной модели, корректность бизнес-инвариантов, осознанные компромиссы.
Тесты. Агент пишет первичный набор тестов под спецификацию. Senior смотрит, добавляет специфичные кейсы, которые знает он и не знает агент.
Документация. Агент держит её актуальной: меняется код — обновляется markdown в репо. Не «один раз написали и забыли», а как естественный артефакт каждой PR.
Деплой и мониторинг. Здесь меньше всего изменилось. Devops-инженер настраивает пайплайны и алерты, агент помогает с конкретными скриптами и terraform.
Что в этой картине не делает агент: не принимает решения, которые нельзя откатить. Доменная модель, границы сервисов, выбор между Saga и 2PC, инцидент-менеджмент, ответ заказчику. Это всё человек.
Где AI-native компания ломается без методологии
Я наблюдал несколько таких команд изнутри, и сценарий разрушения у них одинаковый. Здесь те же риски, что и в любой команде с AI без методологии (см. подробный разбор), но с одним усилителем: в AI-native команде каждый риск умножен на скорость и поделен на количество людей, которые могут его поймать.
1. Тридцать сервисов в тридцати стилях — за полгода, а не за три
Обычная команда без методологии накапливает несогласованность медленно: десять разработчиков пишут по PR в день, ревью замедляет, общий контекст хоть как-то склеивается через разговоры в чате.
AI-native команда из пяти инженеров с агентами выкатывает в десять раз больше кода. Каждый сервис генерируется в новой сессии Claude, без связи с предыдущим. Через полгода — двадцать сервисов, каждый в своём стиле обработки ошибок, каждый со своим подходом к транзакциям, каждый со своими соглашениями именования. Воссоздать общий стиль ретроспективно стоит дороже, чем переписать половину.
2. Никто не помнит, как это написано
Это специфика именно AI-native, в обычной команде её нет. Senior, который делегировал агенту 80% набора кода, через три месяца открывает свой же сервис и не помнит логики. Не потому что плохо помнит — а потому что не он её писал, он только направлял. Контекст был у агента в той сессии, и сессия закрылась.
В обычной команде хоть кто-то всегда помнит — junior, который зубрил, тестировщик, который ломал. В AI-native такой памяти нет. Без явной спецификации в репо, восстанавливать контекст придётся через чтение кода — а код часто устроен так, как его написал бы средний разработчик, а не так, как нужно вашему домену.
3. Выдуманные паттерны закрепляются как стандарт
Агент в одной сессии выдумал странную обвязку — например, обернул бизнес-операцию в DTO с тремя уровнями вложенности «потому что в обучающих данных так часто делают». Senior не среагировал, code review был автоматический, паттерн ушёл в master. Через две недели агент же увидел этот код в репо как пример и повторил его в следующей задаче как «принятый в проекте стандарт». Через два месяца в кодовой базе пятнадцать таких обёрток — и теперь это уже выглядит как осознанное решение.
В обычной команде эту цепочку обрывает живой ревьюер. В AI-native — обрывать некому, цикл замкнут.
4. Журнал происходящего размывается
Регуляторный сценарий: вам нужно объяснить, почему в коде написано именно так. В обычной команде — git blame, автор, его комментарии в PR, его обоснование. В AI-native код «написал агент по запросу инженера», и весь содержательный контекст остался в чате с моделью, который, скорее всего, не сохранился. Если ваш домен под аудитом (финтех, медицина, госсектор) — это не теоретический риск.
5. Разворот бизнеса стоит как переписывание
В стартапе разворот бизнеса — нормальное событие. В обычной команде с методологией это означает: меняем UseCase-ы внутри устоявшихся слоёв, ядро домена живёт. В AI-native без методологии разворот означает, что меняется бизнес-смысл, а под ним пятнадцать сервисов в пятнадцати стилях, ни один из которых нельзя расширить, не сломав. Это не разворот, это переписывание с нуля.
Что нужно поверх, чтобы AI-native компания жила 3+ года
Хорошая новость: вся методологическая обвязка, которую крупные команды выстраивают годами, в AI-native команде разворачивается за неделю. Потому что её носитель — не люди, а скиллы и спека-как-код, и они подключаются однократно.
1. Скиллы вместо style guide. Все правила проекта — в Claude Code skills, агент применяет их сам. См. настройку плагинов под UCP. 11 из 12 атомарных скиллов в моём наборе работают без внешних зависимостей — порог входа низкий.
2. Спецификация в репо. Каждый сервис — со спекой по универсальному шаблону. Спека и код меняются в одном PR. Это та самая «память», которой нет в AI-native команде по умолчанию: не у людей, не у агентов, а в репо.
3. Tier зрелости подбирается осознанно, а не «всё на минимуме». Соблазн AI-native команды — сделать всё на Tier 1, потому что «MVP, агент быстро напишет». Через полгода ядро бизнеса, которое должно было быть на Tier 3 с DDD, превращается в кашу. Правильный паттерн — справочники и CRUD на Tier 1, ядро на Tier 2–3, внешние интеграции через порты Tier 4.
4. AI code review с первого дня. Не «потом подключим, когда вырастем», а сразу. Подключать на двадцати сервисах в пятнадцати стилях — больно, на одном сервисе — пятнадцать минут.
5. Memory Bank на проект. То, что должно быть общеизвестно команде — лежит в CLAUDE.md и подключаемых markdown в репо. Каждая новая сессия агента стартует с этим контекстом. Это компенсирует «никто не помнит, как это написано».
Эти пять штук вместе занимают примерно одну рабочую неделю senior-инженера на старте. Цена пропуска — переписывание через год.
Кейс
Близко к этой модели работает один из стартапов, с которыми я делал консалтинг — описано в «Код стартапа не превращается в legacy». Команда 4–8 разработчиков, активный AI-кодинг, MVP с быстрой эволюцией требований. Внедрили UCP с правильным выбором Tier по модулям и AI-скиллы для review каждой PR с первого дня.
Через полтора года: кодовая база остаётся читаемой, разворот бизнеса не требует переписывания фундамента, найм senior-ов проще, потому что чистый код видно на собеседовании.
Что забрать из статьи
- AI-native компания — это PO + tech lead + по одному senior на компетенцию + агенты. Не «команда с Copilot», а команда без рутинных ролей.
- Скорость растёт в 5–10 раз. Накопление технического долга — тоже в 5–10 раз, если ничего не делать.
- Пять характерных рисков: расходящиеся стили между сервисами, потеря памяти о коде, выдуманные паттерны как стандарт, размытый журнал происходящего, разворот бизнеса ценой переписывания.
- Лекарство — методология, разворачиваемая через скиллы и спеку-как-код за неделю на старте. Цена пропуска — переписывание через год.
- AI-native — модель, в которой методология ценнее, чем когда-либо. Не вопреки AI, а из-за него.