Запрос «скорость разработки с AI» звучит как обещание сжать квартал в неделю. Маркетинг IDE и облачных агентов усиливает ощущение, что bottleneck — только скорость набора кода. На практике bottleneck чаще в согласованиях, неясных требованиях, регрессии, онбординге и сопровождении.

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

Где AI реально ускоряет разработку

Каркас и типовые модули

CRUD, формы, REST/GraphQL-обёртки, DTO, маппинги, конфиги CI, Dockerfile, Helm-черновики — модели делают это быстро, потому что паттерн повторяется миллионы раз в обучающих данных. Выигрыш максимален, когда у команды уже есть стандарты: структура папок, линтер, шаблон модуля. AI заполняет форму, а не изобретает архитектуру с нуля.

Пример для команды из 5–8 человек: новый справочник в админке — раньше 2–3 дня (сущность, миграция, API, UI, тесты). С AI-черновиком и жёстким шаблоном — 1 день при том же уровне ревью. Экономия не в «магии», а в снятии копипаста.

Перевод, документация, коммуникация

README, OpenAPI-описания, release notes, черновик ТЗ для внутреннего заказчика, резюме обсуждения в тикете. Здесь модель сильна, потому что ошибка обычно видна человеку за минуты. Всё равно нужна вычитка терминов домена: модель может уверенно написать неверный глоссарий.

Тесты по спецификации

Генерация кейсов по acceptance criteria, property-based заготовки, таблицы граничных значений. Критично: модель не заменяет понимание инвариантов. Инженер формулирует «что должно быть всегда истинно», AI предлагает варианты нарушения. Без этого получаются тесты, которые проходят и ничего не гарантируют.

Разбор чужого кода и онбординг

Легаси без документации: «объясни поток данных от контроллера до БД», «где выставляется флаг X». Ускоряет вход нового разработчика на 30–50% по субъективным оценкам команд, если ответы верифицируются по коду, а не принимаются на веру.

Рефакторинг механический

Переименование с обновлением импортов, разбиение длинного метода, замена устаревшего API библиотеки по инструкции миграции. Риск — пропущенные динамические вызовы и рефлексия; обязателен прогон тестов и статический анализ.

Что остаётся медленным даже с AI

Сложные места — гонки, распределённые транзакции, согласованность кэша, промышленные протоколы (OPC UA, Modbus в нестандартных связках), криптография, расчёт лимитов в финтехе. Модели часто «угадывают красиво и неверно»: код компилируется, тесты на happy path зелёные, прод ломается под нагрузкой или на edge case.

Где скорость превращается в технический долг

Типичные провалы

• Сгенерированный код без тестов — скорость спринта, месяц раскопок в проде.
• Секреты в репозитории — модель «для примера» вставила ключ в конфиг; без pre-commit hook и сканера это улетает в git.
• Зависимости без аудита — предложен пакет с похожим именем или устаревшей уязвимостью.
• Копипаст уязвимых паттернов — SQL-конкатенация, eval, отключение проверки сертификатов «временно».
• Архитектурный дрейф — каждый разработчик с AI тянет свой стиль; через квартал монолит из несовместимых слоёв.
• Дублирование вместо переиспользования — агент не знает, что утилита уже есть в lib/, пишет третью копию.

Ускорение спринта ценой месяца инцидентов — плохая экономика. Практичное правило для зрелых команд: AI пишет черновик, человек принимает ответственность. Ревью, линтеры, CI, SAST, threat modeling для чувствительных зон не отменяются — они становятся ещё важнее, потому что объём диффа может вырасти.

Скрытая стоимость: ревью и когнитивная нагрузка

Если джун с AI выдаёт 400 строк в день, а сеньор тратит два часа на разбор каждого PR, суммарная скорость команды падает. Нужны лимиты на размер диффа, обязательный self-review чеклист от автора, и политика «одна задача — один осмысленный PR».

Смежная культура быстрого прототипирования через агентов — вайбкодинг. Для продуктов с ответственностью за данные и аптайм см. также материал про разработку с AI в продуктовом контуре.

Процесс команды: как встроить AI без хаоса

Роли и границы

Конвейер, который масштабируется

1. Короткое ТЗ или ticket с acceptance criteria (даже 5 пунктов).
2. AI-черновик в ветке, желательно из шаблона репозитория.
3. Self-check автора по чеклисту (см. ниже).
4. Автоматические ворота: lint, unit, integration на CI.
5. Ревью человеком с фокусом на инварианты, а не на стиль — стиль ловит линтер.
6. Документация изменений в PR description для будущего себя.

Без шага 1 модель галлюцинирует требования. Без шага 5 вы строите фабрику долга.

Чеклист self-review после AI

• Я прочитал каждый изменённый файл и понимаю diff.
• Нет секретов, внутренних URL, персональных данных в коммите.
• Новые зависимости обоснованы и проверены (лицензия, активность, CVE).
• Тесты проверяют поведение, а не «вызов мока».
• Ошибки обрабатываются явно, не проглатываются.
• Логи и метрики на критичном пути не хуже, чем до изменения.

