Всем привет! Меня зовут Алексей Пронский, я отвечаю за архитектуру в AI-департаменте группы компаний БКС. Мы строим агентные системы, AI-ассистентов, OCR-системы, речевую аналитику и Classic ML модели. Поскольку мы работаем по принципам enterprise разработки, за каждым таким проектом стоит архитектурное решение (далее — арх.решение) — документ, который проходит согласование с бизнесом, корпоративной архитектурой, ИБ и владельцами смежных систем. Арх. решения мы ведём в Confluence, диаграммы рисуем в Draw.io. Типичный цикл от получения бизнес-требований до согласованного арх. решения в среднем занимает две-три недели.

За последний год LLM-ассистенты произвели настоящую революцию в написании кода. В этой статье я покажу, как добиться такого же эффекта в архитектуре — перейти на подход Architecture as Code и передать рутину LLM. Мы используем Structurizr для описания архитектуры и Claude Code как LLM-ассистента. Буду показывать примеры на их основе, демо-репозиторий можно будет посмотреть на GitHub.

Проблема: архитектор — это не тот, кто рисует квадратики

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

• Получил бизнес-требования (БТ) — прочитал, разобрал 40-шаговый BPMN-процесс.

• Определил, какие системы затронуты, какие нужно создать, какие доработать.

• Создал страницу с решением в Confluence, открыл плагин Draw.io, нарисовал контейнерную диаграмму, потом практически продублировал её в диаграмме инфопотоков.

• Оформил информационные потоки в таблицу, где заполнил необходимые поля: код, объект данных, источник, потребитель, тип и т.д.

• Заполнил обязательные разделы ИБ: ролевую модель, потоки с защищаемой информацией, статусы.

• Написал НФТ, требования к реализации.

• Отправил на согласование. Получил 15 замечаний. Половина — "не заполнены такие-то поля", "не указаны ответственные", "содержание раздела не соответствует стандартам". Исправил. Отправил снова.

Знакомо? Основная боль здесь — не в том, что работа сложная. Она механическая. Архитектурное решение принимается за час. А оформлять его приходится два дня. И ещё неделю итерироваться по замечаниям, половина из которых — очевидные неточности и несоответствия.

Что меняется с введением подхода Architecture as Code

Идея Architecture as Code проста: описывать архитектуру не в виде картинок, а текстом в виде кода на DSL. Диаграммы генерируются автоматически по коду. Мы используем Structurizr — инструмент для описания архитектуры в формате C4 Model.

Вместо рисования в Draw.io вы пишете модель:

// Определяем системы
white_tower = softwareSystem "Белая Башня" "Главный зал общения с магами"
bree_crossroads = softwareSystem "Перекрёсток Бри" "Узловая станция Средиземья"

// Определяем связи с указанием протокола
white_tower -> bree_crossroads "Запрашивает свитки через Перекрёсток" "MCP/HTTPS"
white_tower -> radagast "Передаёт вопросы Радагасту" "REST/HTTPS"

Structurizr из этого кода генерирует диаграммы — IT-ландшафт, контекст выбранной системы (C1 уровень), контейнеры внутри системы (C2 уровень). Одна модель, много представлений.

Вот что это даёт на практике:

Единый источник правды. У нас 20+ систем в IT-ландшафте. Раньше каждое арх. решение содержало свои диаграммы — отдельные файлы, которые быстро устаревали и рассинхронизировались между собой. Чтобы вести ландшафт, приходилось просматривать множество последних арх. решений, формировать представление об изменениях в архитектуре по ним и обновлять диаграмму ландшафта вручную. Это большой объём работы. Теперь, после перехода на описание арх. решений в Structurizr, диаграмму ландшафта нашего департамента мы получаем бесплатно.

Структура в нашем архитектурном репозитории выглядит следующим образом:

structurizr/
  workspace.dsl          # Главный файл — собирает всё через !include
  workspace.json         # Координаты элементов на диаграммах
  common.dsl             # Общие акторы и внешние системы
  domains/               # Архитектурные домены - каждая команда владеет своим доменом
    genai/
    agents/
    ocr/
    ...

Каждый домен — отдельная пара файлов: model.dsl (модель) + views.dsl (диаграммы). Общие элементы — акторы, внешние системы — вынесены в common.dsl. Команды работают со своим доменом, не трогая чужие.

