Вы знали, что с помощью LLM можно вывести подход Architecture as Code на новый уровень?

И с тем, и с другим бывают проблемы. Субъективно, по качеству Opus значительно лучше Sonnet. И за той, и за другой моделью иногда приходится руками код править.

Контекст тоже периодически переполняется, это проблема. Здесь есть общий (для агентов) тренд - уходить от заполнения огромного CLAUDE.md к специфичным скиллам и специфичным документам в docs. Это помогает, т.к. инструкции из CLAUDE.md подгружаются в контекст всегда, а из скилла только при вызове этого скилла. Соответственно, скилл уже выбирает, какие документы из docs подгрузить для выполнения своих функций.

Вы знали, что с помощью LLM можно вывести подход Architecture as Code на новый уровень?

Как альтернативу Lite, рассматриваем плагины в VSCode и общий Structurizr On-Prem. На Event Storming Diagram, спасибо, посмотрим!

Вы знали, что с помощью LLM можно вывести подход Architecture as Code на новый уровень?

Да, вы правы! Автоматический Feedback Loop тут просто необходим. Иначе человеку на каждый шаг пришлось бы самому открывать схемы в UI и валидировать, что получилось.

Вы знали, что с помощью LLM можно вывести подход Architecture as Code на новый уровень?

Понимаю вас. Вкусовщина и бесконечные совещания, к сожалению, слишком часто являются частью нашей профессии. Что несомненно демотивирует и мешает развиваться.

Вы знали, что с помощью LLM можно вывести подход Architecture as Code на новый уровень?

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

Вы знали, что с помощью LLM можно вывести подход Architecture as Code на новый уровень?

Спасибо за развёрнутый комментарий! У Structurizr DSL действительно есть ограничения. В первую очередь он про описание структуры, в нём ничего нет про логику и правила.

Но именно об этом и статья: о том как LLM позволяет преодолеть ограничения DSL.

В нашем подходе логика, правила, стандарты, шаблоны переносятся в слой инструкций к LLM-агенту. По сути, мы создаём тот самый Decision framework поверх модели на DSL, о котором вы пишете, только не на жестком языке типа OPA/Rego, а на естественном языке промптов. Цель не в том, чтобы полностью перенести знания из головы архитектора - а в том, чтобы описать типовые правила и снять рутину. Постепенно определить, стандартизировать и описать самую критичную логику и ограничения вполне возможно.

И здесь есть ещё один важный эффект: когда правила описаны явно - в промптах, в документах, в примерах - они становятся общими для всей команды. Когда на ландшафте работает 5-10 архитекторов, каждый со своим опытом, знаниями и представлениями о правилах в голове, это особенно ценно.

В нашем репозитории эти правила живут в нескольких местах:

• CLAUDE.md - общие инструкции для проекта: стиль именования, структура репозитория, общие принципы.

• Файл скилла SKILL.md - инструкции к конкретному сценарию. Здесь описывается логика: что проверять, какие разделы генерировать, какие правила применять.

• Директория docs - стандарты ИБ, требования корпоративной архитектуры, шаблоны. LLM читает их и добавляет в контекст.

• Директория solutions - примеры уже согласованных арх. решений. LLM распознаёт паттерны внутри них и применяет к новому решению.

Также в Structurizr DSL мы можем помечать элементы и связи метаданными через теги и properties. На основе этих метаданных LLM может понимать, какие правила нужно применить.

Как бы я решал описанные вами кейсы в нашем подходе:

1. Если поток несет ПДн - нужно шифрование и запись в раздел ИБ
   В DSL на поток вешается тег "PDn". В инструкции скилла прописываем правило: "Проверь все связи с тегом PDn. Если протокол не TLS/mTLS - ошибка валидации. Если тег есть, убедись, что этот поток упомянут в разделе ИБ документа".
   

2. Если система внешняя, нужен API Gateway
   Внешние системы в модели уже помечены тегом External. В скилле прописываем правило: все связи от систем с тегом External к внутренним контейнерам должны идти через API Gateway.
   

3. При добавлении нового контейнера, он должен попасть в реестр, получить код, владельца
   Прописываем в скилл инструкцию: "для каждого нового контейнера заполни properties: code, owner и т.д. и создай запись в реестре; если увидишь контейнер без этих свойств - ошибка валидации".
   

4. Два контейнера в разных контурах безопасности - нужен межсетевой экран

   Для контейнеров прописываем property securityZone=zoneA/zoneB. В скилле пишем инструкцию "Если связь пересекает разные контуры безопасности, добавь запись в таблицу межконтурного взаимодействия".

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

Вы знали, что с помощью LLM можно вывести подход Architecture as Code на новый уровень?

Постараюсь добавить что-то шаблонное. Реальные БТ не могу выгружать по политикам компании.

Вы знали, что с помощью LLM можно вывести подход Architecture as Code на новый уровень?

Сейчас решаем эту проблему только частично - вручную подкладываем спецификации смежных систем в соответствующую папку input. Агент учитывает документы из неё при генерации арх. решения и при ревью.

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

У нас в компании есть корпоративная База Знаний для Искусственного Интеллекта (БЗИИ) и реализован RAG по ней. В том числе, там есть статьи из корпоративного Confluence со спецификациями систем. Плюс, сейчас в разработке корпоративные MCP сервера по Confluence и Jira. Эти сервисы можно подключить как тулы к Claude Code и тогда агент сможет искать релевантную документацию и получать полный текст статей.

Это в планах есть.