QA for AI-Generated Code: What Breaks Before Launch and How to Catch It

An AI-assisted prototype from Lovable, Cursor, Claude Code, Replit, or another tool may reach a demo quickly, but production readiness depends on the intended users, data, exposure, architecture, and evidence. The gap between "it works on my screen" and "it meets defined quality, security, and operating requirements" must be verified rather than inferred from how the code was produced. This is a risk-based QA process for AI-assisted builds before release.

None of this is an argument against building with AI. We build with it too. It is an argument for testing the output the same way you would test any code that is about to touch real money, real data, and real users.

Why can AI-generated code fail in production?

A coding assistant only has the requirements and context made available to it, and its output can contain insecure patterns, invented dependencies, or assumptions that do not match the deployed system. Human-written code can have the same classes of defect. Treat generated code as untrusted until its architecture, dependencies, data flows, and behavior have been reviewed against explicit requirements.

Risk depends on the application and its exposure. Use a threat model and a verification standard instead of assuming either that AI-generated code is unsafe or that a successful demo proves readiness.

What actually breaks in AI-generated code?

These are common review areas, not a measured defect ranking for all AI-assisted builds. Scope them to the system and target risk level.

• Authentication and authorization. Test object, function, property, and tenant boundaries in trusted server-side code. A working login does not prove that user A cannot access user B's data.
• Input and output handling. Define types, lengths, formats, encodings, allowed values, and rejection behavior for every trust boundary. Sanitisation is context-specific, not a universal substitute for validation and safe APIs.
• Credentials and sensitive configuration. Check source, history, build artifacts, logs, and client bundles. Revoke or rotate exposed credentials and move privileged operations behind trusted boundaries.
• Exceptional conditions. Test timeouts, partial failures, retries, empty results, malformed responses, resource exhaustion, and recovery without leaking sensitive detail.
• Performance and resource limits. Profile representative data volumes and concurrency. Look for unbounded reads, repeated queries, missing limits, and expensive work triggered by untrusted input.
• Concurrency and replay. Test duplicate and parallel requests for state-changing operations, then enforce transactional or idempotent behavior where the business rule requires it.
• Dependencies and build integrity. Inventory direct and transitive components, verify package identity and provenance where feasible, check supported versions and advisories, and review licence obligations.
• State reconciliation. Confirm that user-visible state follows authoritative backend state and that asynchronous or failed operations can be reconciled.

"The generator is not the assurance boundary. Define the target, inspect the system, reproduce material findings, and keep evidence that the controls work."

The production-readiness checklist for AI-assisted builds

This is the structure of a Wavect first pass, reviewed on 2 September 2026. It is not a complete test plan for every system. Select controls by architecture, exposure, threat model, regulation, and service level.

1. Authorization audit. For each protected operation and data path, confirm a trusted server-side or serverless boundary checks the actor and requested action. Client-side checks can support user experience but are not a security boundary.
2. Input boundary test. Exercise malformed, oversized, hostile, and unexpected input at relevant entry points. Confirm safe rejection or handling.
3. Secret sweep. Scan the repo and the client bundle for keys, tokens, and credentials. Rotate anything that leaked and move it server-side.
4. Failure-path coverage. Simulate material external failures and confirm defined retry, fallback, user messaging, logging, and recovery behavior.
5. Load and query review. Profile representative workloads and data volumes. Bound reads and address repeated or unexpectedly expensive queries.
6. Concurrency test. Fire parallel and duplicate requests at anything that writes money or state. Add idempotency where it is missing.
7. Dependency and licence review. Use automated inventory and advisory checks, then review relevant findings, provenance, support status, and licence obligations. A scanner cannot prove that every dependency is safe or compatible.
8. Regression evidence. Add proportionate automated and manual tests for critical behavior so later changes can be checked against a baseline. See test-driven development for one way to structure executable expectations.

If you want AI to help create and maintain those regression tests, use a separate assurance boundary. Our agentic testing vs test automation pilot guide explains which work an agent can own, which assertions must stay deterministic, and how to measure a 30-day trial.

This is the core of our software QA service. Deliverables depend on scope and may include findings, reproduced evidence, fixes, tests, deployment controls, and residual-risk notes. No review proves the absence of defects.

Can I just ask the AI to fix its own code?

Partly. AI tools can propose tests and fixes, search a repository, and reason over supplied architecture or issue context. They can also miss scope, introduce regressions, rely on stale vulnerability knowledge, or validate their own assumptions. Keep an independent assurance boundary: humans remain accountable for requirements and risk acceptance, while generated findings and patches need reproducible tests and review. For one narrow discovery step, our Cisco Antares review explains local CWE-driven vulnerability localization and why candidate files still require a security reviewer.

How long does it take to make AI-generated code production-ready?

There is no defensible universal duration. Scope depends on target architecture, code and test quality, data, exposure, integrations, deployment, regulation, specialist testing, repository access, and remediation depth. Start with a bounded review, state its limitations, and estimate hardening only after evidence collection.

When is the code beyond saving?

Compare remediation and replacement when defects are systemic, the architecture cannot meet requirements, dependencies are unsupported, or migration risk dominates. Rebuilding is not automatically cheaper: it adds feature-parity, migration, cutover, retraining, and new-defect risk. Record assumptions, options, acceptance criteria, rollback, and residual risk before deciding.

Primary sources for the verification approach

These sources support risk-based secure development and verification. They do not establish defect rates for AI-generated code or certify a specific application.

• NIST Secure Software Development Framework 1.1
• NIST IR 8397, Guidelines on Minimum Standards for Developer Verification of Software
• OWASP Application Security Verification Standard 5.0.0
• OWASP Top 10:2025
• OWASP Secure Coding with AI Cheat Sheet