Ask HN: How to deal with just being a PR reviewer for LLMs nowadays
I know .. architecture is important and yes it is also fun to figure it out, but apart from that all that was fun for me is done by AI nowadays and I am basically a PR reviewer for Claude now.
And I hate it. I am looking at a terminal window half of the day and have to figure out what the LLM wants to do ... depending on much Anthropic nervs the model, this can be easy or it still invents words and I have to check every detail.
My brain feels like it is getting cooked after a couple of hours, but the work day is only half done.
How do you guys deal with this?
I've heard the same concern from multiple fellow engineers recently. It also often comes with a fear that they'll be doing only "boring PRs review" in the future, or even worse - that their AI agents will be just talking to other engineers AI agents without involving humans :/
I believe it's really important to stop reading every line of code during the PR review and go one level higher. Work on the guardrails, security, creative parts of the architecture, challenge architectural decisions of your AI setup and learn. It's also often related to the lack of trust to the code generated by your setup, if you don't believe it then you spend a lot of time finding issues without actually improving anything.
Once you built a trust in what your AI generates, then you can skip many boring parts and focus on more creative things (or whatever you like more).
Btw if you don't like looking at a terminal window half a day then create a better interface in your setup - it can be better storytelling, diagrams, visuals, charts, whatever you like to make it feel better :)
Personally I'm more into diagrams and flows, so I try to turn every PR review into higher level flow analysis where I can predict what might be wrong, architecture flaws and so on instead of reading every line of code.
I can't do much about the amount of text I gotta read, I do have a line in my claude.md file to ask Claude to keep telling me about stuff that I missed or haven't responded to yet so I make sure I haven't missed any important stuff, and it's usually at the bottom of every response, Claude does talk a lot, (codex tends to be better at communicating) but what I found a bit helpful is the unslop skill by pstack, it can help your claude talk in a more read-friendly way. https://github.com/cursor/plugins/blob/main/pstack/skills/un...
when it comes to reading the diffs, I created my own app to review the diffs away from github, manage my PRs and do everything I could on github without relying on it's broken UI https://pyor.review
You could also just ask Claude to help you go through stuff bit by bit, you'll slowly build the skill and adapt to reading Claudish.
I still find it exciting to watch the reasoning of the AI models, and this keeps me engaged in the product they produce. Many times I marvel at what they came up with. Trying to catch them going on the wrong path down a rabbit hole can be a fun game as well. It's a very interesting time and things are shifting. I do hear about the brain drain you are experiencing, trying to keep up with all the information that comes at you at high speed.
My advice would be to outsource the annoying parts to AI.. like have a sub-agent do the verification, debugging, playtest whatever to grade the work done for example if that's the part you least enjoy. Learn to trust the process, but also keep refining it. Build a harness around the tasks, and spend time on improving that. It will give you satisfaction that you build that (in coordination with AI) and you've created something new.
I felt the same way for a long time. What changed it for me was reviewing less by reading and more by asking. Instead of going through the diff top to bottom, which gives me headaches given the amount of code Claude writes, I started asking for data flow walkthroughs and architectural overviews.
Agents have gotten incredibly good at coding already, so trying to find a bug or inefficiencies is a huge waste of time.
I started focusing purely on architectural patterns instead to ensure it follows patters we want, and also to get a good understanding of how the feature/fix works so I can continually stay updated with how the entire application works.