[Внедрение ИИ в разработке: от скриптов до мультиагентной системы]

Эта статья не про "как выбрать модель", а про то, как мы шаг за шагом пришли к мультиагентной системе, которая помогает разворачивать фичи в продукте от начала до конца с ИИ из нескольких репозиториев.

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

С чем мы столкнулись на старте:

• Несколько репозиториев в одном продукте.
• Одни и те же шаги при старте любой фичи.
• Ручная синхронизация между кодом, спеками и договоренностями.
• Тяжелые ревью, особенно когда изменения затрагивают несколько компонентов.

На этом этапе про ИИ вообще речи не было. Нас интересовало только одно: как уменьшить количество рутинных решений, которые разработчик принимает каждый день.

Что мы сделали вначале:

• Скрипты для генерации шаблонов и бойлерплейта.
• Единую структура фич в разных репозиториях.
• Утилиты для навигации: быстро понять, где что лежит, куда добавлять код.
• Автоматизацию типовых шагов перед PR: проверки, форматирование, подготовка описания.

Фактически мы описали в скриптах ответ на вопросы:

"Как у нас правильно заводить фичу?" "Как правильно разнести изменения по сервисам?" "Как подготовить PR так, чтобы его можно было быстро ревьюить?"

Важно: задним числом стало понятно, что эти скрипты – это уже зашитая политика поведения. Там были правила и ограничения, просто без LLM.

Когда стали доступны LLM-инструменты, мы не начали с "автокомплита всего и вся". Вместо этого мы сделали модель интерфейсом к нашей автоматизации и стайлгайдам, а не "умной чёрной коробкой", которая всё решает сама.

Ключевые принципы:

• Источник истины – код и конфиги, а не ответы модели.
• Архитектурные решения и ограничения зафиксированы заранее.
• LLM работает только в заданных рамках и запускает нужные сценарии.

На практике это выглядело так:

1. Разработчик описывает интент (что он хочет сделать) →
2. Агент понимает контекст проекта (репозитории, сервисы, архитектуру) →
3. Затем агент дергает нужные скрипты/паттерны, а не "придумывает мир с нуля"

Для команды это ощущается не как "ИИ-магия", а как удобный слой поверх знакомых процессов.

По мере роста сценариев один "универсальный" агент начал терять управляемость. Он одновременно пытался планировать, принимать архитектурные решения, писать код в разных доменах и проверять результат. Возникла классическая проблема "бога-объекта", только в форме ИИ-агента.

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

Планер / Архитектор – формирует согласованный план изменений по всем затронутым репозиториям, определяет границы, контракты и порядок внедрения.

• Frontend-разработчик – изменения UI и клиентской логики.
• Backend-разработчик – основной серверный код.
• Bbackend-разработчик с уклоном в legacy – адаптация существующих старых сервисов.
• Разработчик плагинов – интеграции, расширения, внешние точки подключения

AQA – пишет и поддерживает e2e-тесты, проверяет поведенческие инварианты системы.

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

В какой момент стало понятно, что система заработала? Мы дошли до сценария, когда фичу можно проводить почти во весь цикл с минимальным ручным вмешательством:

1. Вход: ТЗ / юзер стори / продуктовая спека
2. Автоматическая декомпозиция:
   - Выделение затронутых сервисов и репозиториев
   - Разнесение работ по ролям
3. Планирование изменений в коде:
   - Что добавить/изменить в каждом сервисе
   - Какие контракты/миграции затрагиваются
4. Генерация и внесение изменений:
   - Код сразу в нужном стиле и структуре
   - Учет специфики конкретного сервиса
5. Тесты и проверки:
   - Генерация/обновление тестов
   - Прогоны линтов, тестов, базовых сценариев
6. Документация и PR:
   - Обновление доков и контрактов
   - Осмысленное описание PR

Роль человека:

• Согласовать архитектурные и продуктовые решения.
• Проверить критические места.
• Принять финальное решение о слиянии.

Результат: меньше случайных решений, меньше "разъехавшихся" подходов, больше воспроизводимости.

Хотя мы целились сначала только в разработку, довольно быстро появились бонусы для других ролей.

