The model proposes, deterministic code disposes
Why I treat large language models as a proposal engine and never as the final authority, and how that one rule shapes every app I ship.
There is one sentence behind almost everything I build right now: the model proposes, deterministic code disposes. It sounds like a slogan. It is actually an architecture.
A large language model is very good at one thing and very bad at another. It is good at reading messy input and proposing structure: here is the gist, here is a draft, here is a label that probably fits. It is bad at guaranteeing that the structure is correct. Ask it the same question twice and you can get two different answers. For a chat toy that is fine. For a product a parent or a teacher relies on, it is not.
So I draw a hard line. The model is allowed to read and to propose. It is never allowed to be the last word on anything that has to be true.
What that looks like in code
Take Marina Method, an AI study guide pipeline. A model reads a source text and proposes a Bloom level for each question (Bloom’s taxonomy is the standard ladder from “remember” up to “create”). That proposal then hits plain Python: a classifier with explicit rules, a citation check that confirms every claim traces back to the source, and a router that decides which mode the question belongs to. None of those steps can hallucinate, because none of them are a model. They are code, and code does the same thing every time.
The proof that this matters is the test suite. Marina Method has 188 automated tests. They do not test the model. They test the deterministic layer that sits between the model and the user, the part that is allowed to say no.
Why I keep the human in the loop too
The same instinct applies to how I work, not just what I ship. I pair tightly with AI agents, but every architectural decision is mine, every change runs through Google standard code review, and every change is tracked to a ticket. The agent proposes. A person disposes.
This is not AI skepticism. I build with these models every day and they make me faster across the whole stack. It is just a refusal to confuse fluent with correct. The fluency is the model’s job. The correctness is mine, and it lives in code I can read, test, and trust.