- Describe production use and consequences
- Inspect implementation and permissions
- Test allowed and disallowed behavior
- Rehearse release and recovery
- Assign monitoring and maintenance
What does production readiness mean for an AI-built app?
Production readiness means the application has been evaluated against its actual use and consequences. A public brochure site, a staff scheduling tool, and a portal containing customer documents have different exposures. Giving them the same generic ready-to-launch label misses the decisions that matter. Start by identifying who uses the app, what information it holds, what actions it can take, and what happens when those actions are wrong.
The term vibe coding describes a style of building, not a certification. For this discussion, it means developing through natural-language requests with substantial AI-generated code. Some teams inspect and test every change carefully; others accept the output largely on appearance. Those practices should not be treated as equivalent simply because both use an AI assistant.
GitHub's responsible-use guidance calls for reviewing and testing agent-generated work before merging. OWASP also documents risks specific to AI-assisted coding workflows. Neither source means every generated application is insecure, nor does following one checklist prove an application safe. They support treating generated changes as work that requires evidence and responsible review.
Why can a convincing demonstration still hide important failures?
A demonstration usually follows the expected path using a small set of familiar accounts and data. That can show whether the interface is understandable, but it says little about unauthorized requests, repeated submissions, expired sessions, interrupted connections, or incompatible records. A success message may appear even when the underlying action failed.
Consider a fictional equipment-maintenance portal. A customer signs in, sees their own equipment list, and requests a service visit. The demonstration looks complete. Before release, the team still needs to establish that another customer cannot retrieve those records, that a request is not duplicated after a retry, and that a notification does not imply a confirmed appointment when staff have only received a request.
Turn each uncertainty into an acceptance question with an observable result. For example: when an account without permission requests a protected record, the system refuses access and returns no protected details. This hypothetical test concerns the team's own application and controlled test accounts. It is more useful than asking the AI whether the code looks secure.
Which parts of the implementation deserve direct inspection?
Inspect the boundaries where the app accepts information, decides permissions, changes records, calls external services, and exposes results. Have a qualified developer explain how each important action reaches its final state. If no one can explain the flow without asking the generating tool to summarize itself, the project has an ownership problem that a polished interface cannot resolve.
In the fictional portal, map how a service request gets its customer identity, equipment identity, requested date, and status. Determine which values the server trusts and which it verifies. OWASP authorization guidance emphasizes enforcing access decisions consistently and checking permissions for requests. Hiding an interface control is not sufficient evidence that the underlying action is restricted.
Also inspect dependencies, configuration, and external connections. Confirm that libraries exist, are intentionally selected, and are appropriate for the project. Determine where secrets are stored and which environments can use them. A dependency scan is useful evidence within its scope; it does not establish that business logic, permissions, or every integration is correct.
How should testing differ from repeating the original prompt?
Test the requirements and failure cases independently of the generated implementation. A tool that writes code can also write tests that repeat the same mistaken assumption. Review what a test actually proves, the data it uses, and whether a deliberately incorrect behavior would cause it to fail. The presence of many passing tests is not a substitute for that reasoning.
For the portal example, verify separate cases for a customer, a staff member, and a person who is not signed in. Try a valid request, missing information, an expired session, a repeated submission, and a temporary failure in the notification service. Confirm the resulting record and user message, not only the screen appearance. Use fictional records and a controlled environment.
Include people testing the actual interface. Check keyboard operation, readable errors, narrow screens, and recovery after an interrupted task. Ask whether someone can distinguish saved, pending, failed, and confirmed states. These usability checks complement technical tests because a system can behave as implemented while still causing users to misunderstand what happened.
What controls should surround the coding assistant itself?
Separate the assistant's development access from the application's production access. Give the tool the permissions needed for the assigned work and review any request to expand them. The ability to edit a feature does not inherently require access to live customer data, deployment credentials, or unrelated repositories.
OWASP's AI coding guidance discusses untrusted material entering an agent's context, sensitive information exposure, and excessive tool access. A practical project should identify which sources the assistant can read, what actions it can take, and which actions need a human decision. Instructions found inside an issue, downloaded document, or third-party file should not silently acquire authority over the project.
Review the actual changes before accepting them. Check whether the tool edited unrelated files, weakened tests, changed permissions, or introduced an unexpected external service. Keep the task small enough that a reviewer can understand its effect. A confident completion message is a report to verify, not evidence that every requested check actually ran.
What must be ready if deployment fails?
Plan the release and recovery before users depend on the app. Identify the version being released, the configuration it expects, the person authorizing the change, and how success will be checked. Rehearse the process in an appropriate nonproduction environment using representative fictional data and the same important states.
A rollback deserves particular attention when a release changes stored data. Restoring old application code may not reverse a database migration or an external action. For the portal, ask what happens to service requests created during the release window and whether the previous version can interpret them. Have a qualified engineer design and test the recovery approach for the actual system.
Assign monitoring that reflects the business task. A server responding to a basic health check does not prove customers can submit service requests. Review submission failures, background processing, and notification delivery as appropriate to the design. Establish who receives an alert, how they investigate it, and how affected users receive accurate updates.
How can an owner decide whether to launch, narrow, or continue development?
Make a decision from the remaining uncertainties and their consequences. If the team cannot verify who can access private records, the portal example needs more engineering before launch. If an optional reporting chart is unfinished but the essential workflow is validated, the team may be able to remove that chart from the initial scope. The actual decision belongs to accountable project owners and qualified reviewers.
Keep a short release evidence packet: agreed requirements, significant design decisions, reviewed changes, test results, known limitations, recovery steps, and maintenance ownership. Record unresolved items plainly. Do not relabel them as accepted risks without an authorized person understanding what the acceptance means.
Dappr can discuss AI-assisted app development as part of a scoped project. Bring the prototype, repository access arrangements, intended users, data categories, and known limitations. A review must establish what can be reused and what needs further work. This article is not a security certification, a fixed-price rescue offer, or a promise that any existing prototype can be made production-ready without substantial changes.
Questions before you begin
Does AI-generated code always need to be rewritten?
No. Review the actual implementation against requirements, maintainability, dependencies, and risk. Some code may be usable, some may need focused correction, and some may be more practical to replace. The generating method alone does not answer that question.
Is a security scanner enough before launch?
No. A scanner can identify certain classes of issues within its coverage. It cannot establish every permission boundary, business rule, operational failure mode, or recovery behavior. Combine relevant tools with qualified review and meaningful tests.
Can a prototype use real customer information?
Choose data access deliberately with the responsible project and privacy reviewers. Fictional or appropriately prepared test data is often sufficient for prototype evaluation. Do not add live information merely to make the demonstration feel realistic.
Who should own an AI-built application after delivery?
Name the party responsible for code, hosting access, updates, incidents, backups, and future changes. Document the handover and support scope. The AI tool does not become accountable for those responsibilities because it helped create the app.