Comment by Mayank Bansal on "The most dangerous AI-generated code looks finished"

Great write-up. I completely agree that deterministic validation belongs outside the model. We've been exploring something similar with Failproof AI, but focused on runtime behavior after the code leaves the editor—things like false completion, low-progress loops, and execution policy checks. Feels like deterministic code review and runtime validation solve complementary parts of the same reliability problemv

That sounds cool, I'm genuinely curious. False completion, sycophancy, and such are the exact things that keep me up at night haha. I think some mix of static analysis, guardrails, reflexion loops, and a little more could get us there. We will see. I'm working on some of the same stuff on my side, not public yet, but the overlap is real. What have you found works for you in your setup?

Lmao, I know the feeling. We've gradually moved away from "LLM checks another LLM" and toward deterministic runtime checks for anything that matters. Completion validation, execution policies, and progress checks have been much more reliable in our experience. Checkout our Failproof AI repo, love to hear feedback from you. Mark star also if it's helpful to you ;)

Already starred it. The move from LLM reviewing LLM to deterministic runtime checks is exactly the right call. I came to the same conclusion on my side. Going to give it a real run in Claude this week. How do you handle false positives on the checks?

That's been one of the biggest design goals for us. We treat false positives as bugs in the rule, not something the user should just live with. The rules are deterministic, so if a check fires incorrectly, it'll do it consistently, which makes it much easier to reproduce, debug, and either improve the rule or add a narrowly scoped exception. I'd much rather have a predictable false positive than an LLM making a different judgment every run.

Search Hashnode