Testing, Reviewing and Refactoring AI-Generated Code

A developer asks an assistant for a username validator, then asks it to write tests. The tests pass. Everything is green. The validator quietly accepts a username with a newline at the end, which later causes a mismatch in a database lookup.

The tests passed because they were written from the same assumptions as the code. If the model overlooked the case when writing the validator, it very likely overlooked it again when writing the tests. Green tests mean the code does what the tests expect. They do not mean the tests expect the right things.

• Why tests must come from the requirement, not from the code.
• A worked example in which a plausible validator has a subtle bug.
• How to use AI to draft tests and edge cases, and check that the tests are strong.
• How to review AI-generated changes.
• How to refactor safely.

A good test states what should happen, independently of how the code does it. If you write the expected values by running the code and copying its output, you have created a test that can only ever agree with the code. That is called a characterisation test, and it has a legitimate use (pinning down current behaviour before a refactor), but it is not evidence that the behaviour is correct.

So the order matters:

1. Write the requirement in plain words. "A valid username has 3 to 16 characters, using only lowercase letters, digits and underscores."
2. Derive test cases from the requirement, including boundaries and nasty inputs.
3. Then generate or write the code, or test the code you already have.

Ask the AI to help with step 2 without showing it the implementation:

Requirement: a valid username has 3 to 16 characters, using only lowercaseletters a-z, digits 0-9 and underscores. List test cases as a table: input, expected result (valid or invalid), and thereason. Cover boundaries (length 2, 3, 16, 17), invalid characters, emptyinput, whitespace, a trailing newline, and non-ASCII letters.

Because the assistant has not seen the code, it cannot just mirror it. You then review the table: do you agree with each expected result?

Here is a plausible first draft of the validator, the kind of thing an assistant might write, alongside a stricter version. The program tests both on the same five inputs.

# File: username_check.pyimport re# A plausible first draft from an assistant: 3 to 16 lowercase letters, digits or underscores.DRAFT = re.compile(r"^[a-z0-9_]{3,16}$")# A stricter version: fullmatch has no trailing-newline loophole.STRICT = re.compile(r"[a-z0-9_]{3,16}")def draft_is_valid(name):    return bool(DRAFT.match(name))def strict_is_valid(name):    return bool(STRICT.fullmatch(name))cases = [    ("priya_01", True),    ("ab", False),    ("Priya", False),    ("a" * 17, False),    ("priya_01\n", False),]print(f"{'input':<16}{'expected':<10}{'draft':<8}{'strict':<8}")for name, expected in cases:    label = repr(name) if len(name) < 12 else repr(name[:9] + "...")    print(f"{label:<16}{str(expected):<10}{str(draft_is_valid(name)):<8}{str(strict_is_valid(name)):<8}")

input           expected  draft   strict'priya_01'      True      True    True'ab'            False     False   False'Priya'         False     False   False'aaaaaaaaa...'  False     False   False'priya_01\n'    False     True    False

The draft gets four of the five cases right, and a quick glance at the first four rows might make you stop. The fifth row reveals the bug: the draft accepts 'priya_01\n'. In Python's regular expressions, $ matches at the end of the string and also just before a trailing newline. So the pattern considers a name with a newline valid. The stricter version, using fullmatch, requires the whole string to match.

Two lessons:

1. The bug lives in the edge, not the middle. Tests drawn only from "normal" examples (the first four rows) pass. A requirement-driven list that includes "trailing newline" catches it.
2. Ask the assistant to explain why its code handles each case. If you ask "how does this treat a trailing newline?" with the code visible, a good answer would notice $, and a weak one would not. Test it.

(The details of regex behaviour vary between languages. Always check the documentation for the one you use.)

Run through these for any function, and ask the assistant to propose more for your specific one.

A test suite that cannot fail is useless. A cheap check, a manual form of what is known as mutation testing: after the tests pass, change the code to be wrong and see whether any test fails. Remove a boundary check, flip a comparison, delete a branch. If everything stays green, your tests do not cover that behaviour.

Do this especially for AI-generated tests, which often have these weaknesses:

• Tautologies: the test recomputes the answer using the same logic as the code.
• Over-mocking: everything is replaced by fake objects, so the test checks the mocks, not the behaviour.
• Weak assertions: assert result is not None when the exact value matters.
• Happy path only: no empty, invalid or extreme input.
• Copied outputs: expected values pasted from the code's own output.
• Passing by coincidence: a test that would pass for several wrong implementations.

Coverage numbers do not fix this. Code can be fully covered and badly tested, because coverage counts lines that ran, not behaviours that were checked.

AI changes can be large and plausible-looking, and reviewers tend to skim what looks fluent. Slow down and use a checklist.

A tip for large diffs: ask the assistant to produce a change summary (what changed and why), then check whether the summary matches the diff. If the summary mentions something the diff does not contain, or the diff contains something the summary does not mention, investigate.

An assistant can be a useful extra reviewer, especially for catching things humans tire of: inconsistent naming, missing error handling, forgotten edge cases. Make it useful:

Review the diff below as a careful senior engineer. Focus on: correctness foredge cases, error handling, security, and anything that is changed but notmentioned in the description. For each concern, quote the line, explain therisk and say how confident you are. If you find nothing in a category, say"no issues found in this category", and do not invent concerns.[paste diff]

Treat the result as leads to check:

• Some points will be wrong (false positives). Verify before acting.
• It will miss things. A clean report is not a clearance.
• It may praise what is merely familiar. Keep your own review.
• Do not let "the AI approved it" replace a human sign-off where your team requires one.

Refactoring means changing the structure of code without changing its behaviour. AI is good at proposing restructurings, and the risk is that it changes behaviour too, in subtle ways.

1. Have tests first. If there are none, write characterisation tests that pin down the current behaviour, including its oddities.
2. Ask for a plan, not the finished result. "List the refactoring steps you would take, smallest first, and what behaviour each preserves."
3. Take one step at a time, and run the tests after each.
4. Commit after each green step, so you can undo.
5. Compare before and after for performance if it matters, using a measurement.
6. Review the diff for behaviour changes, such as altered error messages, ordering, rounding or default values.
7. Stop at "good enough." Endless AI-suggested rewrites increase risk and review burden.

• Generating tests from the code, then treating them as proof.
• Never trying to break the code, so you never learn whether the tests can fail.
• Skimming big diffs because they look tidy.
• Accepting a new dependency without checking it.
• Treating an AI review as a clearance.
• Refactoring without a safety net.
• Chasing coverage numbers instead of behaviours.

• Next: Security and Licensing Risks of AI-Generated Code looks at the risks that tests often miss.
• For a larger-scale view, see Vibe Coding vs Responsible AI-Assisted Building.
• For test-first habits in general, keep a checklist in your personal AI playbook.