За последнее время заметил любопытный перекос: написать новый компонент становится всё проще, а согласованно изменить уже работающую систему — не всегда.

LLM быстро собирает адаптер, обработчик, API и тесты. Каждая задача по отдельности выглядит небольшой. Но стоимость решения определяется не количеством строк, а тем, как оно вписывается в существующую архитектуру.

Представим обычную задачу: в системе электронного документооборота нужно добавить дополнительную проверку перед отправкой документа.

На уровне кода — несколько условий и новый вызов API. А на уровне системы сразу появляются вопросы: кто отвечает за результат проверки, что делать при недоступности сервиса, как исключить повторную отправку, где хранится статус и кто его считает достоверным?

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

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

Я бы оценивал архитектурное качество такого решения не только тестами и успешной сборкой. Есть более показательные признаки: — сквозной сценарий можно проследить от события до результата; — у данных и бизнес-правил есть понятные владельцы; — сбои, повторы и тайм-ауты имеют определённое поведение; — новое требование не заставляет менять половину системы; — ключевые компромиссы зафиксированы в архитектурных решениях (ADR).

Особенно полезно проверять стоимость типового изменения. Берём одну бизнес-правку и составляем карту: какие сервисы, контракты, данные и команды она затронет. Если для одного поля нужны семь согласований и четыре релиза, проблема точно не в скорости написания Java.

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

В отчёте DORA за 2025 год есть созвучный вывод: ИИ усиливает существующие сильные стороны и проблемы процесса разработки. Быстрая генерация сама по себе не гарантирует устойчивой поставки изменений.

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

Источник: https://dora.dev/research/2025/dora-report/

#Архитектура #КорпоративнаяАрхитектура #ИИ #Автоматизация #АрхитектурноеРевью