Live data from Hacker News

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

stagereview.app

31–40 of 119 posts

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

#31

[flagged]

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

Another big surprise: now that agents are the ones writing most (if not all) the code right now, we've found that a lot of early users are using Stage to not only review others PRs but also their own PRs, before they have others review it

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

#32
post #15

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

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.

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

#33

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 an…

Agree that agents are definitely handling more and more of the coding side, and there's almost no doubt they will get better slop-wise.

In our view, even vibe coders should understand how the codebase works, and we think review is a natural place to pause and make sure you know what you and your coworkers are shipping. And we should have tools to reduce the mental load as much as possible.

Do you think there's a problem of cognitive debt among your coworkers who aren't reading the code or reviewing PRs?

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

#35

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.

Open source is something we're thinking about! We've just been focused on building for now but its definitely not off the table

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

#36

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!

Thank you! Let us know any ways we can make it better

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

#37
post #8

Earlier quoted context omitted.

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?

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

Nice! Will try it out

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

#39

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.

Exactly. "Why was this change made"? "What were the options"? "Why this is a good way of doing it"? "What are the subtle things I came across while making this change"?

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

#40
post #24

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

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!

CHAPTERS.md sounds like a good idea for when the auto-grouping doesn't match the actual structure of the work. Looking forward to seeing it.
Post reply on HN