A guide by SevenLab
A working AI-built prototype demonstrates a workflow, not its readiness to handle production users and data. Whether the code was created with Claude Code, Cursor or Lovable, buy a review against the intended deployment and risks. SevenLab's Governed Build page is the relevant starting point for an assurance enquiry. Agree the actual review coverage, remediation responsibilities and release evidence in the proposal.
Define what is being reviewed and what is changing
Start an AI code audit or vibe coding audit with a fixed repository version, deployment configuration and description of the intended users. Include dependencies, database changes, external services and any code outside the generated interface. Ask the reviewer to distinguish source inspection from running the application and assessing its deployed environment. A review of selected files cannot answer every question about the security of the full application.
Illustrative scenario, hypothetical scope: a team wants to move a Lovable app from an internal demonstration into customer-facing production. The assessment brief should cover the real repository, authentication setup, data ownership and deployment route, not just the visible screens. Entry criteria should include a reproducible build and an inventory of services and credentials. If essential components cannot be inspected, require the report to identify that limitation and exclude unsupported release conclusions.
- Freeze the repository version and inventory services, dependencies and database changes.
- State the intended users, data sensitivity and production deployment context.
- Require explicit review boundaries and disclosure of inaccessible components.
Ask for security evidence, not a clean-looking diff
An AI code review, a broader AI code audit and a software security audit can have different scopes. For a Claude Code security assessment or Cursor code review, ask whether the work examines only recent changes or also surrounding trust boundaries. Require attention to server-side authorisation, input handling, secrets and dependency risk. Automated findings should be assessed for relevance, while a lack of findings should not be presented as proof of security.
Illustrative scenario, hypothetical scope: a customer portal hides another customer's records in the interface but accepts their record identifier in an API request. Acceptance should include direct cross-account requests and evidence that the server refuses access, followed by a regression test. If the app also uses a language model, separately test whether untrusted content can influence privileged actions. A convincing frontend demonstration does not replace those checks when securing an AI app.
- Request a review plan covering application boundaries, not just generated lines.
- Test unauthorised requests directly against server endpoints and data access paths.
- Require reproducible findings, remediation ownership and retests for release blockers.
Test deployment, data changes and recovery
Moving an AI prototype to production requires operational evidence beyond code inspection. Ask for a clean deployment, separation of test and production credentials, observable failures and documented recovery procedures. Assess database migrations, repeated requests and external service outages against the actual workflow. A proposal to secure AI-built software should identify which checks are included, which need another specialist and which remain the buyer's operational responsibility.
Illustrative scenario, hypothetical scope: a generated database migration changes how order status is stored. Reverting the application code may not restore the previous data structure or values. Acceptance should include migration testing on a representative non-production copy, a verified backup restoration and a documented decision between rollback and forward repair. Confirm who can pause processing and how affected orders would be reconciled. This provides a more useful production gate than simply showing that the app starts.
- Reproduce deployment without relying on a developer's local environment.
- Test migrations, interrupted writes and external service failures.
- Verify backup restoration and assign authority to pause and recover processing.
Keep release approval tied to reviewed evidence
AI code governance should connect a reviewed version to test evidence, unresolved findings and a named release owner. When comparing a vibe coding agency or an assurance partner, ask who fixes issues, who verifies the fix and what invalidates the original review. Use the Governed Build enquiry to agree these deliverables rather than assuming a standard package covers every risk. A review can support a release decision but cannot guarantee security or legal compliance.
Illustrative scenario, hypothetical scope: after a review is approved, a team generates a new payment-related change and wants to deploy it under the earlier approval. The governance process should identify the changed components, require relevant retests and route the release back to the authorised owner. Acceptance should include a handover with the reviewed commit, finding status, operating instructions and responsibility for future changes. Agree review and remediation timing from the actual scope rather than assuming immediate clearance.
- Link release approval to a specific commit, test record and finding status.
- Define which changes require renewed review and who authorises deployment.
- Obtain operating documentation and named owners for fixes and future maintenance.