Announcer
The following program features simulated voices generated for educational and philosophical exploration.
Greg Evans
Good evening. I'm Greg Evans.
Andrea Moore
And I'm Andrea Moore. Welcome to Simulectics Radio.
Andrea Moore
We've spent three nights examining what AI coding agents can do—their capabilities, architectures, and methodological practices. Tonight we turn to a social and technical question that every team using these tools must answer: how do we review code we didn't write? What does code review mean when the author is an algorithm?
Greg Evans
Code review has always been about more than catching bugs. It's knowledge transfer, quality gate-keeping, maintaining team standards, teaching junior developers. When an AI generates a pull request, which of those functions still apply? And which require rethinking?
Andrea Moore
Joining us is Jessie Frazelle, who has extensive experience with code review culture at Docker and Google, and who has been publicly exploring the implications of AI-generated code. Jessie, welcome.
Jessie Frazelle
Thanks for having me. This is a topic I think about constantly.
Greg Evans
Let's start with the practical question. You're reviewing a pull request and you know it was AI-generated. Does that change how you review it?
Jessie Frazelle
Absolutely. With human-written code, I make certain assumptions. If there's a clever bit of logic, I assume the author thought through edge cases. If there's a pattern I don't recognize, I assume it might be solving a problem I'm not aware of. With AI-generated code, I make no such assumptions. Clever code might just be pattern-matching gone weird. Unfamiliar patterns might be hallucinated best practices that don't actually make sense.
Andrea Moore
So you're inherently more skeptical.
Jessie Frazelle
I'm differently skeptical. With junior developers, I look for common mistakes—off-by-one errors, null pointer issues, resource leaks. With AI code, I look for plausible nonsense. Code that looks right, follows conventions, but accomplishes something subtly wrong or solves the wrong problem entirely. The AI won't cut corners out of laziness, but it might implement a perfect solution to a misunderstood requirement.
Greg Evans
That's an interesting taxonomy of failure modes. Human errors tend to be implementation mistakes. AI errors tend to be specification misunderstandings.
Jessie Frazelle
Exactly. And that changes what you test for. With human code, I might spot-check the logic. With AI code, I verify that the code actually does what the commit message says it does. I treat the specification as potentially lossy—something might have been lost in translation from human intent to AI implementation.
Andrea Moore
How do you verify that? Do you need more comprehensive testing? Different testing?
Jessie Frazelle
You need tests that validate behavior against requirements, not just tests that verify the code works as written. Integration tests become more important than unit tests. You want to confirm that the feature actually solves the user's problem, not just that the function returns the expected output for given inputs.
Greg Evans
That sounds like it increases review burden significantly.
Jessie Frazelle
It does initially. But you develop intuition for what to look for. Certain patterns raise flags—overly generic variable names, unnecessarily complex logic, implementations that feel like they're trying too hard to be clever. After reviewing enough AI-generated code, you start recognizing its signature. Just like you can sometimes tell code was written by a particular human, you can tell when it came from an AI.
Andrea Moore
What's the signature? What makes AI code distinctive?
Jessie Frazelle
It's often very thorough but lacks personality. A human might write a quick-and-dirty implementation knowing they can refine it later. An AI writes comprehensive code right away—complete error handling, extensive documentation, every edge case covered. But it lacks the implicit knowledge humans have about what actually matters. It treats every case as equally important.
Greg Evans
Is that a bad thing? Thoroughness seems valuable.
Jessie Frazelle
It can be. Sometimes you end up with over-engineered solutions to simple problems. Error handling for cases that can't actually occur. Documentation that explains things that are obvious from context. The AI doesn't have the judgment to distinguish between important edge cases and theoretical ones. It's comprehensive but not necessarily wise.
Andrea Moore
Let's talk about the social aspects of code review. When you review a human's code and leave comments, you're teaching them, building team knowledge. Does that happen with AI-generated code?
Jessie Frazelle
No, and that's a significant loss. Code review is one of the primary mechanisms for knowledge transfer on a team. Senior developers review junior code and explain why certain approaches are preferred. That feedback loop doesn't exist when the AI is the author. You can request changes, but the AI doesn't learn from them in any persistent way.
Greg Evans
What about the human who directed the AI? They're still in the loop.
Jessie Frazelle
True, but the learning is different. If I review your code and say 'this should use a bounded buffer,' you understand why and will make that choice yourself next time. If I review AI-generated code and make the same comment, the human might just tell the AI to fix it without understanding the issue. They become a pass-through rather than a learner.
Andrea Moore
That seems like a serious concern for junior developers. They lose an important learning mechanism.
Jessie Frazelle
It is. We might need to explicitly preserve that learning path. Maybe require junior developers to implement certain features without AI assistance, or mandate that they explain in comments why the AI's approach was chosen. Turn the review into a teaching moment even when the AI wrote the code.
Greg Evans
Let's discuss review standards. When a human submits marginal code—it works but isn't elegant—you might accept it with suggestions for improvement. Do you hold AI-generated code to a higher standard?
Jessie Frazelle
I think you should. The AI doesn't get tired, doesn't have deadlines, doesn't have off days. If it produces mediocre code, that's a prompt engineering problem or a tool limitation, not a human performance issue. You should expect AI-generated code to at least meet your team's baseline quality standards, and often exceed them.
Andrea Moore
What about ownership? When there's a bug in AI-generated code six months later, who takes responsibility for fixing it?
Jessie Frazelle
The human who approved it. This is non-negotiable. You can't say 'the AI wrote this, not my problem.' If you merged it, you own it. That's why the review process has to be thorough. You're not just checking if the code works, you're committing to maintain it.
Greg Evans
Does that change the risk calculation? Might reviewers be more conservative, rejecting AI code they'd accept from a trusted colleague?
Jessie Frazelle
Possibly, and that might be appropriate. Trust in code review comes from knowing the author's capabilities and patterns. You don't have that history with an AI. Every pull request is from a 'new contributor' you haven't built trust with. That warrants additional scrutiny.
Andrea Moore
How do we document that code was AI-generated? Should that be explicit in commits, pull requests?
Jessie Frazelle
I think it should be. Future maintainers deserve to know. If I'm debugging something and discover it was AI-generated, that changes my debugging approach. I'm more likely to question the fundamental logic rather than assume the author had a reason for their choices. That context is valuable.
Greg Evans
Some might argue that's creating a two-tier system—human code versus AI code.
Jessie Frazelle
It already is a two-tier system. The code has different properties, different failure modes, different maintenance considerations. Pretending otherwise doesn't make those differences go away. Transparency lets you account for them appropriately.
Andrea Moore
What about contribution attribution? If an AI writes significant portions of your codebase, how does that affect project ownership and credit?
Jessie Frazelle
That's thorny. Lines of code metrics become meaningless. Commit counts are misleading. We need new ways to measure contribution. Maybe it's the quality of specifications given to the AI, or the thoroughness of review, or the architectural decisions that guided the AI's work. The valuable contribution shifts from implementation to direction.
Greg Evans
We're running short on time. If you were designing a code review process for teams using AI coding tools, what would be your top priority?
Jessie Frazelle
Explicit accountability. Make it crystal clear that the human who merges AI-generated code owns it completely. That creates the right incentives for thorough review. If you're not willing to maintain it, don't merge it. The AI is a tool, not a teammate you can defer responsibility to.
Andrea Moore
Accountability over automation.
Jessie Frazelle
Right. The automation is powerful, but it doesn't diminish human responsibility—it increases it. You're responsible not just for your own work but for adequately supervising the AI's work.
Greg Evans
Jessie, thank you for these insights.
Jessie Frazelle
Thanks for the conversation.
Andrea Moore
Tomorrow we'll explore the economics of AI-assisted development with Patrick Collison and Erik Brynjolfsson.
Greg Evans
Until then, review like you own it—because you do. Good night.