Версионирование и diff. Архитектура хранится в git — можно смотреть историю, делать code review, сравнивать версии. С бинарными .drawio файлами это невозможно.

Разные диаграммы по одной модели. Представьте, что вам нужно показать системную архитектуру со связями, отражающими зависимости элементов, и тут же — движение инфопотоков по той же архитектуре. В Draw.io для этого придётся нарисовать две диаграммы с по-разному направленными и подписанными стрелками. А если для схем в арх. решениях нужно ещё и визуально выделять новые и изменяемые элементы, а в диаграмме ландшафта — нет? В Draw.io это означает ручное дублирование с раскрашиванием элементов в разные цвета.

В Structurizr DSL для этого есть механизм тегов. Модель остаётся единой, элементы модели помечаются тегами и по-разному отображаются в разных представлениях (view).

В коде это описывается следующим образом (в инфопотоках проставлен тег Dataflow):

// Связи контейнеров
aragorn -> isengard_listeners "Забирает расшифровки из потока" "Kafka"
aragorn -> moria_vault "Сохраняет в Хранилище" "TCP"
aragorn -> ravens  "Отправляет Воронов с заданиями" "AMQP"

// Инфопотоки
isengard_listeners -> aragorn "INF01. Расшифровки речей" "" "Dataflow"
moria_vault -> aragorn "INF02. Расшифровки и результаты анализа" "" "Dataflow"
aragorn -> ravens "INF03. Задания на обработку" "" "Dataflow"

И создаётся два view: один, исключающий связи с тегом Dataflow и второй, наоборот, включающий.

container aragorn_palantir "aragorn_palantir_containers" "Палантир Арагорна: архитектура" {
    include *
    exclude relationship.tag==Dataflow
}

container aragorn_palantir "aragorn_palantir_dataflow" "Палантир Арагорна: инфопотоки" {
    include *
    exclude relationship.tag!=Dataflow
}

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

Контейнерная диаграмма — зависимости компонентов

Диаграмма инфопотоков — движение данных

Автоматизация. Как только архитектура превращается из картинки в код, она может стать таким же участником CI/CD-процесса, как и программный код.

На практике в CI/CD часто автоматизируют:

1. Валидацию архитектуры. Structurizr парсит DSL и ловит ошибки: несуществующие ссылки, дубликаты идентификаторов, нарушения правил C4. В Draw.io можно нарисовать стрелку в никуда — и никто не заметит до ревью.

2. Экспорт диаграмм. После мёржа в main запускают скрипт, который рендерит все диаграммы в SVG и экспортирует их в confluence или заливают архитектуру на архитектурный портал (в нашем случае это Structurizr On-Prem)

3. Аналитику. Поскольку модель — это структурированный код, можно программно анализировать архитектуру. Например, автоматически сгенерировать таблицу всех HTTP-взаимодействий для сетевиков.

4. Проверки для ИБ. Проверяют, что все вызовы в открытый интернет проходят через прокси, персональные данные передаются только по защищённым протоколам.

5. Детекцию архитектурного дрифта. Сравнивают связи сервисов из трейсинга (OpenTelemetry) со связями в DSL. Если в трейсах есть вызов, которого нет в архитектуре — алерт архитектору.

6. Связь с инфраструктурой. Генерируют из архитектурной модели скрипты для разворачивания инфраструктуры.

Всё это звучит хорошо. Но есть нюанс.

Писать DSL-код ощутимо тяжелее и дольше, чем рисовать квадратики мышкой, особенно для тех, кто не привык работать с кодом. Нарисовать диаграмму на 10 систем в Draw.io можно за 20 минут. Чтобы описать ту же модель в DSL, разобраться с синтаксисом, правилами видимости, ограничениями нужно уже час-полтора. Добавьте сюда создание views, настройку стилей, экспорт диаграмм. Architecture as Code даёт перечисленные выше преимущества — но приходится платить за это временем на кодирование.

И вот тут появляется LLM.

А что если добавить LLM?

Использование LLM меняет правила игры по двум основным направлениям.

1. LLM закрывает главную проблему Architecture as Code

Код — это родной язык для LLM. Языковым моделям всё равно, на чём писать: на Python, Java или на Structurizr DSL.

