Your LLM Needs a Language, Not Another Prompt (2026)

The model should propose the plan. Your system should own the language.

The next reliability upgrade for an LLM feature may be a language designer, not a larger model.

When a user request must become a workflow, query, configuration, or simulation, asking a model to emit unrestricted Python or JSON makes your product contract a token-prediction problem. A more durable pattern is emerging: let the model express intent in a narrow domain-specific language (DSL) or typed intermediate representation, then let deterministic software validate, compile, and execute it.

The PM translation is simple: move the model from writing the system to selecting what the system is allowed to do.

What changed

A July 14 essay by Unmesh Joshi on Martin Fowler’s site gives the pattern a useful product shape. A DSL is a constrained vocabulary for one domain, such as SQL for data queries or Kubernetes YAML for infrastructure. Joshi argues that the LLM has two different jobs: help the team discover the domain abstractions, then become a natural-language interface to the small language once it exists. In his Tickloom examples, the DSL’s compiler catches invalid distributed-system scenarios and returns domain-level errors instead of opaque runtime failures. 1

The research signal is more specific than a general recommendation to use schemas.

Design the language for the model. The Anka preprint tested a data-transformation DSL with canonical operations, explicit intermediate names, named steps, and verbose keywords. With zero prior training exposure to Anka, Claude 3.5 Haiku reached 99.9% parse success and 95.8% overall task accuracy across 100 benchmark problems. On multi-step tasks, Anka scored 100% versus 60% for Python. GPT-4o-mini showed the same direction, with 86.7% versus 60%. These are promising preprint results from one domain and two models, not evidence that a new DSL will outperform Python everywhere. 2
Compile a plan instead of accepting generated code. PlanCompiler, an April 2026 preprint, restricts the model to choosing nodes from a fixed registry and supplying typed parameters. A deterministic validator checks node existence, edge validity, type compatibility, cycles, orphans, arity, and required parameters before compilation. In its 300-task evaluation, it reports 278 first-pass successes, compared with 202 for GPT-4.1 and 187 for Claude Sonnet. The compiler’s reported total inference cost was $0.3562, versus $2.1396 and $18.3907 for those baselines. The scope is narrow: ordered, single-stream data workflows, without true branching, fan-in, repeated nodes, open-domain tools, or automatic repair. 3
Treat syntax as the first gate, not the finish line. A June 2026 study across software-engineering structured-output tasks found that grammar-constrained decoding, regex checks, and strict templates reduce syntax failures. Its TTMG control nearly eliminates syntax errors, but structural and value errors remain. A valid shape can still contain missing fields, wrong arguments, or a semantically incorrect API call. 4

The implementation vocabulary is already familiar to developers. A Gradient Flow discussion of BAML describes prompts as functions with defined inputs and outputs, with schema-aligned parsing, testing, and cross-language use. It is an accessible explainer, not adoption evidence. 5 A practitioner signal points in the same direction: Carlos E. Perez wrote that dense model outputs are a reason to construct a domain-specific language and constrain the model to that domain. 6

Why PMs should care

1. The product contract moves upstream.

In a prompt-first system, the prompt, examples, parser, tool definitions, and retry logic collectively describe the product. They drift easily. In a language-first system, the durable artifact is the domain contract: the allowed operations, types, state transitions, and invariants. The prompt becomes an interface to that contract rather than the contract itself. That makes the feature easier to review, version, and migrate across model providers. 1

2. Reliability becomes measurable at multiple layers.

A single “agent success rate” hides where the system fails. A compiled contract lets you separate parse validity, type and dependency validity, execution success, and domain correctness. That gives the team a better upgrade question: did the new model improve reasoning, or did it merely produce fewer malformed strings? The structured-output study’s syntax-versus-value distinction is the reason to keep these metrics separate. 4

3. The tradeoff is front-loaded design work.

DSLs are not a free reliability layer. They need a semantic model, a parser or schema, validators, error messages, tests, and a registry that stays current. Low-resource languages can also be harder for models to generate than Python, especially when the prompt must carry both a domain model and a constraint language. 7 The pattern pays off when the workflow is repeated, the operation set is stable, and failures are expensive enough to justify owning the contract.

A practical decision rule:

Workflow shape	Recommended model boundary	Primary launch metric
Open-ended research or drafting	Natural-language output with review	Human usefulness and factual accuracy
Repeated 3+ step workflow with stable operations	Typed plan or small DSL, then deterministic execution	Domain-correct success per request
High-risk action with irreversible side effects	Typed plan, independent validator, approval gate	Unsafe-action rate and reviewer burden

How to implement now

Choose one narrow workflow. Start with a high-volume path that has repeated steps and a stable operation vocabulary: invoice triage, catalog updates, support-ticket routing, or a controlled data transformation. Do not start with a general-purpose “agent platform.”
Write the contract before the prompt. Define the smallest set of operations, explicit input and output types, required fields, allowed transitions, and domain invariants. Prefer one canonical form per operation and explicit names for intermediate state. A model should have fewer valid ways to express the same intent, not more.
Make the model emit a plan, not executable code. The output should select registered operations and provide parameters. Keep compilation, credentials, retries, network access, and side effects outside the model’s authority. The validator should be able to reject an invalid plan before any action runs.
Add semantic checks that syntax cannot provide. Parse the output, validate types and dependencies, then run domain-specific checks and a dry run where possible. A well-formed request to refund the wrong customer is still a product failure.
Measure the boundary. Build a representative task set and compare the current prompt-and-tools baseline with the typed-plan version. Track parse success, validation rejection, domain correctness, latency, cost per successful task, retry rate, and human review time. Segment results by workflow depth. The Anka result suggests that constraints matter most as sequential state management gets harder, but your own distribution should decide the rollout threshold. 2
Keep repair bounded. Feed validator errors back to the model for a small number of repair attempts, then stop and route the case to a human or a safe fallback. Log every rejection by category. The goal is not to hide failures behind retries; it is to learn which part of the contract is underspecified.

The PM action this week is to pick one repeated workflow, inventory its real operations and failure modes, and prototype a typed plan registry beside the existing implementation. Run both systems on the same task set. If the error profile shifts from malformed output to visible, testable domain mistakes, the architecture has moved the problem into a boundary your product team can actually own.

Your LLM Needs a Language, Not Another Prompt

The model should propose the plan. Your system should own the language.

What changed

Why PMs should care

How to implement now

참고 출처

관련 콘텐츠