VibecodingVibecodingBuilding software by describing intent in natural language and steering an AI toward a working result, instead of hand-typing every line. is a workflow where you say what you want in plain language, direct an AI model to write the code, and check, correct, and iterate until it actually does what you intended. The term was popularized in February 2025, when Andrej Karpathy, a founding member of OpenAI and former head of AI at Tesla, described 'fully giving in to the vibes' and forgetting that the code even exists [1]. It spread because it named something a lot of people had quietly started doing: building by conversation.

The reason vibecoding spread is speed. Even an engineer who could write the same code by hand can't do so as fast as a model, so a draft that would have taken an hour arrives in minutes flat. The deeper win comes next, because while the model works, you're free to write the next prompt or steer a second agentAgentAn AI system that can take actions, see what happened, and decide what to do next, rather than only producing text. on another task. Your output is no longer limited by how fast you produce code, but by how fast you can decide what to build and confirm it was built right.

The careless end of that range is what gives vibecoding its reputation, and the difference between the two ends is the difference between a demo and a product. This book is aimed at the product end, which means you stay responsible for the result while the AI produces it quickly, tirelessly, and sometimes wrongly. A demo only has to work once, in front of people rooting for it. A product has to work at 3 a.m. for a stranger who isn't.

You'll sometimes hear 'vibecoder' used as an insult, shorthand for someone who can't really program and just pastes whatever the model says. Reject that framing, because every generation of tooling has drawn this line and then witnessed it move: assembly programmers doubted compilers, and C programmers doubted garbage collection. The question is whether the work holds up and whether the person who shipped it can stand behind it. A vibecoder who specifies clearly and verifies carefully is doing real engineering, which is the standard this book holds you to.

None of this means programming knowledge stops mattering, only that it shows up differently. You still need to recognize what 'correct' looks like and why an off-by-one breaks a loop, because those are the kinds of judgments you'll constantly be making about the model's output. What changes is where your attention goes, moving away from recalling syntax and toward specifying and verifying.

You plan and architect the build, you direct and steer the model as it generates the code, you check that the result holds to your intent, and after that check you draft your next request for code before the cycle repeats.

AI assistance in code editors didn't arrive all at once, and seeing the steps makes today's tools less mysterious, starting with the autocomplete and IntelliSense that shipped in Visual Studio back in 1997. These were rule-based and statistical suggestions scoped to a single identifier or line, driven by the symbols already defined in your project. Useful, but they only ever finished a thought you had already started typing.

The next wave was search, meaning Google and Stack Overflow, where the human still did most of the reasoning manually, while the machine only did retrieval, until the real change came in 2021 with GitHub Copilot. It was the first widely used tool to put a large language modelLarge Language Model (LLM)A neural network trained on vast amounts of text to predict likely continuations, which is what lets it generate code, prose, and explanations. (LLM), a network trained on vast amounts of public code, directly in the editor, suggesting whole multi-line blocks from only a comment or a function name.

From there, chat-based assistants (ChatGPT in late 2022, Claude in early 2023) could hold a conversation about an entire problem, explain their reasoning, and adapt across many turns. Then agentic IDEs (Cursor, Claude Code, Devin Desktop) narrowed the gap further by letting the model read, edit, and run code across many files on its own. Given permission, these tools reach past the editor and onto your machine, which turned 'suggest some text' into 'do the task.'

The pattern is worth naming because it predicts what comes next. Each wave automated more of the how and left the human more of the what and the question of whether the result is right, and vibecodingVibecodingBuilding software by describing intent in natural language and steering an AI toward a working result, instead of hand-typing every line. is the current step in that progression. Specifying and verifying are the skills that every wave so far has left in human hands.

ChatGPT, Claude, and Gemini are general-purpose chat assistants. You should keep in mind that the product is separate from the model within it. For example, ChatGPT is the product, while the LLMLarge Language Model (LLM)A neural network trained on vast amounts of text to predict likely continuations, which is what lets it generate code, prose, and explanations. is only one part of a package that also includes the interface, the saved instructions, and any tools it can access. These assistants answer questions, explain code, brainstorm designs, and write snippets. Most can now run code in a sandbox of their own, and some can reach your files if you connect them. What stays true is that, by default, they work on whatever you paste in, or on what they have produced themselves in that conversation, not on your project on your machine. That boundary is useful because it makes a chat assistant a low-stakes place to think before you commit to anything.

So the best use of a chat assistant is often before you write any code. Pressure-test an approach, compare two code libraries, or ask it to poke holes in your plan. It's a better thinking partner for the what and the why than a code generator for the how, which is what the IDE-level tools do better anyway.

