AI в разработке: 30-60% ускорения — реальность или хайп?

Февральский эксперимент

Февраль 2025-го. Рабочий созвон, экран расшарен — тимлид пишет Flink-джобу для нового пайплайна обработки транзакций. Рядом открыт корпоративный AI-ассистент. Тимлид формулирует задачу, получает код, копирует в IDE. Через двадцать минут у него есть рабочий скелет стримингового пайплайна — маппинги, окна агрегации, watermark-стратегия. На это обычно уходит полдня.

Я смотрю на результат и думаю: ок, впечатляет. А потом замечаю, что сгенерированный код использует ProcessingTime вместо EventTime. Для нашей системы, где задержки между источниками могут достигать минут, это катастрофа. AI не знает, что у нас разнородные источники данных с разным latency. Он выдал технически валидный код, который в продакшене перемешал бы события из разных временных окон.

Этот момент задал тон всему нашему подходу к AI в команде. Не «ура, ускорение!» и не «фигня, не работает». А трезвый вопрос: где граница между ускорением и иллюзией ускорения?

Контекст: Decision Engine и 20 ТБ в сутки

Я руковожу кластером разработки платформы предодобренных персонализированных кредитных предложений ВТБ — Real-Time и Batch Decision Engine. Обработка 20 ТБ данных в сутки, 500K RPS в production, формирование офферов по всем кредитным продуктам для всей клиентской базы банка в реальном времени. Стек: Flink, Kafka, Tarantool, Scala, Python.

И здесь — классическая проблема enterprise Big Data. Скоуп недооценён на старте. Каждый спринт вскрывает новые зависимости. Требования меняются быстрее, чем команда реализовывает предыдущие. Интеграции с десятками банковских систем, регуляторные ограничения ЦБ, legacy-контракты.

Когда в конце 2024-го AI-инструменты дозрели до уровня «можно пускать в продуктовый код», мы начали эксперимент. Не приказом сверху — «теперь все используют AI-ассистент» — это путь к хаосу. А пилотом. Сначала аналитики — у них самые формализованные задачи. Через месяц показали результаты команде. Потом разработчики. Потом тестировщики.

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

Где деньги лежат

Бойлерплейт и шаблонный код — здесь AI просто зверь. CRUD, маппинги DTO, конфигурации сервисов, миграции БД. Раньше scaffolding нового микросервиса с REST API, валидацией, обработкой ошибок и логированием — 2-3 часа. Сейчас — 30-40 минут, включая ревью. Экономия 70-80%, и качество ревью при этом не страдает, потому что валидировать шаблонный код — задача механическая.

Рефакторинг — 50-60%. Миграция компонентов между версиями фреймворка, переименования с учётом зависимостей, смена паттернов. AI держит контекст всего проекта и не пропускает импорты в дальних файлах. Рутина на несколько дней сжимается в полдня.

Тесты — 60-70%. И вот тут неожиданный бонус: AI методично перебирает граничные случаи, о которых ты не подумал. Null-значения, пустые коллекции, максимальные размеры, concurrency-сценарии. Покрытие растёт в 3-4 раза быстрее. Но — и это важно — ты определяешь стратегию тестирования. Что тестировать, на каком уровне, какие инварианты. AI генерирует, ты думаешь.

Документация — 50-60%. Черновик по структурированным заметкам генерируется за минуты. Аналитик редактирует вместо того, чтобы начинать с пустого документа. Формализация требований из записей митингов — скелет user stories с acceptance criteria готов быстрее, чем ты допьёшь кофе.

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

Где AI создаёт иллюзию

Архитектурные решения. AI предложит пять вариантов — и все будут технически корректны. Но выбор определяется вещами, которые не помещаются в промпт: политика организации, компетенции конкретных людей в команде, планы развития продукта на два года вперёд, регуляторные ограничения ЦБ, legacy-системы с обратной совместимостью. Ускорение — 10-20%, и то за счёт генерации вариантов для обсуждения, не за счёт принятия решений.

