Vibe coding no longer stops at the clickable prototype. We increasingly come across projects where a single person, with an AI assistant, puts together a complex system in a few months: with permission management, an admin interface, online payments, and integrations with several external services. And the code isn't bad.
We've written before about how a prototype becomes a production product. Now we're going one step further: what if the code is already in good shape, and you're still not ready to go live?
The code is done, the product isn't
We recently reviewed one of these applications before launch. We ran it, ran static code analyzers on it, and went through the entire codebase with colleagues (and with AI too). The result was better than we expected: the developer had already fixed most of the serious findings of an earlier security audit, the structure of the code was tidy, and the system implemented the processes described in the specification functionally.
This isn't a one-off. With AI-built applications, web and mobile alike, the risk is usually not in the code but around it:
- No release process in place. A change pushed to the main branch can go live automatically, with no mandatory build and test checks.
- No versioning. A release doesn't tell you what changed or whether the change is compatible with the previous one. Semantic versioning (semver) gives a simple rule for this: in the MAJOR.MINOR.PATCH format, raising the major version signals that something changed in a backward-incompatible way.
- Outdated dependencies. The framework and package versions fall behind, with known vulnerabilities, even though critical CVEs scoring above 9 have been appearing one after another in recent weeks.
- Production differs from the repo. Manual changes in a web interface, database migrations from which the production state can't be reliably rebuilt.
- Half-handled edge cases, especially in financial flows.
None of these is a sign of bad code. Each is a sign that the professional routine is missing, the kind a development team builds up over years, often through painful experience.
The first release usually still works out. The trouble comes with the second, or during an incident. With a mobile app, for example, the old version keeps running on users' phones for weeks and calls the same backend as the new one. If the second release silently breaks this compatibility, the old app stops working overnight, and there is no quick way back.
Kent Beck describes this tension as features vs. futures. Every new feature uses up some of the system's future room to maneuver, and you can only win it back with tests, a tidy structure and deliberate design. AI-assisted development makes this balance more urgent: features arrive faster than ever, and the future runs out just as fast.
The blueprint is right, but only from above
Code written with AI typically follows what you asked for faithfully. The house matches the blueprint. The problem is that the blueprint is two-dimensional: it shows the rooms and the doors, but not the structural engineering, the wiring and the emergency exit.
AI builds the main path, the "happy path," very well. But it thinks of edge cases only if you do. What happens if a customer disputes the charge with their bank weeks later? If a refund recorded in the admin interface never happens at the payment provider? If someone opens your AI-based customer service chat a thousand times with a script, and you pay the bill?
People don't gain this experience while writing code, but from having seen things break in production. Experience draws the third dimension.
The same AI, the same blind spots
An obvious idea: if AI wrote the code, let AI check it too. This partly works, and we use it in our reviews as well. But it has a limit. If the same model writes, tests and fixes the code, the same blind spots are present in all three steps. What didn't "occur to it" during development won't occur to it during testing either.
During an incident this is especially dangerous. Under pressure, we fix things fast, with the same tool and the same mindset that created the bug.
The AI agent itself deserves special attention too. If the coding assistant can run commands and write files without approval on a machine from which the production system is also reachable, that is a new kind of operational risk.
The solution isn't to throw the prototype away and hand the whole project to "experts" – after all, they will use AI too – but to bring in a new, independent perspective: different tools, an experienced outside eye, and real people who use the system in ways the developer never imagined.
The invisible layer
What turns a working application into a product that can be operated responsibly is mostly not visible on screen. We usually look at four areas.
Process. A change doesn't go live directly from the developer's machine, but through automated checks and a separate test environment. New features roll out gradually, to a small group of users, and there is a way back if something breaks.
Operations. You know when something is wrong before a user tells you. Keys and passwords are stored encrypted, not in the code. The audit logs let you trace afterward who did what and when, which is worth its weight in gold for disputed transactions and incidents.
Knowledge. If only one person knows how the system works, that person is the system's biggest risk. A plain-language description of the business and technical processes is the first step toward being able to bring in others. For that, though, you have to understand what you built. Mitchell Hashimoto, co-founder of HashiCorp, calls this the “whiteboard defense”: at any moment someone can pull you aside, and you must be able to explain how a system you've shipped to customers works. You don't need to remember function names, but why X and not Y, what happens if someone uses it maliciously, and where it gives out. For a prototype it doesn't matter; for a production product it does.
Legal and administrative side. A privacy notice, the GDPR compliance of the providers you use, an incident response procedure. The code says nothing about these, yet they must be in order before going live. A lawyer is a good partner for this, but someone has to explain the technical side to them too.
Before you go live: a checklist
If your answer to several of the following is "no" or "I don't know," your code may be done, but your product isn't.
- Test coverage. Do you have an automated test suite, and do you know how much of the code it covers? AI writes tests quickly; the question is whether it tests the important things.
- Specification. Is it written down what the system must do and what it must not? Without a specification, a test only checks what the code does, not what it should do.
- Staging environment. Do you have a test environment separate from production, with its own database, where every change is tried out first?
- Quality gates. Do the build, type checking and tests have to pass before anything goes live? Are keys and passwords encrypted and kept outside the code?
- Edge cases. Have you thought through and tried the edge cases: refunds, chargebacks, interrupted payments, duplicate requests, abuse, unexpected cost explosions?
- SAST. Does static code analysis (for example SonarQube or Semgrep) run on every change?
- Dependency scanning. Do you check packages and container images for known vulnerabilities, for example with Trivy? Do you know how outdated your framework is?
- Human testing with test reports. Did real people test following pre-written scenarios, and did you document the result so you can look back at it later as a reference?
- Monitoring and audit log. Do you get an alert when something is wrong? Can you trace afterward who did what in the system?
- High availability (HA). What happens if a component goes down? Is there redundancy, health monitoring, automatic restart?
- Disaster recovery (DR) plan. Do you have a backup, and have you actually tried restoring from it? Do you know how much data loss and downtime your business can bear?
How we help
If you have your code and are about to go live, we can get involved in several ways, depending on how much you want to do yourself.
Pre-launch review. We go through the application and the processes around it: static code analysis, dependency scanning, a vulnerability test on the running system, thinking through the edge cases. The result is a prioritized, plain-language report on what to fix before launch and what can wait.
Setting up the production environment. We build what's missing: an automated release process, a staging environment, monitoring, encrypted key management, backups and a recovery plan. If you like, we'll also take over operations.
Expert consulting. You keep developing, and we stand beside you: we review your decisions, help with testing and fixes, and are there if something happens in production.
Bring what you have. We'll tell you what's missing for real users to use it securely with real money. Get in touch!