ИИ не уберёт overengineering. Он его ускорит

Overengineering это когда вы решаете простую задачу сложным способом: лендинг на микросервисах, Kubernetes для десяти пользователей, архитектура под миллион запросов при небольшом трафике. Вы платите деньгами и временем за решение, которое несоизмеримо сложнее самой задачи.

Так устроены стимулы. Сложное решение читается как профессиональное, простое как недоработанное. Никого не увольняли за то, что он взял Kubernetes. Увольняли за то, что не подумал о масштабировании. При такой асимметрии рационально перестраховываться, и разработчики перестраховываются.

ИИ учился на открытом коде и статьях, а там преобладают решения крупных компаний: они пишут блоги, выкладывают фреймворки, задают моду. Задачи у них другие: миллионы пользователей, сотни разработчиков, требования регуляторов.

На запрос «напиши аутентификацию» модель выдаёт то, что чаще всего встречала: слоёную структуру с абстракциями, интерфейсами и обработкой сценариев, которых у вас не будет. Это корректный ответ на усреднённый запрос из интернета. Ваш проект в это среднее не попадает.

Раньше за усложнение платили временем. Написать пять слоёв абстракции это неделя работы. Где-то на третий день человек начинал сомневаться, так ли они нужны. Цена работала как тормоз.

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

Единственный естественный тормоз overengineering'а исчез. Дело не в качестве генерации: код может быть отличным. Дело в том, что он стал слишком дешёвым.

Использовать ИИ как редактора

Распространённый сценарий выглядит иначе: разработчик просит сгенерировать модуль с нуля, получает 500 строк и вставляет их в проект. Выяснять, что здесь лишнее, никто не станет, код работает. Так overengineering и попадает в проект за одну генерацию.

Обратный порядок даёт другой результат:

1. Сначала пишете сами. Тридцать строк, простой JWT, одна функция проверки. Зато вы понимаете каждую строку.
2. Потом отдаёте ИИ на упрощение. «Вот код. Убери всё, без чего он продолжит работать. Покажи, что можно выбросить.»
3. Разбираете предложения. Часть будет мимо, но в этом режиме модель работает лучше: находить лишнее ей удаётся точнее, чем придумывать нужное.

При редактировании есть точка отсчёта это ваш код и ваше понимание задачи. При генерации точки отсчёта нет, и модель подставляет усреднённую.

Ещё два приёма:

• Ограничения в промпте. Если генерируете с нуля, задайте рамку явно: «Самое простое решение, которое работает. Без фреймворков, без слоёв абстракции. SQLite, один файл.»
• Контекст проекта. Фраза «у меня 100 пользователей и сервер за десять долларов» меняет ответ сильнее, чем любые уточнения формулировки.

Компании, которые внедрили ИИ-агентов глубже всех, вокруг генерации выстроили целый слой ограничений.

Stripe, по публичным описаниям, пропускает через ИИ больше тысячи pull requests в неделю. Задачи для агентов формулируются узко: не «сделай фичу», а строго ограниченное изменение. Инструменты, доступные агенту, отобраны вручную. Каждый результат проходит проверку. Компания сознательно пожертвовала масштабом задачи ради предсказуемости результата.

У Google, Shopify и Airbnb архитектуры отличаются, единого стандарта в индустрии нет, каждый строит под свои риски. Общее в том, что агентов встраивают в существующие процессы (GitHub, Slack, Linear) и обкладывают проверками.

Никто из них не берёт результат генерации «как есть». Ценность появляется от рамок вокруг генерации.

ИИ усиливает то, что уже есть в голове у разработчика. Склонность усложнять он реализует за секунды, привычку резать лишнее, тоже.

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