Bryce Darling

Yeah, the code review loop is what's worked for me. What are you using to review the fixes in your own setup: /review, by hand, or something else? Curious what's working for you.

What a great question. It sent me back into the code to verify the whole path. Severity is locked into the rule, so the agent can't demote a blocking finding just to finish. It can propose a suppression, but now it can't approve its own exception. I verified that for both blocking severity levels. The useful rule I added is that the agent whose work is being gated can't also be the final authority on whether the suppression gate applies. You improved the system. Thank you, Kartik

Append-only in normal operation, yes. Immutable against an agent with the same shell access, no. That distinction is why I didn’t make the log the completion authority. The history records which transition the harness accepted. It can't tell me whether the work earned "done," so the guard now treats completed as a claim. A separate read-only reviewer checks the original task against the current repository state and issues a certificate bound to both. Redefine the task, change the artifact, replay stale evidence, or delete an uncertified task, and the gate blocks. The pattern I landed on is append-only event history plus independent certification of the work.

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 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?

Agreed on where this needs to go. The layer I keep hitting is one step down: the test files/functions exist but don't verify behavior at all or well enough. Mocks that check wiring not logic, stubs with zero assertions, that kind of thing. Verification of a green suite where the requirement was never actually checked basically. That foundation has to be solid before requirements level validation means anything, and I don't think we've even solved that yet.

Thanks. Reliable, to me, starts with not letting the same model review its own code. A model checking its own work tends to give itself a pass. Different models from different labs help: different training, different blind spots, they catch what each other misses. Same-model review alone isn't enough. And neither is skipping the deterministic checks layer.

Exactly, and I'd push it one step further: the tests are the easier part to automate, the contract is the hard part. An agent writes passing tests against an incomplete spec just as confidently as it writes code that compiles. Nothing makes it cover invalidation or eviction unless the contract already names them. I lean on rules and hooks to enforce TDD and gate commits on test coverage, but coverage of the wrong contract still passes clean. How do you keep the contract itself airtight before the agent starts writing the tests?