In 2023 I wrote a note to myself that formal languages were the bridge between programming and intelligent systems. I was speculating. Three years on, the pattern is showing up in real production systems, and the speculation deserves a more careful defense.
Here's the argument, cleaner than I could state it then:
LLMs are excellent at generating natural language and code. They are terrible at guaranteeing anything about what they generate. This is a structural property, not a temporary limitation. A probabilistic model cannot make deterministic promises.
Formal languages are the opposite. A well-defined grammar has validated syntax, deterministic parsing, provable properties. It can guarantee what it accepts. It cannot generate creatively.
Combine them and the properties align. The LLM proposes. The formal grammar disposes. The pattern:
- A DSL captures the rules of the domain, including its constraints, its vocabulary, its structural laws
- The LLM proposes candidate solutions in that DSL
- The compiler rejects malformed proposals before they touch anything downstream
- Only valid proposals reach production
This is not theoretical. It's what durable AI-assisted systems actually look like when you strip away the marketing. Not "trust the model" and not "avoid the model", but "let the model propose, let the grammar dispose".
The interesting corollary is that DSLs are now a strategic asset in a way they weren't ten years ago. A well-designed domain-specific language is the interface between an unreliable generator and a system that needs guarantees. If you have one, you can absorb model improvements as they come. If you don't, every improvement to the underlying model requires re-engineering the guardrails.
For anyone building domain-specific AI products right now, the highest-leverage engineering investment isn't better prompts or fancier retrieval. It's a real DSL that expresses the domain's rules in a form the compiler can enforce.
Formal languages were always the bridge. It just took the current era of AI to make the bridge load-bearing.
Drafted in January 2023
Updated for site in 2026