Как внедрить ИИ в разработку: план на 3 месяца

Что известно из исследований

Прежде чем строить план, полезно понять, какой эффект вообще можно ждать. Данные расходятся, и ниже разобрано почему.

Цифры расходятся, потому что меряют разное. Эксперименты Microsoft и Google считают скорость отдельного человека на ограниченной задаче. METR смотрит на опытных людей в репозиториях, которые они хорошо знают: там подсказки чаще мешают. Faros и DORA смотрят на команду и релизы, и там картина другая. Код пишется быстрее, PR становятся крупнее, ревьюеры не успевают, стабильность падает.

Отдельно о качестве данных. Faros продаёт аналитику разработки, его выводы построены на корреляциях между кварталами. DORA проводит опрос, её данные — ответы людей. Эксперименты Microsoft и Google проверяли AI-ассистенты 2022–2024 годов, автономных агентов в них не было. Ни одна цифра из таблицы не переносится на вашу команду напрямую. Поэтому в плане ниже первым делом идёт собственный стартовый замер.

Доверие к результату тоже невысокое. В опросе Stack Overflow 2025 46% разработчиков не доверяют точности AI-инструментов, доверяют 33%. Главное раздражение назвали 66%: решения от AI почти правильные, но не до конца. Такой код выглядит готовым и проходит беглое ревью, поэтому проверки в процессе важнее, чем выбор модели.

Для плана из этого следуют три вывода:

1. Ускорение на шаге кода реально. Без изменений процесса до релизов оно не доходит: узкое место сдвигается на ревью и тестирование.
2. Самооценка ускорения ненадёжна. Участники METR были уверены в ускорении, а замер показал замедление. Эффект проверяют по данным Git и CI.
3. DORA в отчёте 2025 года называет AI усилителем: у команд с хорошей инженерной базой он усиливает сильные стороны, у остальных — проблемы. Перед пилотом нужно понять, какая база у вашей команды.

Сначала цель, потом инструменты

«Внедрить ИИ» можно по-разному. Купить лицензии всем разработчикам — это первый уровень: быстрее работает отдельный человек. Перестроить процесс так, чтобы агенты делали задачу от спеки до MR, а люди ставили рамки и принимали результат, — это третий уровень. Уровни подробно описаны в статье AI SDLC. Бюджет, сроки и роли у этих вариантов разные, поэтому цель фиксируют до старта.

Хорошая цель пилота записывается в метриках команды и проверяется через три месяца:

Чек-лист готовности команды

Пункты взяты из модели AI-возможностей DORA 2025 и из того, на чём чаще всего спотыкаются пилоты. Отметьте, что у пилотной команды уже есть.

Как читать результат:

• 9–11. Можно запускать пилот. Пробелы закроются на диагностике.
• 5–8. Пилот возможен, но первый месяц уйдёт на инженерную базу. Чаще всего не хватает быстрых тестов, небольших MR и позиции компании по AI.
• 0–4. Агенты усилят текущие проблемы. Сначала стоит навести порядок в CI, тестах и размере изменений, иначе пилот покажет рост нестабильности.

Почему пункты именно такие. DORA проверила, какие условия усиливают эффект от AI, и выделила семь: понятная позиция компании по AI, качество внутренних данных, доступ AI к этим данным, дисциплина работы с системой контроля версий, работа небольшими партиями, фокус на пользователе и качество внутренней платформы. Например, при частых коммитах растёт эффект AI для отдельного разработчика. При регулярных откатах растёт эффект для команды. Работа небольшими партиями уменьшает трение и улучшает показатели продукта.

Как выбрать пилотную команду и задачи

Команда

В предисловии к отчёту DORA 2025 Джин Ким приводит опыт Adidas. Команды со слабо связанной архитектурой и быстрой обратной связью получили прирост на 20–30% по коммитам, PR и скорости выпуска функций. Команды, плотно связанные с ERP и с медленной обратной связью, почти ничего не получили. Отсюда критерии:

• у команды свой сервис или модуль, который она может выкатывать независимо от других;
• тесты и CI работают, обратная связь занимает минуты;
• бэклог живой и похож на работу остальных команд, чтобы результат можно было перенести;
• лид команды хочет участвовать, его не назначили;
• команда не тушит пожар прямо сейчас.

Худший выбор — самая запущенная легаси-система «потому что там больнее всего». Пилот там покажет, что AI не работает, хотя не работает инженерная база вокруг. Начинать стоит с типичной команды, а к сложным системам переходить после первого результата.

Задачи

Задачи для пилота берут из реального бэклога, специально придуманные задачи ничего не покажут. Хорошие первые задачи:

• новый эндпоинт или экран по образцу уже существующих;
• выгрузка или отчёт с понятными критериями приёмки;
• тесты для модуля, у которого они слабые;
• исправление ошибки, которую можно воспроизвести;
• небольшая доработка внутри одного модуля.

