“vibe coding” still maintains stable search demand in the United States, and related queries like Lovable and OpenCode are both on the rise.
Just because a prototype can be demonstrated does not mean it can withstand real users, real data and real bills.
The following twelve thresholds are ordered by failure impact, rather than arranged into a general template by development process.
Threshold 1: The team can explain key code
At least one maintainer can explain the authentication, payment, data writing and deployment paths.
The generated code that cannot be explained is isolated first and is not put online directly.
Assign code owners to key directories.
Threshold 2: The warehouse is the only source of truth
All production code goes into Git.
Unsynchronized modifications in low-code platforms must be exported.
Default branches enable protection and status checking.
Each deployment can be traced back to the commit SHA.
Threshold 3: Dependencies can be installed repeatedly
The lock file must be submitted.
Execute in a new environment:
|
|
Builds cannot rely on software installed globally by a single developer.
Check for abandoned packages, licenses, and known vulnerabilities.
Threshold 4: The key disappears from the code
|
|
Front-end environment variables will enter the browser package and cannot store server-side secrets.
Keys that have been submitted must be rotated.
Use different credentials for production and testing.
Threshold 5: In addition to authentication, there is also authorization
Successful login only proves who the user is.
Authorization determines what the user can read and modify.
Use two ordinary accounts to test horizontal override.
Use a normal account to directly request the administrator API.
Front-end hidden buttons cannot replace server-side checks.
Threshold 6: Database changes can be forward compatible
First add nullable fields, then deploy compatible code, and finally tighten constraints.
Large table migration evaluates table lock time.
Deleting columns and renaming them is not done in sync with the app release.
Exercise on a replica at production data scale.
The backup must actually be restored.
Threshold 7: Both input and output have boundaries
Server-side validation type, length, format and permissions.
File upload checks true type, size and storage path.
Rich text is escaped according to the output context.
URL scraping blocks intranet addresses and redirect bypasses.
Error responses do not reveal stack and database structures.
Threshold 8: Payment and quota cannot be calculated only on the client side
Prices, discounts and subscription status are confirmed on the server side.
Webhooks verify signatures and prevent duplicate processing.
Each consumable API has rate and cost caps.
The free quota cannot be bypassed by changing parameters.
Manually can quickly suspend abnormal accounts and functions.
Threshold 9: Test coverage failure path
|
|
Then test login failure, insufficient permissions, third-party timeout, and database unavailability.
Critical processes have at least one end-to-end smoke test.
AI generated code may not delete or skip referee tests.
Threshold 10: Logs can be located but do not leak secrets
Each request has a request ID.
Logging error type, time taken and version.
Authorization, cookies, passwords, complete prompts, and personal information need to be desensitized.
The log retention period and access rights are clear.
The alert points to the executable runbook instead of just sending a red message.
Threshold 11: Release using progressive traffic
Deploy internal or a small percentage of users first.
Observe error rates, latency, login success rates, and fees.
Database migrations and application versions have separate health indicators.
Don’t roll an unavailable feature online for the first time on a Friday night.
The feature switch should be able to turn off new paths without rebuilding.
Threshold 12: Rollback drill before release
The last stable image can still be deployed.
Configuration changes are versioned.
Prepare forward repair scripts when the database is incompatible.
There is a downgrade page for third-party failures.
Make it clear who can decide to roll back, who executes it, and who notifies users.
Use preview to expose hidden dependencies
Create staging similar to production.
Deploy once starting from an empty database.
Upgrade once from the previous version.
Disconnect the email, payment, and AI APIs and test them once each.
Simulate disk fullness, quota exhaustion, and DNS failure.
Record recovery time and missing information.
The reasonable role of AI Agent in the release process
Agents can generate tests, interpret diffs, organize dependencies, and perform read-only checks.
It should not approve production deployments, rotate master keys, or delete databases on its own.
High-risk orders retain manual confirmation.
The Agent’s conclusions must be verified by CI, monitoring, or actual documentation.
What should be included in the release record?
|
|
These fields allow incident response to be independent of an individual’s chat history.
Under what circumstances should the launch be postponed?
There are no restoreable backups.
The team has no idea where the production keys are.
Logged-in users can guess IDs and read other people’s data.
Deployment cannot be mapped to source version.
There is no cap on third-party billing.
The sole maintainer is going offline.
It’s often cheaper to delay for a day than to go live with the risk of unknown data.
Final signature form
| Person in charge | Evidence that needs to be confirmed |
|---|---|
| Development | CI, diff, versions and dependencies |
| Security | Keys, Authorization and Negative Testing |
| Data | Migration, Backup and Recovery |
| Operation and maintenance | Monitoring, alarms and rollback |
| Products | Downgrade experience and user notifications |
Vibe Coding shortens prototype time and does not automatically assume production responsibility.
Only when there is evidence for all twelve thresholds can the prototype truly become operational software.
Extended reading of production
Create a change freeze window before publishing
Before entering production release, only fixes that block rollout will be accepted. New AI generation improvements are carried into the next version, avoiding continuous changes to the baseline during acceptance.
Commits, dependency lock files, database migrations, and configuration versions are logged when the freeze begins. Any exception modifications rerun the relevant checks.
Design downgrades for third-party AI APIs
Set single request timeout, concurrency limit and account budget. The page gives an understandable prompt when a supplier is unavailable, rather than spinning endlessly.
Non-critical generation functions can be temporarily turned off; Agent tasks involving data writing should be stopped and retained in the intermediate state, and the model cannot be quietly changed to continue execution.
Monitor real user paths
Just because the home page is accessible does not mean that the product is available. Synthetic monitoring should cover registration, login, creation of core objects, and exit, using dedicated test tenants.
The payment process no longer repeats orders in production, and configuration, webhook health, and test environment transactions can be monitored. Key indicators set both error rate and latency thresholds.
User data deletion requires end-to-end verification
Check the main database, object storage, search index, analysis platform and asynchronous queue when deleting an account. Deletions from backups follow public retention policies.
After deletion is initiated, an internal task ID is generated. The user interface only displays the progress and does not expose the background storage structure.
Domain name, email and security response header
Verify MFA for HTTPS auto-renewal, DNS control, and domain registration accounts before going live. Configure SPF, DKIM and DMARC for the email domain name, and test it with a real inbox.
Check for CSP, HSTS, X-Content-Type-Options and a reasonable Referrer Policy. CSP is first observed in reporting mode and then gradually tightened.
First hour after release
Designate a release owner to watch for errors, delays, registrations, payments, database connections, and third-party fees. Others avoid unrelated deployments at the same time.
Write the rollback threshold in advance. For example, if the error rate continues to exceed three times the baseline for five minutes, the traffic will be suspended, rather than a temporary argument after the incident.
Review AI generation part
Flag modules in this release that were first generated by AI, modified by AI, and written entirely by humans. Compare their defects to review time, but don’t attribute them based on this.
Whether prompts, tests, permissions, or architecture really need improvement should be determined by evidence. Add valid checks to the next release threshold to form a repeatable process.
The watch event will be closed 24 hours after the release is completed. Make sure that the backup tasks, cost alarms, and scheduled tasks for the next day are all normal before marking the version as stable.
Stable releases remain rollback targets until the next release passes the same check.