Дебаг распределённых систем. Race conditions, каскадные отказы, intermittent failures под нагрузкой. У нас был кейс: стриминговый пайплайн терял события при определённом паттерне нагрузки. AI видел код, но не видел графики Grafana, не понимал паттерны нагрузки, не знал, что этот конкретный топик Kafka переключается на другой брокер при перебалансировке. Диагностика таких проблем — детективная работа, и AI в ней ассистент, а не детектив.

Code review бизнес-логики. AI ловит null pointer exceptions, неоптимальные запросы, стилистические проблемы. Но пропускает ошибки в бизнес-процессах. Он не знает, что клиенту категории Premium скидка считается иначе, если это не описано явно. Он не знает, что status = 3 означает «клиент на ручной проверке из-за санкционных ограничений». Доменное знание — пока за человеком.

Матрица: что куда

Тип задачи	Экономия	Качество результата AI	Уровень контроля
Бойлерплейт, CRUD	70-80%	Высокое	Минимальный
Тесты, автотесты	60-70%	Среднее-высокое	Средний
Документация	50-60%	Среднее	Средний
Рефакторинг	50-60%	Высокое	Средний
Прототипирование	40-50%	Среднее	Высокий
Бизнес-логика домена	20-30%	Низкое-среднее	Обязательный
Архитектура	10-20%	Низкое-среднее	Обязательный
Дебаг сложных систем	10-15%	Низкое	Обязательный

Закономерность очевидна: чем формализованнее задача, тем выше эффект AI. Чем больше неявного контекста — тем ниже.

Как мы это внедряли (без лозунгов)

Начали с аналитиков. Собрали рабочие промпты в Сфере.Знания — «как генерить тест-кейсы», «как писать документацию», «как делать code review». Не заставляли каждого изобретать велосипед.

Ввели правило двойной проверки: любой результат AI проходит ревью человеком. Без исключений. Это не бюрократия — это гигиена. После случая с ProcessingTime vs EventTime никто не спорил.

Измеряли эффект честно. Не «нам кажется, что стало быстрее», а сравнение velocity в спринтах до и после. Первый месяц — результат нулевой. Люди тратили время на освоение инструментов, промпты были кривые, результаты AI приходилось переписывать. Второй месяц — начало роста. Третий — вышли на плато. К четвёртому месяцу сформировалась библиотека промптов и паттернов, которые реально экономили время. Кривая внедрения — классическая J-образная: сначала хуже, потом сильно лучше.

Отдельная история — сопротивление. Двое разработчиков принципиально отказывались от AI-инструментов. Один — из соображений «я и так быстро пишу код». Второй — из опасений за качество. Мы не давили. Через два месяца первый увидел, что коллега с AI закрывает задачи заметно быстрее, и пришёл сам. Второй так и не пришёл — и это его право. Заставлять людей менять инструменты силой — путь к саботажу.

Безопасность по умолчанию. В regulated-окружении нельзя гнать реальные данные во внешние сервисы. Это требует отдельной работы по настройке: локальные endpoint-ы, обезличенные тестовые данные, правила работы с промптами, в которых нет конфиденциальной информации. Скучная работа, но без неё любой AI-эксперимент заканчивается звонком от службы безопасности.

Контекст решает всё. Файлы с правилами проекта, примеры кода, описание доменной модели — всё это кратно повышает качество генерации. AI без контекста — это рандомный генератор технически валидного, но бесполезного кода. AI с контекстом — это junior, который читал всю документацию и запомнил её лучше, чем ты.

Pet-проект как лакмусовая бумажка

Параллельно с enterprise я использую те же инструменты на собственном full-stack проекте. И вот что интересно: на pet-проекте ускорение ещё заметнее. Не потому что задачи проще — потому что нет организационных ограничений. Нет compliance, нет согласований, нет обезличивания данных.

