The vibe coding playbook for beginners

In An agent in a folder we gave the AI a bounded workspace. Vibe coding points the same idea at software. This playbook is for people who do not write code but want to start exploring building software with AI. We explain what vibe coding is, the building blocks of a real app, the mindset that works and how to get started, and along the way we build a small app where a team orders lunch.

What is vibe coding?

Andrej Karpathy gave it the name in a post in early 2025, a way of building where you "forget that the code even exists". You say what you want, the AI writes the code, and you shape the result through quick rounds of feedback. You do not need to know how to write code, but you do need to know what you want.

"I haven't written a line of code by hand in, I think, eight months now."

Boris Cherny, head of Claude Code at Anthropic, to Fortune, June 2026

Since 2025 the AI agent has learned to read your files, run the app, look at the result and try again. In a JetBrains survey of more than 15,000 developers in 2026, 90 per cent used AI coding agents at work every week. Lovable says four in five of the people building on it describe their role as non-technical. In Anthropic's study of Claude Code sessions, people in the ten largest occupations came within seven percentage points of software engineers in how often their sessions succeeded.

Which tools can you use?

There are four ways in, from easy to more advanced.

These are the tools we see most often, and there are many more.

In the chat. Claude builds small apps right in the conversation as artifacts, with nothing to install, and you can share them by link. An artifact can also fetch live data through your connectors each time it is opened, for example from a spreadsheet in SharePoint or a page in Notion. ChatGPT has Sites, which builds and publishes small websites and apps, and Gemini has Canvas. It is the fastest way to test an idea.

App builders in the browser. Lovable, Bolt, Replit and Google AI Studio build a full web app from a description, with hosting and a database handled for you, and all have a free plan. Designers can start from their own designs in Figma Make. You get there faster, but you have less say over how the app is built.

In the IDE. Developers get the same help inside VS Code, Cursor or JetBrains, through Claude Code, GitHub Copilot or Cursor's own agent.

Coding agents. This is what we use at GritAI, and the path this playbook follows. The AI agent works in a folder on your own machine, where it can read your files, run the app and test it while it builds.

• Claude Code runs under the Code tab in the Claude desktop app and shows your running app in the Browser pane while it works. It needs a paid Claude plan.
• Codex, from OpenAI, runs in the ChatGPT desktop app with a live preview, and is included in every ChatGPT plan.

Cursor and Google's Antigravity are editors built around the same kind of agent, so they belong here too. The tips and advice in this playbook fit all of them.

You choose the building blocks yourself. With a coding agent you decide the framework, the database and where the app runs, with the agent's help. App builders like Lovable, Riff and Base44 make most of those choices for you.

Our recommendation. If you get hooked on building with AI and want more freedom, move to a coding agent such as Claude Code or Codex. For heavy use, Claude Max or ChatGPT Pro has given us the best value.

Building mindset

Writing the code is no longer the hard part. The hard part is imagining what to build, and you do not have to do that alone. Talk the idea through with the AI as you would with a sparring partner, ask for other ways to solve it and let it push back.

The best people with AI are often the ones who have good conversations, give the right context and work well with the AI while they build. Tell it who the app is for, what they do today and what good looks like, and show it a screenshot when you have one.

YouCopy

I have an idea for [the idea in one sentence]. Before we build anything, help me think it through. Suggest three different ways to solve it, and point out what is still unclear.

Build in small steps, one screen, feature or fix at a time, and look at the result in between. Expect the first version to be rough. You decide what gets built and whether it works, and the agent does the typing.

How do you vibe code?

In 2025 the advice was to write a detailed plan first. In 2026 you can start with less, because the agents ask when something is unclear.

Building with AI in 2026 is more about having a conversation than writing the perfect prompt.

Let the agent interview you. Both Claude Code's best practices and OpenAI's Codex guide suggest it.

YouCopy

I work as a [your role] in [your team]. I have an idea for something I want to build, [the idea in one sentence]. Interview me about who it is for and what the first version must do, one question at a time. When we agree, suggest the smallest first version and start building it.

From there the method runs in five steps, and you go round them many times.

1. Start with the problem you are trying to solve. Say who has the problem and the one thing the app has to do.
2. Explore solutions. Ask the agent for a few ways to solve it and pick one. Claude Code's plan mode and Codex's /plan propose a short plan without editing anything. Correct what is wrong, then let it build.
3. Let it take the first shot.
4. Try it and say what is off. Click around in the preview, and ask about what you do not understand.
5. Save, share and get feedback. Ask the agent to save a working version in Git, then show it to the people it is for.

Most of the time goes into step four. Say what you did, what happened and what you expected. The last part is the one people leave out.

A short file in the project saying what the app is and how you like to work saves explaining it again. Claude Code reads CLAUDE.md at the start of every session, and Codex reads AGENTS.md.

Why a single HTML file?

Start with a single HTML file. It opens in any browser, with no build step, no account and nothing to install, and the agent can write all of it in one go. The lunch page at the top of this guide is one.

