Show HN: GitHub "Lines Viewed" extension to keep you sane reviewing long AI PRs(chromewebstore.google.com) I was frustrated with how bad a signal of progress through a big PR "Files viewed" was, so I made a "Lines viewed" indicator to complement it. Designed to look like a stock Github UI element - even respects light/dark theme. Runs fully locally, no API calls. Splits insertions and deletions by default, but you can also merge them into a single "lines" figure in the settings. |
Massive walls of code have always been rejected simply for being unreviewable. Why would you suddenly allow this for AI PRs - where you should be even more strict with your reviews?
So, I'm kind of okay with large PRs as long as they're one logical unit. Or, maybe rather, if it would be less painful to review as one PR rather than several.
I still disagree. Why was the feature not split up into more low-level details? I don't trust that kind of project management to really know what it's doing either.
I am not promoting micromanagement, but any large code review means the dev is having to make a lot of independent decisions. These may be the right decisions, but there's still a lack of communication happening.
Hands off management can be good for creativity and team trust, but ultimately still bad for the outcome. I'm speaking from my own experience here. I would never go back to working somewhere not very collaborative.
But, it becomes incumbent on the author to write a guide for reviewing the request, to call the reviewer's attention to areas of interest, perhaps even to outline decisions made.
What would you put into the commit message fields if it were a git commit?
https://github.com/cboone/cboone-cc-plugins/blob/main/plugin...
I don't do it because the chances of me reviewing vomited code are close to 0.
With the increased volume of code with agentic coding, what was once occasional is now a daily occurrence. I would like to see new kinds of code review to deal with larger volume of code. The current Github review interface does not scale well. And I am not sure Microsoft has organizational capacity to come up creative UI/UX solutions to this problem.
Things that I’d consider table stakes that Phabricator had in 2016 - code movement/copying gutter indicators and code coverage gutters - are still missing, and their UI (even the brand new review UI that also renders suggestion comment diffs incorrectly) still hides the most important large file changes by default.
And the gutter “moved” indicators would be more useful than ever, as I used to be able to trust that a hand-written PR that moves a bunch of code around generally didn’t change it, but LLM refactors will sometimes “rewrite from memory“ instead of actually moving, changing the implementation or comments along the way.
https://github.com/jbonatakis/differ
It helps when there’s a massive AI PR and it’s intimidating…seeing that it’s 70% tests, docs, and generated files can make it a bit more approachable. I’ve been integrating it into my CI pipelines so I get that breakdown as a comment on the PR
I'm not saying that doesn't work, but writing a guide means the author is now also doing all the planning too.
A successful "guide" then becomes more about convincing the reviewer. The outcome is either a lot of friction, or the reviewer is just going through the motions and trust is eroding.
Splitting "handling the happy vs error path" sounds even worse. Now I first have to review something that's obviously wrong (lack of error handling). That would commit code that is just wrong.
What is next, separating the idea from making it typecheck?
One should split commits into the minimum size that makes sense, not smaller.
"Makes sense" should be "passes tests, is useful for git bisect" etc, not "has less lines than arbitrary number I personally like to review" - use a proper review tool to help with long reviews.
Don't give me 2000 lines unless you've made an honest good-faith attempt to break it up, and if it really can't be broken up into smaller units that make sense, at least break it up into units that let me see the progression of your thought as you solve the problem.
Tbh I only know it from squashed PRs.
However:
> "Co-author" is not a git concept. It is a convention in commit messages used by some services, including GitHub. So, the solution is to edit the actual commit message with git commit --amend and add a line to the end:
I think it's still early days, and it's probably the case that a lot of software development teams have yet to realize that a team basically just doing PR reviews is a strong indication that a codebase is very quickly trending away from maintainability. Our team is still heavily using LLMs and coding agents, but our PR backlog recently has been very manageable.
I suspect we'll start seeing a lot of teams realize they're inundated with tech debt as soon as it becomes difficult for even LLMs to maintain their codebases. The "go fast and spit out as much code as humanly possible" trend that I think has infected software development will eventually come back to bite quite a few companies.