Using AI for Python Code Reviews

AI-assisted code review genuinely, reliably catches a specific and valuable category of issue: mechanical, pattern-recognizable problems that don't depend on any context beyond the code itself. open(path) with no corresponding with statement or explicit .close() call — a resource-leak pattern this curriculum's Context Managers lesson covered in depth — is exactly the kind of issue an AI reviewer catches quickly and reliably, since recognizing it requires only understanding the code's own structure, not any external knowledge about the specific project.

This extends to a genuinely useful range of mechanical concerns: missing error handling around an operation likely to fail (an unguarded external API call, following the requests lesson's timeout and raise_for_status() guidance), inconsistent naming conventions, an obviously missed edge case visible directly from the function's own logic (a division with no zero-check, an index access with no bounds check), or a pattern this curriculum has specifically flagged as an anti-pattern elsewhere (a bare except: clause, a mutable default argument). None of these require knowledge of your team, your business, or your system's history — they're identifiable from the code in isolation, which is exactly the kind of analysis AI review performs well and quickly.

This genuine strength is worth taking seriously rather than dismissing — an AI-assisted first review pass catching these mechanical issues *before* a human reviewer ever looks at the code means that human reviewer's time and attention aren't spent on issues a faster, more mechanical process could have caught first, freeing their genuinely valuable, context-dependent judgment for the review work only they can actually do.

AI code review has a genuine, structural limitation worth naming precisely — not as a temporary capability gap likely to close with a more advanced future model, but as a fundamental fact about what information is actually available to it: an AI reviewer analyzing a specific piece of code has no access to your team's institutional history, past production incidents, or unstated business context, because that information simply doesn't exist anywhere in the code itself or in whatever context happens to be provided in that specific review request.

'We tried this exact caching approach six months ago and it caused a production outage' is information that lives in your team's collective memory, or in an internal incident report — not in the code being reviewed, which, in isolation, might look like a perfectly reasonable, even elegant caching strategy. 'This function looks redundant, but it exists specifically to work around a known bug in a third-party payment provider's API' is similarly invisible to any reviewer, human or AI, lacking that specific institutional context — but a human team member who was present for that discovery, or who has access to the team's shared knowledge, can catch it; an AI reviewer analyzing the code cold, without that specific context explicitly provided, structurally cannot.

This isn't a criticism of AI review's genuine capability — it's a precise statement of what kind of information an AI reviewer, by its nature, does and doesn't have access to. A human reviewer's specific value in code review isn't (only) catching missing error handling — mechanical issues an AI reviewer often catches just as well — it's precisely this kind of context-dependent, institutionally-grounded judgment that no analysis of the code in isolation, however sophisticated, can substitute for.

Understanding both AI review's genuine mechanical strength and its structural context-blindness points directly toward the effective professional workflow: use AI review as a genuine first pass, catching mechanical, pattern-recognizable issues quickly and consistently *before* a human reviewer's attention is spent on the code at all — and rely on human review specifically for the architectural fit, business context, and institutional-memory-dependent judgment that no AI review pass, however capable, can structurally provide.

This isn't a compromise or a workaround — it's a genuine division of labor matched to each reviewer's actual strengths: AI review is fast, consistent, and tireless at catching the mechanical issues this lesson's first section covered, freeing human reviewers from spending their limited time and attention on exactly those issues, and letting that human attention focus specifically on the questions only they can actually answer — does this fit our architecture? Have we seen this pattern cause problems before? Does this correctly reflect an unstated business requirement the code itself doesn't and can't make visible?

This two-pass workflow — AI catches the mechanical, humans catch the contextual — is a direct, practical extension of the same 'right tool for the right part of the problem' philosophy this curriculum has applied consistently throughout: automated tooling (Ruff, mypy, pre-commit, now AI review) for what can genuinely be automated and mechanically verified, human judgment reserved specifically for what genuinely requires it — never treating either as a full substitute for the other, but combining both for a review process stronger than either alone.

An AI reviewer can catch a missing null check in seconds. It cannot know that this specific architectural pattern caused a production incident six months ago — only a human reviewer with that context can.

AI review genuinely excels at MECHANICAL issues -- missing error handling, inconsistent naming, unclosed resources -- caught quickly and reliably.

Checkpoint: Why is an unclosed file handle exactly the kind of issue AI code review tends to catch reliably?

• →It's a mechanical, pattern-recognizable issue (open() without a corresponding close() or context manager) that doesn't require any knowledge of the specific project's history or business context
• →AI review catches every possible category of issue equally reliably, with no particular strengths or weaknesses

AI review has a STRUCTURAL blind spot: no knowledge of your team's history, your production incidents, or unstated business context.

Checkpoint: Why can an AI reviewer not catch "we tried this exact approach 6 months ago and it caused a production outage"?

• →It has no access to your team's institutional history, past incidents, or unstated context -- information that exists only in your team's own memory or internal records
• →This is a current, temporary AI limitation that will be fully solved by a more capable future model

The effective pattern: AI review as a FIRST PASS catching mechanical issues, freeing human reviewers to focus on architecture and business context.

Code review catches issues before merge; AI Performance Optimization closes this section, applying the same collaborative discipline to a different, specific category of code concern.

Detect a Real Mechanical Issue. Finish uses_context_manager(): this is exactly the kind of issue an AI reviewer catches reliably.