Review, Testing & Refactoring with AI

AI code is still code — review it like a junior's PR

The biggest mistake teams make: lower the review bar for AI-generated code. AI output needs more scrutiny in some areas (hallucinated APIs, wrong assumptions) and the same scrutiny everywhere else (logic, security, performance).

The review checklist

Apply this to every AI-assisted PR:

#	Check	Why AI fails here
1	Compiles and tests pass	Obvious but often skipped when diff "looks right"
2	No invented APIs or imports	#1 hallucination category
3	Matches existing patterns	AI defaults to generic patterns, not yours
4	Edge cases covered	AI implements happy path; misses null, empty, concurrent
5	No unnecessary dependencies	AI loves adding libraries you don't need
6	Security: no secrets, no injection	AI may hardcode keys or skip input validation
7	Performance: no O(n²) surprises	AI optimizes for readability, not scale
8	Diff scope matches task	AI "fixes" unrelated things (drive-by refactors)
9	Error handling is real	Empty catch blocks, swallowed errors
10	Tests test behavior, not implementation	AI writes tests that mirror its own code, not requirements

AI-assisted code review (reviewing human code)

AI is useful for first-pass review, not final approval:

Good uses: Bad uses: - Find missing error handling - "LGTM" without human reading - Spot inconsistent naming - Trusting AI security audit alone - Suggest test cases - Auto-merging based on AI approval - Explain unfamiliar code - Replacing human reviewer entirely

Pattern: AI review → human triages findings → human decides merge.

Tools like Cursor Bugbot automate the first pass in CI. Treat findings as signals, not verdicts.

Test generation patterns

When AI-generated tests work:

• Happy path + obvious edge cases from a clear spec
• Snapshot/regression tests for output formatting
• Boilerplate test structure (setup, teardown, mocks)

When they fail:

• Concurrency and race conditions
• Integration tests requiring real infrastructure
• Tests that need domain knowledge of business rules
• Property-based or fuzz testing

Best pattern: you write test cases (table of inputs/expected outputs), agent writes test code.

Safe refactoring with AI

Refactoring is where AI shines — if you constrain it:

1. Tests green before starting — baseline
2. One refactoring type per agent session — rename, extract, or move, not all three
3. Run tests after each step — agent can auto-fix if wired to terminal
4. Mechanical refactors only — extract method, rename, move file. Not "redesign this module"

Safe: "Extract the validation logic from OrderHandler into OrderValidator. Update imports. All existing tests must pass unchanged." Risky: "Clean up the order module" (ambiguous scope, drive-by changes)

When to reject AI output entirely

Reject and restart when:

• Agent changed files outside your spec (scope creep)
• Same bug appears after 2 fix attempts (missing context)
• Security-sensitive code without your explicit review
• Architecture diverges from your plan (agent "simplified" your design)
• Tests were deleted or weakened to pass

Restart with tighter spec, more context, or smaller scope — not more pleading.

Eval-driven development

For AI features you build (not just AI you use), adopt eval suites:

• Collect real failure cases from production/support
• Write pass/fail criteria before prompting
• Run evals on model upgrades before switching
• Track regression rate over time

Anthropic and OpenAI both publish eval frameworks. The mindset is identical to unit tests: define expected behavior, automate checking.

Interview framing

"I review AI code with the same rigor as a junior engineer's PR, plus extra checks for hallucinated APIs and scope creep. I use AI for first-pass review and test scaffolding, but human judgment on merge decisions. For refactors, I require green tests before and after, one change type per session."

Senior signal: Share a specific rejection story: what the AI got wrong, why you restarted, and what context was missing. Shows you use AI productively without trusting it blindly.