Как идти к Agentic Engineering, когда структуру команды сейчас трогать нельзя
Статус: черновик. Пишем и редактируем прямо на сайте. Текст ещё не финальный: структура, формулировки и примеры будут меняться.
Что усилит Habr-статью
Telegram-пост уже держится как позиция. Для Habr стоит усилить несколько слоёв:
- Определения. Что в тексте называется Agentic Engineering, AI-native командой, E2E-ответственностью, run-процессом, микро-юнитом. Так читатель будет сверять текст с авторскими определениями, а не со своими трактовками.
- Контекст организации. Масштаб без NDA-рисков: крупная инженерная организация, финтех, регулируемая среда, много команд, сложные домены, годовые цели и бюджетные контуры.
- Картинка “просто сделать маленькие AI-native teams”. Почему она популярна, где работает, где упирается в домен, зависимости, роли, административную структуру, нехватку аналитиков/тестировщиков и стратегические проекты.
- Критерии готовности. Как понять, какой путь выбрать: низкая/средняя/высокая готовность команды, зрелость инженерных практик, частота работы с агентами, наличие run-процессов, уровень E2E-понимания.
- Практические сценарии. По 1–2 конкретных примера на каждый путь: какой процесс агентизировали, как выглядела ротация, что делали “no hands” люди, как устроены микро-юниты.
- Метрики. Что мерить: MAU/W50/W80 API или аналоги, lead time, throughput, defect rate, доля change/run работы, количество ручных проверок, время в ожидании зависимостей.
- Риски и анти-паттерны. Агентная демка без поддержки, ручная валидация как bottleneck, “один герой всё тащит”, микро-юниты без E2E, рост throughput без роста ценности.
- Что сделать в понедельник. Habr любит практический выход: короткий чеклист запуска для руководителя/тимлида.
Рабочая структура статьи
Вступление: красивая картинка AI-native команды и “фигушки”
- 2–3 человека, E2E, агенты, production.
- Почему это хорошо выглядит на слайде.
- Почему в большой организации всё сложнее.
Почему пересборка команд не всегда лучший первый шаг
- Годовые цели, бюджеты, оргструктура, стратегические проекты.
- Хайп вокруг маленьких AI-native teams.
- Предметная область: большой финтех-процесс трудно аккуратно нарезать.
- Главный риск: потерять E2E.
Предусловия Agentic Engineering
- Люди понимают полный путь задачи.
- Люди умеют работать с агентами как с частью инженерного процесса.
- Без этого возникает “красивая демка + ручная проверка всего”.
Путь 1: агентизировать нудный run-процесс
- Что брать.
- Почему уже автоматизированный процесс может быть хорошим кандидатом.
- Как ротировать людей.
- Какой эффект ждать.
- Риски.
Путь 2: 2–3 человека в режиме look ma, no hands
- Команда остаётся в текущей структуре.
- Несколько людей работают через агентов почти во всём.
- Как их опыт заражает остальных.
- Как не превратить это в кружок героев.
Путь 3: микро-юниты внутри той же команды
- Команда остаётся командой на бумаге.
- Внутри появляются маленькие кросс-функциональные юниты.
- Почему дефицит специальностей растит E2E.
- Как меняются ретроспективы и обмен опытом.
Как выбрать путь
- Низкая готовность → run-процесс.
- Средняя готовность → 2–3 агентных практиков.
- Высокая готовность / большая команда → микро-юниты.
- Это набор безопасных экспериментов, которые можно комбинировать.
Метрики и признаки прогресса
- Adoption: MAU/W50/W80 по API/агентам.
- Delivery: lead time, throughput, defect rate.
- Flow: ожидание зависимостей, доля run/change, ручные проверки.
- Learning: сколько людей умеют формулировать задачи агентам, проверять результат, писать скилы.
Что сделать в понедельник
- Найти один run-процесс.
- Выбрать 2–3 добровольцев.
- Провести первый AI Lab / разбор практик.
- Договориться о метриках.
- Через месяц выбрать следующий эксперимент.
Финал
- Agentic Engineering вырастает из практики команды.
- Приказ стать AI-native выращивает совещания.
- Органичный путь выращивает E2E и навык работы с агентами.
Черновик статьи
Красивый образ AI-native команды обычно такой: 2–3 человека, полная E2E-ответственность, агенты забирают рутину, команда быстро доводит идею до production.
На слайде выглядит отлично. Фигушки.
В большой организации этот слайд сразу встречает годовые цели, бюджеты, стратегические проекты, административные контуры и уже собранные команды. Пересобрать всё ради новой модели работы редко получается быстро. Вокруг этого пути сейчас больше всего хайпа, поэтому он кажется единственным вариантом.
Есть ещё боль предметной области. В финтехе это особенно заметно: большой процесс трудно нарезать на аккуратные кусочки и раздать разным командам. В этот момент легко потерять главное — способность доставлять ценность от идеи до production с минимумом зависимостей.
Поэтому мне ближе органичный путь, специфичный для контекста команды. У каждой команды будет свой безопасный вход.
Что я называю Agentic Engineering
В этой статье Agentic Engineering — это режим работы, где агенты становятся частью инженерного процесса: помогают разбирать задачу, читать кодовую базу, готовить изменения, писать тесты, проверять гипотезы, чинить ошибки, обновлять документацию и собирать контекст для решения.
Ответственность всё равно на человеке. Он задаёт границы, принимает решения, проверяет качество, отвечает за последствия и понимает, где агенту можно доверять, а где нужен жёсткий контроль.
Для такого режима команде нужны два навыка одновременно:
- люди понимают E2E-специфику работы целиком, включая соседние зоны;
- люди умеют работать с агентами как с нормальной частью инженерного процесса.
Иначе Agentic Engineering быстро превращается в красивую демку, после которой человек вручную проверяет всё, что агент нагенерил, и едет кукухой от невозможности это поддерживать.
Где упирается идея “просто сделайте маленькие AI-native команды”
Маленькая команда с E2E-ответственностью — сильная идея. В некоторых командах к этому правда стоит прийти.
Проблема начинается там, где организация уже живёт в плотной системе обязательств. Есть годовые цели, стратегические проекты, бюджеты, роли, административная структура, регуляторные ограничения и уже набранные команды.
Ещё сложнее с предметной областью. Большой процесс редко режется на независимые кусочки идеально. Если нарезать его только по компонентам или этапам, можно получить команды, которые много делают у себя внутри, и длинную цепочку ожиданий между ними.
Для Agentic Engineering это особенно больно. Агент ускоряет подготовку изменений. Когда команда видит только свой кусок пути, ускорение быстро упирается в согласования, проверки, зависимости, ручную валидацию и соседние команды.
Короче: практичная цель — вырастить условия, где люди лучше видят E2E и умеют безопасно использовать агентов.
Путь 1. Агентизировать нудный run-процесс
Самый спокойный вход — взять рутину. Лучше жирную, скучную, местами недетерминированную.
Это может быть новый процесс. Ещё лучше — уже автоматизированный. Звучит странно: зачем агентизировать уже автоматизированный процесс? Именно там обычно известны настоящие углы: где падает, где нужна ручная проверка, где живут исключения, где скрипт ждёт человеческого решения.
Сначала один человек собирает агента вокруг этого процесса. Потом подключаем второго: показываем, как делали, и просим агентизировать ещё один процесс. Потом вовлекаем третьего.
Здесь ценность в экономии времени и в новом навыке. Команда учится описывать процесс агенту, задавать ограничения, проверять результат, вести журнал решений и отличать место, где агенту можно дать свободу, от места, где начинается опасная магия.
Параллельно рутины становится меньше. Освобождается место для change-работы и экспериментов.
В нашем опыте в таком режиме примерно за полгода половина команды начинает нормально пользоваться кодинг-агентами.
Где подходит: команды с осторожным отношением к AI, сильной run-нагрузкой, большим количеством ручных проверок и понятными повторяющимися процессами.
Главный риск: застрять в “автоматизации ради автоматизации” и оставить навык только в run-контуре.
Путь 2. Оставить команду как есть и выделить 2–3 человека в режим “look ma, no hands”
Мам, смотри, я без рук.
Команда сохраняет привычную форму: роли, планирование, обязательства, административную структуру.
Внутри неё 2–3 человека берут правило: задачи проходят через агентов. Руками формируем фреймворк работы: рамку, проверку, финальное решение и места, где без человека пока никак.
Через первый месяц эти люди обычно начинают делиться находками с остальными коллегами: промптами, скилами, способами декомпозиции, проверки, отладки, работы с легаси.
Остальные начинают прозревать. Они видят соседей, которые уже работают иначе с тем же кодом, теми же ограничениями и тем же релизным циклом.
Это важный момент. Внедрение перестаёт выглядеть как внешняя методология. Оно становится локальной практикой команды.
В нашем опыте за 3–6 месяцев 70–80% команды уже активно используют кодинг-агентов и примерно понимают, как ставить им задачи.
Где подходит: команды со средней готовностью, сильными инженерами, нормальным уровнем доверия и возможностью выделить несколько людей на практику.
Главный риск: сделать из этих людей “AI-героев”, к которым потом несут все задачи. Их задача — заражать практикой без превращения в новый bottleneck.
Путь 3. Разделить команду на микро-юниты внутри той же оргструктуры
Команда из 15 человек может остаться одной командой на бумаге. Внутри появляются маленькие кросс-функциональные юниты по 2–3 человека.
Статические или динамические — зависит от контекста. Важнее другое: работу берёт маленький юнит.
Сразу проявляется дефицит специальностей. Аналитиков и тестировщиков обычно меньше, чем разработчиков. Людям приходится чаще работать вместе: mob programming, swarming, быстрые синхронизации, совместная проверка результата.
Вот здесь и растёт E2E-понимание.
Разработчик видит аналитику. Аналитик видит инженерные ограничения. Тестировщик наконец-то попадает в процесс создания ценности раньше: до момента, когда реализация уже готова и её надо только проверить.
Агент становится общим инструментом юнита.
Ретроспектива тоже меняется: обсуждаем опыт между юнитами, чтобы удачные приёмы быстро расходились по команде.
В нашем опыте за пару месяцев почти вся команда начинает активно пользоваться кодинг-агентами и лучше понимает полный путь задачи.
Где подходит: большие команды, где уже есть базовая готовность к агентам, много параллельной работы и слишком длинная координационная цепочка.
Главный риск: назвать группы микро-юнитами, сохранив старую передачу работы по этапам. Тогда E2E не вырастет.
Как выбрать путь
Критерий выбора — уровень готовности.
- Низкая готовность: начните с run-процесса. Нужен безопасный контур и понятный первый результат.
- Средняя готовность: выделите 2–3 человека в режим работы через агентов. Нужны носители практики внутри команды.
- Высокая готовность или большая команда: пробуйте микро-юниты. Нужен рост E2E и короткая координационная цепочка.
Это набор экспериментов, которые можно комбинировать. Команда может начать с run-процесса, потом выделить “no hands” людей, потом перейти к микро-юнитам. Другая команда может сразу начать с микро-юнитов, если у неё уже есть сильная инженерная культура.
Главное — избежать единого шаблона для всех.
Что измерять
Если цель — сокращать время реализации с помощью AI, одной метрики использования инструмента мало.
Полезно смотреть на четыре группы сигналов.
1. Adoption
Сколько людей регулярно работает с агентами. Внутри можно смотреть MAU, W50, W80 или любые локальные аналоги: сколько людей используют API/агентов в 50% или 80% рабочих дней.
2. Delivery
Lead time, throughput, defect rate. Быстрее писать код — ещё не значит быстрее приносить пользу. Важно, доходит ли задача до результата.
3. Flow
Где задача ждёт: аналитика, ревью, тестирование, безопасность, соседняя команда, бизнес-проверка. Agentic Engineering часто быстрее показывает узкие места, чем обычная процессная оптимизация.
4. Learning
Сколько людей умеют декомпозировать задачу для агента, задавать ограничения, проверять результат, писать скилы, повторно использовать удачные сценарии и объяснять это коллегам.
Что сделать в понедельник
Для старта в текущей оргструктуре я бы сделал так:
- Найти один жирный run-процесс, который всем надоел.
- Выбрать одного человека, который соберёт первый агентный сценарий.
- Через 2–3 недели подключить второго человека и попросить повторить подход на другом процессе.
- Параллельно выбрать 2–3 добровольцев, которые месяц делают часть задач через агентов и каждую неделю показывают находки команде.
- Если команда большая — попробовать микро-юнит на одной задаче и провести ретроспективу между юнитами.
- Договориться о метриках: adoption, lead time, defect rate, ожидания между этапами, доля run/change работы.
Финал
Agentic Engineering начинается с практики, где люди безопасно набивают два навыка: E2E-ответственность и работу с агентами.
Приказ “с понедельника стать AI-native” обычно выращивает новые совещания.
Если эти навыки растут, команда сама понимает, какая форма ей подходит. Иногда это маленькая AI-native команда. Иногда микро-юниты. Иногда хорошо агентизированный run-контур, который освобождает время для change-работы.
Органичный путь скучнее слайда и лучше переживает встречу с реальной организацией.