In February 2025, Andrej Karpathy described a style of programming where you "fully give in to the vibes" and "forget that the code even exists". For vibe coding for non-technical founders, that sentence is both the promise and the warning: you can describe an app in plain language and watch it appear, but nobody on your team may understand what was built.
This guide covers how to start, which risks have actual evidence behind them, and the point where a prototype needs a developer's eyes.
What vibe coding actually involves
You tell an AI tool what you want in everyday language, it writes the code, and you run the result and ask for changes. The skill is in describing the product clearly and judging whether what comes back is right.
Merriam-Webster added the term in March 2025, defining it as a way of working where the coder doesn't need to understand how or why the code works. That definition is the part to take seriously. If you want the longer version of the history, our piece on what vibe coding is and how it speeds up an MVP covers it.
How non-technical founders can start vibe coding
Start smaller than feels useful. A prototype that does one job for one kind of user teaches you more than a half-built platform, and it's far easier to check.
- Write down who the app is for and the single task it should finish for them.
- Describe the screens and the information each one shows, in plain sentences, before you open any tool.
- Ask for the smallest working version, then run it yourself after every change.
- Change one thing per request. When a request touches five features, you can't tell which one broke.
- Keep a running note of what you asked for and why, so a developer can follow the reasoning later.
That last habit sounds like admin, but it's the cheapest insurance in the list. A developer inheriting an app with no record of its intent has to reverse-engineer both the code and the decisions behind it.
If your goal is a demo for investors or early customers, rapid prototyping with AI shows how teams get from idea to something clickable in days.
Which tools founders end up using
The names that come up most are AI coding agents and app generators. When the security firm Tenzai ran its December 2025 test, it used Claude Code, OpenAI Codex, Cursor, Replit and Devin. Lovable, another popular generator, appears in the incident record below.
We won't rank them here, because the sources we read don't support a winner. In Tenzai's test the low-to-medium severity flaw counts were the same across all five tools. Our comparison of vibe coding tools for non-technical founders goes through the options in more detail.
What the security research found
AI-built apps are usually good at the textbook problems and weak at the ones that depend on your business. That's the pattern in the best evidence available.
InfoWorld reported Tenzai's results: five tools each built the same three applications, and the 15 apps together contained 69 vulnerabilities. About six were rated critical. Tenzai found no exploitable SQL injection or cross-site scripting in any of them.
The serious problems sat elsewhere. The most common was improper authorization when accessing APIs, meaning the app didn't properly check who was allowed to see or change what. Tenzai also said the agents lack human common sense and depend mainly on explicit instructions, which is why business logic is where they slip.
All five agents introduced a server-side request forgery flaw, which lets an attacker make the app fetch arbitrary web addresses. Tenzai's explanation was that no universal rule separates a legitimate URL fetch from a malicious one.
Real products have gone wrong too. Wikipedia's account of the criticism records that in May 2025, 170 of 1,645 web apps built with Lovable had a flaw that exposed personal data to anyone, and that in July 2025 the founder of SaaStr documented a Replit agent deleting a database despite explicit instructions not to change anything.
Treat the Tenzai study as a controlled test of fresh apps, not a measure of every vibe-coded product in the wild. It does show where to look first.
What to check before real users arrive
Photo by Shahram jahansooz on Pexels
Test the places where one customer could reach another customer's information. You don't need to read code to do this, only to try things a stranger might try.
- Log in as one user and see whether you can open another user's records by changing the address in the browser.
- Find every feature where the app fetches a link a user supplies, such as importing from a URL, and ask the tool how it limits where those requests can go.
- Walk through your pricing, discount and permission rules by hand and confirm the app enforces each one, because that's where Tenzai found agents failing.
Security consultants quoted by InfoWorld recommend a secure code review as part of the development process, plus static and dynamic analysis before deployment. A founder can't do those alone. Paying an engineer for a review before launch is the realistic way to cover them.
Why Y Combinator's AI-heavy startups aren't your template
The headline figure is easy to misread. Y Combinator's Jared Friedman said that about a quarter of the Winter 2025 batch had codebases that were 95% AI-generated, and TechCrunch reported his caveat in the same breath.
Friedman said these founders were not non-technical: "Every one of these people is highly technical, completely capable of building their own products from scratch." Diana Hu added that you need enough taste and training to know whether the model is producing good or bad output.
Garry Tan went further, saying reasoning models weren't yet good at debugging, so founders have to understand their products in depth. The speed is real, but the people getting it were already able to catch the tool's mistakes. If you're not one of them yet, you're borrowing someone else's judgment, and that's a gap the review step above has to fill.
For a fuller look at where the approach beats a conventional build and where it doesn't, see our vibe coding versus traditional development comparison.
When to bring in a developer
Bring one in before the app holds other people's data or money, and sooner if you're stuck. Debugging is the other trigger: when the tool starts breaking things it fixed last week, you've reached the limit of describing your way out.
Don't assume AI assistance means a developer will be faster either. A METR study of 246 tasks found developers using AI tools were 19% slower, while believing afterward that they'd been about 20% faster. Felt speed and measured speed can diverge, and a founder has even less to check against.
A prototype that's proved demand is the right input for a proper build. If yours has reached that point, our apps and SaaS development team can take the product forward from what you've already learned. Bring your running notes and the prototype itself.
Frequently asked questions
Who coined the term vibe coding?
Andrej Karpathy, a computer scientist and OpenAI co-founder, described it in an X post at the start of February 2025. Merriam-Webster listed it as slang and trending a month later.
Do I need to learn to code first?
The sources don't say you must. They do say you need enough judgment to tell good output from bad, and that you should understand your product deeply because AI debugging is still unreliable. Learning to read code helps with both.
Is vibe coding the same as no-code?
No-code platforms hide the code behind visual builders, while vibe coding has an AI write real code from your description. Our no-code versus vibe coding breakdown compares them directly.
Cover photo by Jakub Zerdzicki on Pexels
