61–70 of 119 posts
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.
I was actually recently thinking about similar idea. I am someone who started coding post LLMs and have basic technical understanding. I know what loops, variables, API, backend bla bla is. I learned bunch more since then but I am not capable of making decisions based on git diff alone. And I want to. I want to because I think increasing my skills is still super important, even in AI era. The models are getting bette…
We've wondered about what the review experience should look like for newly technical or non-technical people now that they are increasingly putting up PRs themselves. These people will be less opinionated about certain technical decisions in general so maybe the future looks like review processes very personalized to your experience level and your background. Definitely a lot to think about
Right now the chapters UI is only available on our website but we're exploring possible integrations and/or a desktop app
Maybe I'm missing something obvious, but if I was going to have my team use this, I'd want someone to answer the following question If AI is good enough to explain what the change is and call out what to focus on in the review, then why isn't AI good enough to just do the review itself? I understand that the goal of this is to ensure there's still a human in the review cycle, but the problem I see is that suggestions…
Maybe I'm missing something obvious, but if I was going to have my team use this, I'd want someone to answer the following question If AI is good enough to explain what the change is and call out what to focus on in the review, then why isn't AI good enough to just do the review itself? I understand that the goal of this is to ensure there's still a human in the review cycle, but the problem I see is that suggestions…
Imo human review is important for context/knowledge sharing even if a machine or tool can mechanically determine the change is reasonable
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…
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?
Really like this idea. But at what point do you think its valuable to have this chapters breakdown versus splitting things up into multiple PRs?
In the ideal world, each PR is as small and self-contained as possible but we've noticed people struggling to justify the extra overhead every time.
Earlier quoted context omitted.
Open source is something we're thinking about! We've just been focused on building for now but its definitely not off the table
"Building" is always easier when you have a community that is ready and able to rout out bugs and suggest new features. Closed source makes that much less practical and appealing for most.
Sort of related to that, we've been thinking a lot about the future of code review for OSS. Its clear with Cal.com going closed source that something needs to change. Would love to hear any thoughts you have
Earlier quoted context omitted.
Plannotator, open source runs locally, has code review: https://github.com/backnotprop/plannotator and a code tour feature about to ship: https://x.com/backnotprop/status/2043759492744270027/video/1 - integrated comment feedback for agents - inline chat - integrated AI review (uses codex and claude code defaults) Stage (op product) navigation tour is nice UX, about a day worth of work in addition to the incoming code…
this is for AI agent work though. That's cool, but not every team that wants better UX for complex work uses agents. Even if it "just works" for real scenarios, the marketing could be better.
Earlier quoted context omitted.
"Building" is always easier when you have a community that is ready and able to rout out bugs and suggest new features. Closed source makes that much less practical and appealing for most.
Totally get that, still something we're actively talking about! Sort of related to that, we've been thinking a lot about the future of code review for OSS. Its clear with Cal.com going closed source that something needs to change. Would love to hear any thoughts you have