Современные LLM могут генерировать целые системы по текстовому описанию, но с этим связана фундаментальная проблема. Строить большие системы — значит принимать тысячи мелких дизайн-решений, которые невозможно прописать заранее. Спецификация — это гипотеза, а не готовый чертёж. Настоящий дизайн открывается только в процессе реализации, когда ты реально пишешь код и упираешься в конкретные ограничения.
Тут и помогают DSL — предметно-ориентированные языки. Они работают с LLM гораздо лучше универсальных языков вроде Java. Почему? Потому что у DSL узкая область: Mermaid для диаграмм, SQL для запросов, Kubernetes YAML для инфраструктуры. LLM легко генерируют их по описанию, особенно если дать пару примеров. Для агентов это ещё удобнее: DSL почти всегда можно проверить детерминированным валидатором (парсером, компилятором). Ошибки приходят на языке предметной области — «вы не можете выбрать действие до выбора клиента» — а не стектрейсом из глубин сгенерированного кода.
Автор приводит два примера. Первый — утилита для создания PowerPoint-презентаций с диаграммами. Вместо ручной анимации он описал структуру слайдов на YAML с отсылками к PlantUML-диаграммам. LLM выступила сначала как со-дизайнер: помогла продумать разметку с шагами. А затем — как интерфейс: превращала английскую просьбу в валидный YAML.
Второй пример сложнее — фреймворк Tickloom для тестирования распределённых систем. Суть в семантической модели: каждый узел крутится в однопоточном цикле тиков, время считается в тиках, сообщения — обычные Java-объекты. Разработчику остаётся только писать протокольную логику, а не думать о потоках и сети. LLM по описанию генерирует код обработчиков, используя готовую терминологию (Replica, quorumRequest, Handler).
Но и этого оказалось мало для тестовых сценариев. Обычный код теста — мешанина из вызовов tick(), кодировок байтов и фабрик. Поэтому поверх семантической модели автор построил внутренний DSL на Java с прогрессивными интерфейсами. Тот же сценарий теперь выглядит как чистый английский: «клиент BOB пишет ключ через BYZANTIUM, затем перекличка, разделение сети». LLM, получив описание проблемы из DDIA §10.6 про нелинеаризуемое чтение кворума, генерирует сценарий, который не только компилируется, но и читается как описание эксперимента.
В итоге вырисовываются две фазы работы с LLM. Первая — проектирование самого DSL или абстракции. Здесь LLM — партнёр для мозгового штурма: предлагает варианты, критикует, портирует идеи. Ты остаёшься за рулём, потому что именно эти решения надо понимать и владеть ими. Вторая фаза — после того как DSL готов. LLM становится естественно-языковым интерфейсом к вашему инструменту. Описание на английском почти напрямую отображается в словарь, который вы задали.
Ключевой вывод: настоящий актив — не промпт, а DSL и семантическая модель. Сгенерированный код плотный, читаемый и остаётся артефактом, который можно менять через месяц без возврата к исходному запросу.