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

33•cpan22•21h ago

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!

Comments

ryanjso•21h 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•21h 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

tasuki•1h ago

> 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...

ryanjso•29m ago

Yeah, but we're a small company and sometimes cut corners to move faster, so if a tool can solve this instead of potentially adding more friction to other engineers I'm all for it.

gracealwan•18h 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•18h 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•7h 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.

sscarduzio•17h 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•17h 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•9h 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•5h ago

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

dean_stratakos•1h ago

We don't support that currently, but would love to see examples where you disagree with the chapters so we can figure out the best interface

You can regenerate the chapters anytime, but it might lead to similar results as the first time

cpan22•29m ago

We're also planning on adding functionality to support some sort of CHAPTERS.md file that lets you specify how you want things broken down!

electrum•1h ago

Does Stage work for PRs that have multiple commits? These could be considered "stacked diffs", but in the same PR.

dean_stratakos•1h ago

Chapters are regenerated every time a new commit is pushed to a PR. Our thinking is that the chapters should serve as "auto stacked diffs" since they should follow a logical order.

Do you or your team use stacking in your workflows?

whywhywhywhy•1h ago

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•1h ago

> 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.

dean_stratakos•51m ago

In our experience, it's difficult to create well-mannered commits as you code and new ideas pop into your head or you iterate on different designs (even for LLMs). One concept we toyed around with was telling an LLM to re-do a branch using "perfect commits" right before putting up a PR. But even then you might discover new edge cases and have to tack them on as additional commits.

We thought git wasn't the right level of abstraction and decided to tackle things at the PR level instead. Curious to hear your experiences!

kvdveer•49m ago

I feel that grouping related change in commits can be challenging, as git really presents commits as grouping in time, not topic.

It is certainly possible to do topic-grouping in commits, but it requires significant effort to het that consistent on a team level.

tfrancisl•1m ago

I concur. I cannot accept that we are so disconnected from what we're building that we can't go back and revise our commits or something else to make it make sense.

phyzix5761•48m ago

This is a really cool idea but where's the moat? What's stopping someone from replicating the functionality?

cpan22•14m ago

Thanks! I think we're really focused on making the overall review experience as guided and obvious as possible for the human. Chapters is a great start but we're coming up with more ideas on how we can make the process even easier

embedding-shape•48m ago

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.

nathannaveen•28m ago

I assume this problem could be solved if we write up what we actually want (like a GH issue) and maybe in the future the guys at Stage could use github issues as part of their PR review?

cpan22•19m ago

I agree, that's also really important and something we're brainstorming

Currently on Stage we also generate a PR summary next to the chapters and that's where we want to do more "why" that pulls in context from Linear, etc.

And I know there's a lot of cool teams like Mesa and Entire working on embedding agent context into git history itself so that could an interesting area to explore as well

kylestlb•41m ago

I assume Gitlab/Github will add these sort of features to their products within the next few months

dean_stratakos•33m ago

It's possible, but at the same time it's been years and they haven't copied things like Graphite's dashboard or stacked PR interface yet. We have the advantage of speed :)

builderminkyu•25m ago

The framing of "humans back in control" resonates. A lot of AI tooling right now optimizes for speed over correctness — the assumption being that AI output is good enough to ship. Stage seems to push back on that. What's been the biggest surprise from early users so far?

cpan22•1m ago

Thanks! Yeah we believe strongly that humans need to be in the code review loop to some extent

I think one thing we've seen from early users that surprised us is how chapters was quickly becoming the unit of review for them as opposed to files - and they've asked us to add functionality to mark chapters as viewed and comment on them as a whole

tfrancisl•2m ago

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.

Isaac Asimov: The Last Question (1956)

Claude Design

Middle schooler finds coin from Troy in Berlin

Healthchecks.io Now Uses Self-Hosted Object Storage

It Is Time to Ban the Sale of Precise Geolocation

Iceye Open Data

Claude Opus 4.7

Codex for almost everything

Scan your website to see how ready it is for AI agents

Ada, Its Design, and the Language That Built the Languages

FIM – Linux framebuffer image viewer

The Utopia of the Family Computer

Teddy Roosevelt and Abraham Lincoln in the same photo (2010)

CadQuery is an open-source Python library for building 3D CAD models

中文 Literacy Speedrun II: Character Cyclotron

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

A Python Interpreter Written in Python

Reflections on 30 Years of HPC Programming

Official Clojure Documentary page with Video, Shownotes, and Links

Android CLI: Build Android apps 3x faster using any agent

Human Accelerated Region 1

Playdate’s handheld changed how Duke University teaches game design

Show HN: SPICE simulation → oscilloscope → verification with Claude Code

Guy builds AI driven hardware hacker arm from duct tape, old cam and CNC machine

Substrate AI Is Hiring Harness Engineers

The missing catalogue: why finding books in translation is still so hard

ReBot-DevArm: open-source Robotic Arm

A Better R Programming Experience Thanks to Tree-sitter

A Git helper tool that breaks large merges into parallelizable tasks

Qwen3.6-35B-A3B: Agentic coding power, now open to all

Isaac Asimov: The Last Question (1956)

Claude Design

Middle schooler finds coin from Troy in Berlin

Healthchecks.io Now Uses Self-Hosted Object Storage

It Is Time to Ban the Sale of Precise Geolocation

Iceye Open Data

Claude Opus 4.7

Codex for almost everything

Scan your website to see how ready it is for AI agents

Ada, Its Design, and the Language That Built the Languages

FIM – Linux framebuffer image viewer

The Utopia of the Family Computer

Teddy Roosevelt and Abraham Lincoln in the same photo (2010)

CadQuery is an open-source Python library for building 3D CAD models

中文 Literacy Speedrun II: Character Cyclotron

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

A Python Interpreter Written in Python

Reflections on 30 Years of HPC Programming

Official Clojure Documentary page with Video, Shownotes, and Links

Android CLI: Build Android apps 3x faster using any agent

Human Accelerated Region 1

Playdate’s handheld changed how Duke University teaches game design

Show HN: SPICE simulation → oscilloscope → verification with Claude Code

Guy builds AI driven hardware hacker arm from duct tape, old cam and CNC machine

Substrate AI Is Hiring Harness Engineers

The missing catalogue: why finding books in translation is still so hard

ReBot-DevArm: open-source Robotic Arm

A Better R Programming Experience Thanks to Tree-sitter

A Git helper tool that breaks large merges into parallelizable tasks

Qwen3.6-35B-A3B: Agentic coding power, now open to all

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

Comments