Re:Ask HN: How to deal with shipping AI-written code you don...
by tptacek on Tuesday October 20, 2026 @01:42PM
(#50169947)
I don't even hook my tool up to Github. I just make it ultra easy to whack a PR number into the app and pull up all the details; all my review happens outside Github itself. The approach would work just as easily on Gitlab.
The key thing, for me, is just having an app that is useful enough to keep running. I get ideas on how to streamline and improve review as I do it (for instance: double click on a symbol to highlight it throughout the rest of the function so I can trace assignments and expressions). Five years ago, implementing these random ideas would be too expensive; I'd lose several hours to each of them. Now it's just: have a dumb idea, share the dumb idea with the agent managing my app, check back in in 10 minutes, and now my review app is better.
It's very much like working in Emacs, but for everything.
That's really it. I've been finding the same limitations with the default PR code review tools. We currently make do by having a section in our PRs "recommended review order" with a list of files/dirs that should be looked at first, which not only is much smaller Loc than everything else but is the main relevance of the PR.
Within a given project there are inevitably certain files/concepts that are more important, and a better review tool will help emphasize the structure of a large PR to make things easier to review.
I suppose you created a web based front end to GitHub PRs for your team to use? Or is it a local tool? Wondering how yours works.
We use gitlab and there's probably some way to hook up a custom external review tool easily (a bot that posts a link to view the current PR in the tool, for example)
Thanks for the idea!