AI-Generated Code Audit Checklist | Aatvi Production Readiness Framework v1

AI-generated code should be treated like code from an unknown third-party contractor: useful, fast, and not automatically trusted. The right audit is a structured review of whether the app can handle real users, real data, and operational pressure.

Aatvi Production Readiness Framework v1 turns this AI-generated code audit checklist into a record of evidence, unknowns and decisions. It is a public review aid, not a claim that Aatvi has inspected a particular application.

Download the Framework v1 review worksheet (CSV). Open it in a spreadsheet or text editor. The blank rows contain prompts, not findings or a score.

The 60-second answer

For an example of how checklist findings become a launch decision, see the illustrative audit report.

Before shipping an AI-generated app, review authentication, authorization, secrets, input validation, data exposure, dependency risk, tests, observability, deployment settings, rollback paths, and code ownership. Record the evidence and owner for each area. Unknowns are work to investigate, not proof that a control is either present or absent.

How to use this framework

1. Name the application, release scope, data handled, environment and reviewer. Avoid putting credentials or personal data in the worksheet.
2. For each of the ten areas below, reproduce a representative check and record an evidence reference: a test result, reviewed configuration, code location, deployment record or a sanitized screenshot. A statement that a feature exists is not evidence that its boundary works.
3. Mark each area verified, gap, unknown or not applicable. “Verified” means the cited evidence supports the specific release scope; it is not a general security certification. Explain any “not applicable” decision.
4. For every gap or unknown, name the affected user or data boundary, an owner, the proposed action and how it will be retested. Keep the raw evidence in a suitably access-controlled place; the public worksheet only needs references.
5. Decide whether to hold launch, fix and retest, or proceed with documented residual risk. A missing server authorization boundary, exposed live secret, cross-tenant data access or untested critical transaction calls for a hold until corrected and independently retested. Other findings require an explicit owner and risk decision tied to the release. Reassess after material code, configuration or scope changes.

This method deliberately has no numerical safety score. Severity depends on actual exploitability, data sensitivity, release scope and compensating controls; counting checked boxes cannot establish readiness. A qualified reviewer must examine the system and make the final launch decision.

Start with one important user flow

Choose a flow that crosses an important boundary, such as reading a workspace record, changing an administrator setting or processing a payment event. Write down who may perform it, what must be rejected and which evidence will support the decision. Use authorized test accounts and non-production data.

For a workspace-record check, record: the permitted user and workspace; an attempted request from a different workspace; the expected denial; the observed result; and the test or code reference. Mark the result unknown until you have inspected the evidence. A successful check supports this specific boundary; it does not verify the rest of the application.

1. Authentication and authorization

Check whether the app has a coherent identity model, not just a login screen.

• Every protected route should enforce authentication on the server, not only in the client UI.
• User roles should be explicit and tested.
• Tenant or account boundaries should be impossible to bypass by changing an ID in the URL.
• Session expiry, token refresh, logout, and password reset flows should behave predictably.
• Admin features should have separate authorization checks, not just hidden navigation.

AI tools often generate a happy-path auth flow and then miss the uncomfortable cases: stale sessions, deleted users, cross-tenant access, direct API calls, and privilege changes after login.

Evidence to keep: a role and data-boundary map plus repeatable anonymous, expired-session, cross-user and cross-tenant API tests. Record the server or database rule that rejects each forbidden request.

2. Secrets and environment configuration

AI-generated prototypes frequently leak secrets because the tool optimized for a working demo. For a hands-on vulnerability breakdown across database policies, client secret prefixes, and role spoofing, see our guide on 12 critical security flaws in vibe-coded apps.

• Search for API keys, service tokens, private URLs, database credentials, and webhook secrets.
• Confirm secrets are loaded from environment variables or a secrets manager.
• Make sure client-side bundles do not include server-only keys.
• Rotate any credential that was pasted into a prompt, committed to Git, or shared with an AI coding tool.
• Separate development, preview, and production configuration.

Any secret that touched the generated repo should be assumed exposed until proven otherwise.

Evidence to keep: a dated repository/history and built-bundle scan, inventory of where each secret is stored, and revocation or rotation records for any exposed credential. Keep secret values out of the worksheet.

3. Input validation and output handling

AI-generated code often trusts inputs because generated demos start from ideal data.

• Validate request bodies, query parameters, route params, uploads, and webhook payloads.
• Sanitize rendered user content to prevent XSS.
• Use parameterized queries or ORM-safe methods for database access.
• Check file upload type, size, storage location, and access policy.
• Validate LLM outputs before passing them into code execution, SQL, browser automation, workflow tools, or customer-visible messages.

This matters even more for LLM apps. OWASP lists prompt injection, insecure output handling, supply-chain vulnerabilities, sensitive information disclosure, excessive agency, and overreliance among the major LLM application risks.

Evidence to keep: negative tests for malformed inputs, unauthorized uploads, unsafe rendered content and untrusted model output reaching tools or database operations. Include the validation boundary and expected rejection.

4. Dependency and supply-chain risk

The fastest AI-generated apps often carry unused packages, stale boilerplate, and risky transitive dependencies.

• Run dependency audit tools for the package manager in use.
• Remove unused packages and generated examples.
• Check whether dependencies are maintained and license-compatible.
• Pin runtime versions for Node, Python, package managers, and deployment images.
• Generate or update an SBOM if customers, investors, or enterprise buyers will ask for one.

Do not treat a clean install as evidence of safety. It only proves the dependency graph resolves.

Evidence to keep: the lockfile and runtime pins, a dated dependency advisory review, a record of unused package removal and decisions on unresolved advisories. An SBOM can help, but does not replace review.

5. Data model and privacy

Many AI-built MVPs have a database schema that works for the first demo and fails under real customer behavior.

