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

ccpan22 about 20 hours ago 9 commentsRead Article on stagereview.app

HI version is available. Content is displayed in original English for accuracy.

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!

⚡ Community Insights

Discussion Sentiment

67% Positive

Analyzed from 325 words in the discussion.

Discussion (9 Comments)Read Original on HackerNews

gracealwan•about 17 hours ago

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.

dean_stratakos•about 17 hours ago

100%. A big part of code review in my mind is to automate away specific mistakes and anti-patterns across a team. I think there are a lot of interesting things to be done to merge the code writing and code reviewing cycles.

t0mas88•about 6 hours ago

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.

ryanjso•about 20 hours ago

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?

dean_stratakos•about 20 hours ago

Yeah that could be useful, especially with the increased popularity of stacked PRs

But I see it working together with chapters, not instead of bc it's still good to see the granularity within a PR

sscarduzio•about 16 hours ago

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.

cpan22•about 16 hours ago

This is really cool and we definitely have this problem as well. I really like the flowchart deciding on where to put each learning. Will have to try it out!

Do you find that this list of learnings that end up BUGBOT.md or LESSONS.md ever gets too long? Or does it do a good job of deduplicating redundant learnings?

sscarduzio•about 8 hours ago

Thanks! We have ~1000PRs/year. Seniors are way less than juniors and a lot of knowledge is transferred via pr messages.

The deduplication and generalisation steps really help, and the extra bugbot context ends up in just about 2000 tok.

Global LESSONS.md has less than 20 “pearls” with brief examples

sebakubisz•about 4 hours ago

Can reviewers adjust the chapter splits manually if they disagree with how it grouped the PR, or are the chapters fixed once generated?