18 сентября 2026
9
Эволюционная архитектура — это подход к проектированию систем, где изменения безопасны и быстры, а контекст сохраняется через ADR, границы модулей и метрики.
Почему это важно в 2026? Сегодня код пишется мгновенно, но контекст теряется безвозвратно. Архитектура стала языком, на котором бизнес разговаривает с ИИ. Разбираем, что изменилось и почему роль архитектора стала ключевой.
Такая архитектура учитывает будущие изменения и позволяет контролировать их влияние на систему. Agile отвечает за организацию работы команды и выпуск изменений, а эволюционная архитектура — за то, как развивать систему, сохраняя её ключевые свойства и управляемость.
Но возникла новая проблема. ИИ не помнит, что было вчера. Не знает, почему выбрали PostgreSQL, а не MongoDB. Не понимает, что заказчик имел в виду под «гибкой скидкой». Если не задать жёсткие рамки — он создаёт рабочий, но не вписывающийся в систему код. Поддерживать такое невозможно.
Аналитика GitClear подтверждает: за 2020–2024 годы доля рефакторинга упала с 24% до 9,5%, а доля скопированного и вставленного кода выросла с 8,3% до 12,3%. В 2024 году копирование впервые за время наблюдений превысило перемещение кода — то есть команды стали реже структурировать код и чаще его дублировать. Это не означает, что ИИ генерирует некачественный код. Проблема в том, что ИИ позволяет наращивать объём кода без улучшения окружающей структуры. Через несколько месяцев в системе обнаруживается несколько версий одной и той же бизнес-логики. Объём кода растёт, сложность сопровождения увеличивается, тестов становится больше, а изменения приходится вносить в нескольких файлах вместо одного.
Agile-манифест, опубликованный в 2001 году, утверждает: «Работающее ПО важнее исчерпывающей документации». Это не означает, что документация не нужна: манифест сохраняет её ценность, но не считает самоцелью. На практике команды часто ограничивались минимальной фиксацией решений и полагались на знания опытных участников проекта. Пока эти люди оставались в команде, такой подход мог работать. С распространением ИИ-ассистентов, которым нужен доступ к контексту проекта, необходимость в актуальной документации стала очевиднее.
Нейросеть не может обратиться к коллеге и уточнить, почему система устроена именно так. Ей нужен явно зафиксированный контекст: описание системы, архитектурные решения и ограничения предметной области. В этом смысле короткие ADR становятся не формальностью, а практичным источником контекста для ИИ-ассистентов.
DORA (DevOps Research and Assessment), исследовательская программа Google Cloud, в отчёте за 2025 год описывает ИИ как усилитель: он может масштабировать как сильные стороны организации, так и её проблемы. Практический вывод для архитектора таков: документация становится не только средством передачи знаний между людьми, но и источником контекста для ИИ. Без неё ассистенту сложнее учитывать принятые решения, ограничения и цели системы.
Отдельно следует рассмотреть работу с батчами. Батч — это пакет изменений, который команда выкатывает за один раз. DORA на протяжении нескольких нет показывает: чем меньше батч, тем здоровее система. DORA 2025 включает «работу мелкими батчами» в число семи способностей, которые усиливают положительный эффект ИИ. Там же выдвигается гипотеза: ИИ позволяет генерировать больше кода в одном изменении, а большие наборы изменений труднее ревьюить — отсюда связь ИИ с ростом нестабильности доставки. В DORA 2024 фиксировалось снижение пропускной способности на 1,5% и стабильности на 7,2% на каждые 25% роста внедрения ИИ. В DORA 2025 пропускная способность демонстрирует рост, однако нестабильность сохраняется. Причина, по мнению авторов, не в качестве генерируемого кода, а в объёме изменений, выпускаемых за один раз.
Такой инструмент называют fitness functions — это автоматические проверки, которые оценивают заранее заданные архитектурные свойства и помогают выявлять отклонения от установленных правил.
Данные DORA за 2025 год показывают, что ИИ не отменяет необходимость контроля качества: он скорее усиливает уже существующие сильные и слабые стороны организации. Поэтому сгенерированный код разумно рассматривать как черновик, который нужно проверять и при необходимости дорабатывать.
Результаты опроса Stack Overflow подтверждают эту проблему: 66% разработчиков назвали наиболее частой трудностью работу с решениями ИИ, которые «почти правильные, но не совсем», что приводит к дополнительной отладке. Поэтому задача архитектора — задавать архитектурные ограничения, контракты и метрики, которые можно проверять автоматически.
DORA 2025 формулирует это так: «ИИ — это усилитель». Сильные команды становятся сильнее, слабые — слабее. 90% респондентов используют ИИ в работе, более 80% отмечают рост личной продуктивности, при этом 30% не доверяют ИИ-коду. Архитектор — это тот, кто делает команду сильной: задаёт контекст, рамки и метрики.
Stack Overflow 2025 дополняет картину: 46% разработчиков активно не доверяют точности ИИ, а 76% не планируют использовать ИИ для деплоя и мониторинга в ближайшие 3–5 лет. То есть архитектурное мышление остаётся человеческой задачей.
Три навыка, которые стали критичными:
Формулировать требования так, чтобы их понял и человек, и нейросеть
Лёгкое документирование решений (ADR, C4) как «память проекта»
Построение архитектурного надзора через метрики, а не через код-ревью
Где и как вы фиксируете архитектурные решения? Используете ли ADR или другой удобный формат?
Как ИИ-ассистент получает контекст проекта — описание системы, ограничения предметной области и принятые решения?
Как вы контролируете качество изменений, если объём кода уже невозможно полностью проверять вручную?
На каких принципах вы определяете границы сервисов — на требованиях предметной области, независимости изменений и требованиях к надёжности или только на распространённых шаблонах?
Есть ли у вас метрики и автоматические проверки, которые показывают, сохраняет ли система нужные архитектурные свойства?
Два или более отрицательных ответа — сигнал, что команде может потребоваться обучение практикам эволюционной архитектуры. Его цель — научиться фиксировать решения, управлять контекстом проекта и автоматически проверять архитектурные свойства системы.
Мы обновили интенсив-практикум «Эволюционная архитектура: проектирование в условиях неопределённости и развития ИИ» — программа полностью отражает реалии 2026 года.
ИИ-контекст как часть проекта. Отдельные блоки про то, как работать с нейросетями: задавать рамки, сохранять контекст, контролировать качество.
Обновлённая практика. Event Storming, ADR, C4, black-box метрики, топология команд — всё на реальных кейсах.
Фокус на Time-to-Market. Как находить баланс между качеством архитектуры и скоростью релиза.
Работа с техдолгом. Как выявлять архитектурные риски и составлять план работы с техдолгом
18 академических часов: 61% теории, 39% практики.
9 модулей: от архитектурного анализа до организационных аспектов.
Практика: Event Storming, ADR, C4, black-box метрики, топология команд.
Удостоверение о прохождении.
Программа построена так, чтобы дать не только теорию, но и практику: 39% обучения — работа над реальными кейсами. Слушатели разрабатывают ADR, подбирают black-box метрики для контроля архитектуры без ручного чтения кода, разбирают критерии выбора между монолитом и микросервисами, определяют границы системы через Event Storming и DDD и осваивают практику предотвращения переусложнения.
Архитекторам, которые хотят системно работать с ИИ-контекстом.
Тимлидам и техлидам, отвечающим за качество и скорость доставки.
Senior-разработчикам, переходящим в архитектурную роль.
Руководителям разработки, которым нужно управлять техдолгом.
Это подход, при котором система спроектирована так, чтобы её можно было быстро и безопасно менять, а знания о ней сохраняются в ADR, границах модулей и метриках.
Чем эволюционная архитектура отличается от Agile?
Agile отвечает на вопрос «как быстро выпускать изменения». Эволюционная архитектура добавляет к этому фиксацию решений, управление границами и надзор через метрики, чтобы изменения не накапливали техдолг.
Зачем архитектору ADR в 2026 году?
ADR — это память архитектурных решений для команды проекта и ИИ-ассистентов. Нейросеть не может спросить у коллеги, поэтому ей нужен читаемый контекст: что решили, почему, какие альтернативы отклонили.
Модульный монолит или микросервисы — что выбрать?
Размер сервиса определяется не модой, а Time-to-Market и стоимостью координации. В 2026 году модульный монолит часто выигрывает, потому что даёт ИИ общую картину системы.
Как контролировать качество, если код-ревью не тянет объёмы?
Через black-box тесты, fitness functions и метрики наблюдаемости. Архитектор проверяет не «как написана функция», а «что система выдаёт на входе и выходе».
Кому подходит интенсив-практикум «Эволюционная архитектура» в Учебном центре IBS?
Архитекторам, тимлидам, senior-разработчикам и руководителям разработки, которые хотят системно работать с ИИ-контекстом, управлять техдолгом и строить архитектурный надзор.
Что такое эволюционная архитектура?
Эволюционная архитектура — это подход к проектированию и развитию систем, который помогает безопасно вносить постепенные изменения и сохранять важные архитектурные свойства. Для этого используют архитектурные решения (ADR), границы модулей, метрики и автоматические проверки.Такая архитектура учитывает будущие изменения и позволяет контролировать их влияние на систему. Agile отвечает за организацию работы команды и выпуск изменений, а эволюционная архитектура — за то, как развивать систему, сохраняя её ключевые свойства и управляемость.
Почему в 2026 код подешевел, а контекст подорожал
Двадцать лет в ИТ боролись за скорость разработки: Agile, CI/CD, микросервисы. Все эти практики решали одну задачу — быстрее выпускать новые версии и реагировать на запросы бизнеса. Сегодня эту задачу решают LLM. Cursor, Copilot и аналогичные инструменты генерируют рабочий код за секунды. По данным Stack Overflow 2025, 84% разработчиков используют или планируют использовать ИИ-инструменты (годом ранее — 76%), 46% применяют их ежедневно.Но возникла новая проблема. ИИ не помнит, что было вчера. Не знает, почему выбрали PostgreSQL, а не MongoDB. Не понимает, что заказчик имел в виду под «гибкой скидкой». Если не задать жёсткие рамки — он создаёт рабочий, но не вписывающийся в систему код. Поддерживать такое невозможно.
Аналитика GitClear подтверждает: за 2020–2024 годы доля рефакторинга упала с 24% до 9,5%, а доля скопированного и вставленного кода выросла с 8,3% до 12,3%. В 2024 году копирование впервые за время наблюдений превысило перемещение кода — то есть команды стали реже структурировать код и чаще его дублировать. Это не означает, что ИИ генерирует некачественный код. Проблема в том, что ИИ позволяет наращивать объём кода без улучшения окружающей структуры. Через несколько месяцев в системе обнаруживается несколько версий одной и той же бизнес-логики. Объём кода растёт, сложность сопровождения увеличивается, тестов становится больше, а изменения приходится вносить в нескольких файлах вместо одного.
Зачем архитектору ADR в 2026 году?
ADR (Architecture Decision Records) — это память архитектурных решений для команды и ИИ-ассистентов. Формат: одно решение — одна запись, содержащая суть решения, обоснование, отклонённые альтернативы и принятые последствия.Agile-манифест, опубликованный в 2001 году, утверждает: «Работающее ПО важнее исчерпывающей документации». Это не означает, что документация не нужна: манифест сохраняет её ценность, но не считает самоцелью. На практике команды часто ограничивались минимальной фиксацией решений и полагались на знания опытных участников проекта. Пока эти люди оставались в команде, такой подход мог работать. С распространением ИИ-ассистентов, которым нужен доступ к контексту проекта, необходимость в актуальной документации стала очевиднее.
Нейросеть не может обратиться к коллеге и уточнить, почему система устроена именно так. Ей нужен явно зафиксированный контекст: описание системы, архитектурные решения и ограничения предметной области. В этом смысле короткие ADR становятся не формальностью, а практичным источником контекста для ИИ-ассистентов.
DORA (DevOps Research and Assessment), исследовательская программа Google Cloud, в отчёте за 2025 год описывает ИИ как усилитель: он может масштабировать как сильные стороны организации, так и её проблемы. Практический вывод для архитектора таков: документация становится не только средством передачи знаний между людьми, но и источником контекста для ИИ. Без неё ассистенту сложнее учитывать принятые решения, ограничения и цели системы.
Микросервисы или модульный монолит: что выбрать
Ещё пять лет назад дробление на сотни сервисов считалось признаком архитектурной зрелости. Сегодня индустрия смещается в сторону модульных монолитов и сервис-ориентированных подходов. Одна из причин этого: ИИ плохо работает в распределённых системах. Он не видит картину целиком, теряет связи между сервисами, генерирует несовместимые контракты. В модульном монолите — единая кодовая база, явные границы модулей, понятная общая картина для ИИ. DORA этот тезис не проверяла, но её данные о важности контекста и внутренних данных для ИИ косвенно его поддерживают. Поэтому практический критерий простой: размер сервиса определяется не модой, а Time-to-Market и стоимостью координации.Отдельно следует рассмотреть работу с батчами. Батч — это пакет изменений, который команда выкатывает за один раз. DORA на протяжении нескольких нет показывает: чем меньше батч, тем здоровее система. DORA 2025 включает «работу мелкими батчами» в число семи способностей, которые усиливают положительный эффект ИИ. Там же выдвигается гипотеза: ИИ позволяет генерировать больше кода в одном изменении, а большие наборы изменений труднее ревьюить — отсюда связь ИИ с ростом нестабильности доставки. В DORA 2024 фиксировалось снижение пропускной способности на 1,5% и стабильности на 7,2% на каждые 25% роста внедрения ИИ. В DORA 2025 пропускная способность демонстрирует рост, однако нестабильность сохраняется. Причина, по мнению авторов, не в качестве генерируемого кода, а в объёме изменений, выпускаемых за один раз.
Контроль качества: от код-ревью к автоматизированному надзору
Начинающие разработчики и ИИ-ассистенты могут генерировать тысячи строк кода в день — объём, который невозможно полностью проверять вручную. Поэтому архитектор смещает фокус с построчного ревью функций на автоматические fitness-функции: проверки циклических зависимостей, чистоту слоев и black-box метрики контрактов.Такой инструмент называют fitness functions — это автоматические проверки, которые оценивают заранее заданные архитектурные свойства и помогают выявлять отклонения от установленных правил.
Данные DORA за 2025 год показывают, что ИИ не отменяет необходимость контроля качества: он скорее усиливает уже существующие сильные и слабые стороны организации. Поэтому сгенерированный код разумно рассматривать как черновик, который нужно проверять и при необходимости дорабатывать.
Результаты опроса Stack Overflow подтверждают эту проблему: 66% разработчиков назвали наиболее частой трудностью работу с решениями ИИ, которые «почти правильные, но не совсем», что приводит к дополнительной отладке. Поэтому задача архитектора — задавать архитектурные ограничения, контракты и метрики, которые можно проверять автоматически.
Какие навыки нужны архитектору в 2026?
Архитектор — это связующее звено между бизнесом и разработкой. Он переводит требования в жёсткие рамки и тесты, по которым система проверяется автоматически. Разработчик понимает, как писать код. Архитектор понимает, как работает бизнес, и переводит требования в жёсткие рамки и тесты для системы. Если описать ИИ общую цель — он сам нарежет её на задачи и напишет код. Но цель и ограничения должен задать архитектор. Без этого ИИ генерирует несистематизированный набор решений.DORA 2025 формулирует это так: «ИИ — это усилитель». Сильные команды становятся сильнее, слабые — слабее. 90% респондентов используют ИИ в работе, более 80% отмечают рост личной продуктивности, при этом 30% не доверяют ИИ-коду. Архитектор — это тот, кто делает команду сильной: задаёт контекст, рамки и метрики.
Stack Overflow 2025 дополняет картину: 46% разработчиков активно не доверяют точности ИИ, а 76% не планируют использовать ИИ для деплоя и мониторинга в ближайшие 3–5 лет. То есть архитектурное мышление остаётся человеческой задачей.
Три навыка, которые стали критичными:
Диагностика готовности к эволюционной архитектур
Если вы не можете уверенно ответить на следующие вопросы, это повод улучшить архитектурные практики:Два или более отрицательных ответа — сигнал, что команде может потребоваться обучение практикам эволюционной архитектуры. Его цель — научиться фиксировать решения, управлять контекстом проекта и автоматически проверять архитектурные свойства системы.
Где учиться эволюционной архитектуре?
Эволюционная архитектура осваивается через практику: ADR, C4, Event Storming, black-box тесты. Эти навыки можно получить на специализированном обучении.Мы обновили интенсив-практикум «Эволюционная архитектура: проектирование в условиях неопределённости и развития ИИ» — программа полностью отражает реалии 2026 года.
Актуальные изменения
Что внутри
Программа построена так, чтобы дать не только теорию, но и практику: 39% обучения — работа над реальными кейсами. Слушатели разрабатывают ADR, подбирают black-box метрики для контроля архитектуры без ручного чтения кода, разбирают критерии выбора между монолитом и микросервисами, определяют границы системы через Event Storming и DDD и осваивают практику предотвращения переусложнения.
Кому подходит курс
FAQ
Что такое эволюционная архитектура простыми словами?Это подход, при котором система спроектирована так, чтобы её можно было быстро и безопасно менять, а знания о ней сохраняются в ADR, границах модулей и метриках.
Чем эволюционная архитектура отличается от Agile?
Agile отвечает на вопрос «как быстро выпускать изменения». Эволюционная архитектура добавляет к этому фиксацию решений, управление границами и надзор через метрики, чтобы изменения не накапливали техдолг.
Зачем архитектору ADR в 2026 году?
ADR — это память архитектурных решений для команды проекта и ИИ-ассистентов. Нейросеть не может спросить у коллеги, поэтому ей нужен читаемый контекст: что решили, почему, какие альтернативы отклонили.
Модульный монолит или микросервисы — что выбрать?
Размер сервиса определяется не модой, а Time-to-Market и стоимостью координации. В 2026 году модульный монолит часто выигрывает, потому что даёт ИИ общую картину системы.
Как контролировать качество, если код-ревью не тянет объёмы?
Через black-box тесты, fitness functions и метрики наблюдаемости. Архитектор проверяет не «как написана функция», а «что система выдаёт на входе и выходе».
Кому подходит интенсив-практикум «Эволюционная архитектура» в Учебном центре IBS?
Архитекторам, тимлидам, senior-разработчикам и руководителям разработки, которые хотят системно работать с ИИ-контекстом, управлять техдолгом и строить архитектурный надзор.