Для человека переход от визуального редактора к коду — это когнитивная нагрузка. Для LLM это, наоборот, упрощение. Модель может не просто генерировать DSL-код, но и понимать архитектуру, которая на нём описана. Она читает существующую модель, определяет контекст, добавляет новые контейнеры в правильные места, проставляет теги, соблюдая ваши конвенции.

Барьер входа, о котором я писал выше, исчезает. Вам не нужно писать DSL руками с нуля. Вы описываете архитектуру на естественном языке, а LLM транслирует их в валидный архитектурный код.

2. LLM выводит автоматизацию процессов на принципиально новый уровень

Мы привыкли, что автоматизация — это жесткие скрипты. Они детерминированы, т.е. делают ровно то, что написано. Но сейчас мы видим сдвиг парадигмы во многих областях — от жестких алгоритмов к агентскому подходу.

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

Поскольку архитектура теперь представлена как код, мы можем применить тот же агентский подход к архитектуре, создать своего рода «архитектурного агента». Мы не просто просим робота «сдвинуть квадратик». Мы ставим задачу на уровне смысла: «Проверь, соответствует ли эта архитектура требованиям ИБ», «Сравни реализацию с бизнес-требованиями» или «Подготовь решение к релизу».

Наш инструмент: Claude Code и Skills

В качестве основы для нашего архитектурного агента мы используем Claude Code — инструмент, который работает в терминале (или как плагин в IDE) и имеет доступ к файловой системе проекта.

Его киллер-фича для нас — Skills. Это не код, а кастомные команды, описанные на естественном языке (в Markdown). По сути, вы пишете промпт-инструкцию один раз, даёте ей имя, и Claude запоминает этот сложный алгоритм действий.

Мы описали в проекте 5 основных скиллов, которые закрывают основную нашу рутину:

1. Генерация арх. решения (arch-generate-solution) — основной скилл. Принимает на вход файл с бизнес-требованиями, задаёт уточняющие вопросы, правит DSL-модель, валидирует её и генерирует готовый Markdown-документ с описанием решения.

2. Архитектурное ревью (arch-review-solution) — эмулирует работу 5-ти согласующих (Solution Architect, Enterprise Architect, ИБ, Бизнес, Смежники). Читает готовое решение и выдаёт список замечаний от каждой роли.

3. Экспорт диаграмм (arch-make-svg) — автоматизирует рендеринг. Проходит по всем view в Structurizr и при этом управляет видимостью элементов (например, скрывает то, что не доехало в прод) и сохраняет актуальные SVG-файлы.

4. Сбор ресурсов (arch-list-resources) — парсит DSL и собирает сводную таблицу по всем контейнерам с полями CPU/GPU/RAM/SSD/Replicas. Мы используем её для учёта железных ресурсов.

5. Разрешение конфликтов (arch-merge-conflict) — жизненно необходимый скилл для коллективной работы. В инструменте, с которым мы работаем локально (Structurizr Lite), есть огромная проблема. Файл workspace.json (в котором проставляются вручную выставленные координаты элементов) постоянно вызывает жуткие конфликты при мёрже веток. Вручную решать их практически невозможно. Но на помощь приходит этот скилл, который прекрасно справляется с этой задачей.

В следующем разделе я детально разберу, как работают два наших главных скилла — генерация и ревью решения.

Разбор основных скиллов: как это работает изнутри

Давайте посмотрим, как устроена магия.

1. Skill: Генерация архитектурного решения (arch-generate-solution)

Это наш «тяжеловес». Скилл представляет собой сложный пайплайн из шести фаз, который превращает сырые бизнес-требования в арх. решение с готовым комплектом артефактов.

На вход скилл принимает входные данные: файл с бизнес-требованиями и схемы процессов (BPMN). На выходе генерирует:

1. Обновленный Structurizr DSL (новые системы, контейнеры, связи).

2. Набор SVG-диаграмм.

3. Черновик документа архитектурного решения (АР).

Вот как Claude Code проходит по фазам выполнения этого скилла:

Фаза 1: Контекст и понимание

Claude сканирует папку inputs/, читает бизнес-требования, изучает BPMN-процесс и загружает текущую архитектурную модель (файлы .dsl). На этом этапе он строит для себя карту изменений: «Ага, нужно добавить новый микросервис в домен AI, связать его с существующим API Gateway и положить данные в Postgres».

