HN Explorer

Show HN: Stage – Putting humans back in control of code review (stagereview.app)

130 points by cpan22 ↗ HN
Hey HN! We're Charles and Dean, and we're building Stage: a code review tool that guides you through reading a PR step by step, instead of piecing together a giant diff.

Here's a demo video: https://www.tella.tv/video/stage-demo-1pph. You can play around with some example PRs here: https://stagereview.app/explore.

Teams are moving faster than ever with AI these days, but more and more engineers are merging changes that they don't really understand. The bottleneck isn't writing code anymore, it's reviewing it.

We're two engineers who got frustrated with GitHub's UI for code review. As coding agents took off, we saw our PR backlog pile up faster than we could handle. Not only that, the PRs themselves were getting larger and harder to understand, and we found ourselves spending most of our time trying to build a mental model of what a PR was actually doing.

We built Stage to make reviewing a PR feel more like reading chapters of a book, not an unorganized set of paragraphs. We use it every day now, not just to review each other's code but also our own, and at this point we can't really imagine going back to the old GitHub UI.

What Stage does: when a PR is opened, Stage groups the changes into small, logical "chapters". These chapters get ordered in the way that makes most sense to read. For each chapter, Stage tells you what changed and specific things to double check. Once you review all the chapters, you're done reviewing the PR.

You can sign in to Stage with your GitHub account and everything is synced seamlessly (commenting, approving etc.) so it fits into the workflows you're already used to.

What we're not building: a code review bot like CodeRabbit or Greptile. These tools are great for catching bugs (and we use them ourselves!) but at the end of the day humans are responsible for what gets shipped. It's clear that reviewing code hasn't scaled the same way that writing did, and they (we!) need better tooling to keep up with the onslaught of AI generated code, which is only going to grow.

We've had a lot of fun building this and are excited to take it further. If you're like us and are also tired of using GitHub for reviewing PRs, we'd love for you to try it out and tell us what you think!

45 comments

[ 3.6 ms ] story [ 65.8 ms ] thread
[deleted]
(comment deleted)
ryanjso
I like the chapters thing, a lot of PRs I review should really be like 5 prs so its nice to have it auto split like that.

Do you see a world where it splits them up on the git level?

tasuki
> a lot of PRs I review should really be like 5 prs

Can't you push back on that? I feel like this tool is trying to fix misbehaved colleagues...

gracealwan
Totally different part of the reviewing experience, but I would love to see PR comments (or any revisions really) be automatically synced back to the context coding agents have about a codebase or engineer. There’s no reason nowadays for an engineer or a team of engineers to make the same code quality mistake twice. We manually maintain our agents.md with codebase conventions, etc, but it’d be great not to have to do that.
t0mas88
I've been working on that as a small open source tool: https://github.com/smithy-ai/smithy-ai

It keeps a repository with markdown files as the agent context, makes those available (via a simple search and summarise MCP) and when closing a merge request it checks whether the context needs updating based on the review comments. If it needs updating a PR is opened on the context repository with suggested changes/additions.

sscarduzio
We have the same problem, and I came up with this:

https://sscarduzio.github.io/pr-war-stories/

Basically it’s distilling knowledge from pr reviews back into Bugbot fine tuning and CLAUDE.md

So the automatic review catches more, and code assistant produces more aligned code.

sebakubisz
Can reviewers adjust the chapter splits manually if they disagree with how it grouped the PR, or are the chapters fixed once generated?
electrum
Does Stage work for PRs that have multiple commits? These could be considered "stacked diffs", but in the same PR.
whywhywhywhy
The idea of a workplace where people can’t be bothered to read what the ai is coding but someone else is expected to read and understand if it’s good or slop just doesn’t really add up.

I personally see the value of code review but I promise you the most vocal vibe coders I work with don’t at all and really it feels like something that could be just automated to even me.

The age of someone gatekeeping the codebase and pushing their personal coding style foibles on the rest of the team via reviews doesn’t feels like something that will exist anymore if your ceo is big on vibe coding.

tasuki
> Stage automatically analyzes the diff, clusters related changes, and generates chapters.

Isn't that what commits are for? I see no reason for adding this as an after-thought. If the committers (whether human or LLM) are well-behaved, this info is already available in the PR.

