How to Review AI-Generated Code Before Deployment

How to Review AI-Generated Code Before Deployment

AI-generated code is ready to deploy only when accountable humans can explain the system, verify its requirements, review the actual changes and dependencies, test misuse and failure, protect data and secrets, validate accessibility and operations, and prove recovery in the intended environment.

Do not ask the same agent whether its work is secure and treat the answer as approval. A release decision needs independent evidence and an owner who can say no.

Freeze the candidate

Review a specific source revision, dependency set, configuration, and deployment target. If generation continues while review is underway, the evidence no longer describes the candidate.

Record the canonical repository, branch or commit, build command, lockfiles, runtime, infrastructure configuration, environment variables, external services, database schema, and artifact digest where available.

Preserve which changes came from the agent, which came from people, and which tools modified the result. Generated code can be transformed by formatters, package managers, migrations, build systems, and deployment platforms after the visible conversation ends.

Confirm what the software is supposed to do

The release owner needs accepted requirements and prohibited behavior. A working preview is not a substitute.

Trace each high-value user job to an acceptance case. Include invalid input, denied access, duplicate requests, timeouts, partial external-service failure, retry, concurrent activity, data loss, restore, and shutdown where relevant.

If the team cannot state what correct means, it cannot distinguish a plausible implementation from a correct one.

Review the complete change

Read the diff and the resulting files. Do not limit review to the section mentioned in the prompt.

Look for unrelated changes, invented APIs, dead code, placeholder credentials, hard-coded environment assumptions, disabled certificate or authorization checks, unsafe parsing, broad exception handling, swallowed errors, unbounded loops, insecure defaults, silent fallback behavior, generated tests that merely repeat the implementation, and code no maintainer can explain.

Use static analysis, type checking, linting, tests, and platform scans as evidence sources. None is a release decision by itself.

flowchart TD
    A["Frozen source and configuration"] --> B["Requirements and risk classification"]
    B --> C["Code and dependency review"]
    C --> D["Security, data, and accessibility tests"]
    D --> E["Reliability and operations evidence"]
    E --> F["Test intended environment"]
    F --> G{"Accountable owner accepts residual risk?"}
    G -->|"No"| H["Revise or stop"]
    G -->|"Yes"| I["Controlled rollout with monitoring and rollback"]

Inspect every dependency

An agent may add a package because it is convenient or because its training examples used it. That does not establish provenance, maintenance, license compatibility, vulnerability status, or necessity.

Build an inventory of direct and transitive packages. Review package manifests and lockfiles. Record source, version, integrity information, license, known vulnerabilities, release age, maintenance signals, update owner, and a removal or replacement path.

GitHub's dependency review documentation illustrates how a pull request can expose added, removed, and changed dependencies along with vulnerability information. The exact tool is optional. Dependency evidence is not.

The NIST Secure Software Development Framework also emphasizes protecting software, tracking provenance, producing well-secured releases, and responding to vulnerabilities over time.

Trace inputs, permissions, secrets, and data

Draw the system boundary. Identify every user input, file upload, event, webhook, model output, database write, external call, administrative action, and background job.

For identity, test authentication, sessions, authorization, account recovery, privilege changes, and cross-user access. A signed-in user must not gain another user's data by changing an identifier.

For inputs and outputs, test validation, encoding, injection, file type and size, path handling, unsafe rendering, and downstream command or query construction. Error messages should help the user without exposing secrets or internal structure.

For secrets, confirm that credentials were never committed, logged, sent to the model, placed in client code, or shared beyond the required environment. Use least privilege, rotation, access records, and environment separation.

For data, record classification, purpose, minimization, notice, consent, retention, deletion, access, backup, restore, residency, third parties, and incident obligations. Synthetic prototype data does not validate the real-data design.

Replit's current security overview explicitly says AI-generated code still needs security review, especially around authentication, database queries, secrets, and data handling.

Use a defined security standard

The OWASP Application Security Verification Standard provides an open basis for specifying and testing web-application security controls. Choose and record the version and level of rigor appropriate to the system.

If the released application itself uses an LLM or agent, add controls for prompt injection, unsafe output handling, excessive agency, sensitive information, tool permissions, model and data supply chains, unbounded cost, monitoring, and human override. The OWASP GenAI Security Project is a current route for that additional risk.

A platform security scan may find useful issues. It cannot know every business rule, data obligation, abuse path, or architectural assumption.

Validate accessibility as behavior

Generated interfaces often look polished before they work for keyboard or assistive-technology users.

Test semantic structure, accessible names, keyboard order, visible focus, focus movement, error identification, status messages, contrast, zoom, target size, motion, reflow, and screen-reader output. Include disabled, loading, empty, error, and recovery states.

W3C's WCAG 2.2 quick reference is the primary standards route for web accessibility. Automated tools can find some failures, but they do not replace manual and user-centered evaluation.

Test reliability and the real environment

A preview can differ from production in domains, headers, identity, persistence, secrets, queues, caches, scaling, network rules, external services, logging, billing, and failure handling.

Test the actual release configuration before depending on it. Exercise load, concurrency, timeouts, retries, duplicate delivery, idempotency, data integrity, degraded dependencies, backup restoration, rollback, and emergency shutdown in proportion to risk.

Define logs, metrics, alerts, support ownership, cost limits, incident severity, escalation, and response time. Confirm that monitoring does not expose sensitive data.

The presence of a Publish button proves only that a platform can attempt a deployment.

Record the decision and residual risk

The release owner should sign off on the reviewed revision, evidence, open findings, accepted residual risk, rollout, monitoring, rollback, and approvers.

If a material answer is missing, the honest status is not ready.

AI can make the first candidate arrive sooner. It cannot accept the consequences of putting that candidate in front of users. That remains the release owner's job.

This page was developed with AI assistance from the E057 transcript and linked primary sources, then structured for human engineering, security, privacy, accessibility, legal, operations, domain, and editorial review. It is a general framework, not a completed review or deployment authorization.