Ключевые идеи

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

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

  • При этом на повестке — и ИИ-ассистенты для разработки. Они должны ускорять работу без просадки по качеству, а ещё важно понимать, как бизнес-пользователи будут использовать эти инструменты вместо привычных low-code решений.

  • Не уходит и тема «зелёного» софта: компании режут затраты на облако, но это лишь косвенно снижает углеродный след. Сложнее — научиться реально работать с возобновляемой энергией.

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

Ключевые тренды

Каждый год редакторы InfoQ вместе с экспертами из индустрии собираются и обсуждают, куда движется архитектура и дизайн ПО. Чтобы навести порядок в этих трендах, они пользуются моделью «Преодоление пропасти» (Crossing the Chasm) Джеффри Мура. Основное внимание при этом уходит на то, что находится на стадии «инноватор» и «ранний последователь» — именно там рождаются темы, которые будут определять повестку ближайшего года.

Для читателей это хороший ориентир: такие тренды могут подсказать идеи и для собственных проектов.

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

Одним из ключевых критериев становится стабильность технологии. Новые идеи обычно развиваются быстро, но при этом им не хватает зрелости и устойчивости, а значит, внедрение требует дополнительных усилий. Когда же InfoQ говорит, что тренд «перешёл пропасть» и дошёл до раннего большинства, это сигнал: технология стала доступна для более широкого круга компаний, которые хотя бы могут прикинуть, насколько она им подходит.

За последний год ИИ активно развивался сразу в нескольких направлениях, и эта область ещё долго останется в центре внимания индустрии. Большие языковые модели (LLM) распространились настолько широко, что перескочили сразу несколько стадий и оказались уже в «позднем большинстве». Сегодня их упоминают в каждой второй презентации про ИИ.

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

Более детально эти вопросы разбираются в отдельном отчёте InfoQ по ИИ, ML и data engineering, а в архитектурном обзоре выделены только самые важные для архитекторов и системных аналитиков направления. Представьте их как блоки на диаграмме: архитектору не нужно самому уметь реализовывать каждый кусок, но он обязан понимать, как ИИ-модуль встраивается в систему. Какие у него входы и выходы, как оценить производительность, масштабируемость, стоимость и другие сквозные характеристики — всё это становится частью работы архитектора.

Agentic AI — Инноватор

Помимо LLM сейчас выстреливают ещё два направления, на которые архитекторам стоит держать фокус: агентный ИИ (agentic AI) и малые языковые модели (SLM). Раньше агентный подход чаще называли просто «AI-агенты». Суть тут в том, что модель способна сама выполнять задачи, а иногда несколько агентов могут объединяться и работать вместе, достигая более качественного результата.

В традиционном софте мы видели похожие вещи — оркестрацию или хореографию для управления потоками работ. Агентный ИИ можно представить как развитие этой идеи: сначала агенты делают отдельные задачи, а со временем схема может вырасти в supervisor-модель, где уже сам ИИ решает, какие шаги выполнять в рамках бизнес-процесса. Пока этот тренд остаётся в категории «инноваторов��: технологии продвинулись далеко, но доверия к «недетерминированным» системам у бизнеса пока маловато.

Для архитекторов здесь есть интересная параллель с микросервисами: у каждого агента свои границы и паттерны взаимодействия. Такой подход делает систему прозрачнее — проще отслеживать действия, настраивать качество работы и обновлять модули. Появилась новая модель? Можно заменить старый агент без переделки всей системы. Главное — не забывать регулярно тестировать агентов по мере того, как они и доступные им действия эволюционируют.

Малые языковые модели (SLM) — Инноватор

Если LLM стали «универсальными комбайнами», то малые языковые модели (SLM) — это их узкоспециализированные родственники. Архитекторы смотрят на них как на способ забрать сильные стороны больших моделей и при этом закрыть их слабые места.

Узкая специализация позволяет SLM выполнять конкретные задачи даже лучше, чем LLM. Они проще и дешевле в обучении, поэтому всё больше компаний могут позволить себе «собственную модель под задачу». Компактный размер даёт ещё пару бонусов: ниже операционные расходы, меньше углеродный след и больше вариантов для развёртывания. В отличие от LLM, которые обычно доступны только через облачные API, SLM можно гонять прямо на своём железе или на edge-устройствах. Это снижает задержки и повышает безопасность данных.

