Ключевые идеи
Пока все вокруг активно прикручивают большие языковые модели, новые эксперименты всё чаще уходят в сторону более компактных и специализированных 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. Смысл не в том, чтобы вернуться к «большому дизайну заранее», а в том, чтобы обсуждать ключевые вопросы раньше, чтобы система могла эволюционировать без постоянных переделок в последний момент.
Опытные архитекторы стараются перестать быть «бутылочным горлышком». Они помогают командам самим принимать решения: подсказывают, консультируют, задают рамки. В итоге команда двигается быстрее и чувствует больше уверенности в выбранном решении.
На это накладывается и развитие инженерных платформ. Если раньше компании часто делали самописные решения, то сегодня платформы становятся продуктами сами по себе. Вопрос «строить или покупать» теперь рассматривается не только с технической стороны — важно понимать, как платформа повлияет на разработчиков, тестировщиков и операторов, которые будут с ней работать каждый день. Именно в этом и проявляется социотехнический подход.
Часто именно неочевидные вещи мешают работе архитекторов и аналитиков: бесконечные споры в команде, задачи, которые теряются в обсуждениях, или документация, которая устаревает быстрее, чем успевает появиться. Эти проблемы редко решаются самим кодом — тут нужны другие подходы. В ближайшие недели можно присоединиться к бесплатным урокам, где будем разбирать эти вопросы на реальных примерах:
9 сентября в 20:00 — Soft skills для системных аналитиков уровня Team Lead
23 сентября в 20:00 — Основы автодокументирования ИТ-процессов
А изучить современные принципы и практики архитектуры, эффективное управление командой аналитиков можно на курсе «Системный аналитик. Team Lead». Управляй аналитиками, строй архитектуру, меняй правила игры в проектах
Dhwtj
я год изредка посматривал на InfoQ, что они там считают перспективным
бред полный
расходимся, пацаны