Как считать эффект: метрики вместо хайпа

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

Метрики потока (Flow)

• Lead time — от «взяли в работу» до «в проде / у заказчика».
• Cycle time — от начала разработки до merge.
• PR throughput — сколько осмысленных PR в неделю на разработчика (не сырых AI-дампов).

Метрики качества

• Change fail rate — доля деплоев, приведших к откату или hotfix.
• Defect escape rate — баги, найденные после релиза.
• Time to restore — как быстро чините, если AI-дифф что-то сломал.

Метрики экономии (для себя)

Ведите простую таблицу спринта:

Если AI сократил набор текста, но удвоил ревью и дал hotfix — скорость не выросла, вы сместили фазу работы.

A/B на уровне команды

Одинаковые по сложности тикеты в двух кварталах: до и после внедрения политики AI (с обучением и чеклистами). Без обучения эффект часто отрицательный — люди доверяют автодополнению слишком рано.

Антипаттерны внедрения AI в разработку

KPI на «использование AI». Разработчики генерируют шум, чтобы закрыть метрику. Лучше KPI на lead time и change fail rate при неизменном качестве.

Запрет без альтернативы. Теневое использование личных аккаунтов и утечка кода. Лучше корпоративный инструмент, политика данных и обучение.

«Сеньоры не нужны, есть агент». Агент не несёт ответственности перед регулятором и клиентом.

Skip design для «мелочи». Мелочи с AI срастаются в неправильную архитектуру за месяц.

Отсутствие golden paths. Нет шаблонов репо, примеров «как мы пишем HTTP-клиент» — каждый AI-дифф уникален как снежинка.

Практические сценарии по зрелости команды

Стартап, 3 человека, MVP

AI оправдан для UI, админки, интеграций с известными API. Инвестируйте в один сквозной e2e-тест на критичный сценарий оплаты/регистрации. Скорость к демо инвестору — главная метрика, но не забывайте про секреты.

Продуктовая команда, 15–30 человек

Стандарты, ADR, design review на границах сервисов. AI — на уровне модулей внутри границ. Запрет на кросс-сервисные изменения агентом без архитектора.

Enterprise, легаси, compliance

AI для документации, тестов, изолированных микрофич за feature flag. Строгий контроль данных (не отправлять PII в публичные модели). Обязательный security review на аутентификацию, авторизацию, крипто.

Инструменты — вторичны, процесс — первичен

Одна и та же модель в Cursor, Copilot или CLI даёт разный результат в зависимости от:

• качества контекста (открытые файлы, @ на символы, AGENTS.md с правилами репо);
• размера задачи (до 200–400 строк diff за итерацию — разумный предел);
• дисциплины верификации.

Потратьте неделю на AGENTS.md / conventions в репозитории — это часто даёт больше, чем смена модели на более дорогую.

Распространённые возражения в команде и ответы на них

«AI заменит нас через год.» История автодополнения и Stack Overflow не убила профессию — сместила уровень абстракции. Ценность смещается к постановке задач, верификации, архитектуре и общению с доменом.

«Сеньору быстрее написать самому.» Часто правда — для задачи на 40 строк. Выигрыш AI на объёме 200+ строк бойлерплейта и на контексте, который сеньор уже забыл (редкий модуль). Пусть сеньор тратит время на ревью инвариантов, а не на копипаст DTO.

«Джуны перестанут учиться.» Риск реален, если дать только вайб без code review с объяснением «почему так нельзя». Парное ревью и обязательное «объясни diff своими словами» сохраняют обучение.

«Код станет однообразно посредственным.» Посредственность — следствие отсутствия стандартов, не инструмента. Шаблоны репозитория и ADR важнее запрета AI.

Недельный эксперимент для тимлида

Если вы только внедряете AI в процесс, не меняйте всё сразу:

1. Понедельник: выберите 3 тикета «средней» сложности, подходящих для AI (каркас, тесты, док).
2. Вторник–среда: одна пара разработчиков работает как обычно, вторая — с AI и чеклистом.
3. Четверг: сравните cycle time, размер ревью, количество замечаний на ревью.
4. Пятница: ретро: что вынести в AGENTS.md, что оставить ручным.

Один такой цикл даёт больше правды, чем месяц споров в чате.

Итог

AI ускоряет разработку там, где работа повторяемая, ошибка дешёвая, а верификация автоматизируема. Он замедляет там, где сложность скрытая, ответственность высокая, а ревью превращается в археологию чужого сгенерированного кода. Честный вопрос команды на планировании: мы сокращаем путь до ценности или только путь до первого коммита? Если второе — через квартал вы измерите это в hotfix'ах и выгорании ревьюеров. Если первое — AI становится нормальным инструментом в конвейере, как когда-то стали IDE и автодополнение: не магия, а инженерная дисциплина с новым слоем черновиков.