Generally, tools cannot fix a broken process. Which should include responsibility for shipping shit.
Show HN: Stage – Putting humans back in control of code review
101–110 of 119 posts
Re: Show HN: Stage – Putting humans back in control of code review
#102Earlier quoted context omitted.
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 leve…
> 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! The frick is a PR abstraction? Is this a GitHub PR abstraction where the commits are squashed and the PR description is whatever was hallucinated at 5 am? Yes, that’s certainly an abstraction, aka loss of information. You either have the information stored in the version contr…
Ah, my feelings exactly, put much more eloquently!
Re: Show HN: Stage – Putting humans back in control of code review
#103> 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.
[dead]
Re: Show HN: Stage – Putting humans back in control of code review
#104Earlier quoted context omitted.
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 leve…
> 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! The frick is a PR abstraction? Is this a GitHub PR abstraction where the commits are squashed and the PR description is whatever was hallucinated at 5 am? Yes, that’s certainly an abstraction, aka loss of information. You either have the information stored in the version contr…
> And if it can’t then you can recuperate the information that you trashed.
Typo: cannot recuperate
Re: Show HN: Stage – Putting humans back in control of code review
#105Looks 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…
Thanks for the feedback! re: local vs cloud, I do think there is a cool work to be done around unifying the writing/reviewing experience locally, but we started with cloud because we designed this as a collaborative product with teams in mind
have you heard of local first? collaboration does not mean you should start with cloud, the opposite its even better suited as you need a sync engine anyways!
Re: Show HN: Stage – Putting humans back in control of code review
#106It'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…
Well if you prompted the PR you know the context
Re: Show HN: Stage – Putting humans back in control of code review
#107This resonates. I'm a non-technical founder who works closely with a dev team, and reviewing PRs on GitHub has always felt like being dropped into the middle of a conversation with no context. The "chapters" metaphor is exactly right — when I review a PR I don't need to see every file change, I need to understand the narrative: what changed, why, and in what order it makes sense to read.
Curious: do you see Stage being useful for less technical stakeholders who still need to understand what's being shipped? Or is this primarily aimed at engineer-to-engineer review?
Re: Show HN: Stage – Putting humans back in control of code review
#108This resonates. I'm a non-technical founder who works closely with a dev team, and reviewing PRs on GitHub has always felt like being dropped into the middle of a conversation with no context. The "chapters" metaphor is exactly right — when I review a PR I don't need to see every file change, I need to understand the narrative: what changed, why, and in what order it makes sense to read. Curious: do you see Stage bei…
Ideally, the world trends towards enabling less technical people to get more involved in the whole software loop! Stage is still geared toward a more technical audience, but I think we are going to start reviewing at a higher level for certain types of software or areas of the codebase where we assign more trust to agents to write proper code
Re: Show HN: Stage – Putting humans back in control of code review
#109So, when I code review, I have a super simple Cursor command that "orients" me in the PR: * where does the change sit from a user perspective? * what are the bookends of the scope? * how big is the PR? * etc. Once I'm "in" and understand what it does, I pepper the AI with questions: * Why did the author do this? * I dont understand this? * This looks funky, can you have a look? * etc. The more questions I ask, the mo…
Agreed! That's why we designed Stage with the intention of AI guiding the human, not replacing them
Re: Show HN: Stage – Putting humans back in control of code review
#110Earlier quoted context omitted.
Thanks for the feedback! re: local vs cloud, I do think there is a cool work to be done around unifying the writing/reviewing experience locally, but we started with cloud because we designed this as a collaborative product with teams in mind
have you heard of local first? collaboration does not mean you should start with cloud, the opposite its even better suited as you need a sync engine anyways!
Good point, we've heard from users that there's a lot of fatigue of switching between local and GitHub all the time so we're thinking of ways to unify that experience