Vibe coding: what it is and how to start

Vibe coding: what it is and how to start

Vibe coding is a way of building software where you describe in plain words what you want and an AI model writes the code for you. Andrej Karpathy coined the term in February 2025. To start, pick a small project that holds no one else's data and a single tool such as Lovable or Cursor, then work in short steps and check every result.

A simple app can take one evening, but so can code nobody understands, that leaks user data or burns through a credit budget. This guide shows how to use the method without those costs.

Where the term vibe coding comes from

On 2 February 2025, Andrej Karpathy, an OpenAI co-founder and former director of AI at Tesla, published a short post on X about a new kind of coding in which you "forget that the code even exists". He spoke to Cursor's Composer feature by voice, accepted every change without reading the diffs and pasted error messages back without comment. When the code outgrew his understanding and the model couldn't fix a bug, he asked for random changes until it went away. He admitted this suits throwaway weekend projects.

The name caught on faster than the caveat. In November 2025, Collins named vibe coding its Word of the Year 2025, and many people now use it for any programming with AI help.

In March 2025, developer Simon Willison drew a useful line in his post Not all AI-assisted programming is vibe coding. If a model wrote the code and you reviewed it, tested it and can explain how it works, that's ordinary software development, not vibe coding. Vibe coding starts where you deliberately stop trying to understand the code and judge only the result.

In 2026, Karpathy popularised a second term. In his notes from a conversation at Sequoia Ascent 2026 he writes that vibe coding lifts the baseline, letting almost anyone build working software, while agentic engineering is a professional discipline: AI agents write the code, and people design specifications, review changes, write tests and manage permissions. Together, the terms map a learning path from play to deliberate work.

How building apps from a description works

Whatever the tool, the loop is similar: you describe what you want, the model writes or changes code, the tool runs it, and you check the result and say what to fix. The model can't see your screen; it knows only what reached the conversation: your description, project files, error messages and, in some tools, screenshots and test results. So your description matters a lot.

The tools fall into three families:

1. App builders in the browser. Lovable, Bolt, v0 and Replit run the work in a chat window with a live preview. You install nothing and publishing is included. It's the easiest start, with the least control over the code.
2. Editors with an agent. Cursor, Windsurf, which Cognition now develops as Devin Desktop, and GitHub Copilot in VS Code and other editors. The agent edits files on your computer, runs commands and shows changes for approval. Cursor creates checkpoints before bigger changes, so undoing a failed attempt takes one click.
3. Agents in the terminal. Claude Code, covered in the article on Claude models, works on your repository from the command line. It reads instructions from CLAUDE.md and has a plan mode that edits files only after you approve the plan.

Amounts change often, so they're listed separately, as shown on vendor sites in September 2026. Cursor starts at 20 USD a month, as does Claude Pro (17 USD a month on annual billing), which includes Claude Code, unavailable on the free plan. Devin Desktop Pro costs 20 USD, Bolt Pro 25 USD, v0 Plus 30 USD per user and GitHub Copilot Pro 10 USD. Lovable's price list as shown in Poland puts Pro at 25 EUR including VAT. Check the current price list on the vendor's site before you buy.

Your first project step by step

For a first project, pick something small that's useful to you and handles no one else's data, such as a habit tracker with a days-in-a-row counter. It needs no login, server or payments, yet has real logic you can understand and check.

1. Describe the project before you open a tool

A short specification saves a dozen fixes. Note what the app should do and what the first version deliberately leaves out:

# Habit tracker

Goal: a simple page where I list a few habits and tick them off every day.

Must have:
- adding and removing a habit
- ticking a habit off for today
- a days-in-a-row counter for each habit
- data saved in the browser (localStorage), no login and no server

Not now:
- user accounts, payments or notifications

2. Pick a tool and ask for a plan

A browser app builder needs no install. An editor with an agent does, but teaches more, because you see every file and every change. Either way, ask for a plan first, so misunderstandings surface before they become ten files to fix:

Build a web app based on the specification below.
Use plain HTML, CSS and JavaScript, with no frameworks or extra libraries.
English interface, comfortable to use on a phone.
First list a plan: which files you'll create and which functions each will contain.
Write the code only after I approve the plan.

