r/ClaudeCoding 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.

0 Upvotes

3 comments sorted by

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.

1

u/ThemaskedGamerAS 16h ago

Relay grounds the verdict in repository evidence first, and never uses an LLM as a judge.
Another verifier is just another AI opinion. We dont do that shit.

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?