Вступление

В какой-то момент это происходит почти в каждой компании. Собрание. Слайды. Уверенный голос.

«Мы должны активнее использовать AI».
«Он ускорит разработку в несколько раз».
«Нам нужно повышать эффективность».
«Возможно, нам и не понадобится столько людей».

Формулировки могут быть мягкими. Могут быть вдохновляющими. Могут быть завёрнутыми в стратегию трансформации. Суть остаётся той же: технология должна кратно увеличить производительность.

И в этот момент создаётся ощущение, что инженерная работа воспринимается как процесс набора текста. Если код пишется медленно — значит, проблема в скорости. Если ускорить написание кода — ускорится и разработка.

Логика понятная. Почти математическая. Но в ней есть одно допущение: что разработка — это печать.

Иногда это напоминает маркетинговый баннер:

«Строитель кладёт один кирпич за 10 секунд. Добавим AI — и он будет класть за одну секунду».

Человеку, который никогда не строил дом, идея кажется блестящей. В десять раз быстрее — значит, в десять раз эффективнее. Проблема только в том, что скорость укладки кирпича — не то же самое, что прочность здания.

И здесь начинается самое интересное.

Как это выглядит сверху

Если честно, с позиции топ-менеджмента всё выглядит довольно рационально. Есть команда. Есть бюджет. Есть сроки. Есть давление со стороны рынка, инвесторов, board.

И вот появляется инструмент, который:

• ускоряет написание кода

• генерирует тесты

• пишет документацию

• помогает с рефакторингом

Возникает логичный вопрос:

Если один разработчик с AI делает больше, зачем нам столько разработчиков?

В управленческой логике это почти формула. Было 100 условных «единиц кода» в месяц. С AI стало 300. Значит, либо мы делаем в три раза больше, либо нам нужно меньше людей.

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

• Если смотреть на разработку из презентации, она выглядит линейно: задача → код → релиз.

• Если смотреть изнутри, она выглядит иначе: контекст → ограничения → легаси → риски → коммуникация → архитектура → компромиссы → и только потом код.

Но эти слои не видны в отчётах. Зато прекрасно видна цифра:

«70% кода написано с использованием AI».

Это звучит современно. Это легко положить на слайд. Это красиво выглядит в стратегии цифровой трансформации.

А вот формулировка:

«Мы два квартала выпиливали легаси и разносили монолит на сервисы»

— звучит не так эффектно.

С точки зрения презентации AI — идеальный KPI. С точки зрения инженерии — это просто инструмент.

Есть ещё один фактор, о котором редко говорят вслух. В большинстве корпоративных структур верхние уровни — это управленческие позиции. Даже если кто-то когда-то писал код, связь с реальной инженерной практикой со временем размывается.

Это естественно. Роль меняется. Но вместе с этим меняется и фокус: от «как устроена система» к «как управлять показателями». И в этой оптике AI выглядит как рычаг эффективности. Почти магический. Только магии в нём нет.

Скорость генерации кода ≠ скорость разработки

Здесь происходит самая незаметная подмена. AI действительно ускоряет написание кода. Иногда существенно. Можно быстрее набросать CRUD. Быстрее написать тест. Быстрее сделать прототип. Быстрее оформить документацию.

Но написание кода — это не разработка. Это лишь один из её этапов. И далеко не самый дорогой.

Разработка — это не «печатание». Это принятие решений.

И вот что обычно не попадает в красивые отчёты:

• анализ требований

• аналитика

• уточнение контекста

• поиск противоречий

• оценка рисков

• продумывание архитектуры

• компромиссы между скоростью и качеством

• последствия изменений

• баги и доработки

AI может предложить вариант реализации. Он не несёт ответственности за то, что будет через полгода. Можно написать код в 3 раза быстрее. А потом в 5 раз чаще его переписывать.

Можно ускорить генерацию фич. И одновременно ускорить накопление технического долга.

