AI-generated code should meet the same product, security and operating requirements as other code.
AI-generated code should meet the same product, security and operating requirements as other code. The useful review question is not whether an assistant wrote a file, but whether the team understands and can support the behaviour being released. Prioritise sensitive journeys and unverified assumptions instead of trying to classify every line by origin.
Trace trust boundaries
Follow sign-in, account recovery, role changes and access to customer data through server-side enforcement. Check that identity and permissions are not trusted merely because the client sends them. Use separate test roles and tenants to verify expected boundaries in an authorised environment. Record the intended rule and observed result so a passing happy path does not hide a missing denial case.
Review dependencies and data handling
Confirm that packages and APIs exist, are suitable for the intended use and have compatible licences. Inspect secret handling, logs, input validation and database migrations. Remove unused generated integrations and placeholder configuration. Use representative non-sensitive test data to verify constraints and errors; an attractive interface does not establish that persistence is correct.
Exercise complete business journeys
Test a purchase, cancellation, import or other critical operation through retries and interruptions. Verify that background work and provider events produce the intended state once. Inspect error handling for responses that announce success before durable work completes. Capture regression tests around the business rules most likely to cause financial or access problems.
Prove operating ownership
Have a team member explain the important components, deploy from a clean environment and restore a test backup. Confirm that alerts, rollback and support responsibilities exist. Replace code the team cannot reasonably maintain, even if it appears to work. Release in a controlled scope with explicit unresolved risks and acceptance evidence rather than relying on the confidence of generated explanations.
- Related service
- Refactor or rewrite an MVP: a decision framework
- Taking over a software project from another agency
Frequently asked questions
Is AI-generated code inherently unsafe?
Its origin alone does not establish quality. Review implementation, dependencies and observed behaviour against the same requirements.
Should we rewrite everything manually?
No. Keep code that is understood and verified; replace unsuitable or unmaintainable parts deliberately.
Are generated tests enough?
Review whether they assert real business rules, include denial and failure cases and fail when behaviour is wrong.
What should be reviewed first?
Identity, permissions, sensitive data, money movements and deployment controls usually have high consequences.
Can a launch proceed with open issues?
Only through an explicit product decision that accounts for impact, mitigations, ownership and follow-up.
Bring the scope. We will help make it buildable.
Share the user journey, integrations and launch constraints. We can clarify the scope and prepare an estimate with assumptions and exclusions.
Further reading
Refactor or rewrite an MVP: a decision framework
The choice between refactoring and rewriting is a choice about delivery risk, migration and evidence.
Taking over a software project from another agency
A software takeover succeeds when the new team can build, deploy and operate the product without relying on undocumented access held by the previous supplier.
Why an MVP is slow: diagnose before optimising
A slow MVP needs a measured diagnosis before a new hosting plan or framework.