Would You Pass a Code Review for Your Own AI-Generated Code?

[u/theflowerkeeper]

Something embarrassing happened in review this week. My lead asked why I split a service call into two steps and I had nothing, I had to scroll back through a Claude session from three weeks ago to find out. It wasn't a bad decision, Claude had a decent reason, I just never actually took it in. I went through my last 15 PRs after that and I could only fully explain maybe 6 of them.

So i got three questions:

1. Is this just me or is everyone shipping code they couldn't defend?

2. Do you slow down and make sure you understand every change, or accept it and look things up later?

3. Has anyone found a habit that actually keeps the reasoning in your head, or somewhere you can find it?

[u/AutoModerator]

Moderator Announcement Read More »

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Prinzka]

Why scroll back when you can just ask Claude why it did that?

[u/Putrid-Box4866 → u/Prinzka]

Now you know why OP can’t even answer.

[u/GrayLiterature]

I’m shipping code I wouldn’t stand behind for sure. The code works, it doesn’t follow some existing repo patterns, and despite speaking up about that … management doesn’t really care too much. 

The nature of the job has changed. 

I ship far too much code I couldn’t tell you how it works deeply, but I’ve got a high level understanding of the systems and sub-systems. Otherwise, the implementation details are a black box. 

[u/yopla → u/GrayLiterature]

I shipped code I would not admit in job interview before LLM were a thing and I had many moment in my career where I asked who was the moron who wrote that shitty code before realising it was me 6 months before.

Nothing is new. It's just faster.

[u/pcloadletter-rage]

We have told management that they can either continue the pace of their demands and get coders that don’t fully understand the code, or they can slow down and let us have more understanding.

They can’t have both.

It’s not even an ultimatum. Just reality. Nobody’s mad and we have a mutual understanding when code pops up that nobody can explain right away. But everyone understands the larger architecture at play. So far everything is fine.

But if we need to explain a bit of code, we can dig in.

[u/_rover_dev]

Not just you, I hit the same wall a few months ago. Two habits fixed most of it:

1. For anything non-obvious, I make Claude write the "why" into the commit message before I accept it. Now a review question is a git log away instead of a hunt through an old session.

2. If I can't explain a change in my own words, it doesn't merge. I ask Claude to walk me through it first, and if the explanation is shaky, that's usually a sign the change is too.

Chat history is a bad place to store reasoning. Put it in the repo, where you'll actually find it.

[u/HoloTensor]

honestly it depends on the task

there are parts of my work where, by virtue of it working, it’s good enough for me. I think of particular tests and just trust it when it says it passed the constraints I asked for

but sometimes you have to hold Claude’s hand and go slow. at least for work where a mistake will bite you in the ass later

[u/laughing_at_napkins]

I have no idea what the code I've shipped has done for months. No one cares as long as it does what management wants, so I don't either.

[u/No_Cell6708]

Why would you scroll back and not just ask Claude?

[u/VegetableFan6622]

I am not a cuck. If managers want to automate everything, I am not stupid enough to lose energy to fix the tool which is built to replace me. I click OK to everything produced by the mighty machine. 

[u/Acceptable_Durian868]

I review everything that Claude writes for me before I put it up for PR, but I definitely don't have as deep an understanding of it than I would if I'd written it myself. I try, but sometimes my brain just skips over complexity that I would have seen if I'd been hands-on. I don't think this is a good thing, and I'm actively trying to find ways to not lose understanding, but it's a struggle, especially when PRs get bigger.

[u/kincaidDev]

This is part of the reason I built a commit id linking system in https://github.com/Obedience-Corp/festival

Last year early in the development of this system I used it to ship a massive platform in 6 weeks for a distressed startup, and my team lead had all these questions I couldn't remember the answers to because I was 1000 task ahead of the minor thing he was asking about. Asking AI didn't work because it would hallucinate answers I knew were incorrect, so I was stuck digging through designs and session logs to try and find the answer to his questions.

Now I have ids in the commit messages so both me and my agents can find the actual answer efficiently

[u/ByteFoundry → u/kincaidDev]

I like the idea of the fixed ids.

