Vibe Coding: What It Is, How It Works, and Its Limits

Vibe coding is describing what you want in plain language and letting AI build it, then steering the result by telling the AI what’s wrong. What sets it apart from ordinary AI-assisted coding is how you judge the output: you check whether the thing runs and does what you asked, and you don’t read every line the AI wrote. It’s fast for prototypes and small tools. Anything headed for production still needs real engineering checks.

What Vibe Coding Means

In a vibe coding session, the AI writes the code and you act as the product owner. You say what you want, look at what you get, and give feedback in everyday words like “the save button doesn’t do anything” or “make the table sortable by date.” The AI rewrites the code until the result feels right. That’s the “vibe” part: you go by how the software behaves, not by how the code is structured.

It helps to think of it as a spectrum:

• Pure vibe coding: You accept the AI’s changes, test by clicking around, and rarely or never open the code. This is common with non-developers and with throwaway projects.
• The middle ground: You let the AI do most of the writing but skim the changes, run the tests, and step in when something looks off. Most working developers who “vibe code” land here.
• AI-assisted development: A developer reviews, understands, and owns every change. The AI is a fast pair programmer, not the decision maker. Most people wouldn’t call this vibe coding at all.

The term spread quickly in early 2025. By March of that year, articles explaining it were already showing up on Medium. You’ll see it written as “vibe coding,” “vibe-coding,” or “vibecoding.” They all mean the same thing.

Can Coding Be Done With AI?

Yes. Current AI tools can write working code in most mainstream languages, scaffold an interface, set up a database, read error messages, and fix many of their own mistakes. What they don’t take over is the judgment: deciding what to build, knowing your actual business rules, noticing when a result looks right but is wrong for your real cases, and owning what happens when it breaks.

What Vibe Coding Is Not

It isn’t a replacement for requirements, testing, or security review. The AI will happily build something that matches your prompt and still miss the point, mishandle unusual inputs, or leave a door open. Vibe coding makes the typing part of software nearly free. It does nothing for the thinking part unless you bring it.

How a Vibe Coding Session Works

Almost every session follows the same loop:

1. Describe the goal. Tell the AI what you’re building, who uses it, and what it should do.
2. Let it generate. The AI produces the interface, the data model, and the logic, often in one pass.
3. Run it. Click through it like a user would.
4. Report what’s wrong. Use plain words: what you did, what you expected, what happened instead.
5. Repeat until it works well enough for its purpose.

A Running Example: An Expense Approval Tracker

Say you run a small team and you’re tired of approving expenses over email. Your first prompt might be:

Build a simple web app where employees submit expenses (date, amount, category, description) and a manager approves or rejects them. Show a list of all expenses with their status.

A typical first result looks surprisingly good: a clean form, a table of submissions, and Approve and Reject buttons. Then you start poking at it. Anyone can approve anything, including their own expenses. The amount field accepts “lunch.” There’s nowhere to attach a receipt.

Round one of feedback: “Only managers should see Approve and Reject. Employees should only see their own expenses. Add a receipt upload to the form.” The AI adds roles, often with a fake “log in as” dropdown so you can test both views, and a file upload field.

Round two: “The amount must be a positive number with two decimal places. Rejecting should require a reason that the employee can see. Add a monthly total per employee.” Now it feels like a real tool, and you can show it to your team.

Where it usually stalls:

• Logins. That fake role switcher has to become real authentication, ideally tied to the Google Workspace or Microsoft Entra ID accounts your team already uses. This is where many vibe-coded apps quietly become insecure.
• Edge cases. What happens when the manager submits an expense? When the approver is on vacation? When someone edits an expense after it’s approved, or uploads the same receipt twice?
• Real data. Receipts need secure storage, approved expenses need to reach your accounting system (QuickBooks, say), and someone has to decide how long records are kept.

Around here, each fix tends to break something else, and the AI starts rewriting parts you didn’t ask it to touch. That’s the signal that you’ve moved past the easy part.

Why Prompt Clarity Changes Everything

Vague prompts get generic apps. A better first prompt names four things:

• The users: “Employees submit, managers approve, finance exports.”
• The inputs: “Date, amount in USD, category from a fixed list, description, receipt as PDF or image.”
• The outputs: “A status for each expense, a reason on rejections, a monthly CSV export for finance.”
• What “done” looks like: “An employee can submit in under a minute, a manager can’t approve their own expense, and the CSV opens cleanly in Excel.”