• Identify all personal, customer, financial, operational, and proprietary data.
• Confirm which tables are public, private, tenant-scoped, or admin-only.
• Check delete, retention, export, and account-closure behavior.
• Confirm backups, migration paths, and seed data do not expose real customer records.
• Make sure analytics and error reporting do not capture secrets or personal data.

If the app handles payments, health records, HR records, children, regulated workflows, or customer secrets, do not launch without a privacy and security review.

Evidence to keep: a data-flow and retention map, access-control test results for each data store, a restore test and a redacted example of a delete or export request. Review analytics and logs for accidental sensitive-data capture.

6. Business logic and edge cases

AI code is usually strongest on the visible happy path and weakest where product rules get specific.

• List the core workflows users will pay for.
• Test empty states, duplicate submissions, race conditions, retries, timeouts, and partial failures.
• Check payment, billing, refund, subscription, invitation, and notification logic.
• Verify date, timezone, currency, and locale behavior.
• Run the app with realistic bad data, not only clean seed data.

If the team cannot explain the business rules from the code, the app is not ready to own customer commitments.

Evidence to keep: acceptance cases for the critical workflows, including duplicate requests, retries, timeouts and partial failures, with observed results and the rule owner who confirmed the expected behavior.

7. Test coverage

Intermittent failures need more than reruns. The guide to deterministic and non-deterministic systems explains which inputs and side effects must be captured for reproducible tests.

Generated tests often assert that generated components render. That is not enough.

• Add unit tests around critical business logic.
• Add integration tests for API routes and database writes.
• Add end-to-end tests for login, core workflow, payment or submission paths, and admin controls.
• Add regression tests for every bug found during the audit.
• Run tests in CI with the same package manager and runtime used for production.

The goal is not maximum coverage. The goal is confidence around the parts that can break trust, money, data, or launch.

Evidence to keep: CI run links and test names for authentication, data boundaries, critical writes and recovery paths. Record missing scenarios instead of using a coverage percentage as a readiness decision.

8. Observability and incident handling

If nobody can see failures, the first real monitoring system will be users complaining.

• Add structured logging for important server events.
• Configure error reporting for frontend and backend failures.
• Track key product events and conversion paths.
• Add uptime checks for public pages and critical APIs.
• Define alert ownership, escalation, and rollback steps.

An AI-built app can pass local testing and still be impossible to operate. Production readiness includes knowing what is failing and who owns the response.

Evidence to keep: sample redacted logs and alerts, an exercised incident contact path, and a failure drill showing who receives the signal and what action follows.

9. Deployment, rollback, and environments

Launch risk often hides in deployment defaults.

• Confirm production build, lint, tests, migrations, and type checks run before deploy.
• Separate preview and production databases.
• Confirm environment variables are present in every target environment.
• Check cache headers, robots rules, sitemap output, canonical URLs, and redirects.
• Document rollback steps before the first public launch.

If a launch requires one person's laptop knowledge, the process is not production-ready.

Evidence to keep: the release pipeline result, environment separation check, migration and rollback rehearsal, and a record of who can perform recovery without a developer's local machine.

10. Maintainability and ownership

If fixes repeatedly expose deeper design problems, use the rescue-versus-rewrite decision guide to assess whether the foundation is worth keeping.

AI-generated code can be useful and still be hard to own.

• Identify large files, duplicated logic, dead code, and unclear boundaries.
• Replace prompt-shaped abstractions with domain-shaped modules.
• Add README notes for setup, architecture, deployment, and known risks.
• Make sure the team can explain how the app works without asking the original prompt history.
• Decide who owns future security updates, dependency updates, and production incidents.

Code that nobody understands is not an asset. It is operational debt with a UI.

Evidence to keep: an architecture and ownership note, reproducible setup steps, a current risk register and named owners for dependencies, security updates and incidents.

Red flags that require rescue before launch

• No server-side authorization on protected data.
• Secrets or production credentials in the repo.
• Payment, auth, or admin flows with no tests.
• Customer data visible through predictable IDs.
• Generated database rules nobody has reviewed.
• Build passes only on one machine.
• No rollback path.
• No owner for incidents.

One red flag does not always mean rewrite. It does mean the team should stop treating the app as launch-ready. If runtime crashes or timeouts are already occurring, consult our guide on debugging a broken vibe-coded app, inspect our pre-launch audit runbook for Cursor-built codebases, or read our buyer's guide to vibe coding cleanup services to understand deliverables and timelines.

Limits of the worksheet

The blank Framework v1 worksheet helps a team organize a review. It does not inspect code, execute tests, verify a system's security, certify compliance, or predict production behavior. Its status fields are observations for one stated release scope at one point in time. The reviewer must validate evidence, especially for authentication, data access, secrets and critical transactions; record exceptions and revisit the decision when the system changes.

When Aatvi helps

Aatvi's AI Code Rescue service turns this checklist into a focused audit and stabilization plan. The output is a ranked report: launch blockers, important fixes, cleanup work, and the evidence needed to decide whether to rescue or rewrite.

For broader implementation work, see AI software development and AI product development.

Source notes

• Google Search Central's AI search guidance says AI search success still depends on original, useful content that helps visitors.
• Google's robots.txt documentation explains that crawlers use the first most-specific matching group, so explicit bot groups must include the disallows they need.
• Veracode's 2025 GenAI Code Security Report found risky security flaws in 45% of AI-generated-code tests.
• OWASP's LLM Top 10 lists risks including prompt injection, insecure output handling, supply-chain vulnerabilities, sensitive information disclosure, excessive agency, and overreliance.
• TechTarget's vibe-coding guidance highlights the risk of generated apps missing security practices when the developer did not ask for them.