DSLs Are the Quiet Fix for Flaky LLM Outputs

The most reliable LLM outputs are the ones the model cannot get wrong. Domain-specific languages (DSLs) enforce that constraint at the grammar level, and engineers building production LLM features are rediscovering this decades-old compiler trick as the practical answer to flaky generation. The HN thread on DSLs and LLM reliability surfaced this week with meaningful traction, and the pattern deserves a full breakdown for anyone shipping structured output features.

The pattern

A DSL here means any constrained formal language you design specifically for a task: a mini-syntax for booking calendar events, a JSON-schema-backed command language for agent actions, a restricted SQL dialect for data queries. Instead of asking the model to produce free-form text and then parsing it, you ask the model to emit only tokens that are valid in your grammar.

The key insight is that LLMs are already language models over token sequences. Constrain the allowed token set at each decoding step (via logit masking, grammar-constrained sampling, or structured generation libraries) and the model physically cannot produce malformed output.

Why now

A few things converged to make this practical in 2026:

• Grammar-constrained decoding is now a first-class feature in inference runtimes like llama.cpp, vLLM, and several hosted APIs, so you do not need to build the sampler yourself.
• Agent pipelines have raised the stakes. A single bad parse in a multi-step agent loop can cascade into a failed task or, worse, a misrouted action. The agent governance conversation happening in parallel is partly a symptom of this fragility.
• Teams that shipped naive JSON-prompt approaches back in 2024 have now accumulated enough production incident data to know that schema validation after the fact is not enough.

How it works in practice

1. Define the task vocabulary. List every valid action, field, or state the model needs to express. If you cannot enumerate it, a DSL is probably the wrong tool.
2. Write a formal grammar. EBNF or a JSON Schema with enum constraints are both valid starting points. Keep it as flat as possible: deep nesting multiplies the surface area for ambiguity.
3. Hook it into your inference layer. Libraries like Outlines or Guidance let you pass a grammar directly to the sampler. For hosted APIs, use response_format with a strict JSON schema where supported.
4. Prompt for the DSL explicitly. Tell the model what grammar it is writing in and provide one or two canonical examples in the system prompt. The grammar constraint handles correctness; the prompt handles intent.
5. Keep a human-readable alias. Your DSL tokens should map cleanly to concepts a reviewer can audit. Cryptic shorthand saves tokens but makes debugging painful.

The trade-off

The honest caveat: DSLs front-load complexity. Designing a grammar that is expressive enough to cover real tasks but constrained enough to be useful is non-trivial. Common failure modes:

• The grammar is too loose and you are back to parsing prose.
• The grammar is too tight and the model cannot express valid edge cases, so it hallucinates the closest legal token instead of flagging uncertainty.
• The DSL becomes a maintenance burden as task requirements evolve, because every new capability requires a grammar update.

For open-ended generation tasks, creative writing, or anything where the output space is genuinely unbounded, DSLs are the wrong abstraction. They shine on closed-world problems: tool-calling, workflow orchestration, form filling, code generation in a subset language.

The agent fault attribution work also points to a downstream benefit worth noting: when agent actions are expressed in a DSL, the audit trail is structured by default, which makes incident reconstruction significantly easier.

Where it goes next

The logical endpoint is task-specific micro-languages that ship alongside models as first-class artifacts, similar to how SQL dialects ship with databases. As forward-deployed AI engineering becomes its own discipline, DSL design will likely become a core skill alongside prompt engineering, not a niche compiler theory curiosity.

The teams winning on reliability right now are not prompting harder. They are shrinking the space of possible outputs until correctness is nearly guaranteed.

If your LLM feature has a well-defined output schema, a DSL with grammar-constrained decoding is the highest-leverage reliability investment you can make today.