Guides · Sep 24, 2026
The vibe coding playbook for beginners
A beginner's playbook for building software with AI, from the first idea to an app people can use.
Built by Simon + Claude
Claude · Code · team-okr
Build an internal tool where my team tracks its OKRs. One HTML file.
I made okr.html with the objective, the key results and who owns each one. It is open in the preview.
Show which key results are behind
Added a line under the list with the key result that is behind.
Put a counter at the top so I can see it at a glance
Added a counter at the top that says 2 of 3 on track. It updates when someone changes the progress.
Editing okr.html…
2 of 3 on track
More customers in the Nordics
Q4 · Sales team
- 20 new client meetingsAnna · 70%
- 5 new dealsJonas · 40%
- Quotes out in under 2 daysMira · Done
Behind · 5 new deals, Jonas
TL;DR
- Vibe coding means you describe what you want in plain language, and an AI agent writes, runs and fixes the code while you steer.
- Think the idea through with the AI before you build, give it the context it cannot guess, and build in small rounds.
- Start with one HTML file, save every version that works, and let a developer look at the app before it goes public.
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.
Along the way we build an internal tool where a team tracks its OKRs, objectives and key results, a goal and the few numbers that show you are getting there.
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 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.
In the chat. This is the fastest way to test an idea, with nothing to install.
- Claude builds small apps right in the conversation as artifacts, and you can share them by link. An artifact can also fetch live data through connectors each time it is opened, for example from a spreadsheet in SharePoint or a page in Notion. It uses the connectors of whoever opens it, not yours.
- ChatGPT has Sites, which builds and publishes small websites and apps.
- Gemini has Canvas, where you can build and preview small apps in the chat.
Inside Microsoft 365 and Google Workspace. Copilot and Gemini can now build apps connected to the data you already have, and a SharePoint list or a spreadsheet in Google Drive can work as a simple database. At work this is often the easiest way in, because your data and the company login are already there.
- Microsoft. In September Copilot Cowork got an /app skill that builds working apps from a description, connected to your data in Microsoft 365, such as SharePoint, and to other systems through connectors. It is still in preview through the Frontier programme, and the same app building is rolling out in Copilot Studio as a public preview.
- Google. In Google AI Studio you can build apps on Sheets and Drive, and Opal makes small AI apps inside Gemini, for now only with a personal Google account.
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.
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.
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.
These are the tools we see most often, and there are many more.
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.
YouI 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.
YouI 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.
- Owners update the numbers
- Version one shows progress
- Reminders come later
Then it builds version one
From there the method runs in five steps, and you go round them many times.
- Start with the problem you are trying to solve. Say who has the problem and the one thing the app has to do.
- Explore solutions. Ask the agent for a few ways to solve it and pick
one. Claude Code's
plan mode and
Codex's
/planpropose a short plan without editing anything. Correct what is wrong, then let it build. - Let it take the first shot.
- Try it and say what is off. Click around in the preview, and ask about what you do not understand.
- 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.
The update button is broken.
When I change 2 to 3 and click Update,What you didnothing happens.What happenedI expected 3 of 5 and 60%.What you expected
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 OKR tool 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.
YouBuild 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.
The agreed way two programs talk to each other.
Settings that never sit in the code, such as API keys, often in a file called .env.
Hosting serves your app on the web, and to deploy is to put a new version there.
An HTML file or a simple site
Web apps with React and Next.js
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.
- Never let the .env file be pushed to GitHub.
- Never put a secret key in the frontend, where every visitor can read it.
- If a key leaks, delete it at the service and create a new one.
- Set a spending limit on pay-per-use services, in case of a leak or a runaway loop.
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.
In the OKR tool, adding a key result is create, the overview is read, changing the progress from 2 to 3 is update and removing an old key result 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.
YouBuild 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 free Apple account runs an iPhone app on your own phone for seven days at a time. To share it or put it in the App Store you need a paid Apple Developer Program membership, and so does a Mac app shared outside the App Store. 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.
- Check who gets the link. Anyone you share an app from Copilot Cowork with can open it and use all its data. Share with the people who need it, not the whole company.
- Know where to stop. Logins, other people's personal data, payments or anything regulated need a developer's review.
The playbook on one page
- 01Think it through with the AI firstAsk for three ways to solve it, and let it push back on what is unclear.
- 02Give it the context it cannot guessTell it who the app is for, what exists today and what good looks like.
- 03Ask for one HTML file firstIn a few minutes you have something to click, with nothing to install.
- 04Build in small roundsOne screen, one feature or one fix, then look at the result.
- 05Say what you did, what happened and what you expectedThe last part tells the agent what the page should do.
- 06Save every version that worksAsk the agent for a checkpoint in Git, so you can go back when a change breaks something.
Just start
Eric Ries described the loop in The Lean Startup in 2011. You build something, measure how people use it, learn from it and build again.
For years building was the slow part, and a round could take weeks. With AI a first version takes an afternoon, so the loop now runs as fast as you can put the app in front of people and listen.
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.