Фаза 2: Уточнение

Это критически важный этап. LLM не бросается писать код сразу. Скилл явно инструктирует модель задать вопросы архитектору. — «В какой домен добавить новый сервис?» — «Нужен ли отдельный инстанс БД или используем существующий?» — «По какому протоколу они общаются?»

Только получив ответы, агент переходит к кодированию.

Фаза 3: Модификация DSL

Агент вносит изменения в .dsl файлы. Здесь работают строгие конвенции, прописанные в наших инструкциях:

• Новые элементы помечаются тегом New.

• Изменяемые — тегом Changed.

• Информационные потоки получают коды INFXXX.

Если изменение затрагивает несколько систем, агент автоматически создает сводный view, объединяя нужные контейнеры на одной диаграмме.

Фаза 4: Валидация и Экспорт

Claude запускает shell скрипт валидации. Это не просто проверка синтаксиса. Скрипт стучится в Structurizr API (поднятый локально в докере), чтобы убедиться, что модель парсится корректно. Если есть ошибка (например, дубликат ID или циклическая зависимость), агент видит лог ошибки, исправляет DSL и пробует снова. Цикл повторяется до успеха. Такой автоматический Feedback Loop — это секрет качественного результата на выходе.

После успешной валидации запускается рендеринг SVG-диаграмм.

Фаза 5: Генерация документа

Агент создает файл АР-<Название>.md по нашему корпоративному шаблону. Он не просто копипастит требования, а заполняет специфические архитектурные разделы:

• Реестр изменений: Таблица с новыми компонентами.

• Интеграционные потоки: Таблица связей (Кто -> Кому -> Зачем -> Протокол).

• Требования ИБ: Предварительно заполняет классификацию данных на основе контекста.

В итоге архитектор получает не пустой лист, а документ, готовый на 80%. Ему остается проверить логику, дописать нюансы и проставить ссылки на Jira и CMDB.

2. Skill: Архитектурное ревью (arch-review-solution)

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

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

Роли агента при проверке:

1. Solution Architect: Проверяет техническую целостность. Совпадают ли диаграммы с текстом? Все ли стрелки на схеме описаны в таблице интеграций? (Это самая частая причина возврата документов на доработку).

2. Enterprise Architect: Смотрит на соответствие корпоративным стандартам. Используются ли утвержденные в тех. радаре технологии? Нет ли дублирования функциональности с другими системами?

3. Специалист ИБ: Ищет уязвимости проектирования. Все ли внешние вызовы идут через шлюз? Где хранятся секреты? Есть ли аутентификация на межсервисных вызовах?

4. Владелец смежной системы: Оценивает влияние на свою систему. Не сломает ли это решение соседние сервисы?

5. Бизнес-заказчик: Проверяет покрытие требований. Реализованы ли все пункты из БТ?

Результат работы скилла — Markdown-таблица с замечаниями:

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

Почему это круто

По нашему опыту, этот скилл отлавливает 60-70% типовых замечаний. Это значит, что с живыми людьми-согласующими мы обсуждаем суть архитектуры, а не тратим 30 минут на споры о том, почему «стрелочка не туда смотрит».

Наши результаты

Мы считаем, что LLM не может (и не должна) принимать архитектурные решения за человека. Выбор паттерна проектирования, компромиссы по CAP-теореме, переговоры со стейкхолдерами — это всё ещё наша работа.

Но LLM блестяще справляется с тем, что архитекторы ненавидят: оформлением, синхронизацией артефактов и первичной валидацией.

Мы провели несколько экспериментов, сравнив время создания арх. решения по старому процессу (Confluence + Draw.io) и по новому (Structurizr + Claude Code). Результаты предварительные, но показательные:

Главный выигрыш — мы перестали тратить дни на «передвигание квадратиков» и поиск опечаток в таблицах интеграций. Теперь это делает машина.

Как повторить это у себя: минимальный набор

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

1. Инструмент: Structurizr Lite (бесплатный, запускается в Docker).

2. LLM-ассистент: Claude Code (работает в терминале, нужен API ключ или подписка).

