Здравствуй, Хабр!

Я давно сознательно избегал трех бесячих тем: фронтир-моделей, автономных агентов ради самих агентов и разговоров про AI-native компании. Потому что вокруг них сейчас слишком много маркетинга и слишком мало инженерной конкретики.

Но после доклада AWS про команды в мире агентского ИИ стало понятно, что интересный вопрос тут не какая модель победит, а какая операционная модель переживет удешевление разработки и придумали ли уже что-то по делу. Статья перед тобой разбор тысяч публикаций про то что думают всякие MAANG о том какие команды в итоге получатся.

СПОЙЛЕР: интернет кишит материалами про замену людей на ИИ, не про внедрение ИИ и то как куда-то внедрили Claude Code и все полетело.

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

1. Модель больше не является преимуществом

Главная мысль AWS очень простая: доступ к сильной модели перестает быть дифференциатором. Модель можно купить через API, взять в готовом продукте или встроить в свой процесс через агентный слой. Разница возникает не в том, кто первым подключил модель, а в том, кто сумел встроить ее в управляемый контур исполнения.

AWS описывает это через развилку Use / Compose / Build.

Use -> берем готовый продукт.

Compose -> берем чужую модель и соединяем ее со своим контекстом, данными и правилами.

Build -> строим свое только там, где модельная способность действительно является ядром бизнеса.

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

Именно поэтому большая часть корпоративных разговоров про AI-native пока выглядит довольно комично. Люди спорят про модель (а некоторые до сих пор про закупку железа для GPU кластера), хотя спорить уже надо про рабочий процесс, границы автономии, проверки качества, учет стоимости и владельца результата.

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

2. Что на самом деле показал доклад AWS

Самый опасный поверхностный вывод из доклада звучит так: сеньор с агентами заменяет команду.

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

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

ЗВУЧИТ КАК МНОГО ХОРОШИХ УСЛОВИЙ ПОЛУЧАЕТСЯ. В природе сейчас такого мало.

Это хорошо ложится на расфоршенный кейс One Developer Is All You Need: https://arxiv.org/abs/2605.18461.

Там один staff engineer с четырьмя агентами закрыл браунфилд кровавую инициативу, которую раньше ожидали от целой команды. Но ключевая деталь не в количестве агентов. Ключевая деталь в том, что у этого человека уже были контекст, качество спецификации, доступ к системам и способность валидировать результат.

То есть агент не отменяет экспертизу. Он капитализирует уже существующую экспертизу.

Без этого one-person squad становится не новой оргмоделью, а дорогим bus factor. Пока этот человек в строю, все красиво. Как только он уходит, вы остаетесь с кодом, агентными обвязками и когнитивным долгом, который никто не понимает.

3. Новые роли: не новая мода, а новая единица ответственности

Самый интересный сдвиг последних месяцев,это даже не рост AI engineer. Это размытие границ между продуктовой, инженерной, платформенной и внедренческой работой.

Рынок сейчас активно нащупывает для этого новые ярлыки: product builder, product engineer, agentic engineer, platform engineer, forward deployed engineer, AI PM.

Снаружи кажется, что это просто очередная инфляция названий должностей. На деле меняется единица вклада.

Product builder -> это уже не классический PM, который пишет PRD и передает его дальше. Это человек, который приносит в обсуждение не намерение, а проверяемый прототип. Именно это сейчас происходит на практике с Cursor, Claude Code и похожими инструментами: продуктовая гипотеза впервые проверяется не через длинный цикл документ → разработка → демонстрация, а через быстрый рабочий артефакт.

Про это хорошо пишет Mind the Product и довольно забавно что Atlassian. С той же стороны на это смотрят Reforge и Every: продуктовая роль не умирает, но резко сдвигается от процессной координации к проверке гипотез через артефакты.

Product engineer -> это уже обратное движение. Инженер не ждет спущенного ТЗ, а работает ближе к пользователю, метрикам и продуктовой ставке. Эту логику давно и последовательно двигает PostHog: чем дешевле реализация, тем менее оправданной становится толстая прослойка между рынком и кодом.

Agentic engineer -> это уже не просто бекендер узнавший про Langchain Studio, Langfuse и LM Studio в старом смысле. Это инженер, который проектирует не один вызов модели, а поведение системы из агентов, инструментов, проверок, памяти и обратной связи. Здесь полезны Agentic AI in Product Management, The Rise of the AI Engineer и фаулеровская Harness Engineering: главная единица разработки смещается от функции к управляемому контуру выполнения.

Platform engineer в этой картине не исчезает, а становится важнее. Просто это уже не человек, который поднимает кубер и делает некий энайбл платформ. Это владелец общего слоя: идентичность агента, права, журнал действий, управление памятью, лимиты, наблюдаемость, каталоги инструментов, оценка стоимости и общие правила запуска. Именно поэтому OpenAI отдельно рассказывает про рост platform engineering в мире Codex и агентных рабочих процессов:
OpenAI’s head of platform engineering on the next 12–24 months of AI

Forward deployed engineer -> вообще отдельный симптом рынка. Если честно я его не понял. Сам факт, что такие роли массово растут у OpenAI, Anthropic и в enterprise-first компаниях, говорит о главном: между демо и внедрением лежит толстый слой интеграций, политик доступа, доменных ограничений и организационной боли. То есть модель сама в компанию не внедряется. Ее кто-то должен протащить через реальную операционку.

