LLM Более стабильный способ написания кода — сначала написать DSL.

Некоторое время назад я видел одну и ту же ситуацию неоднократно: бросая требования прямо в модель, скорость генерации очень быстрая, и доработка тоже быстрая; сначала поместите требования на уровень DSL, а затем позвольте модели записать реализацию вокруг этого уровня семантической модели, и результат будет очевидно стабильным. Изменение очень прямое. Ключевым моментом является не то, можно ли записать модель, а то, было ли предварительно закрыто необязательное пространство.

Естественный язык подходит для указания направлений, но не подходит для принятия слишком большого количества неявных решений. Казалось бы, простое требование при реализации будет разбито на множество мелких решений: как назвать состояние, считается ли сбой завершенным, сколько раз повторять попытку, на чьем часовом поясе основано временное окно и на каком слое записывается журнал. Пока эти суждения все еще скрыты в процессе генерации, модель будет одновременно дополнять детали и менять границы. Окончательно написанное можно просмотреть, но просмотреть сложно.

Естественный язык подходит только для разговора о проблемах

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

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

DSL превращает неявное суждение в явный ввод

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

scenario: payment_timeout
steps:
  - send: order.created
  - wait: 3s
  - if: payment_missing
    then: cancel_order
    audit: required

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

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

LLM подходит для участия в развитии DSL

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

На этом этапе LLM весьма полезен. Это может помочь объединить разрозненные утверждения в набор терминов, а также выявить такие проблемы, как несоответствия имен, пробелы в статусах и отсутствие ненормальных путей на этапе черновика. После того как семантическая модель станет стабильной, она будет генерировать реализации, принципиальные представления и тестовые образцы. Выход будет больше похож на бег по трассе и не будет каждый раз поворачивать в другие места.

Я бы предпочел поставить LLM позади DSL. Сначала проясните границы, а затем позвольте им помочь заполнить границы позже, чтобы система не отвлекалась на импровизацию снова и снова.

Семантический слой также станет громоздким

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

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