3. База знаний (CLAUDE.md): Создайте в корне проекта файл CLAUDE.md. Это критически важно! В нём опишите:

   • Структуру вашего репозитория (где лежат .dsl, где картинки).

   • Основные конвенции (например: «Мы используем C4 Model, новые элементы помечаем тегом New»).

   • Правила валидации (например: «Всегда запускай скрипт ./validate.sh после правки DSL»).

4. Первый скилл: Начните с простого — автоматизируйте ревью. Создайте файл инструкции (например, .claude/skills/review.md), где опишите, на что нужно обращать внимание при проверке архитектуры.

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

Как работает всё, что описано в статье, можно посмотреть в демо-репозитории на github.

Ограничения и подводные камни

Будет неправильно сказать, что всё работает идеально. Мы набили много шишек (и всё ещё продолжаем набивать), прежде чем процесс стал отрабатывать автоматически.

1. workspace.json — хрупкий артефакт. Structurizr хранит координаты элементов в отдельном JSON-файле. Если два архитектора параллельно двигают блоки на схеме, git merge превращается в ад. Мы решили это написанием специального скилла для умного слияния JSON, но проблема всё равно требует внимания.

2. Галлюцинации в DSL. Иногда Claude может придумать несуществующий синтаксис или попытаться связать контейнеры из разных областей видимости (что запрещено в Structurizr). Именно поэтому этап валидации через API обязателен. Без скрипта validate-dsl.sh агент примерно в трети случаев генерирует нерабочий код.

3. Не все схемы генерируются идеально. Иногда плывёт нумерация инфопотоков (и тогда нужно дописывать инструкции в скилл или в CLAUDE.md), или подписи связей на диаграммах наезжают друг на друга (тогда нужно открывать UI Structurizr Lite и вручную передвигать квадратики), или возникают какие-то другие шероховатости. Ручная валидация и исправление недочётов всё ещё необходимы.

4. Контекстное окно. Если у вас большой IT-ландшафт, который описан в монолитном DSL-файле, LLM может начать «забывать» его детали. Мы решили это строгой модульностью: каждый домен — отдельный файл, а агент подгружает только нужные куски. Также стараемся делить большие скиллы на несколько меньшего размера. Эти решения значительно уменьшили масштаб проблемы, но контекст LLM всё ещё периодически переполняется.

Заключение: Архитектура как диалог

Мы начали с того, что архитектор тратит 80% времени на бюрократию и только 20% — на принятие архитектурных решений. Architecture as Code сам по себе не решал эту проблему (он просто менял мышку на клавиатуру).

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

— «Добавь кафку в центр, свяжи с биллингом»
— «Готово. Учесть требования по репликации?»
— «Да, и проверь, не нарушаем ли мы паттерны ИБ»

Теперь мы буквально разговариваем со своей архитектурой. Это и есть будущее работы архитектора. Мы перестаем быть «рисователями» квадратиков и поднимаемся на уровень архитектурных смыслов, оперируя ими на естественном языке. И это будущее, которое уже наступило.

P.S. Пару слов про безопасность

Использование облачных LLM в корпоративной среде всегда вызывает много вопросов, связанных с безопасностью. «А не утекут ли наши секреты архитектуры в обучающую выборку Anthropic?» — вопрос более чем справедливый.

Мы в компании относимся к этому серьезно. У нас действует жесткий стандарт департамента ИБ: прямые запросы к публичным API облачных провайдеров недопустимы.

Для работы с LLM — будь то продуктовые фичи, AI-ассистенты в IDE или наш архитектурный агент — мы используем корпоративный шлюз AI Gateway.

Это единая точка входа, которая выполняет роль "умного прокси" и делает две вещи:

1. Маскирование данных: на лету вырезает или заменяет чувствительную информацию (ПДн клиентов, конкретные IP-адреса, пароли и другие чувствительные данные) перед отправкой во внешнее облако.

2. Аудит и контроль: логирует факты обращений, управляет квотами и позволяет централизованно управлять провайдерами моделей.

Поэтому, когда наш arch-generate-solution отправляет схему на анализ, он делает это через защищенный периметр, и «сырые» корпоративные данные пределы контура не покидают. Если вы планируете внедрять подобный подход у себя — озаботьтесь этим вопросом в первую очередь.

Если у вас остались вопросы, с удовольствием отвечу на них по почте или Телеграм:
pronskiyalexey@gmail.com
@AlexeyPronsky