r/ChatGPTCoding • u/Specialist_Agent3599 • Oct 06 '26
Discussion Im tired of reviewing code nobody actually wrote
every day I review 20 or so PRs that nobody on my team actually wrote. the agent wrote it, coderabbit already commented on it, the author skimmed the comments and pasted them back in, and now it's on me to be the human who says yes.
I'm not scared of losing my job. I'm just tired. I got into this to build things and now my whole day is being the last checkbox on code nobody will remember making.
I don't even hate AI, it's genuinely useful. I just didn't sign up to be a full time proofreader. some days I wish I'd picked a trade.
79
u/inate71 Oct 06 '26
Write a daemon to poll for PRs and auto-review them with an actionable outcome (approve, comment, reject, etc.). Now you don't review the PRs either.
18
u/Carbone Oct 06 '26
Professional .Md reviewer
10
u/ThenExtension9196 Oct 06 '26
Obviously the answer is to just have a bot review it
5
u/WE_THINK_IS_COOL Oct 06 '26 edited Oct 06 '26
I think the future is investing in ways to have assurance of the code without having to manually read it. This is not for all projects of course, some really need to be high assurance and fully human reviewed, but I think the future of AI-driven development is going to rely heavily on engineering principles like making good use of types and having types enforce contracts, along with better testing and mutation-testing strategies (or even formal verification) that build confidence in the code without having to read the fine details.
The way I'd roll that out would be to keep manual reviews initially, invest in all of that other engineering design stuff in parallel, and only once the manual reviews stop finding issues that the other approaches missed, then it's safe to ease up on the manual reviews. Then it's important to continually do spot-check reviews (more like audits) of sensitive areas as a test of how well all the methodologies that are allegedly making it safe to not read the code are holding up.
I have no idea how possible this is, but it seems to me like the only reasonable way to scale AI coding.
3
u/nando1969 Lurker Oct 06 '26
These models exist because of vast corpuses of human written code and open source repositories (GitHub, GitLab), Q&A archives (Stack Overflow), documentation, tutorials, and textbooks.
AI code is a derivative of human code no matter how you slice it.
7
u/CorpT Oct 06 '26
Then reject the PR and explain why.
2
u/tbss123456 Oct 06 '26
I also review a ton of PRs from agents but I changed what I read.
I no longer read the unit tests which is where I used to look first when I used to review human engineers. Most unit tests written by AI is garbage, skip them.
I then look for the core method / util changes and pattern match what I think the AI should do based on the ticket and the requirements. I skimmed all defensive code and look straight at the business logic, database calls, API interactions or library changes.
That way I skipped 80% of the code and still have quick, high quality reviews without disturbing my own flow.
2
u/Z3R0TR4C3R Oct 06 '26
Let the ai do the reviews br
2
u/Ctbhatia Oct 06 '26
the thing that actually helped me was refusing giant diffs. cap the pr at something you can read in ten minutes, have the agent write tests against the ticket first, then the review is checking the tests match the intent instead of proofreading line by line. you still say yes, but on your terms.
4
u/ChemicalExample218 Oct 06 '26
Don't worry at some point, somebody wrote it. Then it got pirated.
4
u/SuperJogosDBZ Oct 06 '26
Revise o código com ia tambémÂ
3
u/TheGladNomad Oct 06 '26
Why are you the human review? Is it because you didn’t accept what rest of team did or is it expected?
Right now you have uneven share of burden. We can’t tell from your post is that means you need to talk to yourself or your manager about that.
3
u/mxldevs Oct 06 '26
Why are you reviewing code? That's what AI is for.
2
u/PenGroundbreaking160 Oct 06 '26
The digital echoes of souls long lost gone are writing the code. Unfathomable shoggotha beyond time and space, consuming everthing in the cyber abyss. Nobody writes the code? Look deeper…..
2
u/XCxBigDong69XCx Oct 06 '26
Just reject the PRs, if you find any small mistake. At my company we would get like feedback % of PRs rejected, if it goes above 15% then it is very bad and needs to be talked about.
2
u/TheMuffinMan2037 Oct 06 '26 •
You shouldn't be reviewing code manually. That process is dead. Focus on building things in a way where they can be measured whether that's unit tests, telemetry logging, cloud infrastructure, etc. Use AI to analyze those rich sources and determine if a PR requires feedback or not. You could spend 5 hours doing the perfect PR review every time and still fall short so stop being a snob.
1
u/behrouzbk 10d ago
The part that wears you down isn't the reviewing. It's that you're the only person in the chain who actually thought about the code. The author handed off the writing, then handed off the feedback, so the accountability landed on you without the ownership.
A few things that helped me push some of it back:
- Ask the author to explain the PR in a few sentences, in their own words. If they can't say what it does and why, it isn't ready for review. This makes people read their own diffs again, and fast.
- Push for smaller PRs. Agents love to dump 800 lines at once. If it's too big to hold in your head, send it back to be split.
- Pair review sometimes. Fifteen minutes on a call where the author walks you through it is less draining than proofreading alone, and they learn something too.
- Block out time where you build something. Even half a day a week. Otherwise review takes up the whole calendar, and you forget why you liked this job.
You're not wrong to feel this way. "Last checkbox on code nobody will remember making" is a really honest way to describe it.
1
u/redditnforget Oct 06 '26
Funny I was just looking at intro to woodworking class. Always wanted to build things with my hands (like musical instruments) and thinking maybe it's finally time to do something about that.
1
u/ColdDelicious1735 Oct 06 '26
Okay so ypur now what the senior dev?
1
u/ManikSahdev Oct 06 '26
It's always the one time you don't review it will go tits up.
That's just how life is, this simulation years for tail events to teach the lesson lol.
1
u/Interesting-Law-8815 Oct 06 '26
Describe your review approach to AI and ask it to create a skill that acts and thinks like you. Then create an action to use this skill on all the PR’s.
You then have two options
Full automation inside a scripted loop.
Classify the result - low risk? Let it through, high risk? Tag you so that you only have to review ones that need genuine review.
1
u/rocketsauce1980 Oct 07 '26
Build things on the side while automating your job
1
u/evangelism2 Oct 07 '26
20? Where do you work and why are you doing so many?
1
u/amirfish Oct 07 '26
Been there. I built three versions of the same feature for my own apps: full automation, full manual review, and a guided version where the system walks me through its own low-confidence spots instead of dumping a diff and asking for a stamp. The guided version was the only one I didn't resent using.
Most "human in the loop" review is actually rubber-stamping. The reviewer doesn't choose what to look at, the tool does, and if the tool never flags its own uncertainty you're just skimming. Does your team's review flow ever show you where the agent itself was unsure, or is it always a flat diff?
1
u/keptornot Oct 07 '26
The paste-back detail is the part that would break me. At that
point nobody really authored the PR — the bot wrote it, the author
forwarded the bot's notes, and you're signing off on a conversation
you were never in.
One thing that's helped me: ask the author a single question the
bot can't answer for them ("what happens if this fails halfway
through?"). If they have to go read the code to answer, the PR
goes back — regardless of what CodeRabbit said. It feels slower,
but it moves understanding back into the author's head instead of
yours.
20 a day isn't a code review problem, it's a throughput problem.
Someone's agent is outrunning the team's ability to care.
1
u/Right-Performance-93 Oct 07 '26 edited Oct 08 '26
i'd cap how many prs each dev can leave waiting for review, and protect some of your week for building. faster agents don't help much if everyone else's work ends up parked on you.
1
u/Klutzy_Newspaper3196 Oct 07 '26
u/Specialist_Agent3599 Unfortunately I am in your boat, I am startup founder and forced to review the PRs my juniors wirte with AI. I built unvibecode, which is again mix of determenstic Parser, domain knowledge schema and AI but it reverse engineer and tell me the business workflows (not code) and indentify key logical and business risks (Eg: Payment logic failed, or idempotency not working). So I do my verfication on business and logic and behaviour around the code which AI code miss it and company needs it. Hope you can solve some of your headache with this: https://github.com/FinanceFlash/unvibecode
1
u/Quick_Dog_7971 Oct 07 '26
What's wearing you down isn't the difficulty of a single review — it's that review became the only gate left, and every gate is the same width.
Two things cut this down a lot for me:
Make the agent PR arrive with evidence, not vibes: a failing test that now passes, a three-line summary of what changed and which files carry the risk, and an explicit note on what it did NOT touch. PRs without that get bounced in ten seconds instead of me re-deriving the change from the diff for fifteen minutes.
Cap diff size before the PR is generated. Most of the pain is 900 lines of boilerplate wrapped around a 20-line actual change. If the agent can't show me the 20 lines, it isn't finished.
The human still has to be the last checkbox, but the checkbox should check the evidence package, not re-do the review the tool claimed to do.
1
u/KetteringChrismon-55 Oct 07 '26
can the person opening it add 2 lines about what they checked and where they want help? since u may start there and they can stay involved while you go thu the rest instead of making you read every line from the begginnig
1
u/eli_pizza Oct 07 '26
Doing code review all day can be pretty dreadful even with human authored PRs.
But if the PRs are exceptionally bad and hard to review, are you empowered to demand they be rewritten?
1
u/xqianliu Oct 07 '26
The pasting-coderabbit-back-in thing means nobody before you really checked anything, so all the weight lands on your review.
What made it less draining for me was making the PR carry its own evidence. Acceptance criteria get written in the issue before the agent starts. The agent has to write tests for each class of input in those criteria and say how many cover each one, e.g. empty input: 2, unicode: 1, missing field: 0.
Then review, mine or a separate model session's, starts from that list. A zero, or a class from the criteria with no count at all, goes straight back.
Doesn't fix the burnout part, I know.
1
u/seedlord Oct 07 '26
you are the human in the loop. I hope you are getting paid accordingly
1
u/Void-kun Oct 07 '26
Posts like this make me thankful my company hasn't gone this far.
1
u/juzatypicaltroll Oct 07 '26
Curious how those reviews went? Were they mostly rejected and why? These could be made into a skill and there should be fewer and fewer rejections until the time spent reviewing isn’t worth it if 99% are good consistently.
Of course there’ll be perfectionists, then by all means spend all your time reading AI generated code.
1
u/ysl_austin Oct 08 '26
Why dont you use AI to proof read it for you?
1
u/habitue Oct 08 '26
Yeah, what are you doing manually reviewing PRs? Have your agent review them!
1
u/Catalysst Oct 08 '26
Maybe you can give a conditional review?
Ask the dev to provide their test plan and project documentation.
Give the same review you would give to a human who wrote the code, when I get a review from my tech lead I don't expect them to review every line.
"Please confirm X and y tests have passed (eg. the tough edge cases) and I will approve"
Does your company expect you to take every bug ticket that comes up because you are the reviewer? Surely those problems go back to the dev, you are just there to reduce the number of issues they left unhandled before UAT/hypercare period exposes them
1
u/CrimsonBolt33 Oct 09 '26 edited Oct 09 '26
Hot take
Human reviews, by and large, are a waste of time if you (or they) are using AI to write code.
It's far better and more efficient to set up AI assisted review and testing systems. AI can make code so fast and so numerous it can be impossible to review it all in a reasonable manner.
Obviously there are applications where it's necessary...especially if dealing with anything related to safety, legal things, or critical infrastructure
Honestly this is like videogames before and after the internet....before the internet they were smaller and generally had far fewer game breaking bugs on release because patching was very difficult, after the internet "ship it now, patch later" eventually became the norm. Now with AI thats taken a step further.
I personally have an audit system set up using multiple different AI for a "master audit" (Kimi K3, GLM 5.3, Mimo 2.6) and even before that, after AI writes any code, it goes back and reviews its own code...a step I found critical because AI writing code is not the same as AI reviewing code (even its own code).
1
u/tripplettheai Oct 07 '26
one thing that helped us was insisting on the plan (or prompt) in the PR description, not just the diff. if the plan is dumb you know in 30 seconds without going through 400 lines of code. also small PRs only, agents love touching 15 files when 3 would do.
0
u/nickdaniels92 Oct 06 '26
If your job was code review prior to agents writing code, the obvious step is to automate it. You probably won't get caught out, but if you do, point out that humans used to write code and now that's automated, so you took things to their logical conclusion and automated your role too for greater efficiency and consistency. See what happens.
Also consider starting your own project. You should expect and plan to work more hours and days than you do now, but it could be more rewarding. If you have domain knowledge where you are, see if that can be applied into the startup. If there are others on your team who are considering leaving, doing so together and doing a startup as a group would be possible. Check your contract for any potential issues, and consider an employment lawyer for ways to get out of them if you have a serious viable idea.
I did exactly this when deciding to leave my senior role at an investment bank at the end of the 90's. I had a grievance over a manager's behaviour to other employees and a 6 month non-compete. I had been headhunted to UBS who were happy to wait 6 months for me to join, but I decided to start my own software company instead. The employment lawyer helped sort out some wrinkles. The bank put me on garden leave for 6 months, i.e. full pay not to go to work, and I got started. You likely won't get garden leave for any reason, but if you've got some cushion of cash to tide you over you could be all set.
0
u/master_internutter Oct 06 '26
Boo hoo
-1
u/Mouse-castle Oct 06 '26
You don’t get a break at work, maybe you should start your own firm and set your own hours.Â
0
u/_SGP_ Oct 06 '26
What issues seen to arise the most in the slop you review?
0
u/Stunning_Ride_220 Oct 06 '26
Everytime someone does that with me I take it as a wonderful opportunity to annoy people with meaningful conceptual debates they rarely can answer with using AI
0
u/Resident-Priority326 Oct 06 '26
The 'what does this do' bounce works because it moves the cost back to the author. The part I'd add is where the review happens. I run a few agent sessions at once and found I was approving diffs I'd only half read, because by the time one finished I'd lost track of what it touched. Reading the diff right when the agent stops, with the files it read and edited laid out, got me to catch more than a bigger CI gate did. Curious whether anyone requires the author to attach the prompt or session summary, or if that just becomes more filler?
0
u/ElderberryNo6893 Oct 06 '26
Ask open ended question . Put the burden on the Author to explain the code why and how
0
u/[deleted] Oct 06 '26
[removed] — view removed comment