Отложить до второго месяца: изменения общих контрактов между командами, миграции данных, крупный рефакторинг, задачи без записанных требований. Это не запрет: такие задачи идут через агента, но с архитектурным ревью человеком. Принцип описан в статье про harness engineering.

План по неделям

Ниже — программа Праксора, по которой мы ведём пилоты. Её можно пройти и своими силами, если в компании есть люди с опытом агентной разработки.

Недели 1–2. Диагностика

Задача этапа — понять, как задача идёт от идеи до production сейчас, и где она стоит дольше всего.

• Пройти путь одной задачи. Взять 5–10 закрытых задач и посмотреть по Jira и Git, сколько времени каждая провела в постановке, разработке, ожидании ревью, ревью, тестировании и ожидании релиза. Так видно, какую долю жизни задачи занимает сам код.
• Снять стартовые метрики за последние 2–3 месяца: lead time, частота релизов, доля неудачных изменений, время ревью, размер MR, доля переделок. Как считать — в статье про DORA-метрики.
• Разобрать, где живут требования и знания: Jira, Confluence, головы людей, история ревью. От этого зависит, что агент сможет прочитать.
• Согласовать с ИБ, какие данные можно отправлять во внешние модели, нужен ли шлюз и локальная модель.
• Просканировать репозитории агентом: структура, тесты, сборка, явные проблемы, которые помешают агентам.
• Выбрать команду и первые задачи по критериям выше.

Признак, что этап провален: стартового замера нет, а пилот уже начался. Через три месяца результат будут обсуждать по ощущениям, и любой вывод можно будет оспорить.

Недели 3–4. Первая версия harness

Harness — среда вокруг агентов: правила, база знаний, спецификации и проверки, всё в git рядом с кодом. Подробно — в статье Harness engineering.

• Правила для агентов. AGENTS.md с командами сборки и тестов, структурой проекта, договорённостями и запретами. Примеры — в статьях про AGENTS.md и CLAUDE.md.
• База знаний. Архитектурная карта, контракты между сервисами, журнал решений в markdown.
• Шаблон спеки. Цель, контекст, критерии приемки, границы, план. Критерии приемки привязаны к тестам. Подробно — в статье Spec-driven development.
• Проверки в CI. Линтер, тесты, архитектурные проверки, ревью вторым агентом. Всё, что можно проверить автоматически, проверяется автоматически.
• Роли. Кто пишет спеки, кто принимает результат, кто отвечает за правила после пилота.

Сам harness собирается за несколько дней. Остальное время уходит на договорённости о ролях. Без них правила через месяц устаревают: никто не считает их своей работой.

Признак провала: правила написаны «на всякий случай» на сотни строк, а проверок в CI не прибавилось. Агент будет пропускать правила, ревьюеры будут ловить одни и те же ошибки.

Неделя 5. Запуск

Воркшоп с командой на её реальных задачах. Команда проводит две-три задачи из бэклога через весь цикл: спека, код от агента, проверка, выкладка. После воркшопа команда работает только по новому процессу. Параллельный «старый способ на всякий случай» убивает пилот: под давлением сроков люди возвращаются к привычному.

Возражения снимают заранее. На время пилота отключают KPI по дефектам, чтобы команда не боялась пробовать. Если скорость и проседает, то меньше чем на неделю.

Признак провала: после воркшопа задачи по-прежнему делают руками, а агентом пользуются для отдельных кусков кода. Значит, процесс не поменялся, и команда осталась на первом уровне.

Недели 6–12. Сопровождение

Основная работа пилота. Цикл повторяется каждую неделю:

1. По истории git видно, где код писал агент, а где человек правил руками после него.
2. Каждую ручную правку разбирают: чего не хватило агенту — правила, знания, проверки или требования в спеке.
3. Причину исправляют в harness: дописывают правило, добавляют проверку в CI, уточняют шаблон спеки.
4. Дефекты из production привязывают к спекам, чтобы понять, на каком шаге их пропустили.

Править код руками и ничего не менять в harness — значит встретить ту же ошибку в следующей задаче. Пример из практики Праксора: агент-ревьюер заметил, что суммы в сводном отчёте расходятся у части клиентов, хотя тесты были зелёные. Причина — агрегация по серверному UTC вместо местной даты клиента. Команда исправила код и добавила правило и проверку в ревью. В следующем продукте агент учитывал это правило с первой задачи.

Работу агентов ограничивают по масштабу последствий. Изменения внутри одного модуля, покрытые тестами, проходят автоматические проверки. Изменения, которые задевают другие команды, агент сам отправляет на архитектурное ревью. Если агент не прошёл проверку три раза подряд, задачу забирает человек.

К середине пилота класс задач расширяют: от типовых доработок к задачам с изменением контрактов и данных.

