Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

stagereview.app

Post reply on HN
Print view View original

111–119 of 119 posts

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

#111

Post by cpan22 »

cygn wrote: post #94

Haven't tried it yet, but it looks neat! My pain points with PRs where people vibe coded something is a bit different though: - I'd like to get an idea how they prompted and developed the PR. - I want to see if for example they just took everything the AI gave them or if they interacted with it critically - I want to see some convincing proof that they tested it, e.g. manually. I.e. along the lines of what Simon desc…

Yep that seems to be a common sentiment! Definitely some interesting areas around capturing agent conversations in commit history that could make this possible

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

#112

Post by cpan22 »

philipnee wrote: post #97

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

Great point and that's our takeaway too from talking to many users. We're exploring ways for Stage to possibly tailor the review flow to each specific PR/user preferences. Would love to hear any ideas if you have any!

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

#113

Post by JulienZammit »

embedding-shape wrote: post #21

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

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.

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

#114

Post by cpan22 »

JulienZammit wrote: post #113
embedding-shape wrote: post #21

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

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…

Good question, we're more focused on the first aspect you mentioned of "does the code you wrote make sense on a high level" rather than "did you miss something" - I think tools like Greptile and Codex are coming out with new security review features that are more suited towards that use case

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

#116

Post by slava_ »

did you think about this tool not from "review someone's PR" but from "review Claude's output" perspective? let's say, I work locally, /effort max and I get a huuuge diff. and then I run a skill "/turn-summary" and it walks me through the changes locally or in some nice UI opened in the browser and helps me to focus my attention in groups. or it would be nice native feature in tools like Conductor.

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

#117

Post by cpan22 »

slava_ wrote: post #116

did you think about this tool not from "review someone's PR" but from "review Claude's output" perspective? let's say, I work locally, /effort max and I get a huuuge diff. and then I run a skill "/turn-summary" and it walks me through the changes locally or in some nice UI opened in the browser and helps me to focus my attention in groups. or it would be nice native feature in tools like Conductor.

Yeah we've been thinking a lot about this! Switching back and forth between local and GitHub is also a frustration of ours so we want to think of ways to unify the experience

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

#118

Post by viktorianer »

stackskipton wrote: post #78
cpan22 wrote: post #41

Earlier quoted context omitted.

Yep that's something we're actively working on! would love to hear any perspectives on best ways to approach this

There isn't one. Most of time you would pair review a PR with human who wrote it and they could explain that. They can't anymore since 9/10, they didn't think through those things.

[dead]
Post reply on HN