Vibe coding is building software by describing what you want to an AI tool in plain English and accepting the code it writes without reading it. For a business, it suits quick prototypes and internal tools, and it is risky for anything that takes payments, stores customer data or has to keep running for years.
AI researcher Andrej Karpathy coined the term in February 2025 for a style of work where you "forget that the code even exists". Collins Dictionary named it Word of the Year in November 2025. Collins defines it as the use of AI, prompted by natural language, to help write computer code. AI app builders can now produce a working app, website or dashboard from a few sentences.
For a founder, the hard part is spotting which projects it saves money on and which ones it quietly turns into a bill for later. The deciding question is what a bug would cost you.
How vibe coding works, step by step
The process is a loop. You type a request, the AI writes or changes the code, you try the result and you say what looks wrong. You judge the app by how it behaves on screen rather than by reading the code underneath. Some tools sit inside a code editor, and others are app builders that host the finished app.
- Describe the outcome in everyday words, for example "a booking form that emails me each new request and blocks two bookings for the same slot".
- The AI generates the screens, the database tables and the logic in one pass, within minutes.
- Click through it and report what broke: "the date picker lets customers book last Tuesday".
- Repeat until it looks right, then publish, which many app builders let you do with a single button.
What makes it vibe coding is the step everyone skips. Nobody reads the code, checks how passwords are stored or asks who else can query the database. When the screen looks right, the job feels finished, and that feeling is where the risk starts.
The line between vibe coding and AI-assisted coding
Review is the whole difference. Developer Simon Willison defines vibe coding as building software with an AI model "without reviewing the code it writes". A developer who reads, tests and understands each AI suggestion before it ships is doing AI-assisted programming. That work carries much less risk, even though the tools are the same.
The difference matters when you hire. A freelancer or agency that tells you they use AI has not told you anything about quality. Ask the follow-up question: who reads the AI's code before it goes live, and what tests run on it? Good answers name a person and a process. Vague ones mean you may be paying developer rates for vibe-coded work.
Why founders started taking it seriously
Founders noticed because AI-written code began shipping inside real products, built by technical teams who could judge the output. In March 2025, Y Combinator managing partner Jared Friedman said a quarter of its Winter 2025 startups had codebases that were 95% AI-generated.
The caveat sits in the same conversation. Friedman stressed that every one of those founders could have built their product from scratch without AI. Diana Hu, a general partner at Y Combinator, said founders still "have to have the taste and enough training to know that an LLM is spitting bad stuff or good stuff".
Working developers are more cautious than the headlines. In Stack Overflow's 2025 Developer Survey, 84% of respondents said they use or plan to use AI tools. Among professional developers, 51% use them daily. But 46% said they distrust the accuracy of AI output, against 33% who trust it. Asked whether vibe coding is part of their professional work, 72.2% said no and another 5.3% said no, emphatically. So more than three in four respondents keep unreviewed AI code out of their paid work.
Where vibe coding works well for a business
AI-built software works well when a mistake costs you an afternoon rather than a customer. That covers clickable prototypes for testing an idea, internal tools a few staff use, one-off data jobs and landing pages you plan to throw away. Karpathy pitched it for "throwaway weekend projects", and Willison treats low-stakes work as fair game.
Prototypes you show to users, then replace. A clickable version of a customer portal lets ten real customers tell you what they would pay for before you fund a proper build. Treat it as a sketch that answers one question, then retire it.
Internal tools with no customer data in them. A stock tracker for a six-person warehouse team, a form that turns site-visit notes into a PDF or a dashboard that merges two spreadsheets all fit here. If one breaks, a colleague tells you at lunch and nobody outside the company is affected.
Data clean-ups belong here too. Cleaning a 4,000-row contact export or merging two price lists is work you can check by eye, so unread code costs little.
Consider a 12-person cleaning company that wants online booking. The owner vibe codes a booking prototype over a weekend and sends it to 20 regular clients. The replies show clients care more about rebooking the same cleaner than about choosing a time slot. That finding rewrites the brief before a developer bills a single hour. The prototype has done its job, even if none of its code survives.
What the research says about AI-generated code security
AI-written code passes a demo far more reliably than it passes a security review. In a 2025 study, Veracode tested more than 100 large language models on 80 coding tasks and found they introduced security flaws in 45% of cases.
The weak spots are the ones attackers use. Cross-site scripting, where an attacker slips malicious code into a page your customers load, went unprotected in 86% of the relevant tests. Veracode's CTO, Jens Wessling, put the trend plainly: models "are getting better at coding accurately but are not improving at security".
Academic researchers found the same gap. A benchmark called SusVibes, published in December 2025, gave AI coding agents 186 real feature requests from open-source projects. With SWE-Agent running Claude 4 Sonnet, 57% of the solutions worked and only 11.8% were secure. All 12 agent setups tested scored poorly on security.
Real apps have already paid for this. In May 2025, a flaw in apps generated by the AI app builder Lovable was published as CVE-2025-48757, rated 9.3 out of 10 for severity. Missing database access rules let anyone, without logging in, read or write the tables behind the generated sites. Researcher Matt Palmer found 303 exposed endpoints across 170 projects, leaking usernames, emails, phone numbers, payment status and secret API credentials.
Nobody on those projects had switched on the rule that stops one visitor reading another visitor's records. Checking for that rule is one of the first things a developer does in a review.
Payments, customer data and live systems need a developer
Payments, logins and customer records are where vibe coding should stop and a developer should start. A mistake there exposes other people's money or data, and the cost lands on your business. Stripe's security guide warns that a business handling raw card data may have to meet more than 300 security controls under PCI DSS, the card industry's security standard.
The safe pattern keeps card numbers out of your code altogether. Use your payment provider's hosted checkout page or its ready-made payment fields. Card details then travel straight to the provider rather than through an app nobody has reviewed. Stripe describes these low-risk integrations as sending payment details to Stripe without them passing through your servers, which reduces your compliance obligations.
Usage-based services need the same care. Willison warns against building anything charged by usage this way. AI, text message and mapping services all bill per use, and he cites cases where unmonitored calls ran up thousands in unexpected charges.
Live systems carry a further risk: an AI agent acting on real data. In July 2025, SaaS investor Jason Lemkin was on day 9 of a 12-day vibe coding test with Replit's AI agent. The agent deleted his production database, which held more than a thousand records on executives and companies. He had given a written instruction that no further changes be made without his permission. Lemkin recovered the data himself, and Replit's chief executive Amjad Masad called the incident "unacceptable" and rolled out automatic separation between development and production databases.
Two habits guard against this. Give an AI agent a test copy of your data, never the live database, and keep backups you have restored at least once. Customer data adds a duty of care on top. If an app stores names, emails, health details or financial records, protecting them is your responsibility, whoever or whatever wrote the code.
The upkeep bill nobody quotes you
The larger cost of a vibe-coded app arrives after launch, when someone has to change code nobody understands. AI output can look right before it is right. In Stack Overflow's 2025 survey, 66% of developers named "AI solutions that are almost right, but not quite" as their top frustration, and 45.2% said debugging AI-generated code takes more time.
Software needs work after it ships. Libraries publish security patches, browsers change, payment and email providers retire old versions of their services, and your own prices, tax rules and processes move. Each change means someone opens the code and works out how it fits together before touching a line.
Here is how that plays out. Six months after launch, a client reports that invoices show the wrong tax. The founder who prompted the app can't remember which of 40 chat sessions produced the invoice logic, and the AI's fix breaks the discount code. A developer now reads the whole codebase before changing one line, and that reading time is billed.
Budget for upkeep from the first day rather than treating launch as the finish line. If nobody on your team can read the code, your maintenance plan is someone you pay, so name them before you go live.
A simple rule for what to vibe code
Sort each part of a project by what a bug would cost. Where a bug only costs you time, vibe code freely. If a bug could expose a customer, lose money or break a law, a developer reviews it before launch. Anything your business cannot run without belongs to a developer from the start.
- Safe to build freely with AI: mockups, prototypes for user tests, internal tools with no customer data, one-off scripts and throwaway landing pages.
- Your public website, contact and booking forms, user logins and links to your CRM or email platform can start as AI drafts, with a developer's review before launch.
- Payments, health or financial records, children's data and anything that moves money or makes decisions about people belong with a developer from day one.
Then ask whoever builds it, whether a freelancer, an agency or your own staff, four questions before you sign. Who reviews AI-written code? Where are passwords and payment credentials stored? What happens when something breaks after launch? Do you receive the code and the hosting account if you part ways? Clear answers to all four are worth more than a low quote.
How to hand a vibe-coded prototype to a developer
A clean handover turns a vibe-coded prototype into a brief a developer can price. Give them the working app, the prompts or chat history that built it, a written list of what it must do and access to every account it touches. Expect them to keep the screens and flows you tested and rebuild the parts that handle data.
- Export the code to a repository in your own name, so it does not live only inside the builder's account.
- Write one page covering what the app must do, who uses it and what data it stores.
- List every outside service it connects to, such as email, payments, maps or AI models, and move each login and credential into accounts your business owns.
- Ask for a short review before any rebuild quote, covering security, data handling and which parts are worth keeping.
- Agree in writing who maintains the app after launch and how fast they respond when it breaks.
Treat the prototype as the most detailed brief you have ever written. A developer quoting from a working prototype prices fewer unknowns than one quoting from a two-line email. That is where the prototype pays for itself.
Should your business use vibe coding?
Your business should use vibe coding if someone will review what it produces before customers rely on it. Without that person, keep it to prototypes and internal tools. The best results come from founders who vibe code the first version, test it with real users and pay a developer to review whatever goes live.
The tools are improving. After these flaws came to light, Lovable released a security scanner and Replit added automatic separation of test and live databases. Those changes help. They still leave a gap: an app builder can flag a missing rule, but it cannot answer to your customers when data leaks. That job stays with someone who understands the code.
A sensible first step is one internal tool or one prototype this quarter. Write one rule down before you start: nothing that touches customer data or money goes live unreviewed. Let the AI draft, and let a person sign off.
If you have a vibe-coded prototype and want to know what it would take to launch it safely, talk to the Techno Mantraa team through our contact page at technomantraa.com/contact-us or at info@technomantraa.com.
Frequently asked questions
It is safe for prototypes and internal tools that hold no customer data. For anything public, have a developer review the code first: Veracode found AI models introduced security flaws in 45% of the coding tasks it tested in 2025.
Yes, AI app builders can produce a working site from a written description within minutes. If the site has contact forms, logins or payments, have a developer check its security before it goes live.
Vibe coding means accepting AI-written code without reviewing it. AI-assisted coding uses the same tools, but a developer reads, tests and understands every change before it ships.
Andrej Karpathy, an OpenAI founding engineer and former director of AI at Tesla, coined it in February 2025. Collins Dictionary named vibe coding its Word of the Year in November 2025.
For a prototype or an internal tool with no customer data, you can manage without one. For anything that takes payments, stores customer data or keeps your business running, you need a developer to review the code before launch and maintain it afterwards.