A minimalist DSL to enforce deterministic code generation with LLMs

Hi everyone,

When integrating LLMs into production pipelines, we often face stochastic issues: hallucinations, architectural over-engineering, and a lack of reproducibility. Instead of stacking layers of fragile prompt engineering, I approached this from a language design perspective: constraining the expression space to enforce determinism.

I designed IPL (Intent Programming Language) with a pragmatic goal: making software generation reliable while drastically cutting development costs and cycles.

To build this minimalist DSL, I leveraged an LLM to help identify and structure a universal, irreducible core vocabulary designed to serve as a deterministic bridge between human intent and executable code.

Minimal Grammar: A strictly reduced syntax with core action primitives and standardized types. The structure is lightweight enough that any basic or local LLM can translate natural language into an .ipl

file zero-shot.

Separation of Concerns: Business logic is isolated in a human-readable, auditable intermediate artifact, completely decoupled from the target tech stack.

Multi-File & Heterogeneous Stacks: Multi-file .ipl

support allows orchestrating complex architectures mixing different backend and frontend layers.

Constrained Transpilation: By locking the lexical scope, the LLM cannot hallucinate exotic architectures. It acts purely as a reliable transpilation engine.

Natural Language Intent:

“If the order exceeds 100 €, apply a 10% discount and notify the customer.”

Intermediary Intent Contract ( .ipl):

(Generated by a basic LLM or written manually)

read order.total as number
if order.total > 100:
    compute discount = order.total * 0.10
    send notification to order.customer_id

Target Code Generation:

From this validated contract, the model transpiles deterministic, idiomatic code across various targets — backend (Rust, Go, Java, Python), frontend/integration (** JavaScript, TypeScript, HTML**), or hybrid stacks.

The repository includes the specification, parser logic, and the Studio IDE interface:

I would love to hear your thoughts, feedback, or critiques on this constraint-first approach to LLM-driven development!