Vibe coding, by engineers
who read the code.

Vibe coding is building software by describing what you want to an AI model in plain language and letting it write the code. The term was coined by Andrej Karpathy in February 2025 for a style where you “fully give in to the vibes” and stop looking at the code at all. Tools like Lovable, Bolt, Replit, v0, Cursor and Claude Code have made it possible for almost anyone to produce a working app in an afternoon.

That last part is true, and it is genuinely useful. It is also where the problem starts. The app on screen is the part of the software you can see. Authentication, permissions, database rules, secrets, input handling, dependencies, hosting and personal data are the parts you cannot, and an AI model will produce something plausible for every one of them whether or not it is safe.

So there are now two kinds of vibe coder. One prompts until the screen looks right. The other prompts just as fast, then reads what came back with the knowledge of someone who has built and run this kind of system before. Both are vibe coding. Only one of them knows what they shipped.

The second kind has picked up names of its own: vibe engineering, a term Simon Willison proposed in 2025, and agentic engineering or agentic coding, where AI agents write and run the code under an engineer’s direction. The names matter less than the test underneath them: is there someone who can read the code, and did they?

This is not a hunch about other people’s code. In July 2025, Veracode’s GenAI Code Security Report tested more than 100 language models on 80 coding tasks and found that the generated code introduced a known class of security flaw in 45% of cases. Newer and larger models wrote more code that worked; they did not write noticeably more code that was safe.

The same year, a researcher scanned 1,645 apps from one vibe coding platform’s public showcase and found 170 whose databases could be read, and in places written, by anyone holding the public key, because row-level security had never been switched on. It was recorded as CVE-2025-48757. The platform disputed the CVE on the grounds that each app’s owner is responsible for protecting that app’s data, and that is exactly the point. The tool built what it was asked for. Nobody involved knew what to ask.

None of this means AI writes bad code. It writes code the way a very fast junior developer does: plausible, mostly working, and in need of review by someone who knows what to look for. The figures above are the published findings of third parties at the time of writing, not measurements of our own; follow the links for their methods.

1. No secrets in the front end. Search the built bundle and the repository history for keys; move every one server-side and rotate any that were ever exposed.
2. Authorisation on the server. Every API route and every record checks who is asking, not just whether they are logged in.
3. Database rules switched on and tested. Row-level security or equivalent on every table, proven by trying to read another account’s data.
4. Input validated and queries parameterised. No SQL built from strings, no user content rendered as raw HTML.
5. Packages verified. Each dependency exists, is the one you meant, is maintained and has no known critical vulnerability.
6. Rate limits on login, sign-up and password reset. Without them, credential stuffing is free.
7. CORS and storage locked down. No wildcard origins on authenticated APIs, no public file buckets holding private uploads.
8. Errors that say nothing useful to an attacker. No stack traces, queries or keys in responses or the browser console.
9. Personal data mapped. You know what you collect, why, where it is stored and how it is deleted, which GDPR expects of you anyway.
10. Logs and an audit trail. When something goes wrong you can tell what happened and to whom.
11. Tests on the parts that protect people. Login, permissions and payments have automated tests, so the next prompt cannot quietly remove them.
12. Backups you have restored once. A backup nobody has tested is a hope, not a plan.

AI is one of our tools, not the only one. We have been building software since 2006, long before a model could write a line of it, and our engineers write, debug and refactor code by hand every day: in new builds, in your existing codebase, and in the parts of a system where generated code is the wrong answer. Laravel, PHP, JavaScript and TypeScript, React and Vue, Python, SQL, cloud hosting and the plumbing between them are what we work in, with or without an AI model in the loop.

That matters for what happens after launch. Everything we build is plain code in mainstream frameworks, so it can be read, edited and adjusted with AI, by us, by your team or by whichever AI coding tool you use next year. The test suite is what makes that safe: when an AI edit, or a human one, breaks something, a test says so before your users do. Software that can only be changed by the tool that generated it is a dependency. Software with readable code and tests is an asset.

Not sure whether you need AI-assisted speed or traditional engineering? Usually it is both, in different parts of the same system. We will tell you which parts are which on the first call.

No. Vibe coding is a fast way to build, and it goes wrong only when nobody who understands the result is responsible for it. Plenty of vibe-coded software is fine as it is. A throwaway prototype to see whether an idea has legs, an internal tool that touches no personal data, a demo for a pitch, a weekend project you are learning from: build those yourself, quickly, and enjoy it. Not everything needs an engineer.

The line is crossed the moment real users, real personal data or real money touch it. From that point the right-hand column of the table above stops being optional, and someone needs to own it who can read the code.