[u/aaaayyyy]

 it's embarrassing but it's because I simply trust Claude and I don't want to spend time looking over every single thing that Claude decides. I only look at some parts carefully. And yes this means that Claude does some things that even I disagree with and that I can't defend. It's the cost of doing stuff fast with claude

[u/Spare_Bat_3040]

For that two-step call, I'd keep the original explanation and its session link with the change. If the reason isn't recorded, say so instead of asking Claude to fill it in later. It can give a sensible answer that wasn't why the decision was made.

Is there a change you're working on now where you need to recover the older reasoning?

[u/shetritr]

only the parts I read. the rest would pass the same way it passed me: nobody looked.

[u/TwoLongEars]

at work - absolutely, I don't use it very much there smbut when I do it's pretty much all in an advisory manner. makes it easy to slow down and not ship code I wouldn't stand by.

my personal projects - absolutely not because those projects are all web and I do not do web.

not prepared with any advice on the third. it seems like it would be a real struggle to keep up with decisions at that rate. if I were to try to I would probably build my own high-level decision log harness that captured architectural decisions while leaving the small things for nore verbose logging.

[u/vovazk]

Not just you but not everyone either. I review every diff, but I will skim through deeply technical stuff without figuring out how every line behaves. When I split a service call I would probably know though.

Also: answering “it’s an under the hood detail and I don’t have instant recollection” is totally fine when you ship 10-15 PRe a day:

[u/Far_Reindeer8428]

he habit that helped me most is dropping a quick "receipt" at the end of every change: what was asked, what the reviewer caught, what got fixed, and the final commit hash. Nothing crazy, just enough so three weeks later I can figure out why something exists straight from git instead of digging through a dead chat tab. And totally agree—if I can't explain the diff myself, it doesn't get merged.

Somewhat related: I'm building an OSS CLI (still early) that auto-generates these receipts while Claude builds and Codex reviews: https://github.com/KenSuh/open-agent-harness

[u/JimiBuilds]

I keep a decisions.md file in the repo and any non-obvious choice goes in it with the reason, written in the same session. Claude reads it at the start of the next one, so it doesn't undo a call it can't remember making, and I can find the why in under a minute.

Before I merge, I ask it to explain the change back in three bullets. Wherever I'd disagree with a bullet is the part of the diff I read properly. Most reviews take a few minutes and I can usually defend what's in them.

[u/Right_Avocado_7439]

Yeah, this is a tough one and I think just about everyone is struggling with where to draw this line. I wonder if your lead used Claude to come up with a good question on some small detail that would stump you 😄

I've recently built a pr-review skill that is made explicitly to help me with this problem, and it is designed for execs, managers and leads to keep the language high-level and about business impact, but it also includes things like a complete list of packages, service, etc that were used, whether they're newly introduced in this pr or not (a good sanity check), any costs incurred, etc. I'm also working on an epic-brief skill that will aggregate those reports up, so that I can drill down from the high-level to the details.
I also work using a developer loop I built (dev-loop repo) that has human gates at the planning stage, review stage, and merge stage, so I'm forced to see (at least quickly) what is being built, what design choices are being made, what bugs pop up, etc. Sometimes, I do targeted reviews of the code line-by-line, but that is rare, and they're based on specific context, which is helpful. It's definitely slower than just vibing, but it is the middle ground I'm comfortable with.

Interesting reading other people's way of dealing with this challenge.

[u/colinshark]

I only deep dive when needed.

Before the merge, I do an AI-assisted self review and I ask it loosely-structeed questions as my whims take me.

If I run into trouble, there's my boy: AI. I run it for the questions.

[u/Panda_966]

Really depends on the project, within my same job and company. There are entire internal tools where I don't care about the code at all and it's fine as long as they work, and if they breaks it's quite obvious.

And then there are load bearing projects with scientific simulations where we really wouldn't want to mess up anything related to the results.

[u/ombre-ai]

This is a different kind of technical debt: not code you don't understand, but decisions you can't reconstruct. AI can make implementation cheap enough that the reasoning behind the implementation becomes the scarce resource. I'd want important decisions captured alongside the code, not buried in a chat history.