Как мы создавали AI-агента, с которым теперь сами разрабатываем продукты

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

Затем появились ИИ-чаты, которые можно было использовать как «продвинутый поисковик»: уточнять детали, показывать код, обсуждать варианты реализации. Заодно можно было попросить придумать имя методу, пока тот не стал processDataFinalReallyFinal.

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

Так, код стал появляться быстрее, но вместе с ним могла расти нагрузка на ревью, тестирование и сопровождение. Разработчик при этом работал еще и курьером между чатом и IDE.

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

В этой статье расскажем, как мы создавали собственного ИИ-агента и постепенно расширяли круг его задач. Разберем, что стояло за решением добавить ту или иную возможность и как ее появление меняло работу над проектом. А в конце обсудим, как изменилось мышление ^[1] разработчиков и что осталось человеку, когда написание кода, создание тестов и проверку изменений уже можно делегировать.

Почему мы решили внедрить ИИ агента в разработку?

Нейросети сейчас — настоящий хайп, но одного желания добавить “AI” к названию продукта нам было недостаточно. Это отличный бустер эффективности, если использовать его с умом. Быстро получить код полезно, но этот код еще нужно проверить, встроить в проект и потом поддерживать. Хотелось делегировать больше работы, а не просто быстрее получать новые задания для себя.

Мы все понимаем: искусственный интеллект ^[2] уже значительно меняет разработку — классический подход, когда весь код писали руками, уходит в прошлое. Наша команда всегда была открыта новым технологиям, но всегда мы подходили к ним с некоторой долей критики, понимая, что не стоит брать на вооружение технологию, в которой недостаточно разбираешься и не знаешь, какой тех долг накопишь от ее использования. Поэтому мы решили сказать «да» внедрению ИИ, но с условием: мы должны четко понимать, как работает то, что мы внедряем, мы хотели минимизировать эффект “magic”. Собственный агент — не только ускоритель разработки, но и возможность разобраться в том, что происходит “под капотом”, а еще — настроить инструмент именно под требования нашей команды.

Наша первая “проба пера”— плагин для автоматической генерации тестов с помощью языковой модели. Его разработку мы начали в 2024 году. Он сразу работал внутри IDE и помогал писать тесты, но агентных возможностей в первой версии еще не было.

Осенью того же года мы добавили в плагин чат с языковой моделью. Необходимая основа уже существовала, поэтому возможность обсуждать задачи прямо в IDE стала логичным продолжением. А в январе 2025 года мы познакомились с возможностями Windsurf и решили развивать собственного агента для Jetbrains IDE.

Постепенно становилось понятно, что генерацией тестов можно не ограничиваться. Нашим следующим решением стало дать возможность плагину работать с файлами и выполнять действия: находить нужный код, вносить изменения, запускать проверки. Нам было важно, чтобы каждый член команды мог использовать возможности агента. При этом работа должна была оставаться именно командной, потому что работать с искусственным интеллектом одному — просто. Разработчик владеет всей полнотой контекста, дает промты, следит за выполнением и помнит, какие задачи уже закрыты. А вот организовать совместную работу, чтобы каждый мог пользоваться агентом без потери контекста и понимал, что уже сделали коллеги, — задача посложнее, хотя сама практика разработки по спецификациям существовала у нас еще до создания ИИ-агента. Поскольку мы привыкли работать в IntelliJ, именно эту IDE мы выбрали в качестве нашего плацдарма.

Как мы расширяли возможности агента

Начнем с языковых моделей. В нашем агенте можно работать с разными LLM: у каждой свои преимущества и ограничения, поэтому привязывать все задачи к одной модели нам не хотелось. Агент поддерживает все современные модели от OpenAI, Anthropic, Google, DeepSeek и др. В том числе поддерживаются возможность для добавления моделей, запущенных локально через ollama. Сейчас новые модели выходят каждый месяц, в день выхода добавляются в нашу собственную платформу-агрегатор и становятся доступны в плагине. Модель можно выбрать вручную либо пользоваться режимом autopilot.

Как мы все понимаем, базовые тулы агента — это просмотр и редактирование файлов, поиск кода и запуск команд. Одной из фишек нашего плагина стало то, что для поиска нужной информации мы использовали возможности самой IntelliJ IDEA: индексы и дерево PSI. Индексы помогают быстро находить файлы, классы и методы, а PSI представляет код как структуру с отдельными элементами и связями между ними. Агент использует эти сведения, чтобы находить нужные участки проекта и передавать их модели. 

Вместе с инструментами понадобился и контроль над их использованием. Одной просьбы “ничего лишнего не трогай” недостаточно — даже если написать ее капсом. Поэтому в плагине мы предусмотрели отключение инструментов и подтверждение действий. Можно отключить конкретный инструмент либо настроить запрос разрешения перед его выполнением. Разработчик может разрешить операцию или отклонить ее. Этот порядок контролирует сам плагин, поэтому нам не приходится полагаться на то, что модель вспомнит и выполнит просьбу “сначала спроси”.

