A 100% Hallucination Free backend code-gen LLM

Community
, ,
1

Disclaimer; Before you reach for your machine guns, proclaiming me to be crazy, hear me out about how my system works.

First of all, my LLM (fine-tuned GPT-4.1-mini) doesn’t emit code, it generates ASTs, as in abstract syntax trees. It’s also a functional PL, where each individual function invocation goes indirectly through the execution layer - Which can be restricted, sandboxed, and 100% perfectly controlled deterministically, allowing the agent to be “creative in composition, not in vocabulary” - Effectively eliminating an entire axiom of security related RCE issues for obvious reasons.

However, when my LLM is told to generate code, the code is checked statically towards its internal meta data, 100% transparently (O(n) process, zero AI), a handful of milliseconds CPU time. This check occurs before the API endpoint returns the code, and if the code contains hallucinated “slots” or functions, not available to it in its current execution context, it will try again twice (1.5 to 5 seconds per invocation) up to a maximum of 3 times, increasing creativity as it goes, before it returns; “Sorry dude, I can’t do this for you!”

I realise that doesn’t eliminate all hallucinations, since these are based upon intent - But it eliminates one very specific axiom of hallucinations, which from a purely practical point of view happens to be the most frequent one - Which is “answers to capabilities in negative space”. Technically, the ability I just described 100% perfectly does just that, as in “100% coverage of negative space”, simply because hallucinated functions refuses to leave the API endpoint, to the point where it would rather accept it doesn’t know how to solve some particular task, than to return hallucinated code …

I’ve been accused of being very smart. I personally find it a little bit surprising I’m apparently the only guy on earth having played with these ideas, especially considering most of it originates from the late 1950s, and should be fairly obvious for anyone with a CS degree - But OK … :confused:

Anyways, read more here, and fork the open source code to verify my claims if you wish too …

And yes, my LLM API endpoint will never return code referencing non-existing functions - It cannot. And it’s not a probabilistic game, it’s a CANNOT! PERIOD! game …

2

And I find it extremely fascinating the post got 30 views, considering it’s the single largest LLM-related problem we’ve got in 2026 - At least according to 100% of Fortune 500 …

And I can scientifically prove my claims …

3

I think your core principle is right.

You are constraining model output with a closed vocabulary, verifier, and whitelist. That is a valid control pattern.

Where I think the opportunity is bigger is applying the same principle earlier than the DSL layer. If the control only catches invalid functions, it still leaves valid but wrong output: wrong business logic, wrong intent, wrong workflow state, wrong architecture boundary, wrong continuation.

That is the part I am focused on: not just “can the generated code reference valid functions”, but “can this step become accepted state in a controlled workflow”.

So I am not dismissing your idea. I think it is pointing at the right problem from a lower layer.

4

And I’m not dismissing your idea either, it’s probably a great idea, but it is non-deterministic, implying 100% guarantees is literally theoretically impossible - And in security, “almost 100%” is the same as “always failing”.

Your approach might have a bajillion interesting use cases, but it’s never going to be 100% secure …

Security without determinism is simply not possible, not even in theory …

5

I never actually said anything about security. You made an assumption about my system.

There was actually another fella who posted pretty much the same thing as you did a few days ago. That’s probably why no one was interested. I wouldn’t view it as something to take to heart though. Don’t worry I barely got any attention too when I posted an article.