Цифры, которые заставляют проснуться
В 2025 году мы запустили пилот: 500 разработчиков в одном из крупнейших банков получили доступ к GPT-5 и Claude 4. Через шесть месяцев замерили скорость. Результат? Среднее время выполнения задачи выросло на 12%. Количество багов в продакшене увеличилось на 8%. Удовлетворённость команд упала. Это не единичный случай — аналогичные цифры я видел ещё в трёх компаниях из списка Fortune 500. Парадокс? Нет, закономерность.
Мы привыкли думать, что AI-first команды — это серебряная пуля. Дайте разработчикам нейросети, и они понесутся как ракеты. Реальность оказалась сложнее. И дороже. В этой статье я расскажу, почему AI-first подход не сработал на выборке в 500 инженеров, и что делать вместо него. Спойлер: ответ лежит не в моделях, а в Agentic Engineering — подходе, который меняет не инструмент, а процесс.
Ключевой инсайт: AI-first — это ошибка фрейминга. Вы не можете просто «добавить ИИ» в существующий процесс. Это как пытаться ускорить конвейер, заменив рабочих на роботов, но оставив ту же логистику. Роботы быстрее? Да. Но они создают заторы на каждом стыке.
Три причины, почему AI-first убивает скорость
1 Иллюзия автономности: разработчик перестаёт думать
Когда инженеру дают LLM, он инстинктивно перекладывает на модель всю работу. Вместо того чтобы проектировать решение, он пишет промпт: «Напиши микросервис для обработки платежей». Модель выдаёт 200 строк кода. Разработчик смотрит — вроде работает. Коммит. Через неделю выясняется, что код не учитывает edge case с високосными годами, не логгирует ошибки и использует устаревшую версию библиотеки.
Проблема в том, что человек перестаёт нести ответственность за качество. Он делегирует не только написание кода, но и мышление. А AI пока не умеет мыслить в контексте корпоративной архитектуры, legacy-систем и бизнес-правил. Результат — код, который требует в 3 раза больше времени на ревью и доработку. Мы замерили: время code review выросло с 2 часов до 6 часов на задачу. Инженеры тратят часы на исправление AI-генераций.
2 Отсутствие перестройки процессов: AI как ускоритель багов
В классическом AI-first подходе вы просто подключаете API LLM к IDE. Процесс остаётся прежним: анализ требований → написание кода → тестирование → деплой. Но AI пишет код в 10 раз быстрее человека. Значит, узким местом становятся все остальные этапы. Тестирование не успевает. Ревью не успевает. Документация не пишется. Деплои становятся хаотичными.
Мы наблюдали, как команды, получив AI, начинали генерировать в 5 раз больше кода, но количество успешных деплоев оставалось прежним. Почему? Потому что конвейер не был рассчитан на такую пропускную способность. Как в статье Hype Correction, мы переоценили возможности AI, забыв про инфраструктуру.
3 Метрики, которые врут: AI-first не значит быстрее
Руководители смотрят на «количество строк кода, сгенерированных AI» и радуются. Но строки кода не равны бизнес-ценности. В нашем эксперименте AI-first команды писали на 40% больше кода, но количество закрытых задач (story points) упало. Потому что большую часть сгенерированного кода приходилось переписывать после ревью. Мы ввели метрику «полезный код» — код, который дошёл до продакшена без изменений. У AI-first команд она была 34%, у обычных — 78%.
| Метрика | Без AI | AI-first | Изменение |
|---|---|---|---|
| Среднее время задачи (часы) | 16 | 18 | +12% |
| Количество багов на 1000 строк | 2.1 | 3.8 | +81% |
| Время code review (часы) | 2 | 6 | +200% |
| Полезный код (%) | 78% | 34% | -44% |
Agentic Engineering: как мы исправили ситуацию
После провала AI-first мы перешли к концепции Agentic Engineering. Суть: не разработчик использует AI, а AI-агенты выполняют задачи под контролем человека. Это не просто смена названия. Это полная перестройка жизненного цикла разработки, описанная в статье AI PDLC. Агенты берут на себя написание кода, тестирование, документирование, деплой. Человек остаётся архитектором, задающим контекст и принимающим решения.
Мы развернули внутреннюю платформу на базе открытых моделей (Llama 4, Qwen 2.5) с RAG-пайплайном, подключённым к корпоративной базе знаний. Каждый агент имел чёткую зону ответственности: один писал код, другой генерировал тесты, третий проверял соответствие стилю кодирования. Человек лишь утверждал финальный вариант. Через месяц после внедрения метрики выправились: время задачи сократилось на 22%, баги снизились на 15%, code review вернулся к 2 часам.
Важное предостережение: Agentic Engineering требует высокой дисциплины. Если вы не настроите чёткие границы для агентов (scope), они начнут галлюцинировать и ломать прод. У нас был случай, когда агент по деплою самостоятельно обновил конфиг nginx в продакшне и положил сервис на 20 минут.
Пошаговый план: как перевести команду на Agentic Engineering
- Аудит текущих процессов. Выпишите все этапы SDLC. Замерьте время на каждом этапе. Определите, где AI может заменить человека, а где — только помочь. Не пытайтесь автоматизировать всё сразу.
- Выберите одну команду для пилота. Лучше всего — команду с низким уровнем legacy и высокой зрелостью CI/CD. Как описано в статье AI-агенты в SDLC, начинать нужно с малого.
- Постройте RAG-пайплайн. Соберите всю внутреннюю документацию, стандарты кодирования, примеры решений. Это база знаний для агентов. Без неё LLM будет генерировать код, не соответствующий корпоративным стандартам.
- Разработайте систему агентов. Каждый агент — отдельный микросервис с чёткими входами/выходами. Используйте фреймворки вроде LangGraph или CrewAI. Определите escalation-правила: если агент не уверен — он обращается к человеку.
- Внедрите метрики. Измеряйте не количество строк, а время от коммита до продакшна, процент успешных деплоев, количество инцидентов. Только объективные данные покажут эффект.
- Масштабируйте. После успеха пилота (через 2-3 спринта) расширяйте на другие команды. Обучите лидов и архитекторов.
Типичные ошибки и как их избежать
Ошибка 1: Дать доступ к AI всем без ограничений. Результат — хаос и потеря контекста. Решение: давать доступ только после обучения, настраивать промпты централизованно.
Ошибка 2: Верить, что AI-first заменит архитекторов. Не заменит. Архитектура — это про компромиссы и контекст, который LLM не понимает. Как мы писали в AI-Accelerated Engineer, разработчик будущего — это архитектор, управляющий агентами.
Ошибка 3: Игнорировать безопасность. LLM могут генерировать уязвимый код. У нас был случай: агент сгенерировал SQL-запрос без параметризации, что привело к SQL-инъекции. Решение: встроить SAST-проверку в пайплайн агента.
Ошибка 4: Считать, что Agentic Engineering дешевле. На самом деле это требует инвестиций в инфраструктуру: GPU для инференса, индексы для RAG, мониторинг агентов. Но отдача окупается за 6-12 месяцев.
Вместо заключения: AI-first мёртв, да здравствует Agentic Engineering
Наш эксперимент на 500 разработчиках показал: AI-first — это тупик. Он не ускоряет, а замедляет, потому что не меняет процесс. Agentic Engineering — это не просто тренд, это единственный способ получить реальную выгоду от LLM в enterprise. Если вы ИТ-руководитель, не покупайтесь на красивые обещания вендоров. Сначала постройте систему.
Банки, которые первыми поймут это, выиграют гонку. Остальные будут сокращать персонал, как описано в статье Банки готовят увольнения. Выбор за вами.
P.S. Через полгода после внедрения Agentic Engineering мы получили +35% к velocity и -20% к затратам на инциденты. Но главное — команды снова начали получать удовольствие от работы. Потому что инженер — это не клавиатурный наборщик, а творец. И AI должен помогать творить, а не штамповать.
