LLM A more stable way to write code is to write DSL first

A while ago, I saw the same situation repeatedly: throwing the requirements directly to the model, the generation speed is very fast, and the rework is also fast; first put the requirements into a layer of DSL, and then let the model write the implementation around this layer of semantic model, and the output is obviously stable. The change is very direct. The key is not whether the model can be written, but whether the optional space has been closed first.

Natural language is suitable for telling directions, but not suitable for carrying too many implicit decisions. A seemingly simple requirement will be split into many small judgments when implemented: how to name the state, whether failure is considered completed, how many times to retry, whose time zone the time window is based on, and which layer the log is written on. As long as these judgments are still hidden in the generation process, the model will fill in details and change boundaries at the same time. The final written thing can be run, but it is difficult to review.

Natural language is only suitable for talking about problems

LLM is very good at developing a vague description into a complete text, and also very good at completing an intention into a readable draft. What it is not good at is long-term stable naming and constraints for a set of business rules. Once the requirements involve state flow, abnormal branches, time boundaries, and permission boundaries, these words seem clear in the mind, but they are often not finalized when they are actually put into the code. The model faces a large group of open problems, and the output will naturally fluctuate accordingly.

This is why long prompt words often become more tiring the more you write them. After the prompt word continues to lengthen, the model still gets a piece of free text, but the free text is longer. It remembers more context without getting more boundaries. If the boundary is not closed, the model can only continue to guess.

DSL turns implicit judgment into explicit input

After changing the input to DSL, the situation changes. The model no longer guesses business based on casual sentences, but fills in the blanks based on a clear semantic model. For a test scenario, a release process, and a graphical description, the nodes and relationships are first defined by the DSL, and then the text, code, and charts are supplemented by the model. The result will be more like something grown out of the same system.

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

The greatest value of this type of definition is not that it looks good when written, but that it can be version controlled, diffed, and reviewed. Code generation, documentation, testing, and diagrams can all grow from the same semantic model. The model here is more like an actuator than an inventor. It is responsible for enforcing the established boundaries and is not responsible for rewriting them on the spot.

Once this boundary is established, many things that would have been noisy for a long time will become quiet. What should be covered by the test, whether failure is expected, and who has the final say on rollback conditions? These are no longer explained on the spot in a natural language, but written into an executable structure. What humans look at is semantics, what machines execute is semantics, and what we return to when troubleshooting is the same semantics.

LLM is suitable for participating in the growth of DSL

LLM doesn’t just have to be executed outside of a DSL. A more appropriate usage is to let it participate in the growth of DSL first. Feed a few real scenarios into it, let it complete the boundary words, enumeration values, abnormal branches, and counterexamples, and then let people stop it. When the DSL is finalized, what is subsequently handed over to the model will not be unlimited natural language, but constrained input.

At this stage, LLM is quite useful. It can help align scattered statements into a set of terms, and can also identify problems such as naming inconsistencies, status gaps, and missing abnormal paths during the draft stage. After the semantic model is stable, the model will generate implementations, schematic diagrams, and test samples. The output will be more like running on a track and will not turn to other places every time.

I would prefer to put LLM behind DSL. Make the boundaries clear first, and then let them help fill in the boundaries later, so that the system will not be easily distracted by improvisation over and over again.

The semantic layer will also become unwieldy

More DSL is not always better. When the field is still changing drastically, premature solidification will lock in wrong assumptions; if the semantic layer is designed too universally, it will become another heavy framework. The truly cost-effective scenario is usually when the same type of actions occur repeatedly, review costs are high, and the behavior must be traceable. At this point, DSL is no longer an additional burden, but rather a collection of scattered judgments into a stable entrance.

Therefore, the more practical judgment is not “Can LLM be equipped with a DSL?” but “Is it necessary to fix the semantics of this matter first?” Once the answer is yes, the cue word should no longer have full responsibility. The prompt is responsible for explaining the intention, the DSL is responsible for carrying the constraints, and the model is responsible for turning the constraints into executable results. What is written in this way is more like an engineering system rather than a series of improvisations.