ИИ-компании в России строят команды вокруг процессов, а не моделей: что меняется в ролях

Поводом для разбора стал доклад AWS о командах в эпоху агентного ИИ и последовавший за ним анализ тысяч публикаций о том, как крупнейшие технологические корпорации (Google, OpenAI, Anthropic, Amazon) перестраивают внутренние структуры. Автор разбора на Хабре, инженер-практик, намеренно обходивший хайповые темы вроде «ИИ-нативных компаний», зафиксировал неприятную закономерность: интернет переполнен материалами про замену людей на ИИ, но почти пуст в части честного анализа того, что происходит с оргструктурой, ролями и управлением при реальном внедрении.

Модель больше не козырь, козырь — процесс

AWS описывает три стратегии работы с ИИ: Use (взять готовый продукт), Compose (подключить чужую модель к своим данным и правилам), Build (строить своё, только если модельная способность и есть ядро бизнеса). Стратегия Build из варианта по умолчанию превратилась в редкий частный случай.

Это подтверждается действиями рынка. Google продвигает Antigravity, OpenAI развивает Codex, Anthropic развивает Claude Code, Cursor продаёт среду для агентного программирования, а Amazon строит платформенный слой Bedrock AgentCore. Все движутся в одном направлении: не «обучи свою модель», а «встрой управляемый контур исполнения в процесс».

Для ИИ-компаний в России этот вывод особенно практичен: спорить о выборе модели уже поздно. Спорить нужно о рабочем процессе, границах автономии агентов, проверках качества и о том, кто отвечает за результат.

Один сеньор с агентами заменяет команду?

Самый опасный поверхностный вывод из доклада AWS звучит именно так. Он удобен менеджеру, который хочет срезать найм и показать окупаемость. Но он неверен.

Корректная формулировка жёстче: сильный инженер с агентами действительно делает больше, но только при наборе условий. У него уже есть чёткие цели, доменный контекст, инженерное суждение и право принимать решения.

Это подтверждает кейс, описанный в публикации «One Developer Is All You Need» (arXiv, 2605.18461). Один staff-инженер с четырьмя агентами закрыл крупную инициативу, которую раньше ожидали от целой команды. Но у него уже были контекст, качественная спецификация, доступ к системам и способность проверять результат. Агент не отменил экспертизу. Он капитализировал уже существующую экспертизу.

Без этого «команда из одного человека» становится не новой оргмоделью, а bus factor (риск, при котором уход одного человека парализует проект). Пока этот человек в строю, всё работает. Как только он уходит, остаётся код, агентные обвязки и когнитивный долг, который никто не понимает.

Аргументы за перестройку команд

• Скорость проверки гипотез. Продуктовая гипотеза впервые проверяется не через длинный цикл «документ, потом разработка, потом демонстрация», а через быстрый рабочий прототип. Cursor, Claude Code и аналогичные инструменты дают человеку с продуктовым мышлением возможность принести в обсуждение не намерение, а работающий артефакт.

• Новые роли отражают реальный сдвиг. Product builder, product engineer, agentic engineer (инженер, проектирующий поведение системы из агентов, инструментов, проверок и памяти), platform engineer, forward deployed engineer, AI PM: за инфляцией названий стоит изменение единицы вклада. Инженер работает ближе к пользователю. Продакт-менеджер приносит не PRD (документ с требованиями), а проверяемый прототип.

• Платформенный инженер становится важнее, а не исчезает. Он владеет общим слоем: идентичность агента, права, журнал действий, управление памятью, лимиты, наблюдаемость, каталоги инструментов, оценка стоимости. OpenAI отдельно описывает рост platform engineering в контексте Codex и агентных рабочих процессов.

Аргументы против поспешной перестройки

• Условия успеха редки. «Один разработчик заменяет команду» работает только при сочетании глубокой экспертизы, доступа к системам и права на решения. В большинстве организаций этого набора нет.

• Когнитивный долг. Код, написанный в связке с агентами, часто понятен только автору. При его уходе команда получает не актив, а чёрный ящик.

• Обсуждения подменяются маркетингом. Как фиксирует автор разбора, корпоративные разговоры про «ИИ-нативные компании» выглядят комично: люди спорят про выбор модели или закупку GPU-кластера, хотя спорить нужно про рабочий процесс и владельца результата.

• Для ИИ-компаний в России добавляется ещё один барьер: часть инструментов (Cursor, Claude Code, Codex в полной версии) недоступна напрямую или доступна с ограничениями, что делает копирование западных оргмоделей без адаптации рискованным.

Агент не отменяет экспертизу. Он капитализирует уже существующую экспертизу. Без этого one-person squad становится не новой оргмоделью, а дорогим bus factor. : Автор разбора на Хабре

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

Автору на Дзене. Попробуйте промпт-инжиниринг (составление точных инструкций для ИИ) не для генерации текстов, а для проверки гипотез: «сработает ли такой формат», «какие возражения читатель выдвинет». Агент полезен там, где у вас уже есть экспертиза, а не там, где вы хотите её подменить.

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

Предпринимателю в РФ и СНГ. Из доступных аналогов: YandexGPT и GigaChat дают API для интеграции в процессы. Но копировать западную оргмодель «один инженер плюс четыре агента» без собственного контекста и экспертизы опасно. Начните с Compose: подключите чужую модель к своим данным и правилам, не стройте своё с нуля.

Ближайшие 12 месяцев покажут не то, какая модель победит, а какие компании научатся выстраивать управляемый контур вокруг агентов: с правами, журналом действий, лимитами и понятным владельцем результата. Те, кто сейчас спорит о выборе модели вместо перестройки процесса, через год обнаружат, что опоздали не с технологией, а с организацией.