Determinism explained

The problem with classic generators

When an AI writes an application's code directly, every fix is a fresh rewrite. Asking for a small change can break something else elsewhere, without warning. That's the source of “fix loops”: you fix, it breaks, you fix again.

Maker's approach: app = builders(specification)

At Maker, the AI does not write the application's backbone. It designs a specification: the list of entities, the business rules, the KPIs. Then deterministic builders: programs, not an AI, turn that specification into a database, API routes, forms and navigation.

“Deterministic” means: the same specification always produces the same backbone. There's no improvisation there, and no hallucinated code.

Some screen blocks, however, really are written by a model: the dashboard, the list summary zones, the sample data, and the signature views at Masterpiece level. They are delimited, their call count is fixed in advance, and they must pass compilation and runtime validation — otherwise they're replaced by their deterministic version. That's the difference between handing a model one part under supervision and handing it the whole application.

The flow, step by step

• Your prompt, in natural language.
• The specification: designed by the AI (entities, rules, KPIs).
• The backbone — database, API routes, forms, navigation — written by deterministic builders from the specification.
• The screen blocks handed to a model, validated by compilation then at runtime before being kept.

What it changes for you

Adjusting your application means adjusting the specification, then letting the builders rebuild. Behaviour stays predictable: no surprise regression, no fix loop billed on every try. You iterate with confidence.

Is this the same as manual no-code (Bubble, WeWeb, Retool)?

No. On Bubble, WeWeb or Retool, no AI builds the application: you configure every screen and rule yourself in a visual editor. It's deterministic because a human defined everything explicitly, not because an AI was tamed.

At Maker, an AI does build the application from a prompt. Determinism doesn't come from the absence of AI — it comes from the AI not writing the backbone. It designs a specification, and a program (not an AI) turns that into a database, routes and screens.

Is this the same as a better-constrained AI agent (Claude Code, OpenAI Codex, Devin, Cursor Agent)?

No again, and the nuance matters. These agents are still language models that write code line by line — even surrounded by strict templates, automated tests and fix loops, an LLM remains by construction capable of producing a different result from one run to the next. You can reduce the randomness, never eliminate it at that step.

At Maker, the LLM doesn't write the application line by line. It designs the specification, and deterministic builders produce the backbone from it — the same AppSpec always produces exactly the same backbone, with no possible variation. The model passes that remain cover delimited screen blocks, with a fixed call count, backed by a compiler and runtime validation. It's not a better-disciplined agent: it's an architecture where the structure escapes randomness entirely, and what's left to the model is bounded and checked.

What academic research says

This architecture isn't unique to Maker: the specification/code split is an active research direction (“correctness-by-construction”), and the non-determinism of classic generators is a fact measured in peer-reviewed journals. All the sources — and a three-article series walking the argument — live on the dedicated research page, so this page stays what it is: the explanation of how it works.

• Research on determinism — sources and article series →