[Content hub](/ru/ai/content)

- type: blog_post

- published_at: 2026-09-04

- tags: agentic-operating-model, ai, practice

Почему AI-native начинается с процесса, контекста и ответственности, а не с выбора модели.

## Место менеджмента и новые роли в AI-native оргструктуре Привет, Хабр. Не знаю заметили ли вы, но я сознательно избегаю трех тем: SOTA-моделей, автономных агентов ради агентов и хайпа вокруг AI-native компаний. Гораздо интереснее то, как меняется структура команд и процессы, когда стоимость создания кода падает к нулю. Наткнулся на [доклад AWS](https://www.youtube.com/watch?v=O7u6myBRsns) про команды в мире агентского ИИ. Он не про новые тулзы. Он про то, как перестраивается операционная модель при изменении экономики исполнения. @[youtube](https://www.youtube.com/watch?v=O7u6myBRsns) --- ## <u>1. Экономика и развилка путей</u> AWS дает простую развилку: Use / Compose / Build. * **Use** — это потребление готового. * **Compose** — сборка процесса из моделей и ваших данных. * **Build** — создание собственной модельной инфраструктуры. Build оправдан только при уникальном ядре бизнеса. Для подавляющего большинства первичен разбор потока: где мы создаем ценность, где теряется контекст, где нужна жесткая проверка. AI-native трансформация начинается не с закупки токенов, а с описания процесса как исполняемой системы.  --- ## <u>2. Когнитивный долг и смерть "тимлида"</u> В наших [AI-чатах](https://t.me/cursor_kz) последние дни идет бурное обсуждение: а нужен ли вообще тимлид в эпоху агентов? Как пишет [teamleads.kz](https://teamleads.kz/shell/#team), выживание менеджера становится сродни уходу за тамагочи. Спойлер: классический тимлид, как диспетчер людей, мертв. Раньше мы оправдывали плохой код и отсутствие тестов нехваткой времени. Сейчас стоимость написания тестов — 10 минут. Технический долг закрывается быстро. Но на его место приходит долг когнитивный. Агенты генерируют абстракции мгновенно. Если инженер не понимает, как работает сгенерированный 10 минут назад код, он теряет контроль над продуктом. Когнитивный долг растет с неимоверной скоростью. ИИ ускорил создание фичей, но траты на коммуникацию никуда не ушли. Решение: радикально плоская структура. Никаких огромных отделов (12-16 человек), где разделены BA, SA, FE, BE, QA и DevOps. В AI-native мире это компактные боевые юниты по 4-6 человек с высокой связностью и полным владением модулем от начала до конца. --- ## <u>3. Таланты и новые роли: от профессий к типу вклада</u> AWS вводит понятие *expert generalist*: человек, который ведет процесс от проблемы до релиза. [Фаулер](https://martinfowler.com/articles/exploring-gen-ai/humans-and-agents.html) четко разделяет why-loop и how-loop: человек силен в выборе, *что* и *зачем* мы строим, а агент берет на себя исполнение. Об этом же пишет и [Andrew Ng](https://www.linkedin.com/posts/andrewyng_meta-pivots-from-open-weights-big-pharma-activity-7454559322900123648-zdsF): сборка ускоряется, узкое место смещается в продуктовые решения. Отсюда вытекает отказ от привычных лычек. В недавнем [твите Бориса Черного](https://x.com/bcherny/status/2071379474277613732) (и его [разборе](https://t.me/drugoi_dev/93)), отлично подмечено: привычные названия должностей больше не работают. Команды будут описываться через тип вклада в конкретный момент времени: 1. **Prototyper** — быстро находит идеи и собирает черновики. В текущем мире скорости это критический навык: умение выкинуть 90% мусора и найти то, что работает (zero-to-one поиск). 2. **Product Builder** — (подробнее у [Converteo](https://converteo.com/en/blog/product-builder-product-manager-ai/)) превращает прототип в рабочий продукт, эксплуатируя агентов. Вместо написания PRD, он приносит проверяемый прототип. 3. **Product Engineer** — (подход [PostHog](https://posthog.com/blog/product-engineer-vs-product-manager)) инженер, который не ждет ТЗ, а сам ближе к пользователю и метрикам. 4. **Forward deployed engineer** — (роль из [SVPG](https://www.svpg.com/forward-deployed-engineers/)) тащит модели в процессы реальных клиентов, преодолевая слой интеграций и ответственности. 5. **Sweeper** — убирает лишнее. Оптимизирует, снижает сложность, чистит код. AI генерирует тонны мусора, Sweeper спасает систему от коллапса. 6. **Grower & Maintainer** — улучшают product-market fit запущенного продукта и отвечают за надежность зрелой системы. Дизайнер может быть сильным Builder-ом, а инженер — Grower-ом. Жесткая привязка к профессии уходит в прошлое.  --- ## <u>4. Структура команд: от пирамиды к песочным часам</u> Организационные формы проходят эволюцию. * **Пирамида** (текущая модель) растит людей, но задыхается на передачах контекста. * **Ромб** появляется, когда режут найм джунов. Пайплайн кадров умирает, средний слой раздут. * **Перевернутая пирамида** — это боевая капсула. Несколько сильных спецов плюс агенты. Риск: нет кадрового резерва. * **Песочные часы** — это целевая модель. Автономные эксперты сверху, тонкий слой менеджмента в середине, новички учатся снизу. Баланс скорости и преемственности. Это созвучно с концепцией [Team Topologies](https://teamtopologies.com/key-concepts): команды строятся вокруг потока ценности и когнитивной нагрузки. AI-native команда — это не старый squad, которому раздали Copilot. Это компактная единица с end-to-end ответственностью.  --- ## <u>5. Операционная модель и инфраструктура</u> В ИТ-инфраструктуре мы видим три этапа эволюции: * **Модель A:** Разработка строит, эксплуатация поддерживает. Для агентов это не работает. Поведение агента зависит от контекста, прав и исторических данных. * **Модель B:** Построил сам, запускаешь сам. Капсула работает быстро, но не масштабируется. * **Модель C:** Целевая платформа. Автономные капсулы базируются на общей платформе. Права, наблюдаемость, аудит и лимиты задаются централизованно. Это [продолжение DevOps](https://arxiv.org/abs/2101.02361). Агентский ИИ не отменяет DevOps. Он делает незавершенный DevOps непростительно дорогими.  --- ## <u>6. Управление контекстом и смерть статус-отчетов</u> [Фаулер](https://martinfowler.com/articles/harness-engineering.html) формулирует суть: агент — это модель плюс обвязка из правил, инструментов, проверок и контекста. Управление агентами сводится к идентичности, правам и аудиту. Это не PDF-регламент на полке, а исполняемый контур. Очень похоже на [Production Readiness Review из SRE](https://sre.google/sre-book/evolving-sre-engagement-model/). Документация перестает быть архивом и становится частью среды исполнения. Как показывает [подход Palantir](https://arxiv.org/abs/2304.14975), доменные понятия должны быть явными и машинно-читаемыми. Что происходит с менеджментом? [Каган](https://www.svpg.com/product-vs-feature-teams/) давно разделяет продуктовые и фича-команды. ИИ радикально ускоряет фича-команды, но не делает их продуктовыми. Старая админ-функция сжимается в ноль. Отчеты в Jira, статусы, ручной пушинг задач, перфоманс ревью — это компенсация плохой структуры и избытка коммуникаций. Новая роль менеджмента — это управление условиями исполнения: * Формализация проблемы и ограничений (тот самый [аппетит из Shape Up](https://basecamp.com/shapeup/1.2-chapter-03)). * Владение доменным контекстом и правилами. * Дизайн потока и готовности к запуску. * Связка клиентской реальности с реализацией. AI-native убирает менеджера как погонщика. Но сохраняет функцию как инженерный контур: границы, поток, готовность, обратная связь. --- P.S. Автор оставляет за собой право быть неправым. Если ваш опыт говорит другое, жду в комментариях.