What is vibe coding? A practical guide for designers (2026)

Vibe coding is a way of making software where you describe what you want in plain language, an AI model writes the code, and you judge the result by running it. You type "add a booking form under the menu", look at the screen, and ask for the next change. The name comes from Andrej Karpathy, who described it in early February 2025 as giving in to the vibes and forgetting "that the code even exists".

That is the strict meaning. In everyday use, the term now covers almost any software built through a conversation with AI, from a weekend toy to a real product. The gap between those two is where most of the risk lives, and most of this guide is about that gap.

I am a designer. I have drawn logos, packaging and interfaces since 2010, and today I also build and ship whole products with Claude Code as a tool in my hand. In this guide I explain where the term came from, what it means and what it doesn't, who it suits, the main types of tools, the workflow I follow, the security basics you cannot skip, and where vibe coding stops working.

Where the term "vibe coding" comes from

In early February 2025, Andrej Karpathy, a founding engineer at OpenAI and former head of AI at Tesla, wrote a post on X that began like this:

"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." (Andrej Karpathy, February 2025)

He went on to describe the method honestly. He accepted every change the AI proposed without reading the diffs (the list of what changed in the code). When an error appeared, he pasted the message back with no comment, and usually that fixed it. When a bug would not go away, he worked around it or asked for random changes until it disappeared. He called it "not too bad for throwaway weekend projects".

That last phrase is the part most people forget. Karpathy was describing a playful way to make small things quickly, not a method for software that holds other people's money or data.

The name stuck because it gave a word to something many people were already doing. In November 2025, Collins Dictionary named "vibe coding" its Word of the Year, and defined it as "the use of artificial intelligence prompted by natural language to write computer code".

Developers pushed back on the loose use of the term early on. Simon Willison, a developer who writes widely about these tools, drew a clear line in March 2025: if an AI wrote your code but you reviewed it, tested it and can explain how it works, that is not vibe coding, it is software development. By 2026 he and other engineers were using "agentic engineering" for the careful, professional version, to keep the two apart.

What vibe coding means, and what it doesn't

Today the phrase is used in two ways, and it helps to know which one someone means.

The strict meaning is Karpathy's: you do not look at the code at all. You judge only what you see on the screen. It is fast and fun, and it is fine for a prototype you will throw away.

The broad meaning is building software mainly by talking to an AI model in plain language, whatever you do afterwards. This is how most designers and founders use the term, and it is how I use it on this site.

What it does not mean is that the AI is in charge. Even in the loosest version, a person decides what to build, judges whether it works, and carries the responsibility when it does not. In my own work the line is simple: I direct, AI accelerates. The model writes code quickly. I decide what gets made, what "done" means, and what is allowed to reach a user.

Both columns count as vibe coding in the everyday sense. Only the right-hand one is something I would put my name on.

Who vibe coding suits

Designers

Designers are better prepared for this than they think. You already think in screens, flows, states and systems. You know what an empty state is, what happens on a small phone, and how a button should feel when it is pressed. Those are exactly the decisions an AI model cannot make for you, and the ones it needs from you to produce something good.

A designer who can vibe code can turn a Figma prototype into something that really works, test an interaction with real data, build a portfolio site exactly as it was designed, or make small tools for a studio. The distance between "this is how it should work" and "this works" gets much shorter.

Founders

For a founder, the main value is the speed of learning. You can put a working version of an idea in front of real users before you hire a team or raise money. The risk is mistaking that first version for a finished product. A prototype that proves people want something is a success. A prototype that quietly becomes the product, with nobody checking how it stores customer data, is a debt.

People who don't program

A teacher, a shop owner or an accountant can use vibe coding to make personal tools that no software company would ever make for them: a tracker for a class, a price calculator, a simple booking page. Start with something only you will use. Move on to tools for other people when you are ready to take on the checks described below.

When it does not suit

