Comment by jFriedensreich

Its pretty clear to a growing number of devs what a review tool should look like. It is more a matter of what needs to happen so this becomes a usable and sustainable reality and what shape of organisation/ players can make this happen in the right way.

- git itself wont go much further than the change-id which is already a huge win (thanks to jj, git butler, gerrit and other teams)

- graphite and github clearly showed they are not interested in solving this for anyone but their userslaves and have obviously opposing incentives.

- there are dozens of semi abandoned cli tools trying this without any traction, a cli can be a part of a solution but is just a small part

What we need:

- usable fully local

- core team support for vscode not just a broken afterthought by someone from the broader community

- web UI for usecases where vscode does not fit (possibly via vscode web or other ways to reuse as much of the interface work that went into the vscode integration)

- the core needs to be usable from a cli or library with clear boundaries so other editor teams can build as great integrations as the reference but fitting their native ui concepts

- it needs to work for commits, branches, stacked commits and any snapshot an agent creates as well as reviewing a devs own work before pushing

- it needs to incorporate CI/CD signals natively, meta did great UI work on this and its crucial to not ignore all that progress but build on top of it

- it needs to be as fine grained as the situation requires and with editability at every step. Why can i just accept one line in cursor but there is nothing like that when reviewing a humans code? Why can i fix a typo without any effort when reviewing in cursor when i have to go through at least 5 clicks to do the same when fixing a typo of a human.

- It needs to by fully incremental, when a pr is fixed there needs to be a simple way to review just the fix and not re-review the whole pr or the full file