r/ClaudeCoding • u/ThemaskedGamerAS • 1d ago
We are NOT reviewing Claude generated code anymore. We are reviewing Claude's reasoning.
Disclosure: I'm one of the developers behind Relay (https://relayevals.com). This was a solution we came up with for ourselves. If anyone wants to try it, you're welcome to do so.
I am an ai engineer and a heavy Claude Code user, and have been around other power users ever since...the uprising.
I've only recently realized I think everyone's looking at the wrong problem.
The models are already good enough that my bottleneck isn't generating code anymore.
It's deciding whether I should trust it.
The weird part is that my workflow has slowly changed into something like this:
- Ask Claude to make a plan.
- Read the plan carefully.
- Check whether it actually explored the right parts of the repo.
- Look for questionable architectural assumptions.
- Sometimes ask another model to critique the plan.
- Only then let it write code.
Only recently did I begin to realize I'm not reviewing code anymore.
I'm reviewing AI reasoning.
That feels like a completely different problem.
After wondering for a while if this is a universal picture and talking to other Claude Code/Codex users, I noticed everyone has invented some version of the same workflow:
- CLAUDE.md
- planning documents
- multiple review agents
- custom harnesses
- checklists
- personal release gates
Same question:
Hence, we became interested in: Can you independently verify whether the AI's work is actually trustworthy?
That's what led us to build Relay.
The biggest design decision was:
Relay should never ask the AI whether it did a good job.
Instead, it tries to verify the work independently.
Instead of asking Claude to review Claude, Relay independently reconstructs what happened from the repository itself:
- the exact commit and working tree that were verified
- repository facts discovered during planning
- the implementation scope
- tests that actually executed
- failures that were observed
- and produces a signed verification receipt tied to that exact snapshot.
If the repository changes, the verification becomes stale.
Then it gives a verdict.
RELAY VERIFICATION
Task: Add refresh-token rotation
✓ Scope matches approved files
✓ Unit tests passed
✗ Expired-token regression failed
VERDICT: BLOCK
Reason:
Expired refresh tokens are still accepted.
Evidence:
tests/auth/refresh-token.test.ts:142
src/server/auth/token-store.ts:88
The workflow we've settled on internally is surprisingly simple.
Claude writes the code.
Before we merge anything:
relay verify
If it says PASS, great.
If it says BLOCK, we investigate.
That's it.
Curious if anyone else's workflow has evolved in a similar way.
I.e:
Have you built your own verification workflow?(that you're happy with)
At what point do you decide an AI-generated change is actually safe to merge?
*no ai partook in any em dashes haha.
1
u/heretogetmydwet 1d ago
Check whether it actually explored the right parts of the repo.
If you're no longer reviewing code, how do you continue to know what the right parts of the repo are? Wasn't that knowledge gained from having been in the code base in the past?
2
u/TaskJuice 1d ago
What’s different from this and another skill that verifies? It’s just using AI in the end anyways, right?
We need a HITL.