Show HN: Stage – Putting humans back in control of code review

How do you handle the problem of AI misleading by design? For example, Claude already lies on a regular basis specifically (and quite convincingly) in this case, in attempts to convince that what is actually broken isn't such a big deal after all or similar.

How can this product possibly improve the status quo of AI constantly, without end, trying to 'squeak things by' during any and all human and automated review processes? That is, you are giving the AI which already cheats like hell a massive finger on the scale to cheat harder. How does this not immediately make all related problems worse?

The bulk of difficulty in reviewing AI outputs is escaping the framing they never stop trying to apply. It's never just some code. It's always some code that is 'supposed to look like something', alongside a ton of convincing prose promising that it _really_ does do that thing and a bunch of reasons why checking the specific things that would tell you it doesn't isn't something you should do (hiding evidence, etc).

99% of the problem is that the AI already has too much control over presentation when it is motivated about the result of eval. How does giving AI more tools to frame things in a narrative form of its choice and telling you what to look at help? I'm at a loss.

The quantity of code has never been a problem. Or prose. It's that all of it is engineered to mislead / hide things in ways that require a ton of effort to detect. You can't trust it and there's no equivalent of a social cost of 'being caught bullshitting' like you have with real human coworkers. This product seems like it takes that problem and turns the dial to 11.

Thanks for sharing this, I do agree with a lot of what you said especially around trust around what its actually telling you

For me, I only run into problems of an agent misleading/lying to me when working on a large feature, where the agent has strong incentive to lie and pretend like the work is done. However, there doesn't seem to be this same incentive for a completely separate agent that is just generating a narrative of a pull request. Would love to hear what you think

So, when I code review, I have a super simple Cursor command that "orients" me in the PR:

* where does the change sit from a user perspective?

* what are the bookends of the scope?

* how big is the PR?

* etc.

Once I'm "in" and understand what it does, I pepper the AI with questions:

* Why did the author do this?

* I dont understand this?

* This looks funky, can you have a look?

* etc.

The more questions I ask, the more the AI will (essentially) go "oh, I didn't think of that, in fact, looks like the issue was way more serious than I first thought, let me investigate". The more I ask, the more issues AI finds, the more issues AI finds, the more issues I find. There's no shortcuts to quality control -- the human drives the process, AI is merely (and I hate to use this term but I will) a...force multiplier.

(i find)the right way to read a PR can differ a lot from project to project. it's not just about context, or syntax, or workflow...

sometimes the best entry point is the PR description or an external ticket. sometimes you need to read the code first to understand the reasoning behind the changes. sometimes the diff itself is fine, but you have to go back several PRs to see how the codebase got into its current state.

i guess like everyone said here, there no right way to do it.

but i enjoy the video and the project, kudos ;)

But how do you know they’re not lying to you? What are your benchmarks for this? Experience? Anecdote? Data?

And I’m asking you in good faith - not trying to argue.

I’m thinking about these types of questions on a daily basis, and I love to see others thinking about them too.