В этом смысле полезно посмотреть и на сам рынок вакансий. У OpenAI, Anthropic, Palantir-подобных компаний и enterprise-first вендоров растет спрос не на prompt engineer, а на людей, которые умеют одновременно говорить с клиентом, понимать систему и собирать рабочий контур вокруг модели.

Снаружи это уже проявляется даже на уровне внутреннего языка компаний. В Meta сотрудники и PM начали переименовываться в AI builders, а на стороне Cursor инженеры уже отдельно проговаривают, что PM теперь могут приносить рабочие прототипы, но инженерные границы и ожидания от качества должны стать жестче:
A Cursor developer says engineers need to set ‘clear expectations’ as AI lets product managers build prototypes

Поэтому я бы формулировал это так: новые роли появляются не потому, что рынок придумал новые названия. Они появляются потому, что старая цепочка передачи контекста начинает разваливаться.

И здесь же полезно разобрать свежий твит Бориса Черного, где он предлагает смотреть на AI-native команду через пять архетипов: prototyper, builder, sweeper, grower, maintainer. В этом твите есть сильная мысль и есть сильное упрощение.

Сильная мысль в том, что роли действительно начинают описываться не должностями, а типом вклада в жизненный цикл продукта. Это точное попадание в реальность. Люди уже все хуже помещаются в старые ярлыки PM, backend, frontend, designer. Один и тот же человек сегодня собирает прототип, завтра чистит архитектуру, послезавтра валидирует ставку с пользователем.

Но упрощение тоже заметное. Модель Черного хороша как описание ролей внутри маленькой боевой капсулы. Она плохо описывает организацию целиком.

Почему она ошибочна или, точнее, недостаточна.

Во-первых, в ней почти исчезает platform engineer. В реальной компании кто-то все равно должен собирать общий слой переиспользуемых кирпичиков. Без этого мы ловим кучу силосов, capsuled execution (модное слово, узнал из комментариев к посту) и очень быстро все превращается в локально оптимизированный хаос.

Во-вторых, в ней размазывается agentic engineer как отдельная инженерная функция. Builder еще не равен инженеру агентного контура. Умение быстро довести прототип до рабочего состояния не тождественно умению проектировать ивалы, гварды, многошаговые тул флоу и поведение системы при частичном отказе.

В-третьих, в ней вообще не виден слой выращивания экспертизы. Роли prototyper/builder/sweeper/grower/maintainer описывают вклад зрелых людей, но ничего не говорят о том, откуда возьмутся следующие зрелые люди. А это центральная проблема hourglass-структуры из AWS.

То есть я бы переформулировал так: схема Черного полезна как язык для описания типа вклада внутри AI-native pod. Но если натянуть ее на всю организацию, она обрезает платформу, управление риском и воспроизводство экспертизы.

4. Структура команд: почему пирамида умирает, а песочные часы — нет

Вторая сильная идея из AWS -> эволюция оргформы.

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

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

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

Но целевая модель для организации, не перевернутая пирамида, а песочные часы.

Именно здесь доклад AWS сильнее большинства попсовых разборов. Он не говорит сеньоры и агенты победят всех. Он говорит: на уровне исполнения вам действительно нужны маленькие senior-heavy команды, но на уровне организации вы обязаны сохранить нижний слой выращивания экспертизы.

Иначе через 5–10 лет у вас не останется людей с суждением. А суждение, как бы банально это ни звучало, не скачивается из модели. Оно набирается через ревью, ошибки, поддержку, инциденты и боль.

То есть скорость без преемственности — это не AI-native. Это просто ускоренный путь к кадровой яме.

5. Операционная модель: агент не терпит старого Dev/Ops-разрыва

Третья сильная линия доклада, Model A, B, C.

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

Model B: команда сама строит и сама запускает. На малом масштабе это работает отлично.

Model C: автономные капсулы поверх общей платформы. И вот это уже выглядит как целевая форма масштабирования.

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

Именно здесь снова появляется platform engineer как одна из ключевых фигур AI-native компании. Пока рынок спорит про product builder, под капотом всегда остается скучная, но критичная работа: собрать общий контур исполнения так, чтобы ten pods не строили десять разных способов хранить память агента, аудировать действия и ограничивать доступ к данным.

Поэтому агентский ИИ не отменяет DevOps. Он делает незавершенный DevOps непростительно дорогим. Это же видно и по тому, как AWS продает AgentCore не как еще одного агента, а как слой подключения, защиты tool calls, отладки и масштабирования.

6. Управление агентами: не регламент, а исполняемый контур

Последний важный вывод. Если агенту просто дать инструменты и попросить быть хорошим, вы не получили новую операционную модель. Вы получили ускоренный способ наделать дорогих ошибок.

Именно поэтому так быстро растут разговоры про policy outside prompt, идентичность агента, runtime-проверки и audit trail. Сингапурский Model AI Governance Framework for Agentic AI и его юридический разбор важны не бюрократией, а простой инженерной мыслью: агент должен быть проверяемым субъектом до действия, а не после инцидента.

Если у агента нет явной идентичности, прав, журнала действий, границ доступа к данным и владельца результата, это не AI-native контур. Это shadow AI с красивой презентацией.

Вывод

AI-native компания — пока не понятно что это, но точно не компания, где всем раздали чат-ботов и coding agents.

Это компания, где рабочие процессы, структура команд, платформа, права, проверки и выращивание экспертизы спроектированы под совместное исполнение людей и агентов.

Модели дешевеют. Исполнение ускоряется. Цена ошибки при этом не падает. Поэтому главная дефицитная способность ближайших лет не уметь пользоваться ИИ, а уметь строить вокруг него контур, который не развалится от собственной скорости.