Deterministic Code Generators (LLM-Authored)

A technique for bounding LLM non-determinism in software delivery — instead of letting the LLM write application code directly and repeatedly, have it write (once) a deterministic generator/interpreter for a stable domain-specific model, so all actual code output is produced consistently by the generator rather than regenerated stochastically by the model each time.

Also known as: code generator pattern, generator/interpreter pattern, DSL-driven code generation, never write code directly, domain-specific language generator

Documents (3)

• Presentation: Decision Models in Agentic Architectures: From Production to Agent Skills Alex Porcelli · 2026-09-14 Reader 🖥️
  High-stakes decisions inside agentic AI systems need a deterministic, auditable decision-model layer (DMN, executed by a rule engine like Drools) sitting beneath the non-deterministic LLM and exposed to it as a skill or guardrail — generated from and owned by business domain experts rather than engineers — because what enterprise AI actually lacks is not mere consistency but full accountability: reproducibility, explainability, and governance together.
• Software Teaming in the Age of AI with James Herr and Woody Zuill Mob Mentality Show · 2026-07-07 Reader 🖥️
  As AI takes over more of the actual typing, ensemble/mob programming becomes MORE important, not less — because code was never the real bottleneck (queueing on requirements and stakeholder availability always was, and AI's speed just exposes that more starkly), and because AI removes typing-speed as the reason non-coders couldn't stay in the room. The core discipline mob programming already trains — communicating high-level intent instead of dictating each low-level step — turns out to be the same skill effective AI-agent direction requires, so learning to team well and learning to direct agents well are converging into one discipline. But this potential is bounded by real, concretely observed LLM reliability limits (non-determinism, context forgetting, and test-hardcoding instead of genuine rule implementation) that demand deliberate engineering countermeasures — deterministic code generators, unit tests reframed as guardrails rather than TDD-as-design, and small on-demand skills files instead of one long instructions file — not blind trust in AI capability claims.
• How AI will change software engineering – with Martin Fowler The Pragmatic Engineer · 2025-11-19 source ↗ Reader 🖥️
  AI's defining change to software engineering is not primarily a jump in abstraction level but a shift from deterministic to non-deterministic systems — and the disciplines that make software durable and legible to teams over time (small reviewable steps, tests, refactoring, shared vocabulary, mentorship) matter more, not less, as a result, even as the field has not yet worked out how teams — as opposed to individuals — should operate with AI.

Open gaps (4)

• incompleteThe talk concedes that AI-assisted model authoring (spreadsheet to DMN) is not itself deterministic, but never specifies what review, testing, or sign-off process governs that generation step before a model is published and trusted to execute deterministically thereafter — leaving a gap in the very accountability chain the talk claims to close end-to-end.
  Presentation: Decision Models in Agentic Architectures: From Production to Agent Skills — read next: Look for engineering treatments of governance over AI-assisted model/spec generation itself, not just over the artifact's runtime execution — e.g., how teams review and test an LLM-authored deterministic generator before trusting its output.
• uninformedFowler attributes the current software-industry downturn and job losses primarily to the end of zero-interest-rate financing rather than AI, but does not engage with the counter-evidence elsewhere in the discourse that some of the layoff wave is genuine AI-driven restructuring (not merely macroeconomic or a cover story) — he states his view confidently without weighing the split causation other commentators report.
  How AI will change software engineering – with Martin Fowler — read next: Compare against corpus accounts that split the layoff wave into AI-washing/cover-story and genuinely AI-driven restructuring components.
• uninformedThe author frames the specs-vs-code and 'throw away code and regenerate' debate as unresolved and untested, without engaging James Herr's already-reported deterministic-generator technique (have the LLM write a DSL/generator once, then produce all code thereafter deterministically from that generator) described in a separate retreat-adjacent conversation — a concrete existing answer to exactly the determinism/cost worry the author raises about full-code regeneration.
  Software Design in the Agentic Age: Placing Your Bets — read next: Read extract-software-teaming-age-of-ai-zuill-herr#p13 (and the corpus's deterministic-code-generators concept) and ask whether that pattern resolves, or only partially resolves, the regeneration-cost/determinism concern raised here.
• incompleteJames's deterministic-generator mitigation (LLM writes a DSL interpreter once; all subsequent code is produced deterministically) is never applied to or tested against Woody's concrete counterexample (an LLM hardcoding outputs across a ~1,296-variant rule engine instead of generalizing). It's left unclear whether the generator pattern would have solved Woody's failing case, or whether it only works for domains that are naturally table/DSL-shaped (like device control) rather than combinatorial business-rule logic.
  Software Teaming in the Age of AI with James Herr and Woody Zuill — read next: Apply James's DSL/generator pattern directly to Woody's rule-engine example and see whether it resolves the hardcoding failure, or find other reports of the generator pattern applied to combinatorial (not device-control) business logic.