AI-системный аналитик: как агент Mindbox изучает задачу, прежде чем написать код
В экосистеме Mindbox экспериментально внедрена роль искусственного интеллекта системного аналитика. Вместо того чтобы сразу генерировать решение, агент проводит предварительное исследование кодовой базы и документации, выявляет архитектурные противоречия и формирует спецификацию задачи. Этот подход позволяет заменить традиционную работу аналитика в команде разработчиков.
# AI-системный аналитик: как агент Mindbox изучает задачу, прежде чем написать код
В современной разработке искусственный интеллект все чаще берет на себя роль ко-программиста, но его вклад ограничен генерацией кода. Старший фронтенд-разработчик компании Mindbox Игорь Уваров рассказывает о том, как его команда перешла к более глубокой интеграции ИИ: агент теперь выступает в роли системного аналитика. Он анализирует репозитории, проверяет архитектурные решения и готовит технические задания, освобождая разработчика от рутины сбора контекста.
Бизнес-задача стояла четкая: в аналитическом отчете необходимо было изменить логику сегментации клиентов. Вместо единой группы «Все клиенты» требовалось ввести разделение на «Идентифицированных» и «Анонимных». Дополнительно нужно было добавить новые метрики: долю выручки и долю заказов. Поначалу проблема казалась простой, однако попытка «вайбкодинга» (написание кода без детального проектирования) показала, что агент, оставленный без глубокого контекста, создает нерабочие решения, размазанные по фрагментам кода.
Исследователь перед программистом
Основная работа разработчика в условиях автоматизации кода смещается на этап подготовки. Программист должен собрать весь необходимый контекст, изучить требования и подготовить условия задачи для нейросети. Чтобы упростить этот процесс, команда внедрила плагин, делегирующий агенту роль аналитика.
Агент не просто генерирует текст спецификации. Он ведет себя как прилежный ассистент: изучает документацию, проверяет историю изменений в репозиториях, ищет скрытые зависимости и ограничения, а затем формулирует вопросы, которые необходимо обсудить с командой. Это позволяет избежать ситуации, когда разработчик, погруженный в детали, упускает важные нюансы архитектуры.
Термин «Слепые пятна» используется в статье для обозначения тех ограничений и забытых решений, которые скрыты в коде. Это могут быть артефакты устаревших функций, специфические условия доступа или нюансы работы с данными, о которых уже никто не помнит. Агент специально настроен на поиск именно таких моментов.
Четыре примера успеха агента-аналитика
В процессе разработки и тестирования плагина было выявлено несколько критических моментов, которые агент успел обнаружить до того, как они привели к ошибкам:
1. Обнаружение забытого решения: В проекте велась практика ведения записей архитектурных решений (ADR). Иногда разработчики или менеджеры забывают о существующих ограничениях, задокументированных ранее. Агент проверил новую задачу против базы ADR и нашел расхождение, которое могло привести к техническому конфликту, о котором никто в команде не знал. 2. Предотвращение нарушения контракта: При добавлении сегмента «Анонимные клиенты» возник вопрос о том, что произойдет, если фронтенд отправит на бэкенд значение all для общего сегмента «Все». Бэкенд-разработчик считал это безобидным. Агент проанализировал код бэкенда и выяснил, что такое значение не входит в список допустимых, а попытка обработки приведет к ошибке и разрушению сохраненных настроек. 3. Спасение при рефакторинге: Во время модернизации кода метрик агент заметил, что план изменений предполагал удаление кусочка кода с важным правилом обработки идентификаторов целей. Хотя без этой логики система могла бы работать, удаление привело бы к некорректным расчетам данных в будущем. Без проверки агента это правило могло бы быть случайно удалено. 4. Расхождения в кодировании: Разработчики фронтенда использовали разные подходы для передачи сегмента «Все» в разные части отчета (пустое значение для таблицы и константа all для графика). Агент отследил эту несовместимость и предупредил о том, что из-за этого данные корректно отобразятся только на графике, а таблица останется пустой.
Под капотом: от скилла к оркестратору
Путь создания плагина не был прямым. Начальный этап представлял собой простой «скилл» (набор инструкций) из 30 строк кода, который давал базовые правила подготовки спецификации. Однако такой подход был недостаточно эффективным и предсказуемым.
Для повышения качества был введены дополнительные механизмы:
* Чек-листы: Агент был обязан проходить структурированный список проверочных вопросов, охватывающий права доступа, корнер-кейсы (пограничные условия), сбои сети, конкурентный доступ и целостность данных. * Агент-критик: Для обеспечения качества был введен субагент, задача которого — не писать код, а критиковать предложенную спецификацию. Критик ищет противоречия, проверяет пограничные случаи и ищет скрытые недостатки, возвращая отчет с замечаниями. * Многоскиллная архитектура: В финальной версии плагин состоит из девяти отдельных скиллов. Они группируют инструкции по контексту: ADR, бизнес-требования, архитектура, пользовательские сценарии в формате Gherkin и словари терминов.
Вторую версию плагина разработали как оркестратора — одного агента, координирующего подчиненные субагенты. Это позволило автоматизировать процесс: от исследования задачи до генерации кода и прогона тестов. Однако оркестрация ввела излишнюю сложность: если на каком-то этапе планирования находили ошибку, приходилось перезапускать весь процесс. Вернувшись к более простой архитектуре набора скиллов, но сохранив субагентов на этапе генерации кода, команда добилась лучшего баланса между гибкостью и эффективностью.
Ограничения ИИ
Несмотря на успехи агента-аналитика, полностью доверить интерфейс пользователю искусственному интеллекту нельзя. Финальная проверка (ручное ревью) остается за человеком.
Даже после тщательной подготовки задачи и успешного запуска тестов команда обнаружила недочеты: * На карточках новых метрик отсутствовало явное обозначение сегмента, по которому рассчитан показатель. Пользователь мог ошибочно считать данные общими. * Логика отображения прироста отрицательных значений была неочевидной: крохотное отрицательное число округлялось до нуля, что визуально скрывало падение показателя. * В ходе рефакторинга исключили фильтр, необходимый для разбивки данных по подписчикам, что привело к отсутствию части информации в отчете для клиента.
История Mindbox демонстрирует, что ИИ не заменяет аналитика, а меняет его функцию. Если раньше аналитик тратил время на чтение кода и поиск зависимостей, то теперь эти процессы автоматизированы, позволяя эксперту сосредоточиться на верификации решений и общении с пользователем. В условиях отсутствия штатных системных аналитиков в компании ИИ стал не просто инструментом, а полноценным участником проектной группы.