A single HTML file is the shortest path from an idea to something you can click. You send the file, the other person opens it, and there is nothing to deploy. At the build day at Mesh in September 2026 people had a running program within the first ten minutes this way.

YouCopy

Build this as a single HTML file with no external libraries, so it opens in any browser and works the first time.

The magic powers of HTML has more on what one page can do.

The building blocks worth learning

You do not need to understand everything under the hood, but knowing the building blocks helps you steer. Most apps have a frontend and a backend that talk through an API.

Be careful with environment variables. An API key works like a password, and anyone who has it can use the service in your name and on your bill. Never paste a key into the chat, and never let the .env file be pushed to GitHub. Never put a secret key in the frontend either, because anyone who opens the app can read it. If a key leaks, delete it at the service and create a new one. Also set a spending limit at services that charge per use, so a leaked key or a runaway loop does not leave you with a large bill.

When the agent uses a word you do not know, ask it to explain with your own app as the example.

What makes it a real app?

What turns a page into an app is that it keeps data people can add, look at, change and remove. Every app you use does this, from your calendar to your bank, and developers shorten it to CRUD, for create, read, update and delete. On the lunch page, placing an order is create, the list of today's orders is read, swapping soup for a wrap is update and cancelling is delete.

A simple HTML app has limits here. It can remember things in the browser on one machine, but for several people to add and see the same data, the app needs a connection to a database it can store the data in.

If you build your own to-do app for your Mac, a local database on your machine handles CRUD fine. An app hosted in the cloud adds another layer of complexity, because the data then has to be stored in a database in the cloud.

Web, desktop or mobile?

When you build with AI, you can build almost anything, but we recommend starting with something simple.

• HTML apps are a single file that opens in the browser, with nothing to install or publish. This is where we recommend you start.
• Web apps open with a link on any device. Many are built with React, often with Next.js, and styled with Tailwind CSS. Lovable and Bolt use React and Tailwind CSS by default.
• Desktop apps sit in the Dock or the Start menu. Mac apps are usually SwiftUI, and apps for both Mac and Windows use Electron or Tauri.
• Mobile apps on iPhone are SwiftUI too, and React Native with Expo makes one app for iPhone and Android.

For data, Supabase and Firebase give you a database and logins without running a server. An app only you use can keep its data in SQLite, a single file on your machine.

Start locally. An app that only runs on your own machine is much safer than one hosted online, and there is nothing to deploy. Most people will be surprised by how fast you can build a Mac app with Claude Code or Codex using the latest models. You need Xcode, which is free, and the agent does the rest.

YouCopy

Build me a small Mac app in SwiftUI that [what it does]. Keep all the data locally on this machine, with no login and no network access.

A real iPhone app takes a few more steps. A free Apple account lets you run it on your own phone for seven days at a time. To share it or put it in the App Store you need a paid membership in the Apple Developer Program, and Apple reviews the app. The same membership is needed to share a Mac app outside the App Store, because Apple has to scan it first. Otherwise the Mac stops the app when other people try to open it. Ask the agent to walk you through each step.

What is GitHub?

If you get hooked on vibe coding, it is worth knowing GitHub.

Git keeps the history of a project. Each saved version, a commit, stores what changed and why, and you can go back to any of them. GitHub keeps a copy of that history on the web, in a repository. Think of it as OneDrive or Google Drive for code.

• It is your backup. If your laptop dies, every version is still there.
• It is how you share the code with a developer you invite.
• It is how the app gets online. Hosting services such as Vercel publish a new version each time you push.

An account is free, and a repository can be private. You do not have to learn the commands. Ask the agent to create a private repository and push after each version that works, and to add .env to .gitignore first, so your keys are never pushed.

Be careful with what you share on GitHub. A public repository can be read by anyone on the web, with its whole history. If the project holds files or information you do not want to share, such as customer data, internal documents or keys, keep the repository private. If you make it public later, every earlier version becomes visible too.

What do you check before you publish?

Understand what you publish. We do not recommend putting something you have built into production, or making it public, if you do not understand how it works. Have a developer or another expert look at what you have made before real users get in.

Do your best to understand what the app does, especially if you plan to bring it online. Know what data it touches and who can reach it.

• Lock the .env file with a deny rule such as Read(./.env), so Claude Code blocks its own tools from reading your keys. A script the agent runs can still open the file.
• Review before you approve. Switch to Manual mode when the agent touches something live, and let it work in its own project folder, not your whole home folder, since it can change and delete files.
• Keep the agent away from real data. If it needs access, give it read-only access.
• Know where to stop. Logins, other people's personal data, payments or anything regulated need a developer's review.

The playbook on one page

Where do you start?

Build something small that you will use yourself, such as a tool that tidies a weekly report or a page for an event. Our community meets at Mesh in Oslo, and the Claude Code Bootcamp for everyone is a full day where you build your own project.

Check what you are allowed to use. If you build something for work, find out which AI tools your employer has approved before you put in customer data, figures or internal documents. Use sample data until you know.