Vibe Coding & AI Coding Tools
You describe what you want. The AI writes the code. That is the whole idea — and it works far better than it has any right to, right up until the moment it quietly doesn't. This is what these tools are, how to drive them, and what you still need to know yourself.
What is vibe coding?
Vibe coding is building software by describing it in ordinary language and letting an AI model write the actual code — then steering the result by describing what to change, rather than editing it line by line.
The phrase comes from AI researcher Andrej Karpathy, who described the workflow in February 2025 as "fully giving in to the vibes" and forgetting the code even exists. It caught on fast: Collins Dictionary made "vibe coding" its word of the year in 2025.
What it looks like
"Make me a page that tracks my water intake." Read the result, run it, then: "The reset button should ask me to confirm first." Repeat until it does what you meant.
What it isn't
It isn't a way to skip understanding code. Someone still has to notice when the tool is confidently wrong — and on your project, that someone is you.
The four kinds of AI coding tool
The names change every few months; the four shapes have been stable. Work out which shape you need before you pick a product.
1. Chat assistants
Claude · ChatGPT · Gemini
A text box in your browser. You paste code in and ask about it, or describe something and get code back. Nothing to install, and by far the best place to start: you can ask "what does this line do?" as many times as you like without anyone watching.
2. In-editor assistants
GitHub Copilot · Cursor · Windsurf
These live inside your code editor. They finish the line you are typing, rewrite a selected block on request, and answer questions about the file you are looking at. The autocomplete is the part people underestimate — it is fast, constant, and easy to accept without reading.
3. Coding agents
Claude Code · Codex CLI · Gemini CLI · agent modes
An agent does not just answer — it acts. It reads your files, edits several at once, runs the tests, sees the error, and tries again. You give it a goal and review the diff. This is where vibe coding gets genuinely powerful and genuinely risky at the same time.
4. Prompt-to-app builders
v0 · Lovable · Bolt · Replit Agent
Describe an app, get a working app with a URL. No editor, no setup. Spectacular for a first version or a demo you need this afternoon — the honest catch is that the twentieth change is much harder than the first, because you are still steering from the outside.
Most of these have a free tier and a paid one, and the details change constantly — check the product's own site rather than trusting any list, including this one.
How a vibe coding session actually goes
It is a loop, not a single request. People who get good results are not writing better first prompts — they are going round this loop faster and stopping earlier when it goes wrong.
- 1
Describe one thing
Not the whole app. One feature, one page, one function. Small requests fail in ways you can actually see.
- 2
Run it before you read it
Thirty seconds of running tells you more than five minutes of squinting. Try our code playground if you have nowhere else to put it.
- 3
Read it and ask about the parts you don't recognise
"What does line 12 do?" is a free question, and the answer is the actual learning. Skipping this step is how you end up with an app you cannot change.
- 4
Describe the difference, not the fix
"The total is wrong when the list is empty" beats "add an if statement". You describe the symptom; the tool is good at the cause.
- 5
Save the version that works
Commit it, or at minimum copy it somewhere. The next prompt can undo something that was already right, and without a saved copy you cannot get it back.
- 6
Start fresh when it goes in circles
Three failed attempts at the same bug means the conversation is now part of the problem. New chat, restate the goal, paste only the code that matters.
How to ask for what you want
A model cannot read your mind, and it will never say "that request was too vague" — it will just guess. Every detail you leave out is a decision you have handed over.
Vague in, generic out
make me a website You will get a website. Almost certainly not yours.
Specific in, useful out
Build a single HTML page that shows a to-do list.
- Add a task with a text input and an "Add" button
- Click a task to mark it done (strikethrough)
- An X button next to each task deletes it
- Save the list in localStorage so it survives a refresh
- Plain HTML, CSS and JavaScript in one file, no frameworks
Explain the localStorage part in comments — I am learning. Four things made the difference: what it does, how it behaves, what to build it with, and who it is for.
Ask it to teach, not just to fix
This function returns NaN when I pass it [2, 4, 6].
function average(numbers) {
let total = 0;
for (let i = 0; i <= numbers.length; i++) {
total = total + numbers[i];
}
return total / numbers.length;
}
Do not rewrite it. Tell me which line is wrong and why,
so I understand the mistake. "Do not rewrite it — explain it" is the single most useful instruction when you are learning. A silently corrected file teaches you nothing.
Use it as a reviewer
Read this file and tell me:
1. Anything that will break if the input is empty or missing
2. Anything a beginner would find hard to change later
3. Anything unsafe to put on a public website
Do not change the code yet — just list what you find. AI tools are often better critics than authors — and asking for a list first stops it from "fixing" things you never wanted changed.
Include
- • What it should do, step by step
- • The language or tools to use
- • Example input and the output you expect
- • The exact error message, all of it
- • Your level — "I am a beginner, explain as you go"
Avoid
- • "Make it better" — better how?
- • Five unrelated requests in one message
- • "It doesn't work" with no error and no code
- • Real passwords, keys or customer data
- • Accepting the answer without running it
Confidently wrong: a worked example
Here is a real class of mistake these tools make. Nothing about it looks uncertain — no warning, no hedge, no "you may want to check this". It is simply wrong.
// Asked: "write a function that returns the average of a list of numbers"
function average(numbers) {
let total = 0;
for (let i = 0; i <= numbers.length; i++) {
total = total + numbers[i];
}
return total / numbers.length;
}
console.log(average([2, 4, 6])); // NaN — not 4
The loop runs one step too far. On the last pass, numbers[3]
does not exist, so the total becomes NaN
— "not a number" — and stays that way. One character causes it:
function average(numbers) {
let total = 0;
for (let i = 0; i < numbers.length; i++) { // < not <=
total = total + numbers[i];
}
return total / numbers.length;
}
console.log(average([2, 4, 6])); // 4 This is the whole argument for learning the basics.
Spotting that bug takes about four seconds if you know how a for loop counts and how array indexes work. Without that, you are stuck pasting "it says NaN" back into the chat and hoping. The tool wrote the code — you are the one who has to know whether it is right.
What these tools are good and bad at
✅ Genuinely good at
- Explaining code — paste anything and ask what it does, line by line.
- Boring, well-defined work — forms, formatting, converting data from one shape to another.
- First drafts — a rough version in seconds that you then shape.
- Error messages — turning a wall of red text into a plain sentence.
- Syntax you half-remember — the thing you would otherwise search for.
- Reviewing your own work — "what breaks here?" before anyone else asks.
⚠️ Unreliable at
- Being right about things it invented — functions and options that do not exist, described perfectly.
- Knowing your context — your users, your data, the decision made six months ago.
- Very recent releases — training data has a cut-off; the newest library version may be news to it.
- Security judgement — it will happily write code that leaks a key unless you say not to.
- Saying "I don't know" — the failure looks exactly like the success.
- Holding a big system in mind — the context window has an edge, and past it, things get forgotten.
Four ways vibe coding bites people
None of these are reasons to avoid the tools. They are the things to check before anything you built this way meets a real user.
1. Secrets in code the browser can read
Ask for "an app that calls this API" and you may well get your key sitting in a file every visitor downloads. Anything in front-end code is public — view-source public.
// 🚫 Never ship this: everything in front-end code is public
const apiKey = "sk-live-9f2a3b7c8d";
fetch("https://api.example.com/data?key=" + apiKey); 2. Nothing checks the input
Generated code assumes the happy path: the list has items, the field was filled in, the number really is a number. Empty and unexpected input is where it falls over, and that is exactly what real users provide.
3. It works, and you cannot change it
The most common bad ending. Four hundred lines that do the right thing, written by something that has now forgotten why. If you could not explain a file to someone else, you do not yet own it — ask for a walkthrough before you move on.
4. Agents doing more than you asked
A tool that can edit files and run commands can also delete the wrong thing or rewrite a file you were happy with. Work in version control, review the diff, and never point an agent at something you have no copy of.
"But could I just build that myself?"
Sooner or later every vibe coder looks at an app they pay for and wonders whether an AI tool could reproduce it in a weekend. Sometimes yes. Often the interface is the easy part and everything underneath it — the data, the integrations, the trust, the people keeping it running — is not.
Can It Be Vibe Coded? works through that question product by product, scoring each one across five layers — interface, core workflow, data, operations, and trust and safety — and landing on a verdict: build it, scope it down, or keep paying. Its summary of the whole problem is a good thing to have in your head before you start: code is cloneable; networks, licensed data, trust and operations usually are not.
Visit canitbevibecoded.comAI engineering vocabulary
The words that come up constantly once you start using these tools seriously. None of them are as complicated as they sound.
Prompt
What you type to the model — the instructions, question or code you hand it. Better prompts get better code, which is why prompting is a skill rather than a magic word.
Model
The AI system itself (Claude, GPT, Gemini and so on). Products like Cursor or Copilot are wrappers that feed your files and questions to a model and show you the answer.
Token
The unit models read and write in — roughly a short word or chunk of a word. Usage limits and API pricing are counted in tokens, not characters or lines.
Context window
How much text a model can hold in view at once, measured in tokens. Everything competes for it: your files, the conversation, the tool output. When a session outgrows it, the earliest parts stop influencing the answer.
System prompt
Standing instructions that sit above the conversation and shape every reply — the tool’s own rules, plus any project rules you add in a file like CLAUDE.md or .cursorrules.
Hallucination
When a model states something false with complete confidence — an invented function, a library that does not exist, a flag that was never in the docs. The most important failure mode to watch for, because nothing in the output looks different when it happens.
Agent
An AI tool that does not just answer but acts in a loop: reads files, runs commands, checks the result, tries again. Claude Code, Codex CLI and Cursor’s agent mode work this way.
MCP (Model Context Protocol)
An open standard for connecting AI tools to outside systems — a database, a design file, an issue tracker — so the model can look things up instead of guessing.
RAG (retrieval-augmented generation)
Fetching relevant documents first and putting them in the prompt, so the answer is grounded in real sources rather than in whatever the model remembers.
Temperature
A setting that controls how varied the output is. Low values give predictable, repetitive answers; high values give creative, less reliable ones. Code generation usually wants the low end.
Fine-tuning
Further training a model on your own examples so it adopts a particular style or task. Rare for everyday coding — a good prompt and the right context almost always get there first.
Prompt injection
An attack where instructions hidden in content the model reads — a web page, an issue comment, a file — hijack what it does next. It matters as soon as your AI tool can read untrusted input or run commands.
The basics you still need
Not all of programming — just enough to read what you are given and describe what is wrong with it. These six lessons carry most of that weight.
Variables
So you can follow what the generated code is storing and where a value came from.
Functions
Almost everything an AI writes arrives as functions. Knowing inputs and return values is how you check them.
Loops
Off-by-one errors are the classic AI-generated bug, and they live in loops.
Conditionals
The missing empty-input check is nearly always a missing if statement.
Arrays
Lists of data are where generated code most often reads past the end.
Debugging
The single most valuable skill when the code you are handed does not work.
Quick Quiz
Vibe Coding Quiz
Five questions on AI coding tools and how to use them without getting burned.
What does "vibe coding" actually describe?
Key takeaways
- 1. Vibe coding means describing what you want and letting the model write it — you steer, it types.
- 2. Small requests, run the result, read it, save what works.
- 3. A wrong answer looks exactly like a right one, so you have to check.
- 4. Never put keys, passwords or customer data in code the browser downloads.
- 5. "Explain this, don't rewrite it" is how the tool makes you better instead of dependent.
- 6. The fundamentals are not obsolete — they are the thing that lets you judge the output.