alt.hn

2/13/2026 at 7:19:45 PM

Show HN: GitHub "Lines Viewed" extension to keep you sane reviewing long AI PRs

 https://chromewebstore.google.com/detail/github-lines-viewed/npledcbofpmjjammgkkoeaehbphhdopi

by somesortofthing

2/15/2026 at 12:40:27 AM

Sure, it looks neat, but why would you ever want this? What happened to closing PRs like thise with a short and simple "This is unreadable. Split it into smaller self-contained commits, and write proper commit messages explaining what they do and why" comment?

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?

by crote

2/15/2026 at 1:32:38 PM

I'm on the fence about this. Sometimes a new feature needs maybe 2k lines of code split over 10-20 or so files. Sure, you could split it up, but you can't necessarily run the parts in isolation and if they get split over multiple reviewers it might even be that no one reviewer gets the whole context.

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.

by rokkamokka

2/15/2026 at 2:12:37 AM

I'm reviewing PRs I wrote myself. Valid concern in a real org though.

by somesortofthing

2/14/2026 at 9:41:11 PM

Related to this, how do you get your comments that you add in the review back into your agent (Claude Code, Cursor, Codex etc.)? Everybody talks about AI doing the code review, but I want a solution for the inverse - I review AI code and it should then go away and fix all the comments, and then update the PR.

by fotcorn

2/15/2026 at 1:23:22 AM

There’s a bunch of versions of this out there. This one’s mine, but it’s based on other ones. It works really well. It assesses the validity and importance of each comment, then handles it appropriately, creating issues, fixing the code, adding comments, updating the GH Copilot instructions file, etc.

https://github.com/cboone/cboone-cc-plugins/blob/main/plugin...

by ctmnt

2/14/2026 at 9:43:31 PM

I suspect you don't need anything special for this. The GH API has support for reading comments from PRs. Maybe have it maintain a small local store to remember the IDs of the comments it's already read so it doesn't try to re-implement already-implemented fixes. Another similar thing you can do is a hook that reminds it to start a subagent to monitor the CI/autofix errors after it creates/updates a PR.

by somesortofthing

2/14/2026 at 10:15:55 PM

GitHub API is actually quite tricky here because there is a different between “comment” and “review” and “review comment” (paraphrasing, I don’t remember the details). So it’s not as simple as one API call that grabs the markdown. Of course you can write a creative one-liner to extract what you need, though.

by danappelxx

2/14/2026 at 10:58:02 PM

I tell claude code “review the comments on this PR” and give it the url, and that’s enough. It then uses the gh cli tool and fetches the PR and individual comments.

by alehlopeh

2/15/2026 at 12:32:56 AM

I don't use it, but you can tag @copilot on GitHub comments and it will do so.

I don't do it because the chances of me reviewing vomited code are close to 0.

by epolanski

2/16/2026 at 1:47:48 AM

What about the data security, is it sending code to any servers or it works on client side?

by melvinodsa

2/16/2026 at 7:21:49 PM

Makes same-origin requests to github's frontend to fetch info about line counts(line count figures are only sometimes loaded into app state) - that's the only network calls it makes.

by somesortofthing

2/14/2026 at 11:03:55 PM

Was this vibe coded? Did you test it on itself?

by nusl