Checklist for Reviewing AI-Generated Code

AI-written code usually works on the "happy path": the user fills in fields correctly, asks for their own data, and the network never drops. Problems appear everywhere else: a user changes a number in the URL, a field is empty, an error message exposes server details, a secret key is pasted into a file. This checklist gives you a fixed set of questions to ask of every change before it reaches real users.

How to review

1. Functionality

• The code does only what was asked and did not add unrequested features, files or pages.
• You actually ran it on your machine or a test environment, rather than taking the tool's word that it "works".
• Edge cases are covered: empty list, a single item, very large values, dates across time zones.
• Nothing that used to work was removed or broken (check files that changed when you did not expect them to).
• No "invented" functions or libraries that do not actually exist.

2. Input validation

• Everything from the user (forms, URLs, files, request headers) is treated as untrusted.
• Validation happens on the server, not only in the browser; browser validation is a convenience, not protection.
• For each field: type, maximum length, allowed format, and whether it is required.
• Database queries are parameterised, not strings built from user input.
• User input shown on the page is escaped, not inserted as raw HTML.
• File uploads are limited by type and size, and no uploaded file is ever executed.

3. Authentication and authorisation

• Every route that shows or changes data first checks that the user is signed in.
• It then checks that this user owns this specific record or has the required role (see the permissions matrix, if there is one).
• You tried changing the ID in the URL or request to another user's ID, and the result was a refusal.
• Hiding a button is not a permission; the server refuses the request even when sent directly.
• In databases that support row-level security, policies are enabled and tested with two different users.
• Responses do not return fields the user does not need (password hashes, internal notes, other users' data).

4. Secrets

• No keys, passwords or access tokens written in the code; all of them live in environment variables or a secrets store.
• The local environment file is excluded from the repository, with an example file listing variable names only.
• No secrets in browser code: anything sent to the browser is visible to every visitor.
• Keys have the narrowest permissions possible (a read-only key if that is enough).
• If a key appeared in code, in a chat with a tool or in a log, it is exposed: rotate it immediately; deleting it is not enough.

5. Dependencies

• Every new library the tool added actually exists, with its exact name, from its official source (look-alike names are a known trap).
• The library is truly needed, and a few lines of code or a library already in the project would not do.
• It is maintained with recent updates, and the package manager's vulnerability check shows no serious issues.
• The lock file is updated and committed with the change.

6. Errors and logs

• Errors are caught and do not bring down the whole application.
• The user-facing error message is clear, in the user's language, and reveals no technical details (file paths, queries, versions).
• Logs contain enough to diagnose, and no passwords, keys or full personal data.
• External calls (email, payments, APIs) have a timeout and defined behaviour on failure.
• No errors silently "swallowed" by an empty catch block.

7. Tests

• The change has at least one happy-path test and one refusal test (unauthorised user, invalid input).
• Tests actually fail when you break the code on purpose (a test that never fails tests nothing).
• The tool did not "fix" a failing test by changing the test to match the bug.
• All existing tests still pass.

8. Accessibility (for interfaces)

• Real interactive elements (a button for actions, a link for navigation), not generic elements with a click handler.
• Every field has an associated label, and error messages are announced to screen readers.
• Everything is reachable by keyboard, with a visible focus indicator.
• Images have alt text, and contrast is sufficient.
• Right-to-left direction is correct on Arabic pages, and the page language is declared.

9. Deployment

• Environment variables are set in production, not left at test values.
• Debug mode is off in production.
• Database migrations are reviewed, do not delete data, and a recent backup exists before they run.
• There is a known way to roll back to the previous version if the deploy fails.
• After deploying: a quick check of the core paths on the live site.

Annotated example 1: a route that returns a booking

// GET /api/bookings/:id
app.get('/api/bookings/:id', async (req, res) => {
  const booking = await db.bookings.findById(req.params.id);   // [1]
  res.json(booking);                                           // [2]
});

const SMS_API_KEY = 'sk_live_EXAMPLE_ONLY';                    // [3]

// GET /api/bookings/:id
app.get('/api/bookings/:id', requireLogin, async (req, res) => {   // [1]
  const booking = await db.bookings.findById(req.params.id);
  if (!booking || booking.patientId !== req.user.id) {              // [2]
    return res.status(404).json({ error: 'Not found' });
  }
  res.json({                                                        // [3]
    id: booking.id,
    date: booking.date,
    status: booking.status,
  });
});

const SMS_API_KEY = process.env.SMS_API_KEY;                        // [4]

Annotated example 2: a contact form

// POST /api/contact
app.post('/api/contact', async (req, res) => {
  const { name, phone, message } = req.body;                  // [1]
  await db.query(
    "INSERT INTO messages (name, phone, message) VALUES ('" +
    name + "', '" + phone + "', '" + message + "')"           // [2]
  );
  res.send('Thanks ' + name);                                 // [3]
});

// POST /api/contact  (rateLimit: illustrative, use your framework's limiter)
app.post('/api/contact', rateLimit({ max: 5, perMinutes: 10 }), async (req, res) => {
  const name = String(req.body.name || '').trim();                 // [1]
  const phone = String(req.body.phone || '').trim();
  const message = String(req.body.message || '').trim();
  const phoneOk = /^[0-9+ ]{7,20}$/.test(phone);
  if (!name || name.length > 80 || !phoneOk || message.length > 1000) {
    return res.status(400).json({ error: 'invalid_input' });
  }
  await db.query(                                                  // [2]
    'INSERT INTO messages (name, phone, message) VALUES ($1, $2, $3)',
    [name, phone, message]
  );
  res.json({ ok: true });                                          // [3]
});

Self-review prompt

Use it after the tool writes the code, in a fresh chat or with a second tool. The result helps you; it is not a final verdict. The decision belongs to the reviewer.

Review the following code as a strict security reviewer. Do not rewrite it all.
1) Explain what it does in 5 lines.
2) For each route: does it check sign-in? Ownership or role?
3) Where is user input used without validation or escaping?
4) Are any secrets or settings hard-coded?
5) What happens when each external call fails?
6) Which three most important tests are missing?
Order findings from most to least serious, with line numbers.
Code: [paste code after replacing any real key or data with fake values]

When to stop and call a professional

• The platform stores health or financial data, or data about minors.
• It takes payments or manages balances.
• You built your own sign-in or encryption instead of using a well-known service or library.
• You could not understand the tool's explanation of a sensitive part of the code.
• Something odd appears in the logs or database with no explanation.

Completion checklist before merging

• You understand what the code does and ran it yourself.
• Inputs are validated on the server; queries are parameterised.
• Every route checks identity and ownership or role, and you tried access as another user.
• No secrets in code, browser code or logs.
• New dependencies are real, necessary and maintained.
• Error messages reveal no technical details.
• At least one success test and one refusal test; all existing tests pass.
• Interfaces work with keyboard and screen reader.
• The deploy has a backup and a rollback path.
• If data is sensitive: a professional security review is scheduled.