Writing that down takes five minutes and saves several rounds of back-and-forth. It also becomes your test list.

Vibe Coding Tools and What Each Type Is For

An AI-based coding platform is software that turns natural-language instructions into code, and usually runs, edits, and sometimes deploys that code for you. They fall into three broad types, and picking the right one matters more than picking the “best” brand.

Browser-Based App Builders

Examples: Lovable, Bolt.new, v0, Replit, and Google AI Studio for quick prototypes.

You type a description in your browser and get a running full-stack web app, often with a database and one-click hosting. These suit non-developers, founders, and designers who want something clickable fast. They shine for demos, MVPs, and simple internal tools.

Where they fall short: the code is shaped around the platform’s conventions, hosting, and integrations, so moving off the platform later can be hard. They also struggle once the app needs complex logic or connections to systems they don’t natively support.

Editor and Terminal Agents

Examples: Cursor, Windsurf, Claude Code, and GitHub Copilot.

These work inside a code editor or your terminal, on a real codebase on your machine or in your repository. They can read and change many files at once, run tests and commands, and fix errors they find. They suit developers, and they’re the right choice once a project has real structure, version control, and tests.

Where they fall short: they assume you can read code. When an agent makes a sweeping change across a dozen files, you need to be able to tell whether it was right. For a non-developer, that’s pure vibe coding with sharper tools and bigger consequences.

General Chat Assistants

Examples: ChatGPT and similar assistants.

Good for generating a script, a formula, a regular expression, or an explanation of an error. They suit anyone who needs a small piece of code and can paste it somewhere useful.

Where they fall short: they don’t see your whole project, so they can’t keep many files consistent, and you’re the one copying code in and out. That works for snippets and gets messy fast for apps.

Examples of What People Build With Vibe Coding

Here’s a realistic spread, with a note on whether each one usually stays a prototype or can go live as is:

• Personal utilities and scripts (renaming files, tracking habits, a recipe scaler): fine to use as is, since you’re the only user.
• Landing pages: often fine to publish once you’ve checked the forms, links, and mobile layout.
• Simple games: fine for fun and sharing; rarely meant to be anything more.
• Clickable MVPs for pitching an idea: a prototype by design. Great for investors or customers to react to, not for real signups and payments.
• Data cleanup and reporting scripts: can be used as is if someone checks the output against a known-good sample first.
• Internal dashboards: can go live for a small team if the data is read-only and access is locked down.
• Form-to-spreadsheet workflow automations: often fine for low volume; needs hardening once a failure would mean lost orders or missed approvals.
• Early client portal mockups: a prototype. Anything that shows client data to clients needs proper authentication and a security review first.

The pattern: the fewer people who rely on it, and the less sensitive the data, the more likely the vibe-coded version is good enough.

Where Vibe Coding Helps and Where It Breaks Down

Where It Helps

• Speed from idea to working demo. Hours instead of weeks for a first version you can click through.
• Access for people who don’t code. Operations leads, analysts, and founders can build their own tools or show developers exactly what they mean.
• Faster stakeholder alignment. People react much better to something real than to a spec document. A rough working app flushes out disagreements early, when they’re cheap.
• Less time on boilerplate. One Medium author argues that developers spend 40–60% of their time writing boilerplate and searching documentation. Whatever the exact share in your team, that repetitive work is exactly what AI tools absorb well.

Where It Breaks Down

• Complex business logic. Pricing rules, approval chains with exceptions, and compliance requirements are hard to describe completely in a prompt, and the AI fills gaps with guesses.
• Integrations with systems like CRMs and ERPs. Connecting reliably to Salesforce, NetSuite, or a legacy SQL database means handling authentication, rate limits, retries, and data mapping that demos skip.
• Performance at scale. Code that’s fine with 50 test records can crawl with real volumes.
• Offline and device-specific features. Offline sync, background tasks, Bluetooth, and strict device management policies are where generated apps tend to fall apart.
• Debugging code nobody understands. When something breaks and no one on the team knows how the code works, you’re stuck asking the AI to guess at its own bugs.

Security, Privacy, and Maintenance Risks

None of these risks mean you shouldn’t vibe code. They mean you should know where the weak spots are and patch them before real people depend on the result.

