How to review AI-generated code before shipping: permissions, tests and recovery

Shipping AI-written code requires evidence about scope, important failure cases and recovery. A successful build, a working page or an assistant’s completion message cannot make that decision alone. Choose checks by impact and keep unverified items visible in the release record.

The original review sources were checked on 2026-10-10; the site positioning case below was recorded on 2026-11-06. The authorization and migration scenarios below are instructional examples, not vulnerabilities found in your project or product benchmarks. This guide starts with a delivered change; the first coding task walkthrough (Chinese) covers writing the initial brief.

Establish exactly which version is under review

Read the repository’s release instructions. Record the target environment, current production version and proposed code and configuration. Preserve other people’s unfinished changes instead of resetting or committing them to obtain a clean workspace.

These commands inspect an ordinary local Git working tree:

git status --short
git diff --stat
git diff
git diff --cached --stat
git diff --cached

The Git diff reference distinguishes working-tree changes against the index from staged changes inspected with --cached. Reading only one misses part of the work. Inspect untracked files identified by status separately; compare already committed branch changes against the confirmed baseline as well. Evidence must describe the version being shipped. Later changes require rechecking affected behavior.

Classify each changed file as requirement, test, dependency, configuration or migration. Extra dependencies, large lockfile changes, disabled checks, removed tests, permission changes and new environment variables need an explanation tied to the task.

Match review depth to impact

This is a triage table, not a security certification. Google’s review guidance emphasizes design, user behavior, edge cases and concurrency; the table turns those concerns into release evidence.

Focused checks are enough for small, low-impact changes; do not create a mirror-image test suite for a text edit. Conversely, screenshots cannot establish authorization or data integrity. When a change spans categories, use the more consequential one to determine review depth.

Scenario one: the button is hidden but the API still deletes another user’s draft

Suppose the rule is “members may delete only drafts they created.” The generated frontend hides the button for other authors, and an administrator’s happy path works. Neither observation establishes server enforcement.

In your own test environment, prepare accounts A and B, a draft for each, and a published object that policy forbids deleting. Use disposable test data and the project’s test client, not real customers’ records.

Exact response codes follow the API contract. A denial might use 403 or a 404 that conceals object existence. Evaluate authorization and side effects rather than memorizing one code.

OWASP’s authorization guidance calls for default denial and permission checks on every request for the specific object or function. Random identifiers, client validation and button visibility are insufficient. Inspect list, export, background-job and cache paths that expose the same data.

If only the frontend repository is available, record server authorization as unverified. Do not turn a frontend pass into approval of the whole feature.

Scenario two: reverting code does not restore lost data

Suppose a post’s published boolean becomes a status field. Adding a default of draft and immediately dropping the old column can incorrectly turn historical published posts into drafts. A successful application startup does not establish correct migration, and an older release may still depend on the removed column.

Prisma’s expand-and-contract explanation describes introducing new structures, migrating data and clients, then removing old structures. Apply that review approach; the table is not production SQL. Locking, transactions and backfill mechanics depend on the actual database.

Rehearse on representative, sanitized data in an isolated environment. Compare state distributions, important objects, null values and new writes, not only total row counts. After partial failure, identify completed stages and a safe continuation rather than blindly rerunning everything.

Describe code rollback and data recovery separately: which release can run, what recovery point exists, how later writes are preserved or reconciled, and who performs recovery. A backup’s existence is not evidence that restoration works. Data lost without a usable backup will not return when Git is reverted.

Read what the passing tests actually assert

Run required project checks and add focused scenarios where the change warrants them. Type checking, building and behavioral tests establish different things; none replaces the others.

For a safely reproducible defect, demonstrate that the relevant check fails against the old behavior and passes after the fix. Use a separate test copy when needed; do not damage the working tree or production state to reproduce it. Separate pre-existing baseline failures from new failures. An unavailable environment means not run, not passed.

Another human or AI reviewer can help find issues, but findings should name a path, trigger and evidence. Several reassuring reviews do not substitute for an executed negative case.

A real site case: filtering worked, but old category links landed behind the header

During pre-release checks of our prompt library on 2026-11-06, we found PL-QA-01: an old category link selected the right results, yet its category button and the start of the results were covered by a fixed header. This is a low-impact UI change from the triage table, requiring focused browser checks. It does not reduce the review needed for authorization or migrations. This is a record of a project defect and fix, not a comparison of models or prompts and not evidence of a prompt improving performance.

Reproduce the obstruction before inspecting the fix

Open the offline anchor comparison, or save the HTML and open it in a browser. It contains only HTML/CSS: no scripts, external resources, forms, API keys or clipboard access. It demonstrates the scrolling mechanism, not the library’s filtering logic, and is not the original test page.

