With AI assistants, software now emerges at a pace that was unthinkable three years ago: describe, generate, watch it run. This vibe coding is productive and fun, and that is precisely where the risk lies. The code looks finished, feels finished and often is not. This article summarizes what the research actually says about AI-generated code, and shows how companies can use the speed without importing tomorrow's problems into production.
What vibe coding does well and where it tips over
AI assistants excel at turning a clear description into working code quickly: forms, database access, reports, entire prototypes. For business departments that want to digitalize their own processes, that is real leverage. The tipping point comes when the prototype quietly becomes a production system: the code works on the demo path, but nobody has looked at error cases, access rights or maintainability.
The core problem is not that AI writes bad code. The core problem is that it writes convincing code. Plausibility replaces scrutiny, and that is exactly the gap that processes have to close.
The research: security remains the weakest link
Veracode's 2025 GenAI Code Security Report tested more than 100 language models on 80 realistic coding tasks. The result: in 45 percent of cases the generated code contained a known security flaw, in Java even around 70 percent. The models failed to defend against cross-site scripting in 86 percent of the relevant tasks. Particularly noteworthy: newer and larger models wrote functionally better but not more secure code. The security rate stayed almost constant across model generations.
Maintainability suffers measurably too. GitClear analyzed 211 million changed lines of code from 2020 to 2024: the share of copied lines rose sharply, duplicated code blocks multiplied, and in 2024 copy-paste exceeded refactoring for the first time. At the same time, the share of code revised again within two weeks grew from 5.5 to 7.9 percent. AI code is written fast, but it also gets touched again unusually fast.
Perceived speed is not measured speed
Google's 2024 DORA report found a remarkable pattern among more than 39,000 respondents: 75 percent report productivity gains from AI, but at team level a 25 percent increase in AI adoption went along with roughly 1.5 percent less delivery throughput and 7.2 percent worse delivery stability. More code gets written, but larger change sets and less scrutiny make the delivery pipeline shakier.
A randomized experiment by the research institute METR from 2025 points the same way: experienced open-source developers were on average 19 percent slower with AI tools, yet believed they had been 20 percent faster. A follow-up in 2026 revised the effect to roughly neutral, while the finding about misperception remained. The honest summary: the productivity gain is real in some situations, and our own judgement about it is unreliable. Which makes objective checks all the more important than gut feeling.
What follows: review is not a brake, it is the precondition for speed
The conclusion from the research is not to ban vibe coding. The conclusion is to treat it like any other source of code, only with higher throughput: whatever goes to production gets checked. Automatically where machines are good, and by humans where context matters.
- Automated quality gates before every submission: secret scan, dependency audit, container vulnerability scan, checks on database migrations including access rules.
- Architecture guardrails the AI reads along: business logic belongs in the backend, access rules in the database, secrets never in the code. Such rules can be handed to the AI as binding working instructions.
- Human review before go-live: an experienced look at data access, error cases and the question of whether the code really solves the problem instead of just the demo path.
- Small, traceable units: one app, one purpose, one owner, one audit log. Rollback planned rather than hoped for.
- Operations as part of the process: monitoring, backups and continuous security scans, because a go-live review does not replace observation in production.
How we implement this with Kinster
In our app platform Kinster this process is built in rather than bolted on: business departments describe their app and develop it AI-assisted in VS Code in the browser, inside guardrails the AI reads as its working instructions. A version can only be submitted if the automated checks let it through, and it only goes live after the review by needful-apps. Deployments run without interruption, the previous version stays ready for rollback, and every decision is recorded in the audit log.
That preserves the best part of vibe coding, namely the speed and the department's closeness to its own process. And the numbers from the studies above remain what they should be: a warning about the unchecked path, not your operational reality.
Frequently asked questions
What is vibe coding?
AI-assisted programming in which people describe in natural language what should be built and an AI assistant produces large parts of the code. The term emphasizes the flow of this way of working: describe quickly, generate, try out. The result only becomes production-ready through checks and review.
Are automated scans not enough, why an additional human review?
Scanners find known patterns: leaked secrets, vulnerable dependencies, typical flaws. Whether an app shows the right data to the right people, whether error cases are handled sensibly and whether the solution fits the process is something no scanner can tell. The combination is the point: machines check broadly, humans check deeply.
Does the review cancel out the speed advantage of AI?
No, it moves the advantage to where it belongs. A review costs hours; a security incident or an unmaintainable system costs weeks. The DORA data shows that unchecked AI speed makes delivery less stable, and unstable delivery is the most expensive form of slowness.
Does this also apply to small internal tools without external exposure?
Especially there. Internal tools often process the most sensitive data (HR, calculations, customers) and are checked the least. The effort may be smaller than for a public product, but access rules, backups and a short review before go-live are the minimum bar here too.