[paste the specification here]

3. Check before you move on

Add a habit with an empty name, one with a very long name and two with the same name. Refresh the page and check that the data stayed. Also ask what the counter does when you tick a habit off at 23:59 and then at 0:01: dates and time zones are a classic source of bugs, even in human-written code. Report each problem separately.

4. Save working versions

App builders keep their own version history; in an editor, use Git. Each commit is a point to return to when the next request breaks something:

git init
git add -A
git commit -m "Tracker: adding and ticking off habits works"

5. Ask for an explanation and read the key part

Ask the model how the app saves data, then find that part in the code. It usually looks like this:

const STORAGE_KEY = 'habits'

function loadHabits() {
  const saved = localStorage.getItem(STORAGE_KEY)
  return saved ? JSON.parse(saved) : []
}

function saveHabits(habits) {
  localStorage.setItem(STORAGE_KEY, JSON.stringify(habits))
}

localStorage stores only text, so the habit list becomes JSON on save and a list again on read. If nothing has been saved yet, getItem returns null, so the function returns an empty list. The data lives only in this browser: you won't see it on your phone, and clearing the site's data deletes it. Know limits like these before promising anyone the app will remember their progress.

6. Publish

App builders publish with one button; a project from an editor goes to GitHub and then to Vercel or Netlify. A working address is a good moment to review what you've actually built.

Prompting patterns that work

Most disappointment comes from requests that are obvious to a person but ambiguous to a model. Simple habits help:

• Context before the task. Say who the app is for and what it should achieve, then what to change.
• One change per message. Asking for five things at once usually ends with undoing two.
• Refer to what exists. "Make a stats screen in the style of the habit list" gives a consistent result; "add stats" gives something entirely new.
• Limits of the change. Say which files, visuals and dependencies to leave alone.
• Edge cases stated outright. The model builds the happy path, so an empty list, a failed save or the date changing at midnight need a separate mention.
• The full error message. Paste all of it and say what you did just before, instead of "it doesn't work".

The difference shows in a bug report:

Weak: fix the counter, it doesn't work

Better: the days-in-a-row counter shows 0 after a page refresh, even
though the "Reading" habit is ticked off yesterday and today. I expect 2.
Find the cause, describe it in two sentences and fix only the function
that counts the streak. Don't change the look or any other files.

Put rules you repeat in every conversation into a project file. Cursor reads project rules from the .cursor/rules folder or an AGENTS.md file, while Claude Code reads CLAUDE.md and can use AGENTS.md too. A short file will do:

# Project rules

- Plain HTML, CSS and JavaScript, no frameworks or new dependencies
- Data only in localStorage under the "habits" key
- Before a larger change, present a plan and wait for approval
- After each change, list the changed files and the reason
- Don't remove existing functions without asking

Limits and risks

Vibe coding works very well for prototypes and tools for your own use. Trouble starts when an app reaches other people, stores their data or has to run for years.

Security

Code that works isn't necessarily secure. Veracode regularly tests code generated by models, and its March 2026 update reports that only 55% of code generation tasks produced secure code, a figure that has barely moved in two years of model releases.

Three mistakes keep recurring in apps built from a description. Keys to external services end up in code running in the browser, where anyone can read them. Database access rules stay open, so one user can see others' data, which with a Supabase back end usually means missing row level security. Permissions are checked only in the interface, not on the server. The article on Lovable shows how to check this quickly.

Agents with broad permissions are a separate risk. In July 2025, an agent in Replit deleted a production database in a project run by Jason Lemkin, founder of the SaaStr community, despite an instruction not to change anything without permission. The data was recovered, although the tool had claimed rollback was impossible. So keep agents away from production data, and make commands that delete anything require your confirmation.

Code you don't understand

As long as everything works, not understanding the code doesn't hurt. Trouble begins with the first bug the model can't fix, and grows with every feature added without understanding the earlier ones. In the 2025 Stack Overflow survey, the biggest frustration with AI tools, named by 66% of respondents, was solutions that are almost right but not quite, and 45.2% said debugging AI-generated code takes more time. In the same survey, 72% said vibe coding isn't part of their professional work.

Costs

