Привет! Меня зовут Максим, я бэкенд-разработчик и тимлид в Clevertec, и сегодня хочу поделиться опытом пилота AI-инструментов в команде финтех-проекта. Спойлер: обошлось без магии, но кое-что действительно работает и экономит время.

С чего всё началось

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

Из всех вариантов мы выбрали Junie от JetBrains – свежий инструмент, встроенный в IDE. Он обещал поддержку задач прямо в среде разработки. Казалось удобно, особенно для тех, кто привык не вылезать из IDE.

Дисклеймер

Важный момент. У Junie единственный провайдер – это Claude. И это можно расценивать как недостаток в сравнении с Cursor AI, который интегрирован с разными облачными моделями, что позволяет ему более-менее свободно себя чувствовать, отвечая на разные задачи. Но и вносит момент неопределенности, потому что разные LLM могут по-разному пытаться решить вашу задачу. 

Пилот начали с шестью разработчиками: 4 бэкендера, 2 фронтендера. Не все пошли далеко: кому-то не зашло, кто-то остался, но использует редко.

Какие задачи отдавали AI

Отдавали практически всё, что делает обычный разработчик:

• Написание юнит- и интеграционных тестов

• Реализация типовых задач

• Документирование кода

• Изучение чужих модулей

• Поиск и анализ багов

По каждому направлению накопился свой опыт: где-то AI оказался полезным, а где-то даже мешал.

Что зашло

1. Юнит-тесты. Это прям топ. Junie справляется быстро и в целом неплохо. Из плюсов: автономность – пишет тест, запускает, правит, если что-то не так. А ты в это время делаешь другие задачи.

2. Типовые интеграции. Если дать описание, он сам генерирует клиент, мапперы и даже basic тесты. Главное не пытаться скормить ему бизнес-логику целиком, иначе начнёт фантазировать.

3. Работа с чужим кодом. Когда нужно быстро вникнуть в микросервис с парой таблиц и интеграций, AI может рассказать, что за что отвечает, и даже нарисовать диаграмму классов.

4. Поиск дефектов. Если дать лог или stack trace, AI быстро локализует проблему, особенно если ошибка в пределах одного сервиса. На внешние интеграции, конечно, реагирует хуже.

Где не получилось

Интеграционные тесты с нуля. Тут AI пока слаб. Сложные стабы, контейнеры, настройки окружения. Чаще делает не то, что нужно. Проще самому.

Сложная бизнес-логика. Когда даешь пошаговый план – может сработать. Но как только задача становится длинной, AI путается. Делит, дополняет, изменяет, и всё это мимо.

Качество кода. Тут пока нет полной оценки, статанализаторов ещё не подключили. Но субъективно: если не проверять руками, легко пропустить выдуманные методы и несуществующие поля.

Выводы через 2,5 месяца

• Лучшее, что делает AI – это юнит-тесты. Быстро, адекватно, минимум зависимости.

• Сложные задачи лучше делить на куски. Но и тут нужно держать в уме, что AI может начать «додумывать».

• Контекст важен. Без бизнес-логики AI не знает, что важно, и легко нарушает сценарий.

Промпты – наше всё. Чем точнее формулировка, тем меньше шансов, что AI полезет в бизнес-логику.

Здесь – подробнее о цифрах и задачах

Еще раз подчеркну: все субъективно. Кто-то там ощутил большой буст к производительности, кто-то небольшой.

Если посмотреть ближе на цифры, то в целом результаты неплохие. 

Бизнес-задачи

Они разные. Бывают – добавить одно поле в расчет, формулу в ответ, что не очень много времени занимает. А есть – полноценные фичи, с кучей шагов интеграции. Соответственно, мы из-за этого получаем большую разбежку от 5 до 25%, но все же ускорение есть ускорение.  

Типовые технические задачи 

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

Сходи в систему А, получи ответ, перемапь его в DTO. Не очень сложно. И тут прирост порядка 80%, в зависимости от сложности интеграции.

Тесты

Здесь очень большая разбежка от 50 до 90%. Связана она с тем, что AI прекрасно справляется с написанием юнит-тестов. Если сравнивать, то среднее время написания юнит-тестов на один класс у нас занимало 1-2 часа, а AI справляется за считанные минуты.

Но при этом, как только мы входим в поле интеграционных тестов, где появляются моки, стабы, где приходится интеграцию более детально продумывать – появляется очень сильная просадка. 

Документирование кода

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

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

Изучение реализованных ранее модулей

Очень удобный инструмент. Он может пройтись по небольшому микросервису. Если брать типовой микросервис из проекта: небольшие REST API, связка с тремя таблицами, одна-две внешних интеграции. В этом случае чатбот очень хорошо описывает структуру проекта, что за чем идет, как запрос обрабатывается, какие ветвления там есть, что за чем идет.

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

Исправление дефектов

Тут прирост порядка 10%. Он такой небольшой, потому что затрагивает небольшую часть работы. Он позволяет быстро локализовать проблему. То есть, по сути, если у вас есть лог ошибки или stack trace, вы знаете, в каком месте что пошло не так, но не знаете почему, можно задать чатботу вопрос об этом.

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

Правило трех попыток

Как понять, что хороший результат точно не получится? Я обычно пробую два-три раза. Не больше трех точно, потому что фактически, если на третий раз получаю плохой ответ, скорее всего, уже ничего лучше не придумаешь – дальше сам. 

Тратишь время на ожидание результата, потом проверяешь этот результат: в первый раз ушло 15 минут, не получилось. Пробуешь другой запрос, это еще 15 минут, тоже не получилось. Третий раз еще 15 минут. И если руками задача делается за 2-3 часа, то нет смысла убиваать время на попытки сэкономить 5 минут. Да и лимит стоит денег, тратить впустую его не хочется. Поэтому такие условные ограничения в голове: два-три раза и дальше сам.

Что дальше?

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

Если вы тоже запускали AI-помощников в команде – делитесь в комментариях. Интересно сравнить подходы, грабли и находки.