Признак провала: доля ручных правок не снижается к восьмой-девятой неделе. Обычно это значит, что правки делают, а причины не разбирают.

Неделя 13. Ревью

Метрики сравнивают со стартовым замером: DORA-метрики, время ревью, размер MR, доля переделок и AI-метрики — какую долю решений принимают агенты и как эти решения влияют на качество. На ревью принимают одно из трёх решений: запускать следующую команду, продлить пилот с конкретными исправлениями или остановиться.

Следующую команду запускают уже свои люди: те 1–3 инженера, которые вели harness в пилоте. Новая команда начинает с готовых правил, проверок и шаблонов, и её запуск идёт быстрее первого.

Роли и время

Самая частая ошибка с ролями — владельцы harness делают эту работу «в свободное время». Время на правила и проверки нужно явно закладывать в спринт, особенно в первый месяц. Если этого не сделать, через три недели правила перестают обновляться, и пилот откатывается к тому, с чего начинал.

Расход на модели тоже планируют заранее. Бюджет токенов задают по командам в шлюзе и смотрят стоимость одной задачи. Мультиагентные схемы расходуют токены быстро: в Anthropic оценивают, что они тратят примерно в 15 раз больше токенов, чем обычный чат. Подробнее — в статье про мультиагентную разработку.

Политика использования AI: что в ней написать

Из семи условий DORA проще всего выполнить первое: понятную позицию компании по AI. DORA с высокой уверенностью показала, что при ясной позиции AI сильнее влияет на эффективность людей и результаты компании, а трения становится меньше. В интервью разработчики говорили, что без такой позиции они либо используют AI меньше, чем могли бы, из страха нарушить правила, либо используют его там, где нельзя. Содержание позиции DORA не оценивала, только её ясность и известность.

Достаточно одной страницы:

• Разрешённые инструменты и как получить доступ.
• Какие данные нельзя отправлять во внешние модели: персональные данные, код под NDA, секреты, коммерческая тайна. Куда идут такие задачи.
• Ответственность за код. Автор MR отвечает за код, кто бы его ни написал. Ревью для кода от агента не ослабляется.
• Что от разработчиков ждут. Пробовать агентов на своих задачах можно и нужно, для этого есть время.
• Как метрики будут использоваться. Для оценки процесса и команды. Оценивать по ним отдельных людей не будут.
• К кому идти с вопросами и где лежат правила для агентов.

Данные и выбор инструментов

Для российских компаний инструмент часто выбирает ИБ. Варианты:

Варианты комбинируют: основная работа идёт через облачную модель, задачи с чувствительными данными шлюз отправляет на локальную. Открытые модели, которые помещаются на доступное железо, обычно слабее лучших облачных на сложных агентных задачах. Перед выбором модель прогоняют на 10–20 задачах из своего бэклога. Подробно о шлюзе и локальных моделях — в статье LLM-шлюз.

Выбор конкретного агента для пилота менее важен, чем кажется. Правила, спеки и проверки из harness переносятся между инструментами. Если в будущем модель или агент сменятся, их не придётся переписывать.

Как измерить результат

Замер строится на сравнении пилотной команды с её же стартом:

• DORA-метрики: lead time, частота релизов, доля неудачных изменений, время восстановления, доля незапланированных релизов-исправлений.
• Метрики процесса: время ожидания ревью, размер MR, доля кода, переписанного в первые недели после мержа.
• AI-метрики: доля изменений, которые агент сделал без ручной доработки, и сколько дефектов пришло из этих изменений.
• Опыт разработчиков: короткий опрос в начале и в конце пилота. Он показывает, где команде тяжело. Ускорение по нему не оценивают: в исследовании METR самооценка разошлась с замером в обратную сторону.

Число PR и строк кода в отчёт не включают. Faros зафиксировал рост PR на 98% в командах, где связи с результатами компании не нашлось. Подробно о замере — в статье Как измерить эффект AI в разработке.

Для руководства результат сводят к трём вопросам: стали ли задачи быстрее доходить до релиза, не упало ли качество, во что это обошлось.

Почему пилоты проваливаются

После пилота: перенос на другие команды

Масштабирование — это перенос готового процесса. Заново строить его в каждой команде не нужно. Правила, шаблоны спек и проверки пилотной команды становятся общей основой. Владельцы harness запускают следующую команду и адаптируют общую основу под её код. Так компания движется к четвёртому уровню: общие знания, правила, агенты и метрики для всех команд.

Порядок обычно такой:

1. Вынести общие правила и проверки из репозитория пилотной команды в общий репозиторий или шаблон.
2. Запустить вторую команду силами владельцев harness, с тем же стартовым замером.
3. Собрать сообщество владельцев из разных команд: изменения в общих правилах проходят ревью, как код.
4. Подключать команды по одной-две. Каждая следующая находит пробелы в общих правилах.

Вопросы