Как мы все понимаем, разработка происходит не в вакууме. Интеграция с другими сервисами — базовая часть работы над проектом. Поэтому мы добавили поддержку внешних подключений через MCP. И это не только GitHub, через который агент может прочитать описание задачи, посмотреть pull request и коммиты. С помощью MCP-серверов можно подключать базы данных, BI-системы для аналитики и облачные платформы, например Яндекс Cloud или Amazon Web Services. Также можно подключить браузер, чтобы агент проверял поведение ^[3] веб-приложения. 

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

В процессе разработки плагина, пока агент еще не получил четкие рамки, правила и порядок работы, он может слегка чудить (а иногда и не слегка). Например, на одном из проектов агент несколько раз ошибался при работе с базой. Однажды SQL-запрос ушел не на тот стенд и вернул правдоподобный, но неверный результат. А еще агент раз за разом путал названия колонок. Приходилось объяснять, с какой базой работать и что учитывать при составлении запросов, а в новом чате — повторять ^[4] все заново.

В итоге нам пришло понимание, что одни и те же последовательности шагов мы задаем агенту снова и снова. Эти повторяемые последовательности мы оформили в skills. По сути, это готовые инструкции: что нужно сделать, в каком порядке и на что обратить внимание ^[5]. Вместо того чтобы каждый раз заново составлять длинный промпт, разработчик может использовать уже подготовленный навык. Так мы закрепили общий порядок работы с агентом, чтобы каждый не объяснял одни и те же требования своими словами. При необходимости инструкции можно дополнять и адаптировать под конкретный проект.

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

Очень полезный навык, который также появился в результате нашей работы над проектами, в том числе при разработке самого плагина, — это code review. За основу мы взяли замечания, которые разработчики нашей команды оставляли при проверке кода коллег в pull request. Когда мы работали над самим плагином, мы чаще всего сталкивались с ошибками многопоточности и использования IntelliJ API. Например, с долгими операциями на EDT и вызовами IntelliJ API без необходимого read action. Эти замечания помогли нам сформулировать, на что агент должен обращать внимание, чтобы разработчикам не приходилось каждый раз объяснять одни и те же требования. На их основе мы подготовили инструкции, по которым агент проверяет изменения, в том числе в текущей локальной ветке. Когда мы зафиксировали эти случаи в ревью, мы заметили, что подобных ошибок стало гораздо меньше. 

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

Навык code review мы многократно дорабатывали на собственных проектах, но его можно адаптировать и под другую команду: изменить правила проверки и добавить требования, важные для конкретного проекта.

Чтобы агент мог учитывать опыт ^[7] предыдущих задач, мы добавили memory — память ^[8] проекта. Он записывает полезную информацию в локальное хранилище и использует ее даже в новом чате. Что именно сохранить, решает языковая модель, но по заранее написанным нами правилам. Например, она может запомнить ограничения, которые задал разработчик. Если агент долго фиксил баг или разбирался с тестом, найденное решение тоже может попасть в память. Разработчик также может прямо попросить записать нужную информацию в memory. При этом согласно правилу учетные данные сохранять запрещено. Так меньше приходится объяснять заново, а агенту проще не наступать на те же грабли.

Отдельно мы выстраивали передачу контекста между разработчиками через спецификации в репозитории. Сама практика разработки по спецификациям существовала у нас еще до создания ИИ-агента, но с делегированием написания кода описанию задачи стали уделять больше внимания. Этот процесс мы дорабатывали постоянно. Сейчас работа над каждой функцией начинается со спецификации: разработчик составляет ее вместе с агентом и создает отдельный pull request. Другой разработчик проверяет документ и одобряет его, и только после этого начинается реализация. Проще ревьюить спецификацию, чем готовый код, поэтому мы стараемся договориться обо всем на берегу. В репозитории также фиксируются принятые решения и уточнения, чтобы было понятно, что уже сделано. Например, при веб разработке бэкенд-разработчик описывает изменения, а фронтенд-разработчик читает их и использует в своей части проекта.

Параллельно мы постоянно дорабатывали интерфейс по отзывам пользователей и собственному опыту — ведь сами работали с плагином и замечали, что неудобно. Например, раньше картинки и файлы прикреплялись отдельно от текста сообщения. Мы сделали так, чтобы ссылку на вложение можно было вставить прямо в нужное место промпта, рядом с пояснением. Так проще показать, к какой картинке или какому файлу относится конкретная просьба, особенно если в сообщении несколько вложений.

Еще добавили «прилипающие» сообщения. Когда агент долго отвечает, исходный запрос остается сверху, а не теряется за очередной порцией текста. Теперь не нужно прокручивать переписку назад, чтобы вспомнить, что именно было поручено.

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

Выходим за пределы IntelliJ IDEA