phyzix5761
This is a really cool idea but where's the moat? What's stopping someone from replicating the functionality?
embedding-shape
It's an interesting idea, but I feel like it's missing almost the most important thing; the context of the change itself. When I review a change, it's almost never just about the actual code changes, but reviewing it in the context of what was initially asked, and how it relates to that.

Your solution here seems to exclusively surface "what" changes, but it's impossible for me to know if it's right or not, unless I also see the "how" first and/or together with the change itself. So the same problem remains, except instead of reviewing in git/GitHub/gerrit + figure out the documents/resources that lays out the task itself, I still have to switch and confirm things between the two.

dbbk
Well if you prompted the PR you know the context
JulienZammit
Related question, does the chapter view help for security review? Code review catches "is this well written", but security review is more like "did the author forget the auth check on this new endpoint, or remove a tenant filter by accident". Those aren't really visible as a chapter since the problem is what's not in the diff. Curious if the authors have thought about that use case or if it's a separate tool entirely.
kylestlb
I assume Gitlab/Github will add these sort of features to their products within the next few months
tfrancisl
Why is this a service and not an open source project? It doesn't seem to do much other than organize your commits within a PR (could be run once on a dev machine and shipped in the code, then displayed separately) and builds a dashboard for PRs that's not too far off from what github already offers, but could also be represented with fairly small structured data and displayed separately.
namanyayg
Looks amazing. I've been trying different stacking PR tools and Graphite and this looks to be the most human-centric so far. I'll have a shot at using this within our team soon. Congrats on the launch!
SkyPuncher
Hmm. All of the examples simply describe what the code is doing. I need a tool that explains the intent and context behind a change.
malcolmgreaves
Y’all are a bit nuts if you want 50% more per month than Claude Pro for this.
jFriedensreich
Looks kind of neat like devon.ai review / reviewstack crossover. But as i tell every of the dozens projects trying to make a commercial review tool: i would rather spend a week vibe copying this than onboarding a tool i have to pay for and am at the mercy of whoever made it. Its just over for selling saas tools like this. For agents i also need this local not on someones cloud. Its just a matter of time until someone does it.
Planktonne
> more and more engineers are merging changes that they don't really understand

You cannot solve this problem by adding more AI on top. If lack of understanding is the problem, moving people even further away will only worsen the situation.

lisayang888
Really like this idea. But at what point do you think its valuable to have this chapters breakdown versus splitting things up into multiple PRs?
superfrank
Maybe I'm missing something obvious, but if I was going to have my team use this, I'd want someone to answer the following question

If AI is good enough to explain what the change is and call out what to focus on in the review, then why isn't AI good enough to just do the review itself?

I understand that the goal of this is to ensure there's still a human in the review cycle, but the problem I see is that suggestions will quickly turn into todo lists. Devs will read the summary, look at the what to review section, and stop reviewing code outside of things called out in the what to focus on section. If that's true, it means customers need to be able to trust that the AI has enough context to generate accurate summaries and suggestions. If the AI is able to generate accurate summaries and suggestions, then why can't we trust it to just do the review itself?

I'm not saying that to shit on the product, because I do get the logic behind it, but I think that's a question you should have a prepared answer for since I feel like I can't be the only one thinking that.

baldai
I was actually recently thinking about similar idea. I am someone who started coding post LLMs and have basic technical understanding. I know what loops, variables, API, backend bla bla is. I learned bunch more since then but I am not capable of making decisions based on git diff alone. And I want to. I want to because I think increasing my skills is still super important, even in AI era. The models are getting better, but are still limited by their core design -- for now it does not seem like they will replace humans.

So getting assistance in the review, in making the decisions and giving me more clarity feels interesting.

Maybe its people like me, who became involved into coding after the LLMs who might be your niche.

One thing I dont understand, the UI/UX? Is this visible only on git itself? Or can I get it working in Codex?

high_priest
No pricing page, you've lost my interest. Doesn't matter that there is an obscured quote on the front page. Be up front about the costs.
te_chris
I’ve built this into a cli TUI. Passes the whole diff to Claude code with a schema and gets a structured narrative back out. Works really well for understanding.

Reconstituting messy things is exactly where LLMs can help.