Искусственный интеллект улучшает отдельные участки системы и одновременно делает сам продукт сложнее для будущих изменений. Это уже видно по реальным проектам.
В июньском исследовании ECIS 2026 о техническом долге авторы проанализировали 1091 открытый Python-проект. После внедрения генеративного ИИ малые и средние проекты начали быстрее накапливать кодовый долг. У крупных картина оказалась сложнее: архитектурный долг снижался — и одновременно рос долг на уровне проектных решений.
На первый взгляд появляется противоречие. Если отдельные изменения вносятся легко и аккуратно, откуда берется проблема на уровне всей системы? Рассмотрим почему каждая следующая заплатка может быть вполне рациональной — и почему именно это превращается в новый архитектурный риск.
Каждая заплатка становится слишком хорошей сделкой
Представьте, что в продукт надо добавить новый сценарий. Можно пойти привычным путем: пересмотреть устройство модуля, разобрать накопленные зависимости и убрать старые ограничения. А можно добавить еще одно условие — и закрыть задачу прямо сегодня.
Второй вариант всегда существовал, но раньше его стоимость была ощутимее, ведь разработчику все равно приходилось писать новую логику и встраивать ее в систему. Агентный ИИ сделал локальный путь гораздо привлекательнее: нужно дополнительное исключение — без проблем. Еще один обработчик — хорошо.
Отчет GitClear The Maintainability Gap (2026) фиксирует это в цифрах: доля рефакторинга в коммитах упала с 21% в 2022 году до 3,8% в
Каждое решение по отдельности выглядит совершенно нормально. И вот тут возникает парадокс, потому что в совокупности они могут дать системно нерациональный результат. Это похоже на дом, где мебель переставить дешевле, чем менять планировку — и так можно жить годами. Но, когда понадобится перенести несущую стену, обнаружится проблема.
Проблема не обязательно в плохом коде
Важно не сводить все к формуле «просто ИИ генерирует плохой код». Свежие исследования показывают иную картину — более неоднозначную.
В опубликованном в июне 2026 года эксперименте Empirical Software Engineering участвовал 151 человек, 95% из них — профессиональные разработчики. Исследователи не обнаружили систематического ухудшения сопровождаемости кода, созданного с помощью ИИ: другие разработчики впоследствии меняли его примерно с теми же затратами времени и без значимой разницы в качестве.
Это дает понять, что риск появляется не внутри отдельного файла или даже отдельного изменения — проблема возникает между изменениями.
Десять качественных локальных решений могут создать систему, в которой одна и та же бизнес-логика постепенно распределилась по нескольким компонентам, исключения начали зависеть друг от друга, а первоначальные границы модулей потеряли смысл. То есть каждая деталь исправна — но конструкция в целом становится хрупкой.
Архитектура перестала напоминать о себе каждый день
Архитектурные правила всегда давали разработчикам практическую выгоду: повторно использовать компонент было дешевле, читать чужой код благодаря понятной структуре — проще. Не накапливался бесконтрольно технический долг.
Искусственный интеллект ослабляет эту мотивацию. Если агенту недорого создать еще один похожий блок, дублирование не так мешает. А если модель быстро разбирает запутанный фрагмент, плохая читабельность — уже не проблема. То есть технология не отменяет архитектуру вообще, но зато полностью убирает часть ситуаций, которые заставляли разработчиков о ней помнить.
Есть и еще одна сложность. Каждая агентная задача получает локальный контекст: файлы, историю изменений. Этого хватает для конкретной задачи, но сумма контекстов не превращается автоматически в целостную картину системы.
Через десятки итераций решения связаны исторически — и эта история нигде не существует в полном виде. Если изменения происходят быстрее, чем команда успевает их разбирать, человек постепенно теряет контроль.
Ловушка замедленного действия
Этот долг может долго не мешать, ведь еще один фильтр добавить легко, новый статус — тоже. Отдельную интеграцию можно быстро подстроить.
Проблема появляется, когда бизнес хочет изменить процесс целиком, например объединить два продукта, перестроить клиентский путь, поменять модель тарификации или выйти в новый сегмент. В такие моменты обычно выясняется, что для этого нужно одновременно изменить десятки локальных решений, созданных независимо друг от друга.
Получается система, которую дешево менять понемногу, но по-настоящему — уже дорого. Поэтому скорость выпуска функций сама по себе уже мало что говорит о способности продукта развиваться.
Architecture.md ничего не запрещает
Отказываться от агентной разработки из-за этого, конечно, не стоит — но архитектурные правила придется переносить из документов в реальные ограничения внутри процесса.
Если правило записано только в architecture.md, помощник может его не увидеть, получить неполный контекст или выбрать решение, которое локально работает, но нарушает общую архитектуру. Поэтому нужны автоматические проверки.
Контур непрерывной интеграции может отслеживать границы модулей, запрещенные зависимости, циклические связи и доступ к данным. Тесты и другие механизмы контроля помогают убедиться, что изменение соответствует ожидаемому поведению еще до попадания в основную ветку.
В итоге архитектура перестает быть просто инструкцией «делайте так». Она становится набором ограничений, которые не дают провести изменение, если оно нарушает правила.
Главная метрика — цена следующего изменения
Если команда измеряет только количество закрытых задач и скорость разработки, локальная оптимизация почти всегда выглядит выигрышно. Но исследование DORA о применении искусственного интеллекта указывает на двойственность: более активное использование ИИ одновременно связано с ростом пропускной способности и увеличением нестабильности поставки. Авторы советуют не циклиться на объеме произведенного кода и смотреть на результат и состояние процесса.
Для архитектуры полезен похожий сдвиг. Недостаточно измерять время текущей задачи — важен радиус ее последствий: сколько затронуто компонентов и возникло новых зависимостей, появились ли специальные исключения, усложнилась ли следующая доработка.
Нельзя, чтобы каждая новая функция требовала вмешательства во все большую часть системы. Это означает, что продукт уже платит проценты по архитектурному долгу, даже если задачи и закрываются быстро.
Что корректировать в процессе
В агентной разработке человеку все меньше нужно контролировать каждое движение вручную. Гораздо важнее становится среда, в которой принимаются решения. Задача — заранее сделать часть плохих решений технически невозможными.
Минимальный набор выглядит так:
- Архитектурные правила проверяются автоматически. Если между модулями запрещена определенная зависимость или доступ к данным должен идти только через подтвержденный интерфейс, это лучше фиксировать не только в документах, но и в проверках контура непрерывной интеграции.
- Тесты контролируют и функцию, и взаимодействие компонентов. Быстрая локальная доработка не должна менять поведение соседних частей системы или ломать критичные сценарии.
- Новые зависимости и исключения становятся наблюдаемыми. Команда должна видеть, где появляется очередной обходной путь или связь между компонентами, которой прежде не было.
- Команда отслеживает, как растет область изменений. Если для каждой новой бизнес-функции приходится затрагивать все больше модулей, это сигнал, что архитектурный долг уже начинает влиять на стоимость развития продукта.
- Локальная заплатка периодически сравнивается с ценой системного решения. В какой-то момент еще одно быстрое исправление становится дороже, чем устранение самой причины. Важно уметь заметить это до того, как крупная перемена потребует переделки половины системы.
Так роль архитектора тоже меняется. Помимо схемы системы он проектирует коридор допустимых решений — набор ограничений и проверок, внутри которого люди и агенты могут работать быстро и не разрушать способность продукта меняться дальше.
Подведем итоги
Плохой фрагмент кода, сгенерированного ИИ, легко найти — гораздо сложнее заметить систему, в которой сотни локальных рабочих решений вдруг перестали складываться в единое целое. Это происходит, потому что искусственный интеллект сделал заплатку слишком выгодной и системное решение каждый раз откладывается на потом.
Архитектура в такой среде нужна даже больше, чем раньше. Теперь ее задача — автоматически удерживать быстрые изменения внутри границ, за которыми сегодняшняя экономия превращается в завтрашнюю неспособность продукта меняться.
