AIArticle Constrained languages shrink the output space so models produce verifiable results instead of plausible noise.
Rachel Goldstein LLMs generate code faster than any human can review it. Speed is no longer the problem. Reliability is. Free-form generation in a general-purpose language produces piles of plausible output that are expensive to check, easy to get subtly wrong, and nearly impossible to validate automatically. The practical way out is not bigger models or cleverer prompts. It is domain-specific languages.
A DSL gives the model hard boundaries. It collapses the space of valid expressions, so a handful of examples lock in the syntax. Because the language is narrow, you can attach a parser, a schema checker, or domain invariants that reject nonsense before it ships. That turns the LLM from an unreliable free-form coder into a translator that emits something you can actually trust.
Unconstrained generation hits a wall #
Large systems cannot be fully specified up front. A natural-language description is a starting hypothesis. The real constraints, edge cases, and trade-offs only appear once you start implementing. When an LLM dumps a large block of Java or Python, reviewing that dump is not the same as writing the code. You can scan chunks for intent, but you never have to wrestle with the design decisions that force the domain model into the open: where a responsibility belongs, what invariants must hold, which boundaries stay stable under change.
Code is two things at once. It is machine instructions and a living conceptual model of the problem. Those abstractions emerge only through construction. Without them as context, the model invents its own vocabulary on every call and the results drift. General-purpose languages make the problem worse because they offer dozens of equally valid ways to express the same idea. The model has too much freedom and too little signal.
Why models handle DSLs cleanly #
Anyone who has asked an LLM for a Mermaid sequence diagram, a Graphviz graph, or a Kubernetes manifest has seen the pattern. A few examples are enough. The same holds for SQL. These are deliberately narrow languages. They encode one domain’s concepts and almost nothing else. The reduced variation means few-shot prompting works reliably, and the resulting text can be parsed and validated without heroic effort.
The contrast with free text or proprietary schemas is stark. One team building a natural-language query helper found that injecting their own schema into the prompt produced valid output only about 12 percent of the time. Substituting SQL raised the success rate to roughly 30 percent. Even a well-known DSL is easier for the model than a custom one, but the direction is clear: narrower is better. Free-text explanations of how to build a query are almost impossible to validate thoroughly. Structured DSL statements are not.
JSON as an intermediate format has the opposite problem. It forces the model to emit structural tokens that carry no domain meaning and simply burn context window. A purpose-built DSL can be both more compact and more meaningful to the model because every token maps to a concept that matters.
Two phases of working with the model #
Treat the LLM as a collaborator first, then as an interface. In the discovery phase you use it to explore the domain vocabulary itself. You sketch core concepts, feed them back, and let the model propose extensions while you keep the semantic model honest. The result is a small set of abstractions that already constrain later generation. Even without a full surface syntax, solid types and invariants improve output quality.
Once the model (the conceptual one) is stable, you grow a thin DSL on top of it. At that point the LLM switches roles. It becomes a natural-language front end. Users describe intent; the model emits DSL statements; your tooling validates, type-checks, and executes them. The DSL is now the source of truth. Any general-purpose code that is later generated is merely a projection that can be regenerated or discarded. The durable asset is the constrained language and the domain model behind it.
What you actually do tomorrow #
Start with the DSLs you already own. Put a validator in the loop for SQL, for Kubernetes YAML, for Terraform, for Mermaid. Reject invalid output immediately and either retry with a tighter prompt or surface the error to the user. The cost is near zero and the reliability gain is immediate.
For a custom domain, do not wait for a full language workbench. A fluent library API, a small YAML dialect backed by JSON Schema, or an s-expression style that maps cleanly onto your existing objects is often enough. Grammar-aware prompting and a few carefully chosen examples make generation reliable without fine-tuning. Recent tooling work shows that even proprietary DSLs become usable once the grammar is in the prompt and the output is forced through a real parser. The trade-offs are real. Designing the DSL and the semantic model still requires human judgment. You will iterate. High-assurance systems still need formal verification on top; a parseable DSL does not magically give you proofs. But the alternative of hoping the next model release will suddenly produce correct general-purpose code at scale is not an engineering plan.
The teams that pull ahead will treat the DSL as the long-lived artifact. Natural language is just the interface. The model is just the translator. Everything else can be regenerated. That is how you turn LLM speed into something you can actually ship.
Sources & further reading #
[DSLs Enable Reliable Use of LLMs](https://martinfowler.com/articles/llm-and-dsls.html)— martinfowler.com -
[Mastering DSL Output: LLM Reliability without Fine-tuning](https://www.faros.ai/blog/mastering-domain-specific-language-output-getting-an-llm-to-perform-reliably-without-fine-tuning)— faros.ai
[Rachel Goldstein](https://sourcefeed.dev/u/rachel_goldstein)· Dev Tools Editor
Rachel has been embedded in the developer tooling ecosystem for nearly eight years, covering everything from IDE wars and package-manager drama to the quiet rise of AI-assisted coding. She has a soft spot for open-source maintainers and an unhealthy number of terminal emulators installed on a single laptop.
Discussion 0 #
No comments yet
Be the first to weigh in.