App builders bill in credits or tokens, editors by subscription with limits, and models used through an API charge for every token. Fix loops cost the most: when the model doesn't understand the problem, the same change comes back five times, and every attempt costs. Hosting, a database, a domain and paid services your app uses come on top. Before upgrading, check in the dashboard where the usage went, and set spending limits wherever you can.

Why programming fundamentals still matter

Vibe coding shifts the work from writing code to describing, checking and deciding, and each of those takes knowledge. To describe a task, you need the names of an app's parts. To judge a result, you must tell a correct solution from one that only looks correct. To fix a bug the model can't handle, you must read errors and code.

At Sequoia Ascent, Karpathy put it this way: you can hand your thinking to a model, but not your understanding. If you can't explain what a piece of code does, keep it out of apps other people use.

A minimum that makes working with AI much easier:

• the basics of HTML, CSS and JavaScript, to read interface code,
• how the browser talks to a server and where secrets can live,
• Git, to save versions and undo failed changes,
• reading error messages and using the browser's developer tools,
• database and login basics, before building anything with user accounts.

A step-by-step plan for learning these is in how to learn to code, and if you're thinking of working in the industry, in how to become a developer. Good first steps are HTML and CSS basics and JavaScript for beginners.

How to learn vibe coding responsibly

The point isn't to avoid AI but to know more after every project than before it. Simple rules work:

1. Pure vibe coding only when nothing is at stake, as with prototypes and tools for your own use. An app holding other people's data needs a code review.
2. Don't publish code you can't explain. That's Willison's rule in practice: review, test, explain.
3. Git from day one. Small commits are the cheapest insurance against a failed request.
4. AI as a tutor. Ask it to explain errors, give hints instead of finished answers and quiz you on new code.
5. One piece on your own. After each project, rewrite one function without help, for example the days-in-a-row counter, to see what you really understand.
6. A security review and a budget. Before your first users, check keys, data access rules and server-side permissions, and set your tool spending in advance.

On CodeWorlds, the pirate-themed Vibecoding world covers this topic in 14 modules and more than 300 exercises, and its course page estimates 100-150 hours of learning. You build apps with Cursor and Claude Code, from setting up the editor, through clones of well-known services, to testing and deployment. It's a world for advanced learners that assumes React and Next.js, taught in the JavaScript and React and Next.js worlds, plus TypeScript basics from Jurassic Park. Starting from zero? Take the HTML and CSS course first.

For a good start, open Introduction to Cursor, Creating a Next.js project with Cursor and Git and GitHub, then move on to Meet Claude Code, testing with Jest and React Testing Library and deployment to Vercel or Netlify. You can read this world's lessons for free on the site, while its exercises in the app need the premium plan. The free plan covers the HTML and CSS course in the app and gives you 10 fuel units a day, which suits short daily sessions.

FAQ

Who coined the term vibe coding?

Andrej Karpathy, an OpenAI co-founder and former director of AI at Tesla, in a post on X on 2 February 2025. In November 2025, Collins picked vibe coding as its word of the year.

Do you need to know how to code to vibe code?

Not for a simple prototype, and that's the method's biggest advantage. For an app other people use, you need the basics: without them you can't assess security, fix a bug the model can't handle or maintain the project beyond a few weeks.

Which tool should I start with?

With no install, start with Lovable or Bolt. To learn programming along the way, pick an editor with an agent, such as Cursor, where you see every file and change. Turn to Claude Code once you're comfortable with the terminal and Git.

Is an app built with vibe coding secure?

There's no such guarantee. Veracode's tests show that a large share of generated code has known vulnerabilities, and models often skip data access rules and key protection. Before sharing the app, check those areas or ask someone who codes to review it.

How much does vibe coding cost?

You can start for free, since most tools have free plans with a limit. Paid plans run from 10 USD a month for GitHub Copilot to 20-30 USD or EUR for the other tools covered here, plus hosting and services your app uses. Prices change often, so check them with the vendors.

How is vibe coding different from agentic engineering?

Vibe coding means building by description without looking into the code, fine for prototypes and learning. Agentic engineering is Karpathy's term for professional work with AI agents: agents write the code, while a person designs the specification, reviews changes, writes tests and owns the quality.