Journal · A Builder's Guide
Vibe Coding 101
My ultimate guide to building with AI.
June 30, 2026 · Blog · By Ansh Vasani
My ultimate guide to building with AI
Audentes Fortuna Iuvat: fortune favors the bold.
That line has been my motto for a long time, and I think it describes the present moment unusually well. For most of history, turning an idea into working software took years of training, a team, and money. A lot of that cost has now collapsed. The tools to build are inexpensive or free, and they keep getting better. What that means in practice is that the main thing standing between an idea and a working version of it is no longer skill or resources: it's whether you actually sit down and start. In an era like this one, being a little bold, and acting before you feel fully ready, tends to pay off.
This is a guide to what people have started calling vibe coding: building software by describing what you want, in plain language, to an AI that writes, runs, tests, and revises the code for you. I'll walk through it from the very beginning (installing a tool, the basic working loop) and then go into the features that make it genuinely powerful, including ones I use every day. My goal is that someone who has never opened a terminal can follow it, and that someone who already codes can still pick up a few things.
What vibe coding actually is
The term comes from Andrej Karpathy, an OpenAI co-founder and former head of AI at Tesla, who described it in February 2025. His framing was that you "fully give in to the vibes" and "forget that the code even exists": you describe a feature, the model writes it, you run it, and if it's wrong you say so and let it try again. The idea spread quickly enough that Collins named it the 2025 Word of the Year.
It helps to think of this as a spectrum rather than a single thing. At one end is vibe coding in its purest form: you accept what the AI produces, you don't read the code closely, and you judge it by whether it works. That's well suited to prototypes, small personal tools, and learning. At the other end is something closer to ordinary software engineering, where you still review the changes and insist on tests, but the AI does most of the typing. As Simon Willison has pointed out, the two aren't the same, and the dividing line is mostly whether you look at the code.
A reasonable way to start is on the looser end, so you can build momentum and get comfortable shipping things, and then move toward the more careful end as your projects start to matter. This guide covers both.
Step 1: Choose a tool and install it
You only need one AI coding agent to begin. Here are three good options, ordered from easiest to most powerful.
Option A: Claude Desktop (the simplest start, no terminal)
If you've never used a command line, this is the place to begin. The Claude desktop app includes a Code tab that gives you the full Claude Code agent in a regular window, so you don't have to touch a terminal at all.
- Download the app from claude.ai/download (macOS or Windows).
- Sign in. Claude Code requires a Pro or Max plan.
- Open the Code tab, point it at a folder on your computer, and describe what you want to build.
That's enough to get going.
Option B: Claude Code in the terminal
Once you're comfortable, the command-line version gives you more leverage, because it can run commands, edit files across an entire project, and coordinate other agents.
# Native installer (recommended: no Node.js required, updates itself):
# macOS / Linux / WSL:
curl -fsSL https://claude.ai/install.sh | bash
# Windows (PowerShell):
# irm https://claude.ai/install.ps1 | iex
# Or via npm (any OS, requires Node.js 18+):
npm install -g @anthropic-ai/claude-code
# Then, from inside any project folder:
claude
The official documentation is at code.claude.com/docs.
Option C: OpenAI Codex (terminal + desktop app)
Codex is a solid alternative agent from OpenAI. You sign in with your ChatGPT account.
# macOS / Linux:
curl -fsSL https://chatgpt.com/codex/install.sh | sh
# Or:
npm install -g @openai/codex
brew install --cask codex # Homebrew
# Launch:
codex # terminal
codex app # desktop app
The documentation is at developers.openai.com/codex.
I do most of my work in Claude Code, so the examples below use its features and phrasing. The underlying ideas (delegating to other agents, planning before building, verifying results) carry over to any modern coding agent.
Step 2: The basic working loop
Vibe coding is closer to a conversation than to issuing commands. The loop looks like this:
- You describe the outcome you want, in plain language.
- The agent writes the code and runs it.
- You look at the result: the running app, or the test output.
- If something is wrong, you describe what's wrong rather than how to fix it, and let the agent work out the solution.
- You repeat until it's right.
The most common early mistake is over-specifying the implementation: telling the agent which function to call or which loop to write. It's usually more effective to describe the outcome and the constraints instead, for example, "the dashboard should load in under a second, and don't change how authentication works." You're acting more like a director than a typist, and the agent generally does better when you leave it room to choose the approach.
Step 3: The features that make it powerful
This is where vibe coding moves from a novelty to something you can build real features with. These are the capabilities I rely on most.
3.1 Give the agent a memory: CLAUDE.md
If you place a file named CLAUDE.md in the root of your project, the agent reads it at the start of every session. It's a good place to record your stack, your conventions, and anything you never want the agent to do. A short file like this noticeably reduces the amount of correcting you have to do later:
# CLAUDE.md
- Stack: Next.js, Postgres, Tailwind.
- Always work on a branch and open a pull request. Never commit to main.
- Never commit secrets or personal data.
- Run the tests before telling me something works.
3.2 Plan before building
For anything more involved than a small change, it's worth asking the agent to plan first. It will lay out the approach, the files it expects to touch, and the trade-offs, and then wait for your approval before writing anything. Spotting a flawed approach at the planning stage takes a few seconds; spotting it after the code is written can cost an hour.
A prompt I use: "Don't write any code yet. Give me a plan first (the approach, the files you'll touch, and the main risks) and I'll approve it before you start."
3.3 Subagents: delegating focused work
A subagent is a separate agent that your main agent starts to handle one specific job in its own context (reading through the codebase, running a long test suite, looking something up in documentation) and then report back only the conclusion. This keeps your main conversation focused, and it lets several pieces of work happen at the same time.
You trigger it just by asking:
"Use a subagent to search the codebase for every place we call the payments
API. Report back the file list and a one-line summary, not the full code."
"Spin up three subagents in parallel, one for each module (auth, billing,
email), and have each one write tests for its module."
"Send an Explore agent to work out how routing is set up in this repo, then
come back and tell me where a new page should go."
The useful part is that the verbose, token-heavy work (reading forty files, or two thousand lines of test output) stays inside the subagent, and only the answer comes back to you. Your main session stays readable, and you stay oriented.
3.4 Workflows: coordinating several agents at once
A workflow is a script that orchestrates many subagents together. Instead of one agent doing ten things in sequence, you can have ten agents each do one thing in parallel and then combine the results. I've used this to review a codebase across many dimensions at the same time, and to build several features at once by giving each agent a separate set of files so they don't interfere with each other.
A prompt that kicks this off: "Use a workflow to fan out across these eight files in parallel, one agent per file, to look for bugs. Then add a second stage that independently double-checks each finding before reporting it to me."
The relationship between a subagent and a workflow is roughly the relationship between a single skilled worker and a small assembly line you've designed. A workflow is worth reaching for when a task genuinely breaks into independent pieces: a migration, an audit, a multi-part build. It's also worth knowing the cost: a workflow can start many agents and use a lot of compute, so it makes sense when the parallelism actually buys you something, and not for routine single tasks.
3.5 Have the agent ask you questions
One of the more useful habits is to let the agent interview you before it starts, rather than trying to write a perfect prompt yourself:
"Before you start, ask me any clarifying questions; anything ambiguous about
the requirements, the design, or the edge cases."
It usually surfaces two or three decisions you hadn't thought to specify. You answer them quickly, and the result tends to be much closer to what you actually wanted. This has saved me more rework than almost anything else.
3.6 Skills and slash commands: reusing your own processes
A skill is a named bundle of instructions the agent can apply automatically when it's relevant, and a slash command is one you trigger yourself by typing /. If you notice you're explaining the same multi-step process more than once, it's usually worth turning it into a skill so you don't have to explain it again. The commands documentation covers how to set these up.
3.7 Integrations: letting the agent work with real tools
This is the part that surprises people most. Through the Model Context Protocol (MCP), an open standard for connecting AI tools to external applications, the agent isn't limited to producing text. With the right integrations connected, it can:
- Run terminal commands. It can install packages, run your build, query a database, or call an API, and then read the output rather than just suggesting the command to you.
- Drive Chrome to test its own work. With the Claude-in-Chrome extension, the agent can open your app in a real browser, click through a flow, read the console, and fix what broke. I use this to have it build a feature and then check it the way a person would.
- Control the desktop. With computer-use, it can operate native applications, take screenshots, and handle tasks that only exist in a graphical interface.
- Connect to your stack. GitHub, databases, deployment platforms, calendars, and email can each be exposed as tools it can use. This overview of how MCP fits together is a good reference.
Put together, these make a fairly complete loop possible: you describe a feature, the agent writes it, runs the build, opens the browser to test it, notices an error in the console, fixes it, tests again, and opens a pull request, while you watch and steer.
Step 4: Working carefully
Moving fast is only an advantage if you don't undo your own progress. A few practices keep vibe coding from causing problems:
- Use version control from the start. Run
git init, commit often, and work on branches. If the agent takes a wrong turn, you can reset and lose nothing. This is the single most important safety net. - Insist on verification. "It works" on its own isn't worth much. "Run the tests and show me the output" is. Ask the agent to demonstrate that something works rather than assert it.
- Read the changes when they matter. Loose review is fine for a prototype; for anything involving real users, money, or data, read the diff.
- Keep secrets and personal data out of the code. API keys belong in environment variables, never in a file you commit. It's worth stating this explicitly in your
CLAUDE.md. - Keep tasks small. A series of small, verified steps is easier to review and easier to undo than one large change.
Step 5: Build something real, with other people
Tutorials are useful, but you learn the most by building something that other people actually use. Real projects come with real constraints and real feedback, and that's what moves you forward fastest.
This is part of why I chose to build for Pixel Parents. It's a platform I'm working on in collaboration with the Stanford Online High School community, with two goals that reinforce each other. The first is to help people in the community get comfortable with vibe coding and develop genuine AI literacy, not just using these tools, but understanding them well enough to build with them. The second is that the thing we're building is a real product the community uses, rather than a set of exercises. Learning to build and having something worth building turn out to work much better together than apart.
It's also an open-source codebase, which makes it a good place to make a first contribution regardless of whether you're a student, parent, or just curious. If you'd like to contribute, the process maps directly onto everything above:
- Fork the repository on GitHub:
github.com/drodio/pixelparents. - Clone your fork to your computer and open the folder with your agent.
- Find something to improve. A useful starting prompt is: "Read through this codebase and suggest three small, well-scoped improvements that a first-time contributor could realistically ship."
- Make the change on a branch, run the tests, and open a pull request. You can let the agent do most of the work here, and read the diff before you push.
- Submit it. A merged contribution to a project people actually use is a meaningful first step, and the same loop applies to every project after it.
Open source is one of the best places to practice, and it costs nothing to take part. Pick a small issue, point your agent at it, and work through it end to end.
In closing
Periods where the cost of building drops sharply tend to bring in a new group of builders, and we're in one of those periods now. You don't need permission, prestige, or a team to take part: you need a tool, a project, and a willingness to get started before there's any certainty.
That's really what the motto is about. Audentes Fortuna Iuvat: fortune favors the bold. The tools are here; the rest is starting.
Ansh
Resources and sources
- On vibe coding: Wikipedia overview · Simon Willison on the distinction · IBM explainer
- Claude Code: product page · docs · subagents · commands · download the app
- OpenAI Codex: quickstart · CLI · GitHub
- On MCP and integrations: how the pieces fit together · Model Context Protocol
- Pixel Parents on GitHub, contributions welcome.