Разработчики одними из первых начали использовать ИИ-агентов, чтобы автоматизировать рутинные задачи. Для компании важно, чтобы такие изменения происходили системно: эффект был очевиден, накопленные навыки собирались и обобщались, а разработчиков можно было бы обучать работе с ними.
Меня зовут Станислав Решетнев, я руковожу отделом разработки в компании Sape по направлению Link Building. Сегодня хочу рассказать об успешном опыте по ускорению написания кода с помощью ИИ. Именно это было одной из целей нашей команды Платформы в прошедшем квартале.
Давайте определимся с терминологией в этой статье: этапами будем называть компоненты и модули, а также стандартные операции разработчика в SDLC (Software Development Life Cycle — цикле разработки ПО). Нас интересовали этапы, которые были наиболее трудоемкими и при этом хорошо поддавались решению с помощью накопленных знаний. Но важна была и субъективная оценка разработчиков: насколько полезно, по их мнению, расходуется время. Мы хотели избавить их от задач, на которые приходится тратить много ресурсов, но которые при этом не требуют высокой квалификации и не приносят удовлетворения от работы.
Как искали задачи для автоматизации
Как понять, что именно нужно ускорять? Нам не хотелось опираться только на ощущения, поэтому мы обратились к опыту коллег. На прошлогодней конференции Avito.Conf мне удалось пообщаться с Александром Лукьянченко, CTO Платформы Avito. Я выяснил, что коллеги оценивали этапы разработки с помощью внутренних исследований. И действительно, снаружи довольно сложно понять, как распределяется время разработчика внутри задачи.
Поскольку наша разработка хорошо платформеризирована, выделить этапы было несложно. Мы знаем, с какими стандартными компонентами имеют дело разработчики, а работа с инфраструктурой тоже во многом шаблонна. Сама архитектура диктует то, как с ней будут взаимодействовать.
Наше исследование заняло около 2 недель и охватило более 200 задач из трекера. Для аналитика мы подготовили документ с описанием типовых этапов:
оформление задачи в таск-трекере;
документирование фичи;
рефакторинг;
анализ данных;
создание асинхронных уведомлений;
создание триггерных счетчиков и т. д.
Для каждого этапа мы указали ключевые слова, встречающиеся в задачах, и кратко описали его суть.
Провести реверс-инжиниринг времени, потраченного разработчиком, оказалось сложнее, чем представлялось даже в самом скептическом сценарии. Но в процессе нам удалось найти несколько зацепок — паттернов работы с задачей, которые помогли провести оценку:
Задача полностью посвящена этапу. Самый удачный вариант, но и самый редкий.
Отмечается ход выполнения задачи. Например, разработчик ставит галочки в плане, и тогда мы смотрим на даты редактирования описания.
Есть упоминания о ходе работы в комментариях.
Есть записи о затраченном времени в логах задачи.
Аналитик располагал данными о времени работы сотрудников и при этом учитывал реалистичность сроков. Пришлось покопаться в логах времени, комментариях и истории изменений, а местами и проконсультироваться с разработчиками. Настоящий детектив!
В итоге у нас получился отчет примерно в таком виде:
По каждому этапу мы собрали не менее 10 задач. Отсеяли этапы, которые не имело смысла ускорять: слишком мелкие или встречающиеся редко. Затем провели оценку по ICE (Impact, Confidence, Ease — влияние, уверенность, простота реализации) и учли экспертное мнение команды Платформы. В итоге мы выбрали 4 этапа, которые оформили в 3 платформенных навыка.
Как встроили навыки в процессы разработчиков
Когда мы начали формировать платформенные навыки, разработчики-бэкендеры еще слабо использовали ИИ-агентов. В основном они ограничивались чат-интерфейсами, чтобы уточнить детали или получить ответ на вопрос. Поэтому мы решили выбрать стандартный агент для кодинга — Opencode.
Мы создали плагин для Opencode, который содержит навыки и MCP-интеграции (Model Context Protocol — протокол контекста модели), а также сделали самое главное — интеграцию с нашей Платформой разработки для отправки метрик. В Sape развита система внутренних событий, которую мы используем как для фиксации действий пользователя в UI, так и для различных внутренних метрик и других задач. Например, если мы хотим провести A/B-тестирование новой фичи и собрать обратную связь, достаточно завести новый тип события и добавить в интерфейс форму, которая будет его отправлять.
Плагин устанавливаем непосредственно в приложения через git submodule. Репозиторий с навыками и интеграциями постоянно развивается, а его версия обновляется в приложениях: разработчики получают изменения автоматически и практически незаметно для себя. Так мы могли постепенно развивать и дополнять систему метрик.
Вот так выглядит первое подключение. Плагин перехватывает lifecycle Opencode и запрашивает авторизацию:
Благодаря этому мы можем идентифицировать разработчика и отправлять метрики от его имени. Кроме того, при вызовах инструментов пробрасываются необходимые доступы.
По результатам исследования мы разработали навыки, которые выпускали итеративно: собирали обратную связь и проводили обучение в командах. В итоге в агенте появились:
В процессе реализации мы увидели, что работа с метриками включает целый пласт задач — от проектирования до создания дашбордов:
подготовка перечня бизнес- и технических метрик;
разметка кода для отправки событий через платформенный компонент;
создание дашбордов для Grafana и сохранение их в JSON для импорта.
Раньше по этим темам разработчикам приходилось освежать в памяти несколько статей в корпоративной базе знаний, проходить чек-лист и самостоятельно придумывать метрики. Теперь достаточно попросить агента:
Продумай метрики для модуля GEO-мониторинга, давай тщательно мониторить взаимодействия с внешними API.
По навыку агент предложит согласовать бизнес- и технические метрики, затем добавит отправку сигналов из кода и в довершение сформирует дашборд для Grafana.
Что и зачем измеряли
Метрики использования агентов отправляются через корпоративную систему внутренних событий. Сейчас у нас есть 12 внутренних метрик для агентов: вызов MCP или навыки, используемая LLM (Large Language Model — большая языковая модель), команда Opencode, запрос на разрешение, ошибки, события сессии, компакция и другие.
Мы построили инфополе, чтобы наблюдать за использованием агентов и при необходимости корректировать процесс через 1:1 и командные встречи — публичные код-ревью, встречи по архитектуре и технологиям. Ниже покажу наиболее значимые графики. Они могут стать отправной точкой для разговора с разработчиком.
Лиды следили за задачами, где мог пригодиться уже существующий навык, и напоминали разработчикам о его использовании.
Какой результат получили
Спустя некоторое время мы начали замерять эффект от использования навыков. Результаты оправдали ожидания: по каждому из этапов время выполнения сократилось примерно в 10 раз.
Составление метрик и создание мониторинга традиционно были трудоемкими задачами, особенно для тех, кто занимался этим нечасто. Случалось, что такая задача отнимала неделю рабочего времени. Теперь в режиме диалога можно разметить подсистему событиями и создать рабочую доску с графиками примерно за полчаса.
Некоторое время также ушло на погружение, но в целом разработчики быстро разобрались, как пользоваться навыками. Позитивные отзывы мы начали получать практически сразу: делились опытом на встречах, обсуждали результаты и способы применения навыков.
Итоги: что мы поняли после внедрения навыков
Чтобы понять боли разработчиков, нам понадобилось исследование. Без него мы вряд ли угадали бы, куда именно стоит приложить усилия. Это хорошо видно по тому, насколько наши первоначальные предположения разошлись с результатами исследования. Например, мы предполагали, что для бэкендеров может быть востребован навык для создания сущностей в базе данных, но оказалось, что это не так. В то же время с отправкой метрик из приложения мы настолько попали, что навыки разлетелись как горячие пирожки. Разработчики были благодарны за такую работу.
Не менее важно удобство использования. Навыки автоматически подхватываются в среде Opencode. После первичной настройки остается только пользоваться ими и наблюдать, как агент понимает задачу и берет на себя рутинную работу.
В предложенном решении есть свои допущения. Например, не все наблюдаемо: разработчики используют и других агентов. Но для нас это не принципиально. Важно было увидеть, что они действительно используют наши технологии.
Мы также увидели, что навыки себя оправдали: время выполнения выбранных этапов сократилось на порядок. Мы получили много положительного фидбека от разработчиков: рутины стало меньше, а пространства для качественного проектирования — больше.
А как у вас происходило внедрение агентов для написания кода? Буду рад вашим комментариям.
