Agentic Engineering не начинается с оргчарта. Он начинается с момента, когда команда видит полный путь задачи и умеет безопасно отдавать часть работы агентам.
Красивая картинка AI-native команды — 2–3 человека, E2E-ответственность, агенты в инженерном процессе, быстрый путь от идеи до продакшена. В большой организации эта картинка сразу встречает годовые цели, бюджеты, стратегические проекты, регуляторные контуры и уже собранные команды.
В этой статье — три безопасных маршрута, которые можно запускать внутри текущей структуры: агентизировать нудный run-процесс, выделить 2–3 агентных практиков или собрать микро-юниты внутри команды.
Два маршрута чтения
Если нужно сразу к практике — переходите к разделу «Что сделать в понедельник».
Если важно понять механику — начните с определения Agentic Engineering и ограничения подхода «просто сделайте маленькие AI-native команды».
Что я называю Agentic Engineering
В этой статье Agentic Engineering — это режим работы, где AI-агенты становятся частью инженерного процесса.
Они помогают:
- разбирать задачу;
- читать кодовую базу;
- готовить изменения;
- писать тесты;
- проверять гипотезы;
- чинить ошибки;
- обновлять документацию;
- собирать контекст для решения.
Ответственность остаётся на человеке. Он задаёт границы, принимает решения, проверяет качество, отвечает за последствия и понимает, где агенту можно доверять, где нужен жёсткий контроль.
Для такого режима команде нужны два навыка одновременно:
- E2E-понимание. Люди видят полный путь задачи: от запроса и аналитики до ревью, тестирования, релиза и проверки результата.
- Навык работы с агентами. Люди умеют формулировать задачи, задавать ограничения, проверять результат, переиспользовать удачные сценарии и объяснять это коллегам.
Без этих навыков Agentic Engineering быстро превращается в красивую демку: агент что-то сгенерировал, человек вручную проверяет всё подряд, команда не понимает, кто владеет качеством, поддержка результата становится отдельной болью.
Почему «просто сделать маленькие AI-native команды» работает не везде
Маленькая команда с E2E-ответственностью — сильная идея. В некоторых местах к ней правда стоит прийти.
Трудности начинаются там, где организация уже живёт в плотной системе обязательств. Есть годовые цели, бюджеты, роли, стратегические проекты, регуляторные ограничения, административная структура и команды, которые уже собраны под текущий способ работы.
В финтехе добавляется предметная область. Большой процесс редко режется на независимые кусочки идеально. Если нарезать его по компонентам или этапам, можно получить команды, которые быстро делают свою часть и передают задачу дальше в длинную цепочку ожиданий.
Для Agentic Engineering это особенно заметно. Агент ускоряет подготовку изменений. Когда команда видит только свой кусок пути, ускорение упирается в согласования, проверки, зависимости, ручную валидацию и соседние команды.
Практичная цель на первом шаге: вырастить условия, где люди лучше видят E2E и безопасно используют агентов в реальной работе.
Путь 1. Агентизировать нудный run-процесс
Самый спокойный вход — взять рутину. Лучше крупную, скучную, с исключениями и неоднозначными развилками.
Это может быть новый процесс. Ещё лучше — уже автоматизированный процесс, который всё равно требует человека. Звучит странно: зачем агентизировать то, что уже автоматизировано? Именно там обычно известны настоящие углы: где падает, где нужна ручная проверка, где живут исключения, где скрипт ждёт человеческого решения.
Примеры подходящих кандидатов:
- разбор регулярных алертов и подготовка черновика решения;
- сбор контекста по типовым инцидентам;
- обновление документации после изменения API;
- проверка стандартного чеклиста перед релизом;
- подготовка отчёта по повторяющимся дефектам;
- анализ очереди запросов в поддержку и привязка к известным проблемам.
Порядок работы простой:
- Один человек собирает агентный сценарий вокруг процесса.
- Команда фиксирует границы: что агент делает сам, что предлагает, что обязательно проверяет человек.
- Через 2–3 недели подключается второй человек и повторяет подход на другом процессе.
- Потом подключается третий.
- Удачные промпты, скрипты, скилы и проверки складываются в общий репозиторий практик.
Ценность здесь двойная. Команда экономит время на рутине и набивает навык: описывать процесс агенту, задавать ограничения, проверять результат, вести журнал решений, отличать полезную автономность от опасной магии.
Параллельно рутины становится меньше. Освобождается место для change-работы и экспериментов.
В моём опыте такой маршрут хорошо работает для осторожных команд. Примерно за полгода половина команды начинает нормально пользоваться агентами для кода, потому что вход был безопасным и связанным с реальной болью.
Где подходит: команды с осторожным отношением к AI, сильной run-нагрузкой, большим количеством ручных проверок и понятными повторяющимися процессами.
Главный риск: застрять в «автоматизации ради автоматизации» и оставить навык только в run-контуре. Поэтому уже на старте стоит задать вопрос: какая часть этого опыта потом переносится в change-работу?
Путь 2. Выделить 2–3 человека в режим «без рук»
Смысл простой: максимум работы проходит через агентов, ответственность остаётся у человека.
Команда сохраняет привычную форму: роли, планирование, обязательства, административную структуру.
Внутри неё 2–3 человека берут рабочее правило: максимум задач проходит через агентов. Человек остаётся владельцем результата, руками формирует рамку работы: цель, ограничения, контекст, проверку, финальное решение и места, где без человека пока никак.
Задача этих людей — не героически делать всё быстрее за остальных. Их задача — выращивать локальную практику команды.
Через первый месяц они обычно начинают делиться находками:
- как формулировать задачу агенту;
- как давать контекст по наследуемому коду;
- как проверять изменения;
- как декомпозировать работу;
- как писать скилы и переиспользуемые сценарии;
- где агент реально экономит время;
- где агент создаёт дополнительную проверку и риск.
Остальные видят коллег, которые уже работают иначе с тем же кодом, теми же ограничениями и тем же релизным циклом. Это важный момент: внедрение перестаёт выглядеть как внешняя методология. Оно становится локальной практикой команды.
В моём опыте за 3–6 месяцев 70–80% команды уже активно используют агентов для кода и примерно понимают, как ставить им задачи. Такой рост появляется из наблюдаемого примера рядом.
Где подходит: команды со средней готовностью, сильными инженерами, нормальным уровнем доверия и возможностью выделить несколько людей на практику.
Главный риск: сделать из этих людей «AI-героев», к которым потом несут все задачи. Их результат стоит оценивать по распространению навыка внутри команды.
Путь 3. Собрать микро-юниты внутри той же команды
Команда из 15 человек может остаться одной командой на бумаге. Внутри появляются маленькие кросс-функциональные юниты по 2–3 человека.
Они могут быть статическими или динамическими. Контекст решает. Важнее другое: работу берёт маленький юнит, который вместе отвечает за проход задачи до результата.
Сразу проявляется дефицит специальностей. Аналитиков и тестировщиков обычно меньше, чем разработчиков. Людям приходится чаще работать вместе: программировать вместе, быстро собираться вокруг застрявшей задачи, синхронизироваться короткими встречами и совместно проверять результат.
Вот здесь растёт E2E-понимание.
Разработчик видит аналитику. Аналитик видит инженерные ограничения. Тестировщик попадает в процесс создания ценности раньше: до момента, когда реализация уже готова и её осталось только проверить.
Агент становится общим инструментом юнита. Один человек может попросить агента собрать контекст по коду, второй — проверить сценарии, третий — подготовить тесты или документацию. Главное, что весь юнит видит задачу целиком.
Ретроспектива тоже меняется. Команда обсуждает опыт между юнитами, чтобы удачные приёмы быстро расходились дальше: какой промпт сработал, где агент ошибся, какая проверка спасла, какой кусок работы лучше резать иначе.
В моём опыте за пару месяцев почти вся команда начинает активнее пользоваться агентами для кода и лучше понимает полный путь задачи.
Где подходит: большие команды, где уже есть базовая готовность к агентам, много параллельной работы и слишком длинная координационная цепочка.
Главный риск: назвать группы микро-юнитами и сохранить старую передачу работы по этапам. В таком варианте E2E не вырастет. Поменяется вывеска, очередь останется прежней.
Как выбрать маршрут
Критерий выбора — уровень готовности команды.
- Низкая готовность: начните с run-процесса. Нужен безопасный контур и понятный первый результат.
- Средняя готовность: выделите 2–3 человека в режим работы через агентов. Нужны носители практики внутри команды.
- Высокая готовность или большая команда: пробуйте микро-юниты. Нужен рост E2E и короткая координационная цепочка.
Это набор экспериментов, которые можно комбинировать. Команда может начать с run-процесса, потом выделить людей, которые работают через агентов, а затем перейти к микро-юнитам. Другая команда может сразу начать с микро-юнитов, если у неё уже есть сильная инженерная культура.
Главное — избежать единого шаблона для всех. Agentic Engineering требует локального входа: где команда уже готова, где есть боль, где можно безопасно проверить новый способ работы.
Что измерять
Если цель — сокращать время реализации с помощью AI, одной метрики использования инструмента мало.
Полезно смотреть на четыре группы сигналов.
1. Adoption
Сколько людей регулярно работает с агентами. Внутри можно смотреть MAU, W50, W80 или любые локальные аналоги: сколько людей используют API и агентов в 50% или 80% рабочих дней.
2. Delivery
Lead Time, Throughput, Defect Rate. Быстрее писать код — ещё не значит быстрее приносить пользу. Важно, доходит ли задача до результата.
3. Flow
Где задача ждёт: аналитика, ревью, тестирование, безопасность, соседняя команда, бизнес-проверка. Agentic Engineering часто быстрее показывает узкие места, чем обычная процессная оптимизация.
4. Learning
Сколько людей умеют декомпозировать задачу для агента, задавать ограничения, проверять результат, писать скилы, повторно использовать удачные сценарии и объяснять это коллегам.
Контрольный вопрос для каждого слоя один: какой бизнес-показатель должен сдвинуться, если этот эксперимент сработает? Стоимость операции, SLA, срок вывода изменений на рынок, нагрузка на поддержку, скорость запуска гипотез, операционный риск — метрика должна быть связана с целью и реальным изменением работы.
Что сделать в понедельник
Для старта в текущей оргструктуре я бы сделал так:
- Найти один жирный run-процесс, который всем надоел.
- Описать текущий маршрут: кто участвует, какие артефакты нужны, где человек принимает решение, где чаще всего возникают исключения.
- Выбрать одного человека, который соберёт первый агентный сценарий.
- Зафиксировать правила проверки: что агент может делать сам, что предлагает черновиком, что человек обязан проверить.
- Через 2–3 недели подключить второго человека и повторить подход на другом процессе.
- Параллельно выбрать 2–3 добровольцев, которые месяц делают часть задач через агентов и каждую неделю показывают находки команде.
- Если команда большая — попробовать микро-юнит на одной задаче и провести ретроспективу между юнитами.
- Договориться о метриках: регулярное использование агентов, Lead Time, Defect Rate, ожидания между этапами, доля run/change работы и один бизнес-показатель.
Через месяц не надо проводить большой комитет по трансформации. Достаточно ответить на три вопроса:
- где агент реально сократил ручную работу;
- где человек стал узким местом проверки;
- какой навык команда сможет повторить на следующей задаче.
Финал
Agentic Engineering начинается с практики, где люди безопасно набивают два навыка: E2E-ответственность и работу с агентами.
Приказ «с понедельника стать AI-native» обычно выращивает новые совещания.
Если навыки растут, команда сама понимает, какая форма ей подходит. Иногда это маленькая AI-native команда. Иногда микро-юниты. Иногда хорошо агентизированный run-контур, который освобождает время для change-работы.
Органичный путь скучнее слайда и лучше переживает встречу с реальной организацией.