If a mistake in your software could hurt someone, cost someone money or expose private information (health records, payments, children's data), vibe coding on its own is not enough. You can still use AI tools, but you need someone who can review the code properly, and you should treat that review as part of the job, not a nice extra.

The main types of vibe coding tools

These tools change almost every month, so I describe them by type and by what their makers say they do. Check each official site for current features and prices before you choose. I compare them in more detail in Claude Code vs Cursor vs Lovable vs Bolt vs v0.

Agentic coding tools: Claude Code and Cursor

These tools work inside a real project: real files, real commands, real version control. You talk to them, they read your project, propose and make changes, run commands and report back. You approve, correct or undo.

• Claude Code is Anthropic's agentic coding tool. Its documentation describes a tool that "reads your codebase, edits files, runs commands, and integrates with your development tools". It runs in the terminal, inside code editors such as VS Code and JetBrains, in a desktop app and in the browser.
• Cursor is a code editor built around AI agents. It calls itself "your coding agent for building ambitious software", and lets you choose between models from several AI companies.

They suit you when you want to own the code, keep it in your own repository and grow a project over months.

App builders in the browser: Lovable, Bolt and v0

These tools let you describe an app in a chat window, see a live preview next to it and publish it, all in the browser. They take care of much of the setup that scares newcomers.

• Lovable describes itself as "a full-stack AI development platform for building, iterating on, and deploying web applications using natural language". From your description it generates the front end, back end, database and login, and it can sync the code to GitHub.
• Bolt invites you to "create stunning apps & websites by chatting with AI", and offers hosting, databases and user accounts through its own cloud service.
• v0 from Vercel generates interfaces and full-stack apps from a description, a wireframe or a mockup, and can deploy to Vercel or open a pull request for review.

Many people start with an app builder and move to an agentic tool once the project becomes serious. That is a sensible path, as long as you can take your code with you.

A realistic workflow for a designer

This is the workflow I follow. I use it for my own products: CofyTill, an Arabic cashier system for cafés and roasteries that keeps selling offline and syncs to the cloud, and MATN, an Egyptian e-learning platform for teachers with a website and iOS and Android apps. I used it for this bilingual portfolio site too. I founded both products and designed their brands and experience, and Claude Code is the tool I direct to write the code. The method below is general on purpose: it is a way of working, not a recipe tied to one project.

1. Write the brief before the first prompt

Before any prompt, write a page. Who is this for? What are the main screens? What data does it keep, and who is allowed to see it? What is out of scope for the first version? This is a design brief, and designers already know how to write one.

Claude Code has a plan mode in which it reads files and answers questions without changing anything. I use that stage to ask it to read the brief, question me about the gaps and write a plan. I edit the plan before a single file changes.

2. Work in small steps

One feature, one screen or one fix at a time. If you cannot describe a change in one or two sentences, it is too big, so split it. Small steps are easier to test, easier to undo and easier for the model to get right.

3. Give every step a way to be checked

The Claude Code documentation puts it plainly: "If you can't verify it, don't ship it." A check can be an automated test, a build that has to pass, or a screenshot compared with your design. For a designer, the click-through matters most: open the page on a phone, switch to Arabic, submit an empty form, try a slow connection. Then ask the AI for evidence, such as the test output or the command it ran, rather than taking its word that something works.

4. Use version control from day one

Git saves a snapshot of your project every time you commit. If a change breaks something, you go back to the last version that worked. Some tools have their own undo (Claude Code can rewind its own edits), but its documentation is clear that this "isn't a replacement for git". Commit after every working step, and push to a private repository so your work also lives somewhere other than your laptop.

5. Read what the AI wrote

You do not have to understand every line. You do have to know what changed. Read the summary after each step, look at which files were touched, and ask "why did you change this file?" when something looks unrelated. Ask for plain-language explanations of anything that handles logins, payments or personal data. Over time you learn to read code the way you learned to read someone else's layered PSD: not every pixel, but enough to know where things are and what holds them together.

6. Give the project a memory

Agentic tools can read a rules file at the start of every session. In Claude Code it is called CLAUDE.md. I write in it what I would tell a new team member on day one: the languages and reading direction, the brand colours and type, the commands that run the checks, and the parts nobody touches without asking. It keeps the work consistent across weeks of sessions.

If you are not a programmer and want a gentler start, I wrote a separate guide to Claude Code for non-programmers, and another on how to build a website with AI step by step.

Security basics you cannot skip

Most of the real risk in vibe coding sits in four places: secrets, access, data and permissions.

Secrets

API keys, database passwords and payment keys never go into the code, a screenshot or a chat. Keep them in environment files that are excluded from Git, and in the secret settings of your hosting service. A key placed in front-end code can be read by anyone who opens the browser's developer tools. If a key ever leaks, cancel it and create a new one the same day.

Logins and who can see what

A login screen is not security on its own. The real question is what each logged-in person is allowed to see and change. The OWASP Top 10, the best-known list of web application security risks, puts broken access control in first place in its 2025 edition: people reaching data or actions that should not be theirs.

This is not theoretical for vibe-coded apps. A public vulnerability record published in May 2025 (CVE-2025-48757) described how an insufficient database access policy in Lovable, up to mid-April 2025, let attackers who were not logged in read or write the database tables of generated sites. The lesson applies to every tool. Ask the AI to explain, table by table, who can read and write what. Then log in as two different test users and try to see each other's data.

Data

Collect only what you need. Know where the data is stored and in which country. Keep backups, and test that you can actually restore them. If your users are in Egypt, Saudi Arabia or Europe, data protection laws apply to you, so read the official guidance or ask a lawyer before you launch.

Packages and permissions

AI tools often add ready-made packages to a project. Check that each one is real, well known and maintained before you accept it. Be careful with what you allow an agent to do: give it a copy of the database to work on, never the live one, and keep anything destructive behind your approval.

Common failure modes

These are the problems that come up again and again.

• The endless fix loop. You paste the same error back again and again, and each "fix" breaks something else. Stop. The Claude Code guide suggests that after two failed corrections you clear the session and start again with a better prompt that includes what you learned.
• It works on my screen. The demo looks perfect with sample data on a large monitor. Then a real user types a long Arabic name, opens it on an old phone or loses the connection. Test the edges: empty, long, slow, small, right to left.
• Code that nobody understands. Karpathy himself wrote that the code grows beyond his usual comprehension. That is fine for a toy and dangerous for a product. Ask for explanations as you go, and keep the structure simple.
• Quiet scope creep. You ask for a button, and the AI also "improves" three other files. Read the list of changed files after every step, and undo what you did not ask for.
• Looks done, isn't. The main path works and the edge cases do not. A plausible result is not a tested one.
• Lost work. No Git, one bad change, and a week is gone. This one is completely avoidable.

The limits of vibe coding

Vibe coding is a real change in who can make software, and I work this way every day. It still has limits, and pretending otherwise hurts the people who use what we make.

• High stakes need real review. Payments, health information and systems many people depend on need someone who can read and question the code. AI tools make that person faster. They do not replace them.
• You own what you ship. Every line in your project is now yours to maintain: updates, security fixes, broken dependencies. The AI will not get the phone call when the till stops working in a café on a Friday night.
• Costs add up. Subscriptions, usage and hosting all cost money, and they grow with the project. Check current pricing on each official site before you plan a budget.
• Taste is still yours. A model will happily produce the average of everything it has seen. The decisions that make a product feel considered (the flow, the hierarchy, the words, the small moment of delight) come from the person directing it. This is where designers have a real advantage.
• Big projects need structure. As a project grows, vague prompts stop working. You need a clear plan, small steps and a codebase you can still find your way around.

Conclusion

Vibe coding started as a joke about forgetting that code exists. It has become a serious way for designers, founders and non-programmers to make real software, on one condition: you stay the one who directs, reviews and tests. Use an app builder to try ideas fast, an agentic tool when you want to own the product, and Git, checks and basic security every time.

If you have a product idea and want a designer who can take it from the brand to a working build, tell me about your project.