# DSLs Make LLM Output Reliable Give a model a [[Domain Specific Languages (DSLs)|domain-specific language]] instead of a general-purpose one, and its output gets dramatically more dependable. Unmesh Joshi (Thoughtworks) made the argument on [[Martin Fowler]]'s site in July 2026, and it is one of those ideas that is obvious in hindsight and almost nobody applies deliberately. ## Why it works **A DSL removes variance.** Java offers a hundred valid ways to express one intent. A DSL strips the variation away. Every choice the language has already made (threading model, networking, timing semantics, error handling) is a choice the model no longer has to make, and therefore a choice it can no longer make badly. What remains is the domain logic, which is the only part you actually wanted from it. **A few examples convey the whole language.** This is why models are so good at SQL, PlantUML, [[Mermaid]], and Kubernetes YAML. The solution space is narrow enough that a short spec teaches it. You do not need the language to be in the training data. A 200-line spec in context is often enough, which is the whole point: the constraint fits in the context window, so training-data coverage stops mattering. **Validation becomes deterministic.** A parser, a schema, a type checker, a compiler. For an autonomous agent, this is the part that matters most. Errors come back at the domain level instead of as a stack trace, so the agent can correct itself without a human in the loop. A DSL without a validator gives up most of the benefit. **A semantic model grounds the vocabulary.** Joshi's Tickloom framework hands the model words like `Replica`, `quorumRequest`, and `Handler`. Prompts land at the protocol level rather than the plumbing level, and the surface available for hallucination shrinks accordingly. ## Two distinct jobs for the model Worth separating, because they need opposite handling: 1. **Designing the abstraction**: the model is a brainstorming partner, iterative, and you should argue with it 2. **Using the DSL once it exists**: the model is a natural-language interface, translating English into valid expressions, and it should be boring and repeatable ## The second use nobody mentions The article frames DSLs as an interface between a non-deterministic model and a deterministic system. There is a second use that is arguably more valuable in agent work: **a DSL as the handoff contract between steps.** Pipe natural language through five model calls and the fifth receives something quite different from what its prompt expects. Make the DSL the contract at each boundary and the drift stops compounding. It does not need to compile or execute; it can be purely declarative, existing only to gate a stage with more structure than prose. This is the same rule as the shared-state boundary in [[Graph Engineering]], arrived at from the language side. ## Where it breaks **"Small" is doing enormous work in the claim.** The advantage holds while a few in-context examples convey usage. As your DSL accumulates things that mix and match, the spec grows until it is a system prompt, and you are back where you started. **Designing and maintaining a language is real work.** The payoff concentrates in well-factored, genuinely constrained DSLs backed by a validator. That is a narrow target, not a default move. **Validators check what they check.** The sharpest counter-example from practice: agent-generated GPU kernels that compile, pass every correctness test, and run slower than the baseline. The validator says pass, the result is useless. If a property matters (speed, cost, memory), it belongs in the check. Otherwise you have automated the production of things that satisfy your tests. **Reliable is not deterministic.** The fair objection is that "reliable" here means "much better", not "repeatable". The fair response is that repeatable-but-not-identical is the standard we accept everywhere else; a good restaurant is reliable without counting the sesame seeds. Both sides are right about different words, and it is worth being explicit about which one you need. ## Tooling is the missing piece The discussion consistently underrates linters, LSPs, and immediate feedback. A plotting DSL that knows your column names can reject a hallucinated column at the moment it is written rather than at runtime. Feedback speed is a bigger lever than language design, and it gets far less attention. ## References - Unmesh Joshi, "DSLs Enable Reliable Use of LLMs" — https://martinfowler.com/articles/llm-and-dsls.html - Hacker News discussion — https://news.ycombinator.com/item?id=48918575 - Reward hacking in agent-generated kernels — https://www.weco.ai/blog/first-evidence-of-recursive-self-improvement ## Related - [[Martin Fowler]] - [[Large Language Models (LLMs)]] - [[AI Agents]] - [[AI Tool Use]] - [[Graph Engineering]] - [[Loop Engineering]] - [[Context Engineering]] - [[Prompt Engineering]] - [[Mermaid]] - [[AI Verifiability]] - [[How Coding Agents Work]] - [[Agentic Engineering]] - [[Domain Specific Languages (DSLs)]] - [[Cursor Agent Swarms]]