Работающий MVP за сроки, несопоставимые с традиционной разработкой. Конкретный пример: мне нужно было реализовать сложную интеграцию нескольких внешних API с кешированием, обработкой ошибок, retry-логикой и rate limiting. В прошлой жизни — неделя работы минимум: изучить документацию каждого API, написать адаптеры, покрыть тестами, отладить граничные случаи. С AI — два вечера. Я описал контракты, описал поведение при ошибках, описал стратегию кеширования. AI генерировал код. Я ревьюил, корректировал, запускал. Самое интересное: AI нашёл edge case в документации одного из API, который я бы пропустил — несоответствие между описанием формата даты и реальным ответом. Машина прочитала доку внимательнее человека. Но — и это важно — она не знала, зачем мне эта интеграция и какие данные критичны. Это знал только я.

Но — и это ключевое — все решения о том, что строить, для кого, какую проблему решать, принимал я. AI кратно ускоряет execution, но не заменяет product thinking. Архитектуру pet-проекта я тоже определял сам, опираясь на опыт enterprise-систем. AI предлагал варианты, но финальное решение — человеческое.

Какие модели я сравнивал (на момент доклада, 2024)

В рамках пет-проектов я тестировал несколько моделей на реальных задачах — от генерации кода до создания учебного курса.

ChatGPT (GPT-4, позже GPT-4o) — на тот момент лидер. Именно на нём я сформировал полноценный курс по системному анализу для T1 Digital Academy: структура, материалы, задания, критерии оценки. Ни одна другая модель на тот момент не справилась с задачей такого масштаба.

GigaChat (Сбер) — честно попробовал на аналогичных задачах. На генерации кода и простых текстов работал приемлемо, но на сложных задачах — формирование курса, архитектурный анализ — результат был значительно слабее. Модель не держала контекст на длинных сессиях, теряла нить рассуждения. Это не приговор — отечественные модели активно развиваются, и к 2026-му ситуация уже другая. Но на момент доклада разрыв был существенным.

Gemini (Google, тогда ещё Bard → Gemini Pro) — сильный в аналитике и работе с данными, но в генерации enterprise-кода отставал от GPT-4. Хорошо работал для research-задач.

Grok (xAI) — интересный инструмент для быстрых ответов и brainstorming, но для серьёзной генерации кода и длинных сессий на тот момент не дотягивал.

Вывод простой: для enterprise-задач на 2024 год ChatGPT (GPT-4/4o) был основным рабочим инструментом. Корпоративные AI-ассистенты, доступные внутри контура, покрывали базовые кейсы, но для сложных задач приходилось использовать внешние модели на обезличенных данных. Ситуация быстро меняется — и это хорошо для всех.

Множитель, а не замена

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

30-60% ускорения — не маркетинговая цифра. Это диапазон из трекера задач за шесть месяцев. Нижняя граница — на задачах с тяжёлым доменным контекстом. Верхняя — на формализованной рутине. Средняя температура по больнице — около 40%.

Но вот что меня напрягает. Инструменты развиваются быстрее, чем команды учатся ими пользоваться. Качество промптов в моей команде до сих пор неравномерное. Кто-то выжимает из AI максимум, кто-то продолжает использовать его как автокомплит на стероидах. Разница в производительности между этими людьми растёт. И это новый вид неравенства, о котором пока мало кто думает.

Через год эти цифры будут другими. Порог входа упадёт, инструменты поумнеют, контекстные окна вырастут. Но принцип останется: AI ускоряет execution, а не thinking. И чем глубже ты понимаешь предметную область, тем больше из него выжмешь. А если не понимаешь — он тебя похоронит быстрее, чем ты заметишь.

Самое важное, что я понял за эти полгода: AI не уравнивает. Он усиливает разрыв. Сильный инженер становится ещё сильнее. Опытный аналитик закрывает задачи, которые раньше были не по силам одному человеку. А тот, кто не понимает, что генерирует — получает красивый код, который ломается в продакшене. И чинить его приходится тем самым сильным инженерам, которые и без того загружены.

---

По мотивам доклада на АиУП 2024 и личного опыта внедрения AI в enterprise-разработке.

Ваш ДПУПП