Красивый образ AI-native команды обычно такой: 2–3 человека, полная E2E-ответственность, агенты забирают рутину, команда быстро доводит идею до production.
На слайде выглядит отлично. Фигушки. 🙅
В большой организации этот слайд сразу начинает конфликтовать с годовыми целями, бюджетами, стратегическими проектами, административными контурами и уже собранной структурой команд. Пересобрать всё ради новой модели работы редко получается быстро. Да и, возможно, это не самый оптимальный путь — просто вокруг него сейчас больше всего хайпа.
🥦 Поэтому я всё больше верю в органичный путь, специфичный для контекста команды. Один подход на все команды не натянешь.
Команде нужен путь, где одновременно растут два навыка:
- люди понимают E2E-специфику работы целиком, включая соседние зоны;
- люди умеют работать с агентами как с нормальной частью инженерного процесса.
Без этого Agentic Engineering быстро превращается в красивую демку, после которой человек вручную проверяет всё, что агент нагенерил, и едет кукухой от невозможности это поддерживать.
___
🗿 Путь 1. Агентизировать нудный run-процесс
Берём рутину. Лучше жирную, скучную, местами недетерминированную.
Это может быть новый процесс. Ещё лучше — уже автоматизированный. Девопсы обычно знают его «особенности»: где падает, где нужна ручная проверка, где живут исключения.
Сначала один человек собирает агента вокруг этого процесса. Потом подключаем второго: показываем, как делали, и просим агентизировать ещё один процесс. Потом вовлекаем третьего.
Ценность простая: команда набивает руку там, где риск ниже. Рутины становится меньше, появляется место для change-работы и экспериментов.
🤩 В таком режиме примерно за полгода половина команды начинает нормально пользоваться кодинг-агентами.
___
💪 Путь 2. Оставить команду как есть и выделить 2–3 человека в режим “look ma, no hands”
Мам, смотри, я без рук.
Команда сохраняет привычную форму: роли, планирование, обязательства, административную структуру.
Внутри неё 2–3 человека берут правило: задачи проходят через агентов. Руками формируем фреймворк работы: рамку, проверку, финальное решение и места, где без человека пока никак.
Через первый месяц эти люди обычно начинают делиться находками с остальными «сослуживцами»: промптами, скилами, способами декомпозиции, проверки, отладки, работы с легаси.
Остальные начинают прозревать: видят соседей, которые уже работают иначе с тем же кодом, ограничениями и релизным циклом.
🤩 В нашем опыте за 3–6 месяцев 70–80% команды уже активно используют кодинг-агентов и примерно понимают, как их готовить.
___
🔬 Путь 3. Разделить команду на микро-юниты внутри той же оргструктуры
Команда из 15 человек может остаться одной командой на бумаге. Внутри появляются маленькие кросс-функциональные юниты по 2–3 человека.
Статические или динамические — зависит от контекста. Важнее другое: работу берёт юнит, не вся команда целиком и не один человек отдельно.
Сразу проявляется дефицит специальностей. Аналитиков и тестировщиков обычно меньше, чем разработчиков. Людям приходится чаще работать вместе: mob programming, swarming, быстрые синхронизации, совместная проверка результата.
Вот здесь и растёт E2E-понимание.
Разработчик видит аналитику. Аналитик видит инженерные ограничения. Тестировщик наконец-то попадает в процесс создания ценности раньше — не в момент, когда реализация уже готова и её надо только проверить.
Агент становится общим инструментом юнита.
🤩 В нашем опыте за пару месяцев почти вся команда начинает активно пользоваться кодинг-агентами и лучше понимает полный путь задачи.
___
Короче: если цель — сокращать время реализации с помощью AI, начинать стоит с условий для практики.