Для владельцев продукта:

• Быстрый прогон "сырая идея → формализованная юзер стори".
• Проверка гипотез до захода в разработку.
• Прототипы API/флоу еще до полноценной реализации.
  

Для команды поддержки:

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

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

Для нас критично важно оказалось:

• Единые инженерные стандарты: STYLE_GUIDE на разных уровнях (рут, бэкенд, фронтенд, сервисы).
• Формализованные роли и ожидания: AGENTS-файлы, которые описывают, кто за что отвечает и как принимаются решения.
• Жесткое отношение к инфраструктурному долгу: автоматизация проверок, линты, CI/CD-пайплайны, которые нельзя "обойти по-тихому".

Без этого ИИ просто масштабировал бы расхлябанность – ускорял бы неуправляемые решения, а не воспроизводимые процессы.

Архитектура из нескольких репозиториев сама по себе – нетривиальная штука. Нужен опыт:

• Построения контрактов границ между сервисами.
• Разведения ответственности между репозиториями и командами.
• Управления изменениями на стыках (когда одна фича трогает и API, и фоновые джобы, и фронт).

Мы довольно рано вложились в то, чтобы:

• Договориться, где живут интерфейсы и договоры.
• Стандартизировать структуру фич в разных сервисах.
• Формализовать порядок работ при кросс-сервисных изменениях.

И уже поверх этого стало возможно учить агентов понимать границы и не ломать соседние системы.

Отдельный пласт – это developer experience и эксплуатационная автоматизация:

• Умение увидеть повторяющиеся действия и превратить их в сценарий или тул.
• Привычка сначала описать процесс, а потом его автоматизировать.
• Опыт выкатывания тулинга так, чтобы им действительно пользовались, а не "обходили стороной".

По сути, перед ИИ у нас уже был опыт построения внутренних инструментов для разработчиков. LLM стал не заменой этому опыту, а следующим шагом: мы просто поменяли интерфейс (с CLI/скриптов на разговор с агентом), но не отказались от принципов.

Мультиагентная модель в нашем случае держится на том, что:

• Архитектурные решения не висят "в головах у синьоров", а описаны.
• У нас есть культура объяснять "почему так", а не только "что сделать".
• Мы готовы вкладываться в обновление AGENTS/STYLE_GUIDE/доков, когда меняется архитектура.

Этот опыт критичен: без него ИИ-агенты либо начинают принимать архитектурные решения сами (что опасно), либо постоянно "спотыкаются" о неявные ограничения, о которых знают только люди.

Наконец, важная и часто недооцененная часть – управление изменениями:

• Объяснить команде, что ИИ – это не замена, а усиление.
• Договориться о зонах ответственности: что делает человек, что – агент, а что – скрипт.
• Настроить обратную связь: как разработчики репортят кейсы, когда агент ошибся, и как мы это учитываем в следующей итерации.

Все наши AGENTS/STYLE_GUIDE и мультиагентная архитектура – это не только про технологии. Это ещё и про общую договорённость в команде "как мы работаем с ИИ так, чтобы он помогал, а не мешал".

Кратко, к каким выводам мы пришли:

• Внедрение ИИ – это инженерный и орг-процесс, а не "выбор модели".
• Без базовой дисциплины ИИ только усиливает хаос.
• Самый здравый вход – через производительность разработки и рутину, а не "сделайте нам все автоматически".
• Когда выигрывает разработка, продукт и поддержка выигрывают по цепочке.
• Мультиагентность – не цель, а естественный ответ на рост сложности.

Следующий логичный шаг – выделение отдельного агента, который будет владеть юнит- и интеграционным тестированием как доменом ответственности, а не как побочной активностью разработки. Сейчас тесты частично создаются разработчиками и частично – AQA на уровне e2e.

В будущем мы хотим:

• Отдельного агента, который проектирует структуру юнит- и интеграционных тестов.
• Следит за покрытием и инвариантами на уровне модулей.
• Обновляет тесты при изменении контрактов.
• Выявляет деградации архитектурных допущений до стадии e2e.

Это фактически будет "владелец внутреннего качества" – агент, который оперирует не фичами, а устойчивостью системы.

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

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