Each of these products is really a family of models at different tiers of capability and cost [3][5][6], from a fast, cheap one for easy requests up to a larger, slower one for hard reasoning. Using the most expensive model to change a button color could waste money, while using the cheapest to design a database schema could waste your afternoon fixing its mistakes.

One limit is worth stating up front. A chat assistant only knows what's in the conversation plus what it learned during training, which stopped at a fixed date. Ask it about a library version released last month, and it will often answer confidently about the version it remembers. Most assistants can now search the web, which helps a great deal with anything recent, though it introduces a failure of its own, because a model can't reliably tell a good source from a bad one and will summarize either with the same confidence. This is a first taste of the hallucination problem that Chapter 9 makes central, and of the context questions that Section 2.3 takes up.

Cursor, Claude Code, Devin Desktop, Codex, and Antigravity all put the model inside your project instead of in a separate browser tab. The names change constantly and come from competing companies, but what these tools do has settled into a recognizable shape. They read the files in your project and edit across several of them at once, and depending on the permissions you set, those edits either arrive as diffs you review first or are simply applied. Most importantly, they can run commands: start a dev server, install a package, run the test suite (often one they wrote themselves), and read the error they just caused. Many can now also drive several agents in parallel on separate tasks, and Chapter 3 covers when that's worth doing and when it costs you more than it buys. Because agentic IDEs now both suggest the code and show you whether it works, they're the most powerful vibecodingVibecodingBuilding software by describing intent in natural language and steering an AI toward a working result, instead of hand-typing every line. tool you can pick up, which is why most of this book is about them.

The genuinely new thing is agency, meaning the tool takes actions in your environment, watches what happens, and decides what to do next based on what it just found out. That feedback loop lets it chase down problems on its own, and it's exactly why your verification role gets bigger: a chat assistant that's wrong costs you a bad copy-paste, but an agentic IDE that's wrong can edit ten files and run a destructive command before you've finished reading its original plan.