Это как если бы на стройке ускорили подачу кирпича, но не изменили расчёт нагрузок. Здание растёт быстрее. Только фундамент остаётся тем же.

И вот здесь возникает ключевая иллюзия:

если код появляется быстрее, значит, продукт развивается быстрее.

Нет.

Продукт развивается быстрее тогда, когда:

• архитектура позволяет менять систему без боли

• команда понимает домен

• ошибки не размножаются экспоненциально

• решения не приходится откатывать

AI ускоряет создание вариантов. Он не ускоряет принятие правильных решений. Он не чувствует, что вот этот «быстрый» костыль через год станет системной проблемой. Он не понимает, что этот seemingly harmless рефакторинг ломает неявный контракт между сервисами. Он не видит скрытых зависимостей, которые живут только в голове у команды.

И самое ироничное — иногда скорость генерации кода даже снижает реальную скорость разработки.

Потому что:

• больше кода — больше пространства для багов

• больше автогенерации — больше шаблонных решений вне контекста

• больше скорости — меньше времени на осмысление

AI отлично ускоряет руки. Но разработка определяется головой. И если компания начинает измерять эффективность в «строках, написанных с помощью AI», она начинает оптимизировать не то. Можно сделать 70% кода с AI. И при этом не ускорить вывод фич ни на день. Вот в этом и разница между генерацией и разработкой.

Где AI действительно полезен

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

Лучше всего AI проявляет себя там, где нужно быстро «поднять черновик»: накидать CRUD, набросать типовую обвязку, сгенерировать DTO / маппинг, собрать прототип, быстро оформить тест-кейсы по уже понятной логике. Он особенно хорош, когда вы уже знаете, что делаете, и вам нужно быстрее дойти до рабочего результата, не увязая в рутине.

По ощущениям это не «искусственный интеллект», а очень умный автокомплит, ускоренный StackOverflow и помощник по синтаксису в одном флаконе. Он экономит время на механике: где какая сигнатура, как называется аргумент, как быстрее развернуть паттерн, как привести код к более читабельному виду.

Но важный момент: AI становится усилителем только в зрелой среде. Там, где уже есть принципы, ревью, ответственность и понимание домена. В такой команде он ускоряет реализацию решений, которые люди уже приняли головой. И это нормальная, честная польза.

Проблемы начинаются ровно в тот момент, когда AI пытаются назначить архитектором. Он может сгенерировать три варианта авторизации, пять вариантов ретраев и семь вариантов «как сделать по best practices». Но он не знает, какой именно вариант выдержит вашу реальность: ваши ограничения по безопасности, ваши исторические компромиссы, ваши неявные контракты между сервисами и те правила, за нарушение которых прилетает не в комментариях к PR, а в проде.

AI видит код. Но он не видит организацию. Не видит контекст. Не чувствует стоимость ошибки.

Поэтому рабочая модель — не «AI вместо инженера», а «AI рядом с инженером». Это не автопилот. Это турбина. К нормальному двигателю она даёт прирост мощности. К разваливающемуся — эффектный взрыв, который на графике выглядит как “ускорились”, а по факту это просто дым.

Заключение

Идея «везде внедрим AI и станем в пять раз быстрее» звучит красиво. На слайде — идеально. В стратегии — современно. В отчёте — впечатляюще. Проблема в том, что реальность сложнее презентации.

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

Если в системе порядок — он ускорит порядок. Если в системе хаос — он ускорит хаос.

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

Через какое-то время исчезнут лозунги про «в пять раз быстрее» и «нам нужно меньше людей». Останется трезвое понимание: AI — это инструмент. Сильный, удобный, местами впечатляющий. Но инструмент.

Разработка по-прежнему будет требовать мышления. QA по-прежнему будет требовать анализа рисков. Архитектура по-прежнему будет требовать решений, за которые кто-то отвечает. И это, пожалуй, хорошая новость. Потому что технологии меняются. А инженерная ответственность — нет.