Build the mental model
AI-assisted, or "vibe coded," development — where an AI generates most of the code from a prompt or conversation — has made it fast to produce something that runs. Speed of production is not the same thing as production readiness, and treating them as the same thing is the core risk of this workflow.
A responsible version of this workflow looks like a normal engineering pipeline with extra scrutiny added, not removed: the AI generates code, a developer actually reviews the diff line by line rather than skimming it, tests run, the change is committed, it deploys to a preview environment, someone tests that preview like a real user would, a security review happens specifically because the code's provenance is different from hand-written code, and only then does it reach production.
Working locally does not mean production ready
A local run has no real traffic, no adversarial input, no cost pressure, and often no real credentials wired in the way production will need. Working locally, or even working in a quick demo, proves close to nothing about production readiness.
- Review authentication and authorization as genuinely separate concerns
- Hunt specifically for hardcoded or exposed secrets
- Check database permissions and API key scoping
- Verify CORS is configured on purpose rather than left wide open by default
- Confirm error handling doesn't leak internal details
- Consider rate limits, logging hygiene, monitoring, backups, and cost
AI-generated code can be functionally correct while being wildly inefficient in ways that only show up as a real bill once it meets real traffic.
RESPONSIBLE VIBE-CODING DEPLOY WORKFLOW
---------------------------------------
AI generates code
|
v
Developer reviews the diff (line by line, not a skim)
|
v
Tests run
|
v
Commit
|
v
Preview deploy
|
v
Test the preview like a real user would
|
v
Security review (auth, secrets, CORS, permissions, cost)
|
v
Production deploy
"Works on my machine" only covers the first box.
Every box after it is where real problems get caught.Connect it to a real scenario
Describe the app
An app that lets users upload files, store them, and query a small database — built almost entirely through a conversational coding tool over an afternoon. It runs locally without errors.
Read the diff
Reading the diff reveals the upload endpoint has no file-size or file-type limit, the database query building doesn't parameterize input, and an API key is sitting directly in the source rather than in an environment variable.
Run tests
Tests pass, but only because they don't cover any of those cases.
Test the preview deploy
A preview deploy makes the file-size problem obvious immediately, since a large upload now visibly hangs the process instead of erasing itself when you close the terminal.
Do the security review
The security review is where the hardcoded key and the injection-shaped query get caught and fixed, not before.
None of these problems would show up from "it works when I click around locally" — they only surface once someone deliberately looks for them, using the same review discipline you'd apply to any other developer's code, arguably more, since nobody on the team wrote this code from a mental model of the whole system the way a human author would.
Working locally does not mean production ready
An app can work perfectly on a laptop and have never faced production traffic, real security threats, or real cost at all. Always work through the checklist before deploying.
Before Deploying AI-Generated Code to Production
Try the working example
function isReadyForProduction(reviewStatus) {
const required = [
"authenticationReviewed",
"authorizationReviewed",
"noHardcodedSecrets",
"databasePermissionsReviewed",
"apiKeysScoped",
"corsConfigured",
"errorHandlingSafe",
"rateLimitsConsidered",
"logsClean",
"monitoringInPlace",
"backupsConfigured",
"costSanityChecked",
];
const missing = required.filter((key) => !reviewStatus[key]);
return {
readyForProduction: missing.length === 0,
missing,
};
}
const notReady = {
authenticationReviewed: true,
authorizationReviewed: false,
noHardcodedSecrets: false,
databasePermissionsReviewed: true,
apiKeysScoped: false,
corsConfigured: true,
errorHandlingSafe: true,
rateLimitsConsidered: false,
logsClean: true,
monitoringInPlace: false,
backupsConfigured: false,
costSanityChecked: false,
};
const ready = {
authenticationReviewed: true,
authorizationReviewed: true,
noHardcodedSecrets: true,
databasePermissionsReviewed: true,
apiKeysScoped: true,
corsConfigured: true,
errorHandlingSafe: true,
rateLimitsConsidered: true,
logsClean: true,
monitoringInPlace: true,
backupsConfigured: true,
costSanityChecked: true,
};
console.log("Not ready:", isReadyForProduction(notReady));
console.log("Ready:", isReadyForProduction(ready));Not ready: readyForProduction false, missing ['authorizationReviewed','noHardcodedSecrets','apiKeysScoped','rateLimitsConsidered','monitoringInPlace','backupsConfigured','costSanityChecked']
Ready: readyForProduction true, missing []5-minute try-it
Flip items in the notReady object to true one at a time and watch how the missing array shrinks
One important caution
Treating "the app runs smoothly locally" as proof of production readiness
Confusing authorization with authentication — checking who someone is but never checking what they're allowed to do
OWASP Top Ten — Cloud Providers & Platforms