These tools also give you control over what the model is allowed to see and do, through two separate mechanisms that are easy to confuse. Standing cross-session instructions (Claude Code's memory, Cursor's project rules, Copilot's custom instructions, all one idea under several vendor names) shape what the model tries to do, and ignore rules, the .gitignore-style kind, keep junk out of what it reads. Permissions govern what it is actually allowed to do, which is why most tools let you decide what runs automatically and what needs your approval. A rules file offers guidance where permissions offer a guardrail, and setting both deliberately is the difference between a helpful collaborator and one that confidently and consistently goes off the rails, which is the subject of Chapter 3.

One practical note is that the same model can feel dramatically more or less capable depending on the tool wrapped around it, because the tool decides what the model gets to see, so a disappointing result can be the tool failing to show it the right files rather than the model being incapable of the task.

Lovable, Bolt, Replit, and v0 sit a layer above the IDE. You describe an app, and they scaffold and often deploy a working version directly, frequently skipping the 'open a code editor' step entirely. v0 specializes in generating polished UI, Lovable and Bolt aim at whole apps, and Replit pairs an agentAgentAn AI system that can take actions, see what happened, and decide what to do next, rather than only producing text. with instant hosting. What they all share is the deliverable: a working app live at a URL.

The speed is the point, since an idea on Monday can be something someone clicks on Tuesday. This is prototyping, and Chapter 12 argues that getting a rough product in front of users early is what actually teaches you whether you're building the right thing, so for validating a concept over a weekend, an app builderApp builderA tool that scaffolds and deploys a working app straight from a description, above the level of a code editor. Optional Chapter M names current examples. beats opening an empty IDE.

The drawback is less control over your code, because the builder makes a thousand small decisions for you, and you inherit a codebase you didn't design and may not fully understand, which can be painful once an app succeeds and has to be maintained. The common claim that builder output is simply unmaintainable overstates it, since one prompt produces a demo, while many careful prompts with real testing produce something more polished. Optional Chapter E, 'Vibe Debugging,' exists precisely because inheriting a builder-generated codebase is now a common real-world starting point.

The three kinds of tools sit on a spectrum. Chat assistants give you words about code, AI-native IDEs give you code in your repo, and app builders give you a deployed product, each step sacrificing control for speed. The right tool depends on the task, so you could use both an IDE and a builder at least once and feel the trade-off yourself instead of taking our word for it.

You'll hear people call certain AI products 'ChatGPT wrappers,' and the phrase is blunt on purpose. It means the product is mostly the underlying chat model with a thin layer on top, such as a custom system prompt, a nicer interface, or one workflow button, while the hard work of reasoning and generation still happens inside someone else's API. The label is usually meant as a criticism, and often deserved, though a genuinely well-designed wrapper can still solve a narrow job faster than opening ChatGPT yourself. It's a useful label when you're deciding whether something adds real value or just repackages something that already exists for a monthly fee.

The pattern shows up everywhere in the current tool boom. An 'AI calorie estimator,' a 'resume rewriter,' or a 'study buddy for organic chemistry' is frequently one preset prompt and a form field in front of a general-purpose model, so from the outside it looks like a dedicated product while under the hood it's a single API call with branding. Recognizing ChatGPT wrappers helps you evaluate tools critically before you pay for one.

A wrapper gives you an answer in a chat-shaped box, while a builder gives you something you can deploy, and either can be the right call. They fail differently, since a wrapper fails when the model is wrong or your question was vague, and a builder fails when you inherit scaffolding you can't maintain.

Chapter 12 returns to the business side, where a larger product can swallow a thin wrapper overnight, but for this chapter, the takeaway is simply to know whether you're paying for a model or for someone's packaging of one. If the product is a wrapper, you're paying for convenience and for the fact that someone chose the prompt, designed the interface, and picked the defaults for you. The underlying model is the same one you could use directly, so use a wrapper when the packaging saves you real time, and if you're the one building, ask whether your product is more than packaging before you charge for it.

Tools change weekly, and models change monthly, so any list of 'the best models' can only be a snapshot rather than a ranking that holds. The table below is dated and describes which models were in common use in AI-native IDEs and app builders when this was written. Before you rely on it, open your tool's model picker and check what the company that makes the model currently publishes [3][5][6], because a newer release, a price cut, or a lack of availability may have changed the answer since this was written. Staying informed is part of the work, and this applies to the whole book: AI moves fast enough that anything specific here may already have been overtaken by the time you read it. You may well be reading this a year or more later, in which case, treat the names as history and the reasoning as current.

For vibecodingVibecodingBuilding software by describing intent in natural language and steering an AI toward a working result, instead of hand-typing every line. specifically, what matters is which model matches the job in front of you inside the tool you're using, which is not always the one that scores highest on benchmarks. Multi-file agentAgentAn AI system that can take actions, see what happened, and decide what to do next, rather than only producing text. work rewards the strongest reasoning model you can afford and actually access, while quick UI polish and copy tweaks might run fine on mid-tier models. Work you can check at a glance and repeat often belongs on the fast, cheap tiers. Optional Chapter M covers install commands, token prices, and effort settings in detail.

Model names in this book are deliberately kept to this section, the tables, and the slides, so that the rest of the text stays useful no matter how far ahead of us you're reading. Everywhere else, the book talks about fast, mid, and frontier tiers, because those categories have been stable for years while the names inside them turn over every few months. Once you understand how the choice works, you can apply it to whatever your tool offers you today.

Start one tier below what you think you need, and move up when the output stops making progress: a wrong architecture, a plan it can't finish, code that doesn't run, instructions it quietly drops, or the moment you realize your prompt left out something it needed. When a task is high-stakes or subtle, running it past another model from a different company is cheap insurance. That catches more than errors, since two models from different labs are less likely to share the same blind spot, which is the move Chapter 2 recommends for hard questions.

The biggest model isn't automatically the right one, since the choice trades reasoning depth against speed, cost, and what you can actually select today. Settings matter too, and most tools now expose several levels of reasoning effort that can change results as much as switching models does.

Frontier models earn their price when the task needs multi-step reasoning, such as tracing a bug across files or holding a long agentAgentAn AI system that can take actions, see what happened, and decide what to do next, rather than only producing text. plan together without losing the thread. They hallucinate less on subtle logic and hold far more information in view at once, which matters in a long session with a lot of history behind it. They are also better at the thinking that surrounds the code: structuring a messy brief, organizing your ideas, and probing for the gaps and contradictions you left in it. The costs are real, since they take longer, the token bills are higher, and sometimes the depth is simply unnecessary. Newer releases can also arrive with availability restrictions or policy limits [4], so the best model on a leaderboard isn't always one you can select.

Fast and mid-tier models make the opposite trade and struggle when the task needs judgment, so they can pick a plausible library that's wrong for your case, miss a security edge case, or stop remembering what matters once a run gets long. The cost of always reaching for the cheapest model is the time you then spend repairing an architecture that a stronger one would have gotten right.

A useful rule is to match the model to how much can break if the change is wrong. Small, self-contained changes that you can check in a minute belong on the fast tier, while work that touches many files, or where the spec is still vague, or where a mistake would be expensive to unwind, is worth the frontier tier when possible. When in doubt, the mid-tier can be a reasonable place to start.