A small team can now describe a customer portal in a paragraph, watch a model produce a working version of it before lunch, and start clicking through it the same afternoon. That speed is real, and it is not going away. What tends to lag behind is everything that happens after the code exists, because the pipeline that carries software from a laptop into production was designed around a slower kind of authorship.
Traditional deployment security assumed a human had already read every line, argued about half of it in review, and could explain why a particular service needed write access to a particular bucket. Generated code breaks that assumption quietly. The code often works, the tests it writes for itself often pass, and nobody in the room has a mental model of which permissions it quietly asked for along the way.
So the answer is not to slow the generation down. It is to move the checks to the place where they still work, which is the deploy step itself. That boundary is the last point where a machine can say no, and it is the part of the workflow most teams have left thin.
The Deploy Step Carries Weight It Was Not Built For
Capital is pouring into AI tooling at a pace that makes even the people funding it nervous, and markets have started asking whether the build-out is outrunning its own economics. Engineering teams face a smaller version of that question: output has multiplied while the machinery that validates it has barely moved. A pipeline with one linter, one test suite, and a manual approval click was adequate when a senior engineer wrote every line by hand. It is thin now, and the thinness shows up in production rather than in review.
Volume changes the math. When a team merges four times a week, a reviewer can hold the whole system in their head. When the same team merges forty times, the gate has to be automated or it becomes a formality that everyone clicks through on the way to lunch.
Automated Testing Has to Cover What the Model Skipped
Models write tests that mirror the code they just produced, which means the happy path gets covered thoroughly and the ugly cases get ignored. A generated endpoint will be tested with a valid payload and rarely with a payload that is nine megabytes of nested JSON. The fix is boring and effective: keep a suite of adversarial tests that the team owns, not the model, and run it on every build. Malformed input, expired tokens, oversized files, concurrent writes to the same record.
Dependency provenance deserves the same treatment. Generated code pulls packages with confidence and no taste, so the build should verify where an artifact came from before it ships. The SLSA build levels describe this as a ladder, from provenance that merely exists to provenance signed by a hardened build platform, and OpenSSF Scorecard gives you an automated read on the health of the dependencies themselves.
Permissions and Secrets Belong at the Deploy Boundary
Generated applications tend toward generous permissions because generous permissions make the demo work. An admin key never throws an authorization error, so the model reaches for one. The place to correct that is not the prompt, it is the deployment configuration, where a service account can be scoped to the two operations it actually performs. Teams that securely deploy vibe-coded apps treat least privilege as a property of the environment rather than a property of the code.
Secrets need the same discipline, and they need it later in the process than most people assume. A credential injected at deploy time can be rotated without touching a repository; a credential pasted into a config file during generation lives forever in git history. Kubernetes documentation is blunt on the subtler trap here, noting that Secret values are base64 encoded, which obscures them but provides no useful confidentiality, and that list or watch permissions on Secrets expose every secret in a namespace rather than the ones a workload references.
Monitoring Closes the Loop After Release
Everything above happens before the app is live, and it is only half the story, since the failure modes of generated software are often invisible until real traffic hits them. An endpoint that quietly returns more data than it should will pass every test and look perfect in a dashboard that only tracks uptime. So instrument for shape, not just health: log which records each request touched, alert on a response payload that grows past its usual size, and watch authorization denials as a signal rather than noise. A spike in denials usually means something was granted access it was never designed to need.
Human Review Moves to the Riskiest Diffs
None of this removes people from the loop; it changes where they stand. Reading every generated line is not realistic at forty merges a week, and pretending otherwise produces rubber stamps. Reading every diff that touches authentication, payment, data export, or the deployment configuration is realistic, and those diffs are a small fraction of the total. Route them to a human automatically, by path, and let the rest ride on the automated gates.
The teams handling this well have not adopted a new philosophy so much as a new placement. They kept the speed, moved the scrutiny downstream, and accepted that the deploy step is now the most important piece of security infrastructure they own. That is a modest reorganization, and it is mostly configuration work rather than culture work.
The alternative is the pattern already showing up in incident reports: an app built in an afternoon, shipped with a key that could read the whole database, running for months before anyone noticed what it could reach. The code was never the problem. The path it took to production was, and that path is the one part of this workflow a team still fully controls.
