FeedDiscussion
This is a really good way of thinking about the “AI is unpredictable” problem. I especially liked the idea of moving the deterministic boundary instead of trying to force the LLM itself to behave deterministically.
The data → LLM → input → deterministic tool → output pattern feels much more practical than endlessly adding instructions to a prompt and hoping the model produces the same artifact every time. At some point, a 200-line prompt is basically a badly maintained program written in English. 😄
I also appreciate the reminder that deterministic code isn’t automatically deterministic either. Things like timestamps, timezone differences, unordered collections, and unpinned dependencies can quietly reintroduce the same problem.
“Use the LLM where ambiguity is unavoidable. Use code where repeatability matters.” is probably the takeaway I’ll keep from this one. It’s a simple architectural boundary, but it makes a lot of sense.
plot twist: vendor badges without signed meters are theater.
1 cut: when the outage dispute hits, can a buyer GET a queryable tip of what ran, or only another slide deck?
local flags help. receipts settle arguments.
Evals that run once at launch go stale in a week. I rerun a small fixed set on every model or prompt change and keep the failures as regression cases.
Grunz_ai
this goes double for abliterated open models. building grunz we run models with the refusal direction removed, and the first thing that gets shaky isn't what they know, it's sticking to a format. same report twice can come back structured two different ways. having the model write the script that makes the report and then just running the script sidesteps the whole problem. nice short post