• Hidden bugs and missing edge cases. The app works on the happy path and fails on the weird ones. Mitigation: write down your top edge cases before you start and test each one yourself. Ask the AI to write automated tests for them too.
• Insecure defaults. Common examples are API keys pasted into front-end code, weak or fake authentication, and input that’s never validated. Mitigation: keep secrets in environment variables, never in code; use an established authentication provider; and check the app against the OWASP Top 10 list of common web vulnerabilities. Tools like GitHub’s secret scanning or gitleaks catch leaked keys.
• Outdated or unvetted dependencies. AI tools pull in libraries freely, sometimes old versions, sometimes obscure packages. Mitigation: run npm audit or your language’s equivalent, turn on Dependabot or a similar update tool, and question any package you’ve never heard of.
• Sensitive data pasted into third-party AI tools. Customer records, contracts, and credentials dropped into a prompt leave your control. Mitigation: use fake or sample data while building, check your AI vendor’s data-use settings, and set a clear company policy on what can go into prompts. Some organizations go further and use self-hosted or private AI setups so data never reaches an external tool.
• Fragile code that’s hard to change. Generated code often grows by patching on patches. Mitigation: use version control from day one so you can roll back, and have a developer refactor anything you plan to keep.
• Lock-in to a builder’s hosting or format. Mitigation: before you commit, confirm you can export the full code and run it elsewhere, and check where the data lives.
• No clear owner. The person who prompted it changes roles and nobody knows how it works. Mitigation: name an owner, write a short README covering what it does and how to run it, and store prompts alongside the code.

Taking a Vibe-Coded Prototype to Production

If a prototype has proven its worth and people want to rely on it, slow down before you generate more code. Here’s a guardrail checklist:

1. Write a one-sentence problem statement naming the workflow, the users, and the business impact. For example: “Managers approve expenses by email, so reimbursements are late and nobody can see what’s pending.”
2. Capture a measurable baseline. Document what triggers the work, the steps and handoffs, the systems it touches, and the top five exceptions that cause rework. Measure how long it takes today, so you can prove the new tool helped. This discovery approach comes from how JAMD Technologies plans app builds, and it works just as well for finishing a prototype.
3. Turn the problem into acceptance criteria. Specific, testable statements like “a manager cannot approve their own expense.”
4. Get a developer to review the architecture and code. Is the data model sound? Is authentication real? Will this survive real volumes?
5. Add automated tests for the acceptance criteria and known edge cases.
6. Set up version control and CI/CD, for example GitHub with GitHub Actions, so every change is tracked, tested, and deployed the same way.
7. Run a security review covering secrets, authentication, input validation, dependencies, and data storage.
8. Document it: what it does, how to run it, how to deploy it, and known limitations.
9. Assign a named owner responsible for support and changes.

The Realistic Paths

• Rebuild cleanly, using the prototype as the spec. Often the best choice when the code is tangled or locked to a builder. The prototype already answered the hardest question: what should this thing do?
• Harden the existing code. Works when the structure is reasonable and the stack fits your environment. A developer refactors, adds tests, and fixes security gaps.
• Hand it off. Give it to your in-house engineering team, or to an outside partner. JAMD Technologies, for example, offers a Vibe Code Finisher service for completing vibe-coded prototypes.

Pick based on how much of the code you’d keep after an honest review. If the answer is “not much,” rebuilding is usually faster than fighting it.

How to Start Vibe Coding Responsibly

1. Pick something low-stakes and internal, like a personal tracker or a tool only your team uses.
2. Write a clear prompt covering users, inputs, outputs, and what “done” looks like.
3. Choose a tool that matches your skills. Browser app builders if you don’t code, editor agents if you do, a chat assistant for a quick script.
4. Keep everything in version control so you can always undo a bad change.
5. Use fake or sample data. Never real customer data while building.
6. Test the edge cases yourself: empty fields, wrong formats, the same action twice, the wrong user trying something.
7. Have someone who reads code review it before anyone else relies on it.

And a simple rule for knowing when you’ve outgrown vibe coding: if a failure would cost someone money, expose data, or stop real work, or if nobody can explain how a part of it works, it’s time for engineering. Until then, have fun with it. That’s what the vibes are for.

Sources

• 🎧 Vibe Coding: A New Rhythm for Building Software in the …
• Vibe Coding: Embracing AI-Driven Development for …