Retrieval-augmented generation (RAG) — Ранний последователь

Самый рабочий способ подтянуть качество LLM сегодня — добавить RAG. Этот подход уже почти стал стандартом, но на практике его внедрение всё ещё требу��т немало усилий.

Поэтому архитекторы начинают проектировать системы так, чтобы данные сразу были удобны для RAG-сценариев. И в будущем мы всё чаще будем видеть архитектуры, где изначально заложено: данные используются не только «для отчётов», но и как топливо для генерации. Это часть общей тенденции к data-driven архитектуре, где именно данные становятся главным активом.

Разработка с поддержкой ИИ — Раннее большинство

Раньше InfoQ отслеживал тренд low-code/no-code — благодаря API бизнес-пользователи могли что-то собирать сами. Теперь эту тему постепенно вытеснила разработка с поддержкой ИИ, потому что сценарии во многом совпадают.

Сегодня ИИ-ассистенты стали нормой для профессиональных разработчиков, но настоящий вызов — это использование таких инструментов людьми без инженерного бэкграунда. Если раньше при проектировании low-code-систем особое внимание уделялось безопасности API, то теперь порог входа ещё ниже. Ассистенты позволяют дергать API, которые вообще-то изначально не планировались для «простых» пользователей.

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

Поэтому архитекторы ищут способы формализовать работу с промптами — так, чтобы генерируемый код не ломал архитектурные и стилевые договорённости. Уже появляются инструменты, которые помогают встроить ИИ-разработку в процессы, но пока это далеки от зрелости классических линтеров или EditorConfig.

Зелёный софт — Инноваторы

Тема энергоэффективного и «углеродно-эффективного» софта всё ещё остаётся на уровне инноваций. Большинство компаний пока ограничивается оптимизацией расходов на облако — и это действительно помогает косвенно снизить энергопотребление. Но гораздо реже речь заходит о том, как сократить углеродный след самих приложений.

Более зрелый подход требует учитывать где и когда исполняется код. Ведь уровень «зелёности» напрямую зависит от того, на чём работает дата-центр. Например, подход follow the sun позволяет подстраивать вычисления под доступность солнечной энергии. С другой стороны, выполнение задач ближе к пикам нагрузки может быть выгоднее, чем держать сервера полупустыми. Иногда проще запустить что-то ночью, когда мощности уже выделены, а спрос минимален.

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

В индустрии уже есть примеры «зелёных» практик. Google распределяет вычислительные задачи между дата-центрами в зависимости от доступности возобновляемой энергии. Microsoft протестировала подводные дата-центры (проект Natick), чтобы снизить затраты на охлаждение и повысить надёжность серверов. AWS позволяет клиентам выбирать регионы с разной долей «чистой» энергии в энергобалансе и заявляет о переходе на 100% возобновляемые источники к 2025 году.

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

Инженерия приватности — Инноваторы

Privacy engineering как тренд появился в отчётах InfoQ в 2024 году — и это не про «отписку для галочки» после очередного инцидента или требования регулятора. Речь о компаниях, которые изначально закладывают приватность в архитектуру системы как одну из ключевых функций.

ИИ делает эту тему ещё более актуальной. Перед внедрением LLM архитекторы должны чётко понимать: какие данные будут уходить по сети, попадут ли они в будущие модели и соответствует ли это условиям, на которые уже согласились пользователи.

Социотехническая архитектура — Ранний последователь

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

Одно из проявлений такого подхода — движение shift-left. Смысл не в том, чтобы вернуться к «большому дизайну заранее», а в том, чтобы обсуждать ключевые вопросы раньше, чтобы система могла эволюционировать без постоянных переделок в последний момент.

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

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

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

А изучить современные принципы и практики архитектуры, эффективное управление командой аналитиков можно на курсе «Системный аналитик. Team Lead». Управляй аналитиками, строй архитектуру, меняй правила игры в проектах