How to Review AI-Generated Code

Treat AI-generated code as an untrusted proposal. Read every line before execution, compare it with the specification, identify inputs, outputs, assumptions, dependencies, and effects, then test expected, boundary, and invalid cases.

Do not accept code you cannot explain. Passing one sample is evidence about one sample, not proof of general correctness or safety.

Confirm that generated code is allowed

Course policies can distinguish among explanation, completion, code generation, review, and disclosure. Before generating or using code, determine:

• whether generation is permitted for this task;
• which parts must be independently authored;
• whether prompts and assistance must be disclosed;
• whether course code may be uploaded; and
• which tools are approved.

If generated code is prohibited, a careful review does not make submission permissible. Ask the instructor about ambiguity.

Read before running

Inspect the code as text. Mark every operation that can:

• read, write, move, or delete files;
• access a network;
• run another process;
• install or import a dependency;
• use credentials or personal data;
• modify persistent state; or
• consume substantial resources.

Unknown code should not begin with administrator access or real private data. Use a disposable environment and fictional test inputs when course rules permit execution.

Map requirements to code

Write a short record titled Code review — [function or task]. For each requirement, write a paragraph naming the code responsible, the test or other evidence that checks it, and the result: supported, missing, uncertain, or needs revision. Include requirements that have no responsible code; that is a finding, not a blank cell.

For example, a paragraph can say that the loop and division return 3 for [2, 4], while a separate paragraph says that no code currently rejects an empty list. Do not fill in a Markdown review table.

This prevents attractive extras from hiding a missing requirement. Also identify code with no requirement. Unnecessary behavior expands the test and security surface.

Review naming and structure, but do not confuse style with correctness. A well-formatted function can still implement the wrong behavior.

Trace inputs, outputs, and state

For each function or module, state:

• accepted input type and range;
• returned value or produced artifact;
• mutation of arguments or global state;
• errors that can occur;
• behavior for missing or malformed input; and
• assumptions about ordering, encoding, time, units, or environment.

Consider:

def average(values):
    total = 0
    for value in values:
        total += float(value)
    return total / len(values)

Questions:

• Are numeric strings allowed by the specification?
• What happens for an empty list?
• Should nonnumeric values be rejected, skipped, or reported?
• Does converting with float lose required precision?
• Which error should the caller receive?

The code’s implicit answers may differ from the assignment.

Check dependencies and APIs

For every import, package, command, or API:

1. confirm that the dependency is permitted and needed;
2. verify its real name in the official source;
3. check the installed or required version;
4. confirm the used method and arguments in official documentation;
5. identify network, license, update, and data obligations; and
6. remove unjustified dependencies.

AI systems can produce nonexistent methods or combine syntax from different versions. A plausible name is not evidence.

Use the course environment rather than installing a package to satisfy code that never needed it.

Test expected, boundary, and invalid cases

Derive tests from requirements before seeing output.

For the average function:

Add tests for units, ordering, duplicate values, large inputs, and precision only when the specification makes them relevant.

A passing suite shows that selected cases passed in one environment. It does not prove the absence of all defects.

Review security and scope

Ask:

• Can input change a path, query, command, or output destination?
• Are secrets embedded in code or printed?
• Is private data sent to an external service?
• Are permissions broader than required?
• Can a loop, request, or allocation grow without a reasonable bound?
• Does error handling hide failure?
• Does the code perform work outside the stated task?

Do not “sandbox” by assumption. Understand what the selected environment isolates and what it can still access.

NIST’s Generative AI Profile describes confabulation as confidently presented erroneous or false content. This sourced limitation supports review; it does not predict which line is wrong. Only specification comparison, documentation, and tests address the particular code.

Require an independent explanation

Without looking at the AI response, explain:

1. the purpose of each function;
2. the data flow;
3. every assumption;
4. why each dependency is present;
5. what can fail;
6. how the tests cover requirements; and
7. what you changed and why.

Then rewrite the smallest part needed to make the code conform. Keep a diff. Large unexplained rewrites make review harder.

If you cannot explain a line, do not submit or maintain it. Consult course materials, official documentation, or an instructor.

Use the checklist

## AI-generated code review

Course permission and disclosure:
Specification:
Every line read:
Inputs and outputs:
State and side effects:
Assumptions:
Dependencies and official documentation:
Expected tests:
Boundary tests:
Invalid-input tests:
Security and privacy:
Unnecessary scope:
Independent explanation:
Decision: accept | revise | reject

Acceptance means the reviewed version meets the known requirements and policy. It does not transfer authorship or remove disclosure obligations.

Common mistakes

• Running before reading. Inspect effects first.
• Testing only the supplied sample. Include boundaries and invalid input.
• Assuming imports exist. Verify official documentation and version.
• Keeping impressive extra features. Remove unjustified scope.
• Ignoring data flow and side effects. Trace them explicitly.
• Treating tests as proof. State what they do and do not cover.
• Explaining only the high-level idea. Account for every line.
• Using review to bypass policy. Permission comes first.

Do this now

Apply the checklist to the average example or another permitted small function. Identify one hidden assumption, write three tests, and decide whether to revise or reject it.

Log what you learned

The code-review record is the learning log. Add dependency, test, and security results only after the corresponding checks, then save the final decision and independent explanation.

Next, learn why AI can sound confident while producing a false claim or fragile solution.