Если вам обещают, что ИИ ускорит разработку в 5 раз — скорее всего, вам пытаются что-то продать. Особенно если «волшебство» сводится к установке плагина в IDE.
Меня зовут Алиса Герасимова, я руковожу отделом функционального тестирования в центре разработки и машинного обучения «Инфосистемы Джет». В статье расскажу, как ИИ ускорил одну из наших команд разработки, но с цифрами из реального мира. Поговорим про метрики, разграничение ролей между человеком и ИИ, а также честно покажем, где машина больше мешает.
Статья будет полезна тимлидам, скрам-мастерам и всем, кто устал от маркетинговых метрик без контекста.
Немного вводных
Вместе с командой мы помогаем вендору «Лаборатории Числитель» разрабатывать два больших инфраструктурных продукта:
-
«Пульт» – система мониторинга ИТ-инфраструктуры на базе Zabbix, дополненная функциональностью для крупных инсталляций: высокопроизводительное хранение данных с использованием ClickHouse, расширяемый модуль отчетности, репозиторий шаблонов и прочее.
-
«Графиня» – платформа визуализации данных в духе enterprise observability. Проще говоря, это первый аналог Grafana, разработанный с нуля.
На примере разработки этих продуктов покажем, как нам удалось ускорить процессы с помощью ИИ без потери качества.
Как использовали ИИ в этом цикле
Мы изначально договорились, что внедрение ИИ не будет просто A/B-тестом в «лабораторных» условиях, а хотели смотреть на метрики в реальных процессах и параллельно копить экспертизу.
Искусственный интеллект использовала вся команда. Ничего, кроме ИИ, не изменилось: стабильный состав, двухнедельные спринты и привычные процессы. Длину спринта и роли специально не трогали, чтобы не нарушить чистоту эксперимента.
Что изменили в рабочем процессе:
-
Отдали ИИ рутинный кодинг. Для этого у каждого разработчика на выбор был Cursor и Codex. Код, рефакторинг, логи, черновики под задачу — все по привычной цепочке «задача → реализация → ревью». ИИ занимается рутиной, а человек продумывает детали, проводит ревью и принимает решения.
-
Делегировали фоновые задачи субагентам. Отдали параллельные узкие задачи: анализ диффов, поиск по репозиториям, подбор формулировок. Человек все еще проверяет результаты и принимает решения, но уже не тратит время на переключения между контекстами.
-
Перешли на spec-driven development. Начали писать спецификации и контракты строго до реализации кода. ИИ выдает неплохой код, который может не сходиться с изначальными договоренностями. Опора на SDD — это жесткие рамки, которые помогают получать предсказуемый результат.
-
Оцифровали контекст через скиллы и интеграции. Подключили ИИ к Git, Jira и Confluence через MCP, а в репозиторий вынесли правила кода, конвенции по мержу и описание предметной области. Без прописанной базы первые недели ИИ был почти бесполезен и отнимал время на настройку и погружение. Со временем процесс пошел.
И еще немного о культуре работы со скиллами.
Когда ИИ выдает неточный результат, естественная реакция — забить и поправить руками. Или исправить нейросеть в рамках конкретной итерации, но в итоге все равно забить.
Чем плох такой подход: ограничения не фиксируются, модель не учится через контекст, а люди не обмениваются опытом. В итоге разработчики вынуждены каждый раз тратить время на ручное исправление ошибок, с которыми сталкивались либо они сами, либо их коллеги.
Мы ввели правило: при каждом отклонении от требуемого результата формулировать конкретное ограничение — почему не так и, как должно быть. Эти ограничения уходят в скиллы и становятся частью контекста для всех. И самое приятное: мы исправляем типовые ошибки ИИ один раз сразу для всей команды.
Где ИИ дал результат, а где — нет
Типовые задачи сильно ускорились. Добавление новой трансформации данных с описанием user story, разработкой и тестированием раньше занимало 2 дня. С ИИ — 2 часа. Новый плагин источника данных: было 5 дней, стал 1 день. В задачах, которые команда хорошо понимала и много делала руками, ИИ снял рутинный слой. Разработчики сосредоточились на ревью и edge cases.
Автогенерация тестов пока шумит. Тесты, сгенерированные без плотной привязки к SDD, дают ложные срабатывания и покрывают не те сценарии. Пока это скорее черновик, чем готовый артефакт. Со спеками результат более предсказуемый, но тогда процесс требует больше времени на настройку и отладку.
Сложные задачи — рулетка. Когда задача новая и незнакомая, подход «сделай по аналогии» не работает. Разработчик тратит 2 часа на промптинг, потом 2 дня на отладку. В таких задачах не стоит кидаться в код, а лучше инвестировать время на творческую работу — проектирование и риски.
Баги в руках человека. Часть разработчиков для починки багов ИИ сознательно не открывает: пофиксить руками по свежей памяти быстрее, чем расписывать контекст в промпт.
Как считали метрики, и что получилось
О метриках договорились заранее, чтобы не подгонять их под вывод. А еще сразу исключили нерепрезентативные, например, сэкономленное время разработчиков или долю AI-generated кода.
Что считали:
-
Baseline. В плане на первое полугодие — 20 задач основного scope. За три месяца при равномерном темпе ожидали закрыть 10. С этим числом и сравниваем.
-
ФСТЭК — отдельно. С января та же команда в тех же спринтах ведёт сертификацию продуктов по ФСТЭК. Это другой тип работы, ее в основной поток не вмешиваем — иначе раздуем или обесценим картину.
-
Velocity. Story points из Jira. Сравниваем стабильный период без ИИ (спринты С16 – С22, август – ноябрь 2025, в среднем ~75 SP) с периодом с ИИ (С1 – С5, январь – март 2026). Декабрь в расчёт не берём, учитываем типичный всплеск закрытий в конце года.
-
Фичи и баги. Считаем закрытые user stories и баги за спринт — дополнение к SP, меньше зависит от инфляции оценок.
Вместо базового плана в 10 задач (baseline) за квартал, команда закрыла 18 задач по основному потоку (13 из запланированных и 5 дополнительных). Держим в уме ещё 13 задач из параллельного трека по ФСТЭК (который договорились не считать), и получаем очевидное перевыполнение плана.
На графике — явный скачок производительности: если до внедрения ИИ средний показатель velocity держался на уровне ~75 SP, то после перехода на новые практики он стабилизировался в диапазоне 120 SP за спринт.
Рост story points видим и в абсолютном количестве закрытых задач: объём выполняемых фичей и багов увеличился с 10-18 до 17-23 за один спринт. В результате фактический прирост пропускной способности (throughput) составил более чем 1.5x по сравнению с плановыми показателями.
В среднем за цикл по основному потоку оцениваем эффект как ускорение на 50%+. Результаты неплохие, но даже для первого этапа не потолок.
Почему эффект могли занизить
ФСТЭК не входит в метрику основного потока. Команда параллельно закрыла 13 задач по сертификации. Эта нагрузка не попадает в основной scope. Без отдельного учёта кажется, будто команда только ускорила фичи, хотя часть ресурсов ушла в другой тип работы.
Старт без общей методики. Первые недели — проб и ошибок, без единых курсов и «школы промптов». Скиллы, SDD и дисциплина контекста донастраивались по ходу. С теми же правилами с первого дня выигрыш мог быть выше.
Замер на типовом контуре. Осознанно опирались на уже освоенные задачи. На сложных и новых статистики мало — velocity (общий темп выполнения) по сумме может недоговаривать про потенциал там, где ИИ ещё не разогнали.
Нет агентов в CI/CD. В эти цифры не входит автоматизация пайплайна и предварительное ревью агентами — потолок по конвейеру пока не трогали.
Что делаем дальше
Spec driven development на следующем уровне. За квартал мы сместили акцент на спецификации до кода. Дальше планируем плотнее завязать проверку соответствия спека и реализации в CI. В идеале у разработчика и ИИ должен быть единый источник правды для разработки, ревью и ИИ-подсказок.
Инфраструктурные ИИ-агенты. Уходим от сценария «каждый сам договорился с моделью» к агенту как части конвейера:
-
CI/CD: агенты на шагах пайплайна: разбор падений, предложение патчей под известные классы ошибок, синхронизация артефактов со спеком, черновики changelog из диффов и задач. Всё с обязательным ревью от человека и ограниченными правами на репозиторий.
-
Ревью и качество: предварительный проход по Merge Request — стиль, очевидные уязвимости, несоответствие контрактам, пропуск тестов. Агент даёт сигнал и черновик, не «зелёную кнопку».
ИИ в связке со спеками. Инфраструктурные агенты используют те же спецификации, что и разработчики: проверка расхождений между спеком и реализацией, генерация заготовок тестов по контракту — с человеческим финальным ревью. Стандарты промптинга и код-ревью с опорой на спецификации, шаблоны «задача + контракт + примеры».
Качество и наблюдаемость. Расширяем метрики: баги на фичу, техдолг, время ревью. Отдельно для ИИ-сценариев — метрики полезности: принятые предложения, экономия времени, ложные срабатывания. Если ИИ ускоряет создание, но снижает качество — чистый выигрыш ниже, чем показывает velocity. Нужны данные, чтобы это увидеть.
Ретроспективы по ИИ-агентам. Регулярный холивар: где ИИ сэкономил время, где ввёл в заблуждение, какие промпты и куски спека переиспользовать, что в спецификациях «плывёт». Отдельно по инфраструктурным агентам: какие шаги пайплайна им доверили, где шумят, что отключили.
Что мы поняли
1,5× после первого касания. Мы стартовали с типовых задач, без отдельной программы обучения и на ходу разбирали косяки, нарабатывали опыт и скиллы для ИИ. А еще начинали без инфраструктурных агентов и без жёсткой нормализации сложности между периодами. Получается в итоговом коэффициенте смешаны ИИ, зрелость команды и особенности метода.
Что мы точно можем утверждать: ускорение типовых задач с нескольких дней до нескольких часов — не погрешность замера.
Что мы пока не можем утверждать: внедрение ИИ точно ускоряет разработку на 50%+. Продолжим замеры, добавим новые метрики и в следующем квартале увидим, насколько эффект устойчив.
Если у вас есть опыт замеров эффекта ИИ в спринтах (хотя бы индивидуального) — напишите в комментариях, будет интересно сравнить подходы.
ссылка на оригинал статьи https://habr.com/ru/articles/1032034/