1. Select “失败 / Before” in the fixed header. The category button scrolls to the top and is covered. Scroll up slightly to find the obscured button.
2. Select “修复 / After”. A 100px scroll margin keeps the target button below the header. The relevant difference is whether the category button receives scroll-margin-top.
3. Repeat both links at a 390×844 viewport. Judge whether the button and first card are visible, not merely whether the URL fragment changed. The demonstration does not compute a pass result; record your browser, viewport and observation if behavior differs.

To check the full path in your own project, use an isolated test copy. Load a new document with a category fragment, then separately enter a query with no matches and change only the fragment through an in-page link or the address bar without reloading the document. After scrolling settles, check the cleared query, selected category, result count, target button and first card. The fixed live site is not a reproduction of the old failure; do not roll production back for this exercise.

Cause and minimal change

The previous CSS gave template cards (.prompt) a scroll margin, but the category fragment targeted a button with data-library-filter. Filtering assertions could pass while the visible landing position failed. The fix applied the existing 100px margin to category buttons without changing filter logic, template text or the copy controller.

Before:

#prompt-library .prompt {
  scroll-margin-top: 100px;
}

After:

#prompt-library .prompt,
#prompt-library [data-library-filter] {
  scroll-margin-top: 100px;
}

This is a formatted excerpt of the actual project change. The CSS scrolling specification describes using scroll-margin to adjust the area considered for scrolling into view. The 100px value was retained from this site’s layout; it is not a universal header size. Recheck after changing typography, zoom or navigation layout.

On the old candidate, directly loading #writing on desktop returned the correct three results. However, the button extended from approximately −0.02px to 43.98px while the header ended at 73px, covering the entire button. The first card started at 65.98px, with roughly 7px obscured. The old report also recorded the issue when switching a residual query to #image or #agent. It did not contain a complete sixteen-case pre-fix failure matrix, so we cannot claim all sixteen failed before the fix.

What the sixteen regression cases checked

Historical retest: all 16 cases passed, eight on desktop and eight on simulated mobile. On 2026-11-06, an independent Chromium check on macOS exercised four categories through two paths: opening a category link directly, and switching to one after a search with no matches. Every case cleared the query and selected the expected category and result count.

• Desktop 1200×800: 8/8. The header ended at 73px, the category button spanned 99.98–143.98px, and the first card started at 165.98px.
• Simulated mobile 390×844: 8/8. The header ended at 65px, the category button spanned 100.20–144.20px, and the first card started at 217.20px.

At both sizes, the whole button and the start of the first card were visible below the header, with no horizontal page overflow. These are CSS pixels rounded to two decimals, measured after scrolling had settled for more than 350ms. The full sanitized 16-case record (JSON) lists the entry path, category, result count and coordinates for each case. These historical measurements come from the site candidate; the simplified comparison above does not produce them.

Only this CSS selector changed between candidates; the other 353 source files were byte-identical. Independent retesting rebuilt the candidate and checked these sixteen cases plus representative first-screen and template-anchor behavior. Type checks, 28 tests and the site audit were inherited from the previous candidate, not claimed as rerun. The same sixteen positioning cases also passed after publication that day; those production checks are separate evidence from the candidate table.

Keep the conclusion separate from untested behavior

The practical lesson is that correct filtering does not establish a visible reading position. For this class of change, add an explicit acceptance criterion that the target and its content appear below the fixed header. A new testing platform is unnecessary.

Mobile coverage used viewport simulation. Physical phones, Safari, screen readers and every zoom combination were not tested. These sixteen cases do not establish a defect-free site, prompt quality, user growth or commercial results.

Make the release decision from an evidence record

Download the bilingual release review worksheet. It starts blank, with no pre-approved checks. For each item, record the object under review, command or action, environment, observed result, evidence location and unverified boundary. Exclude secrets and real customer data.

Before shipping, establish:

1. The intended behavior and exact code/configuration scope.
2. Whether important forbidden behavior is prevented and failures leave correct state.
3. Which required checks ran against the final version and whether missing evidence blocks release.
4. Whether production configuration is ready, with separate code and data recovery plans.
5. Which URLs, critical paths and error signals will be checked after release, and who can stop further exposure.

Unverified cross-account access, unknown historical-value mapping, untested critical failures or a rollback incompatible with the data are blocking findings. Relabeling them as later improvements does not resolve them. Limited rollout still needs an explicit audience and stop conditions.

For model output written to storage, also use the structured-output acceptance guide. For replayed requests and external actions, inspect retry budgets and business idempotency. These tables describe checks to perform, not checks already executed on your project.