AI-native организация начинается с неопределенности: что меняется в структуре, ролях и управлении
Привет, Хабр! Летом у нас была закрытая рабочая сессия технологических руководителей C-Level клуба Онтико. Сессию помогали вести топ-менеджеры из Сloud.ru Анастасия Тафеенко, директор блока разработки платформы Cloud.ru Evolution, и Алексей Молчанов, директор блока разработки облачной платформы. Участники обсуждали, как генеративный ИИ и агенты меняют организационный дизайн, роли, компетенции и работу руководителя на горизонте до 2027 года.
Ниже хочу поделиться картой перехода к AI-native организации, которую мы продумали в рамках встречи. Все примеры обезличил, а спорные прогнозы отделил от выводов, по которым позиции участников совпали.
О чем была рабочая сессия
Главная идея встречи звучала парадоксально: корень перемен лежит в экономике труда, инструменты здесь вторичны. Когда агент способен выполнить подробно описанную работу, ценность человека смещается к той части задачи, где еще много неизвестного. Человеку предстоит снять неопределенность, определить цель, задать критерии результата и принять ответственность за последствия.
Эта логика последовательно меняет всю организацию. Команды становятся меньше, роли собираются вокруг задачи, сотрудники расширяют область ответственности, руководители отвечают за среду для совместной работы людей и агентов. При этом готовой модели пока нет. Рабочая сессия показала общую траекторию и несколько разногласий, которые руководителям придется разбирать уже внутри своих компаний.
Почему исполнение перестает быть центром организации
Классическая организация хорошо умеет делить большую работу на части. Задачу описывают, раскладывают по функциям, распределяют между специалистами и связывают контролем. Чем точнее техническое задание, тем проще подобрать исполнителя и оценить срок. На этой логике выросли грейды, функциональные подразделения, длинные цепочки согласований и большое количество узких ролей.
Агенты меняют стоимость отдельных этапов. Подробно описанную операцию можно передать системе, которая выполнит ее быстро и дешево. Экономически ценной становится работа до появления подробного задания: понять проблему, собрать контекст, увидеть ограничения, выбрать направление и описать ожидаемый результат.
Один из участников выразил этот сдвиг так: работа человека заключается в снижении неопределенности. Когда неопределенность доведена до приемлемого уровня, исполнение можно передать агенту.
И тут важно понимать ограничение: сложность продукта никуда не исчезает. Более доступное исполнение позволяет запускать больше гипотез, быстрее менять систему и обслуживать больше вариантов поведения. В результате сложность «уходит под агентный ковер». Ее требуется удерживать архитектурой, критериями качества, платформой, обратной связью и ответственностью.
Поэтому AI-native организацию нельзя описать количеством лицензий или числом сотрудников, которые используют чат-бот. Ее отличает другой способ распределять работу:
Человек задает цель и границы задачи.
Контекст, принципы и критерии становятся доступными системе.
Агент выполняет операции и возвращает результат вместе с наблюдаемыми следами работы.
Человек или автоматизированный контур оценивает результат.
Бизнес-метрика и найденные ошибки обновляют контекст следующего цикла.
В этом цикле человек постепенно выходит из ручного исполнения. Ответственность за цель, допустимый риск и итоговое решение остается у человека.
Сначала нужно сделать работу видимой
Переход начинается с явных процессов и принципов. Агенту нужны источники контекста, правила, права доступа, критерии качества и понятный способ вернуть результат. Устные договоренности, личные файлы и знания в головах создают пробелы, которые модель заполняет предположениями.
Если в процессе уже есть беспорядок, автоматизация увеличивает его скорость. Команда быстрее производит разные версии результата, быстрее расходует вычислительный бюджет и быстрее разносит ошибки по связанным системам.
Явность процесса не означает огромный регламент. Для первого контура достаточно пяти элементов:
владелец результата;
цель и измеримый критерий успеха;
разрешенные источники данных;
обязательные проверки;
правило остановки и передачи задачи человеку.
Такой набор превращает разговор о внедрении ИИ в проектирование рабочей системы. Он же показывает, какие этапы уже готовы для агентов, а где организация пока держится на неявном опыте отдельных сотрудников.
Здесь появляется конфликт интересов. Чем больше ценность специалиста связана с уникальным контекстом, тем слабее его личная мотивация выгружать знания в общую систему. Значит, управление знаниями становится частью организационного дизайна. Компании потребуются стимулы, время и безопасный процесс, при котором описание знаний воспринимается как вклад в результат и развитие роли.
Структура следует за уровнем неопределенности
Участники предложили смотреть на организационную структуру через уровень неопределенности задачи. Стабильный поток с понятными требованиями легко автоматизировать и собрать вокруг небольшой команды. Новый продукт, сложный домен или высокая цена ошибки требуют больше человеческих ролей, проверок и архитектурной работы.
Поэтому единая схема для всех подразделений выглядит сомнительно. В одной компании могут одновременно работать разные модели:
один продуктовый инженер с набором агентов для простого цифрового продукта;
маленькая кросс-функциональная команда для продукта со сложным контекстом;
платформенная и эксплуатационная функции для общих инструментов, безопасности и надежности;
отдельный контур принятия решений для задач с высокой ценой ошибки.
Общее направление связано с уменьшением команд и ростом их автономности. В дискуссии звучал диапазон от одного до пяти человек. Это ориентир, полученный в рабочем обсуждении, а не универсальная норма. Размер зависит от сложности продукта, зрелости платформы и ограничений отрасли.
Вместе с размером меняется и способ координации. Часть синхронизаций, статусов и подготовки планов можно передать персональным агентам. Участники назвали эту гипотезу «бэклогом без бэклога»: агенты собирают состояние задач, обнаруживают зависимости и согласуют действия между маленькими командами.
Человеческая коммуникация при этом сохраняет важную функцию. Она помогает договариваться о смыслах, разрешать конфликты целей и замечать контекст, который пока отсутствует в цифровой среде. Полная замена общения межагентным обменом осталась одним из самых спорных тезисов сессии.
Что произойдет с матрицей и иерархией
Матрица, вероятно, сохранится там, где бизнесу по-прежнему нужны две оси ответственности: продуктовая и технологическая. Ее наполнение станет другим. Узкие функциональные чаптеры потеряют часть смысла, если команда уже не состоит из отдельных фронтенд-, бэкенд- и QA-специалистов. Технологическое развитие сможет сосредоточиться вокруг архитектуры, платформы, качества решений и работы с агентами.
Иерархия может стать короче, а горизонт планирования сжаться. Участники говорили о квартале и даже месяце как о реальном цикле пересмотра решений. Это тоже гипотеза, зависящая от отрасли. Долгосрочное направление компании остается необходимым, а детальный план на несколько лет быстро теряет связь с доступными технологиями и экономикой исполнения.
Ролей становится больше, должностей меньше
Одна из самых емких фраз прозвучавшей на дискуссии: ролей становится больше, должностей меньше. Сотрудник сохраняет должность, а внутри конкретной задачи берет несколько ролей. Набор ролей зависит от сложности продукта, глубины домена, архитектурного риска и зрелости платформы.
В простом случае продуктовый инженер может соединять работу с потребностью пользователя, постановку задачи и выпуск результата. При росте сложности к нему добавляются другие роли:
full-cycle engineer ведет решение от спецификации до эксплуатации;
domain engineer удерживает предметный контекст и готовит спецификации;
eval engineer строит проверки для моделей и агентных сценариев;
AI architect проектирует взаимодействие моделей, инструментов и данных;
platform engineer развивает среду, в которой работают команды и агенты;
MLOps, LLMOps и AI-SRE отвечают за жизненный цикл, наблюдаемость и надежность;
роли владельца задачи, валидатора результата и асессора образуют контур управления агентами.
Этот список — не карта функций. Он не требует отдельного человека на каждый пункт. В маленькой команде один специалист может совмещать несколько ролей. В сложной системе роли распределяются между людьми, платформой и автоматизированными проверками.
Роли, которые могут существенно измениться: manual QA, SDET, классические фронтенд- и бэкенд-специализации, бизнес- и системные аналитики, тимлиды, UI-дизайнеры, agile-коучи. Тут важно заметить, что это лишь прогноз с горизонтом до 2027 года. Даже внутри сессии не было общего ответа, какие профессии исчезнут и с какой скоростью.
Практически полезнее проверять каждую роль тремя вопросами:
Какую неопределенность снимает эта роль?
За какое решение и риск отвечает человек?
Какую часть работы уже можно передать агенту или платформе?
Если роль в основном передает информацию между системами, переписывает понятные требования или выполняет повторяемую проверку, ее содержание будет быстро меняться. Если роль удерживает цель, архитектурное решение, предметный контекст или ответственность за риск, ее ценность может вырасти.
Команде нужна матрица компетенций, а не универсальный суперспециалист
Образ сотрудника, который одинаково силен в продукте, архитектуре, данных, разработке, коммуникации и работе с моделями, выглядит привлекательным. Найти такого человека трудно, а строить всю модель найма вокруг редкого профиля рискованно.
Но вырисовывается более реалистичная конструкция: целевую матрицу закрывает команда целиком. У каждого участника есть глубокие области и широкий обзор. Состав команды компенсирует индивидуальные пробелы.
Матрица держится на трех опорах.
Смысл и ответственность
Человек понимает, зачем выполняется работа, и связывает решение с результатом продукта. Он готов считать результат агента своим результатом. Ссылка на ошибку модели не снимает ответственности перед пользователем, бизнесом или регулятором.
Сюда же относятся адаптивность и готовность учиться. Инструменты меняются слишком быстро, поэтому ценность одной конкретной техники ограничена. Способность пересобрать свой процесс становится устойчивой частью профессии.
Дизайн системы
Сотруднику требуется системное и архитектурное мышление. Он умеет декомпозировать задачу, видеть связи, заранее задавать свойства системы и управлять контекстом. Надежность, безопасность, стоимость и наблюдаемость входят в постановку задачи до запуска агента.
В эту опору попадает управление знаниями. Контекст нужно отбирать, структурировать, обновлять и давать системе в подходящей форме. Большой архив документов сам по себе еще не создает рабочий контекст.
Критическое мышление
Модель может дать убедительный ответ, который нарушает ограничения, опирается на выдуманный факт или выбирает слабое решение. Человеку нужно проверять качество, видеть риски и запрашивать альтернативы. Первый быстрый результат не должен автоматически становиться финальным.
Под тремя опорами лежит общая база: понимание возможностей и ограничений LLM, умение ясно описывать намерение, продуктовый взгляд, техническая грамотность и максимальная автоматизация обратной связи.
Так меняется и T-shape модель. У специалиста появляется несколько глубоких осей и широкий системный обзор. В материалах сессии это называли переходом к Π-shape. При найме становится важен профиль команды, поскольку два сильных кандидата могут приносить пользу разными сочетаниями компетенций.
Самый неудобный вопрос: где вырастут новые специалисты
Если агент забирает простые задачи, привычная лестница развития ломается. Джун больше не получает несколько лет повторяемой работы, на которой раньше осваивал кодовую базу, тестирование, поставку и эксплуатацию. При этом от него уже ждут системного мышления, продуктового контекста и ответственности за результат, а «учиться не на чем».
Оставить проблему на самотек опасно. Быстрый старт с агентом создает длинную зону неосознанной некомпетентности. Человек способен выпустить работающий результат и одновременно не замечать архитектурные, эксплуатационные или безопасностные риски.
Новая система развития может включать:
учебные задачи с реальной ценой решения и безопасным контуром;
обязательное объяснение архитектурного выбора;
разбор трассы работы агента и причин ошибок;
ротацию ролей внутри маленькой команды;
автоматические проверки, которые дают быструю обратную связь;
наставничество вокруг принятия решений, а не вокруг набора текста;
постепенное увеличение цены ошибки и объема контекста.
Грейды при такой модели могут сохраниться. Их содержание смещается от объема выполненной руками работы к сложности решений, качеству критериев, способности видеть систему и уровню принятой ответственности.
Руководитель становится архитектором среды
Работа руководителя сохраняет значение и меняет содержание. Его задача состоит в том, чтобы собрать среду, где люди и агенты двигаются к общей цели, получают контекст, проходят проверки и дают наблюдаемый результат.
Первое требование связано с личным примером. Команда быстро видит разрыв между призывом использовать ИИ и реальным календарем руководителя. Если лидер сам работает по старой модели, трансформация остается презентацией. Если он показывает собственный процесс, ограничения, ошибки и способы проверки, у команды появляется конкретный образ новой работы.
Второе изменение связано с ответственностью. Руководитель отвечает за бюджет использования моделей, выбор допустимого уровня автономности, права доступа, качество обратной связи и последствия решений агентов. Делегирование операции не равно делегированию бизнес-ответственности.
Третье изменение касается нормы управления. Здесь участники разошлись. Одна позиция предполагает заметный рост числа прямых подчиненных: агент собирает контекст по каждому сотруднику и снимает часть координационной нагрузки. Другая позиция указывает на прежние когнитивные ограничения человека. По этой версии норма вырастет на одного или двух сотрудников, а резкое расширение приведет к выгоранию руководителя.
Полезно разделить управление и контроль. Агент действительно позволяет контролировать больше объектов, задач и показателей. Управление людьми включает доверие, развитие, конфликты, мотивацию и сложные разговоры. Эта часть масштабируется намного медленнее.
Новый риск: параллельность без пропускной способности
Агенты позволяют запустить десять задач почти одновременно. Человеческое внимание от этого не становится в десять раз шире. К полудню руководитель может оказаться в потоке уведомлений, промежуточных решений и запросов на подтверждение из множества проектов.
Проблема проявляется в виде постоянного переключения между контекстом. Поэтому в AI-native среде нужны ограничения на незавершенную работу, очереди решений и правила эскалации. Метрикой руководителя становится скорость получения проверенного результата при приемлемой когнитивной нагрузке команды. Количество запущенных агентов само по себе ценности не показывает.
Платформа создает границу скорости
Маленькие автономные команды требуют общей среды. В нее входят доступ к моделям, управление контекстом, каталог инструментов, контроль прав, трассировка, оценка качества, бюджетирование и безопасная поставка изменений. В материалах сессии эту среду называли agent-first IDP.
Здесь возникает проблема курицы и яйца. Без платформы команды тратят время на повторную сборку одинаковой оснастки. Платформа без реальных сценариев превращается в дорогой внутренний продукт без пользователей.
Выходом может стать последовательное развитие вокруг одного потока создания ценности:
Выбрать повторяемый процесс с понятной бизнес-метрикой.
Описать минимальный контекст и обязательные проверки.
Собрать решение для одной команды.
Выделить повторяемые компоненты в платформу.
Подключать следующие команды только после проверки переиспользования.
Так платформа растет из рабочих сценариев и сохраняет связь с экономическим результатом.
Где общего ответа пока нет
На сессии были разногласия, и они полезны для руководителя не меньше, чем общий вывод.
Станут ли команды почти полностью агентными? Технически доля автономного исполнения будет расти. Вопросы смысла, конфликтов целей и ответственности пока удерживают человека в контуре.
Нужно ли сохранять прежние процессы тестирования? Одна радикальная позиция предлагает ориентироваться прямо на бизнес-метрики и быстро откатывать слабые версии. Другая позиция требует усиливать автоматизированные проверки, поскольку скорость агента увеличивает цену массовой ошибки. Выбор зависит от обратимости решения и цены вреда.
Можно ли переносить AI-native опыт между компаниями? Сотрудники будут приходить с разными наборами ролей, платформ и привычек. Универсальный профиль уступает место «снежинкам» из нескольких глубоких компетенций. Онбординг и оценка кандидатов усложняются.
Кто профинансирует переход для компаний без собственной платформы? Крупные организации строят среду под свою архитектуру и ограничения. Готовое решение редко переносится целиком. Рынку понадобятся стандартные компоненты и понятные интерфейсы между ними.
Как оценивать кандидата, который использует сильного агента? Итоговый артефакт все хуже показывает личную компетентность. Оценке придется смещаться к постановке задачи, выбору критериев, разбору ошибок и способности объяснить решение.
Практическая карта перехода
Начинать с новой оргструктуры рискованно. Сначала полезно проверить саму механику на одном потоке работы.
Шаг 1. Выберите поток с измеримой ценностью
Подойдет процесс, который повторяется, имеет владельца и связан с понятной метрикой. Например, время выпуска изменения, стоимость обработки обращения или доля успешно решенных запросов.
Шаг 2. Найдите точки неопределенности
Отметьте, где команде требуется решение, предметный контекст или оценка риска. Отдельно выделите операции, где правила уже понятны. Первую группу оставьте людям, вторую рассматривайте для передачи агентам.
Шаг 3. Сделайте контекст и правила явными
Опишите цель, источники данных, ограничения, критерии качества, права доступа и условие остановки. Проверьте, что описание доступно и человеку, и системе.
Шаг 4. Разделите роли в контуре
Назначьте владельца цели, исполнителя, валидатора и владельца последствий. Часть ролей может выполнять агент или автоматическая проверка. Бизнес-ответственность должна иметь человеческого владельца.
Шаг 5. Постройте обратную связь
Соедините технические проверки с продуктовой метрикой. Сохраняйте трассу работы агента, причины отказов и решения человека. Без этого команда видит результат и теряет способ улучшать систему.
Шаг 6. Измеряйте две производительности
Первая показывает скорость и качество рабочего потока. Вторая показывает нагрузку на внимание людей: число параллельных задач, количество эскалаций, время ожидания решения и частоту переключения контекста.
После нескольких циклов станет видно, какие роли действительно нужны, где полезна платформа и какой размер команды выдерживает конкретный поток. Оргструктура в этом подходе становится следствием проверенной модели работы.
Что можно сделать уже сейчас
Первый шаг AI-native перехода выглядит прозаично: выбрать один важный процесс и сделать его понятным. Описать цель, критерии, контекст, ограничения и ответственность. Затем передать агенту ту часть, где неопределенность уже снята, и построить обратную связь по качеству и бизнес-результату.
Такой эксперимент дает больше информации, чем общий план трансформации. Он показывает реальную границу автономности, требования к людям, пробелы платформы и цену переключения контекста.
Агенты меняют исполнение быстро. Организация меняется медленнее, потому что ей требуется пересобрать ответственность, обучение, доверие и работу со смыслом. Именно здесь лежит основная работа руководителей на ближайший год.
Какая часть вашей работы уже упирается в неопределенность, а какая готова перейти к агентам? И что мешает сделать этот переход сегодня?
Что еще можно почитать на тему внедрения ИИ в работу:
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.