AI пишет код. Почему архитектура стала главным навыком?

Агент закрывает тикет быстро, а счёт за его решение приходит через месяц.

Ты попросил агента добавить лимит на сумму скидки. AI пишет код за десять минут: PR готов, тесты зелёные, ревьюер ставит approve. Через месяц лимит меняется, и выясняется, что агент заново посчитал скидку в корзине, в оформлении заказа и в счёте. Правка в одну строку превращается в день поиска копий.

Если машина пишет код быстрее тебя, в чём теперь твоя работа? Мой ответ: в решениях о том, куда и как встраивается этот код. Ниже данные, на которых держится этот ответ, и способ делить работу с агентом без роста технического долга.

Написание кода перестаёт быть главным ограничением. Чем проще получить код, тем дороже обходится непонимание того, как он встраивается в систему.

В опросе 484 разработчиков Microsoft на написание кода уходит около 11% рабочей недели. Даже если AI ускорит его вдвое, освободится примерно 5,5% недели. На проектирование систем разработчики тратят около 6% времени, хотя хотели бы около 15%.

Copilot и METR мерили скорость в разных условиях:

Быстрее стало там, где код не во что встраивать, а медленнее в большой системе. Участники METR при этом считали, что ускорились на ~20%. Сам METR называет эти результаты устаревшими, но один вывод я из них сохраняю: ощущению скорости верить нельзя.

AI видит промпт и тот код, который успел прочитать, а архитектура часто лежит за этими пределами: функция в соседнем модуле, граница, которую нельзя пересекать. По версии GitClear (в пересказе DevClass), ассистенту проще вставить новый блок, чем предложить существующую функцию.

GitClear в отчёте 2026 года разобрал 623 млн изменений:

Новый код всё реже опирается на существующий. Отчёт при этом вендорский, методика не раскрыта, и он показывает корреляцию, а не причину. Авторы и сами не винят модель: по их словам, процесс с AI нацелен на атомарный результат (зелёный тест, закрытый тикет), а переиспользование остаётся без внимания.

По оценке DORA 2024, рост внедрения AI на 25% связан с падением стабильности поставки на 7,2%. Авторы отчёта считают, что без маленьких батчей и надёжного тестирования AI поставку не улучшит.

Цена архитектурной ошибки при этом не снизилась: каждую копию правила придётся искать при следующей правке. Наш пример со скидкой на условной схеме:

Справа у правила скидки один владелец, и остальные модули обращаются к нему через интерфейс.

Ценность смещается туда, где AI слаб: в решения о частях системы и их связях.

PR из начала статьи сломался на втором вопросе: никто не решил, какой модуль владеет скидкой.

Этим навыкам давно учат: DDD учит делить систему на ограниченные контексты по смыслу бизнеса, а system design учит взвешивать нагрузку, отказы и цену вариантов.

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

Если упал тест, достаточно перегенерировать код. Если нарушена граница, возвращайся к архитектуре: новый промпт здесь только перенесёт долг в следующий PR.

Для задачи с лимитом скидки ограничения выглядят так:

Тест на контракт пиши сам: если AI пишет и код, и тесты, проверка замыкается на тех же допущениях. Этот риск разобран в обзоре исследований 2026 года.

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

Одноразовый скрипт не нужно проектировать как платёжный модуль.

Чем шире изменение и дороже ошибка, тем больше решений принимаешь до генерации. Таблица адаптирует ориентир из того же обзора.

Число строк в PR почти ничего не говорит о твоей работе: агент пишет их так же быстро. Ценится, сколько изменений система выдерживает без переписывания и сколько копий логики появилось за квартал. AI умеет писать код, а ты должен понимать, какой код нужен, как он впишется в систему и почему решение оправданно.

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