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"?
Show HN: Stage – Putting humans back in control of code review
41–50 of 119 posts
Re: Show HN: Stage – Putting humans back in control of code review
#42Re: Show HN: Stage – Putting humans back in control of code review
#43Re: Show HN: Stage – Putting humans back in control of code review
#44Looks 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…
Re: Show HN: Stage – Putting humans back in control of code review
#45Re: Show HN: Stage – Putting humans back in control of code review
#46You 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.
Re: Show HN: Stage – Putting humans back in control of code review
#47> 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.
We don't think of Stage as moving people further away from code review, but rather using AI to guide human attention through the review process itself
Re: Show HN: Stage – Putting humans back in control of code review
#48> 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 .
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…
Have you heard about `rebase -i` ?
Re: Show HN: Stage – Putting humans back in control of code review
#49Re: Show HN: Stage – Putting humans back in control of code review
#50> 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.
I agree, and that's why we're not building a code review bot which aims to take humans out of the loop We don't think of Stage as moving people further away from code review, but rather using AI to guide human attention through the review process itself
AI guiding human attention means that humans aren't guiding human attention, which means less human understanding of their reviews.