Следующим шагом стал выход за пределы IntelliJ IDEA. В нашей компании работают не только разработчики. Маркетологам и менеджерам тоже интересны возможности агента, но устанавливать и осваивать IDE ради своих задач им незачем. Отсюда появился запрос: можно ли пользоваться теми же инструментами без среды разработки?

В июне 2026 года мы начали переработку продукта и решили отделить агентскую логику ^[9] от интерфейса плагина. Сейчас уже выпущена отдельная терминальная версия — CLI. Ее можно запустить без IDE и общаться с агентом обычным текстом. В ней доступны все те же возможности: работа с файлами, написание и проверка кода, запуск тестов, навыки, правила и подключения через MCP. Можно выбирать языковые модели и распределять задачи между субагентами.

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

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

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

Что изменилось в работе команды?

А теперь посмотрим, какие плюсы и минусы мы заметили после внедрения агента. Самый ожидаемый и планируемый — это ускорение разработки. Теперь на некоторые технически сложные задачи мы тратим в 3-5 раз меньше времени, а многие баги зачастую и вовсе решаются агентом за один промпт. Чтобы оценить изменения, мы проанализировали pull request за два периода: более 500 — с января 2025 года по июнь 2026 года, до внедрения обновленной методологии работы с агентами, и около 250 — после июня 2026 года. Для сравнения выделили фичи, которые команда разработки оценила как средние и крупные и смотрели на время от взятия задачи в работу (назначения ответственного и включения в итерацию), до появления в публичном релизе.

Из положительных изменений, которые не поддаются метрикам, — это трансформация мышления разработчиков. Разработчики стали мыслить более стратегически. Раньше много внимания уходило на техническую реализацию: нужно было написать лаконичный, понятный код. Теперь почти весь код пишет агент, а важнейшей задачей разработчика стала подготовка спецификации. Нужно заранее продумать, как должна работать функция, что увидит пользователь и какие действия ему предстоит выполнить. В нашей команде внимание заметно сместилось в сторону UX/UI. 

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

Теперь о минусах. Кодовая база стала разрастаться. Раньше разработчики старались писать аккуратно и лаконично, а агент иногда ведет себя как параноик: пытается предусмотреть множество ситуаций, которые в нашей задаче вообще не могут возникнуть. На каждую появляется дополнительная проверка или отдельная обработка. Поэтому разработчику нужно проверять написанный код и вовремя проводить code review. 

И да, еще один минус — у агента нет своего критического мышления. Поэтому он не всегда замечает, когда пора остановиться и сделать рефакторинг. Разработчик должен сам замечать неудачные решения и вовремя перестраивать код, чтобы агент не продолжал дописывать его по тому же образцу. Это по-прежнему ответственность человека. 

Что же остается человеку?

Теперь поговорим о том, что остается человеку, когда, в общем-то, почти все основные действия может выполнять агент. Чтобы ответить на этот вопрос, пройдем весь путь работы над новой фичей.

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

Если задача требует отдельного архитектурного плана, просим подготовить его по готовой спецификации. Этот план тоже ревьюится. Саму спецификацию отправляем в pull request, чтобы ее проверил и одобрил другой разработчик. Только после согласования отдаем задачу агенту на реализацию. Здесь по-прежнему действует наш принцип: проще ревьюить спецификацию, чем потом переделывать готовый код.  

Дальше агент пишет код, создает и запускает юнит- и интеграционные тесты. Проверки идут уже во время реализации. Но это не повод свернуть IDE и вернуться только за готовой фичей. Разработчику все равно нужно следить, что пишет агент: не разрастается ли код из-за ненужных проверок, не усложняет ли он участок, который лучше переписать. Поэтому нужно вовремя останавливаться, проводить code review и решать, где нужен рефакторинг.

Когда реализация готова и автоматические проверки пройдены, остается ручное тестирование. Через MCP можно подключить браузер и поручить агенту пройти часть сценариев. Но итоговый результат все равно оцениваем сами. Смотрим, удобно ли пользоваться новой функцией, понятны ли кнопки и сообщения, легко ли пройти путь до нужного действия. Для веб-приложения проверяем верстку на компьютере, телефоне и планшете: ничего ли не съехало, не перекрывают ли элементы друг друга.

Если что-то работает не так, как мы задумали, описываем проблему и возвращаем задачу на доработку. Это касается и технических ошибок, и интерфейса. После исправлений снова проверяем результат. Развертывание делаем сами или поручаем агенту, если ему доступны нужные инструменты и разрешены соответствующие действия. 

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

Получается, работы у разработчика все еще достаточно. Нужно корректно поставить задачу, проверить спецификацию и план, следить за реализацией, проверять, не разрастается ли кодовая база, и принимать решения о рефакторинге. Затем — проверить поведение ^[10] приложения и интерфейс, организовать выкладку на прод и разбираться с обратной связью. Многие действия можно делегировать, но оценивать результат и решать, что делать дальше, по-прежнему приходится самим.

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

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