Vibecoding 101: the complete guide for beginners in 2026

The guide's route on one map: goal, IT map, tech stack, first project, deploy and iteration

Short answer: vibecoding in 2026 is no longer a toy for programmers and not a magic "build me a website" button. It is a new basic computer skill. Roughly like Excel used to be: not everyone needs to master pivot tables, but almost everyone benefits from knowing how to put together a simple sheet, a formula and a report.

The same thing is happening to programming. If you work at a computer, you already have tasks that can be automated: an internal tool, a personal script, a landing page, a simple CRM, a request form, a dashboard, a site for a client, a mini-app for your own business.

But there is a trap. If you walk into vibecoding the way you walk into a website builder, where "you fiddle with something and a site appears", the problems start fast. AI can write code, but if you do not understand at all what a client, a server, frontend, backend, a database, an API, deploy and GitHub are, you will not be able to set the task properly, check the result and take the project to production.

This article is the long text version of the two-hour video "Programming is the new Excel". You can watch the video on YouTube, and below I have laid the material out as a standalone guide for a beginner: from the IT map to the first project, GitHub and Vercel.

The video was recorded in June 2026, the text was checked on Sep 26.

This is not a summary "about programming in general". It is a route into vibecoding: first the big picture of IT, then a concrete stack, then a first project you can take all the way to a public link.

In the video the whole path is laid out as one big map: goal, IT map, stack, coding, testing, deploy and iteration

How this guide is organized

1. Part 1. The IT landscape and the IT map - we work out where the client, the server, the network, frontend, backend, databases, APIs and deploy sit in development.
2. Part 2. Building the tech stack - we pick the model, the tools, the codebase and the minimum setup for a first project.
3. Part 3. Your first vibecoding project - we take a real case, give the agent a task, check it, deploy and iterate.

Inside the tech stack we keep three layers

• Model - which LLM thinks, writes the code and fixes the errors.
• Code - where the project lives, what framework it is built in, how the agent works with files.
• Skill - what you have to be able to do: set the task, read the result, check it, give feedback and take it to production.

Internal links along the way

• AI agent rankings — when you need to pick an agent and a model or to see who is strong at code right now.
• My AI stack in 2026 — the set of tools I use myself.
• Step-by-step setup of a first tech stack — a separate version of the setup guide, with the key steps duplicated below in this article.
• Tool catalog — cards for agents and services with pricing.

Key takeaways

If you are a complete beginner, you do not have to spend a year learning JavaScript, algorithms and how a processor works first. You have to understand the map: where the frontend is, where the server is, how data reaches the user, what an API is for, why GitHub and Vercel keep coming up in conversations about vibecoding and web development.

Vibecoding works best when you have a concrete goal. Not "learn to program in general", but "build a page that takes requests", "make a form for a client", "automate a report", "redo a friend's site", "put together an MVP". A goal keeps the agent from writing abstract nonsense.

AI tools do not cancel architecture. Cursor, Codex, Claude Code, GitHub Copilot, Lovable and Bolt can write code, but they work inside the ordinary IT world: languages, frameworks, packages, databases, clouds, deploy, testing.

For a first web project a sane starter stack looks like this: TypeScript, Next.js, Tailwind CSS, the VS Code editor, an AI agent, GitHub and Vercel. You can leave the backend alone as long as the first task comes down to a static page or a simple MVP with no stored data.

The main skill of a beginner is not "writing code by hand" but setting the task, reading the result, spotting the flaws, giving the agent concrete feedback and going through the cycle: planning, architecture, code, testing, deploy, iteration.

Part 1. The IT landscape and the IT map

First you need the big picture. Not a language, not a framework, not "which prompt do I paste into the agent", but a map of the world the agent will be writing code in. Without that map, vibecoding turns into guesswork: the AI did something, something broke, and you have no idea where the problem is.

Programming is the new Excel

Excel used to be a mandatory skill for anyone who works with information. Not everyone needs to build financial models at investment bank level. But if a person cannot even open a spreadsheet, write a formula and put data in order, they fall out of normal office work.

Programming is heading the same way.

Not in the sense that "everyone has to become a senior developer". No. But being able to build a small site, automate a repetitive action, hook up a form, write a simple script or explain to an AI agent exactly what needs to be done is becoming basic literacy.

In the video I give an example from life: a person on an advertising team built an internal tool that automated most of his routine. He did not become a "classic programmer", but he became the most productive person in his area, because he saw a process that could be handed to a program.

Here is the right thought to start with:

Everything you do regularly at a computer can potentially be automated.

Not necessarily right away. Not necessarily perfectly. But if you see a repetitive action, a spreadsheet, a form, an export, manual copying, a report, a landing page or a small internal process - that is a candidate for a first project.

Start with a goal, not with a language

The first step is not "choose a programming language". The first step is to set a goal.

A bad goal: "I want to learn to program".

A sane goal: "I want to build a page that takes requests from clients".

Other sane goals:

• make a simple landing page for a service;
• automate a report in the business;
• build an internal page for the team;
• redo an acquaintance's old site;
• make a form that saves requests;
• build a personal dashboard;
• make a small tool for your own work.

Why this matters: an AI agent needs specifics. If you say "teach me programming", it starts a lecture. If you say "build a page for a fitness brand with a hero, a catalog, a request form and a deploy to Vercel", it can lay out a route.

At the start of the video the goal is set before the stack: first what we are building, then what we build it with

In the example from the video the goal is this: take the existing Bonafide site and make a new version inspired by Nike.com. That is not a training todo list but a clear product task: there is a brand, there is a visual reference, there is a future site.

A beginner is better off starting exactly like that. Not with abstract "practice", but with a small real result.

Why you need an IT map

IT looks like magic because there are too many entities inside it. Languages, frameworks, the terminal, GitHub, servers, databases, APIs, clouds, domains, builds, packages, deploy, logs, errors.

If you look at all of it as one giant box, vibecoding turns into gambling: you asked the AI, it did something, it seems to work, then it broke, and it is unclear where to look.

You need a map.

The big IT map from the video: instead of a magic box we lay development out by zones

The map is not there to make you an engineer in one evening. It is there so you know where a problem belongs.

If the text on a page is the wrong color - that is frontend and CSS.

If the form submits but the data is not saved - that is backend or the database.

If the site works locally but does not open on the internet - that is deploy, hosting or the domain.

If the agent installed an old version of a library - that is the package manager and dependencies.

If Vercel did not realize the project is on Next.js - that is project structure and build settings.

Once you can place a problem on the map even roughly, you are no longer helpless. You can give the agent proper feedback: "check the deploy on Vercel", "look at package.json", "the form is not writing data to the database", "on mobile the header covers the hero".

Programming languages: why they exist at all

Down at the bottom the computer does not understand TypeScript or Python. It understands machine code: low-level instructions close to the hardware. Writing that way is uncomfortable for humans, so levels of abstraction appeared.

First low-level languages like Assembly. Then C. Then more convenient languages. Then JavaScript, Python, TypeScript and other languages a human can actually use without constant pain.

In the video languages are explained as levels of abstraction: from machine code to languages a human can actually use

The main idea for a beginner is simple: a programming language is a way to explain to the computer what to do, in a form a human can understand.

But for vibecoding on the web you do not need to know every language. At the first step it matters to know which ones come up most often:

• HTML - the markup of a page;
• CSS - the look;
• JavaScript - the logic in the browser;
• TypeScript - a stricter and safer version of JavaScript;
• Node.js - a way to run JavaScript outside the browser;
• SQL - the language for working with relational databases.

If you go into a modern web stack, TypeScript and Next.js will come up constantly. So for a first project it is better not to argue with the market and take a common stack that AI knows well.

The web is client, server and network

Web development rests on three big blocks: the client, the server and the network.

The client is what the user interacts with the product through. A browser, a mobile app, a desktop app, sometimes even a device with no screen. In our case the client is most often a browser.

The server is a computer that hands the client data, pages, images, API responses and everything else. The server does not have to sit in your home. Usually it is somewhere in the cloud.

The network is how the client and the server talk to each other.

The basic diagram from the video: client, server and the network between them

Example: you open a site. The browser on your laptop is the client. It asks for the page. Somewhere in the cloud a server hands over HTML, CSS, JavaScript, images and data. Network communication goes on between them.

For a beginner this matters more than it seems.

When you say "my site is not working", you have to specify: not working where?

• Is the button not showing in the browser?
• Is the server not returning data?
• Is the request not getting through?
• Is the database not responding?
• Did the deploy fail to build?
• Is the domain not connected?

Without this map everything collapses into one phrase: "it broke". With the map you start to understand where to dig.

What a server is

A server is not a magic cabinet. It is also a computer, its job is just to serve others.

Your laptop is usually a client: it asks, displays, handles your clicks. The server usually answers: it stores data, serves files, takes requests, runs code that has to work all the time.

In the video the server is explained through a website: part of the picture and the data comes to the client from another machine

A server has two sides:

• hardware - a physical machine or a virtual machine;
• software - the code, the database, the processes running on it.

When people say "cloud server", they usually do not mean the sky or abstract magic. It is somebody else's computer in a data center that you rent or use through a service.

For vibecoding it is worth understanding the cloud levels:

SaaS - software as a product. Dropbox, for instance. You use it and barely touch the technical part.

IaaS - infrastructure as a service. AWS, for instance. Lots of control, lots of complexity.

PaaS - platform as a service. Vercel, Supabase, Convex, for instance. They take away part of the complexity and give the developer a clearer layer.

A beginner most often needs PaaS. Not because it is "toy-like", but because you want to build a product, not spend a week in AWS settings.

PaaS services like Vercel, Supabase and Convex remove part of the infrastructure complexity

Frontend: HTML, CSS and JavaScript

The frontend is what the user sees and interacts with.

In the classic web the frontend rests on three things.

HTML handles structure: where the heading is, where the text is, where the link is, where the image is, where the form is.

CSS handles the look: color, size, spacing, grids, responsiveness, radii, the state of a button on hover.

JavaScript handles behavior: what happens on a click, how the menu opens, how the form is validated, how data loads without reloading the page.

In the video the frontend is broken down as HTML, CSS and JavaScript together

You can see the HTML right in the browser through View Page Source or the developer tools. That does not mean you have to read all the HTML right away. But it helps to understand: the page did not just "get drawn". There is a structure under it.

View Page Source shows the HTML foundation of a page: not magic, just markup

CSS can be written separately, but modern projects often use frameworks. In the video I show Tailwind: a popular CSS framework that lets you write styles right next to the markup through short classes.

Tailwind on the IT map: a popular CSS framework for modern web projects

On the modern web JavaScript almost always comes together with TypeScript. TypeScript adds types and cuts down the number of silly mistakes. AI agents also find a typed project easier to work with, because they get more hints about the structure of the code.

Next.js is one of the most popular frameworks built on React. For a first project it is good because AI models know it very well, it has a strong ecosystem and it works natively with Vercel.

TypeScript and Next.js show up as the standard pair for modern web coding

Backend, data and databases

The backend is the part of the system responsible for data, business logic, authorization, working with the database, handling requests and talking to external services.

It is easy for a beginner to think "a site is a picture". But almost any serious product runs into data fast.

A user signed up - where do you store the account?

A client left a request - where did it go?

A buyer paid - where is the payment status?

An admin changed the price - where is that written down?

This is where databases appear.

The simplest comparison: a database is like Excel, only for applications. Inside there are tables, records, relations, queries. SQL is the language you can use to ask for and change data in relational databases.

The database ecosystem from the video: SQL, NoSQL, document, vector, time-series and other database types

For a first project you do not need to know the whole database zoo. But you do need to understand that "save the data" is a separate task, not an automatic property of a page.

If you are building a static landing page, you may not need a database at all.

If you are building a request form, you can first send the data to email, Telegram, Google Sheets or a simple backend.

If you are building an app with users, payments, accounts and states, a database is almost inevitable.

A good strategy for a beginner is not to climb into the backend too early. First build the frontend and the deploy. Then add data storage through a clear service: Convex, Supabase or another backend-as-a-service.

API: how programs talk to each other

An API is an interface for programs to interact.

When the client asks the server "give me the list of products", that is a request to an API.

When a form submits a request, that is a request to an API.

When your app reaches out to OpenAI, a payment service, a CRM or a database, it often does that through an API too.

In the video the API is explained as the way the client, the server and external services talk

The most common format for a beginner is a REST API. There are others: GraphQL, WebSocket, RPC and so on. At the start you do not need to know them all. It is enough to understand that an API is a contract: where to send the request, what data to pass, what response to expect.

That is exactly why an AI agent has to be given context. If you just say "hook up payments", it can do anything. If you say "connect the form to an API that takes name, email, phone and message, handle the error and show a success state", the chance of a decent result is higher.

Testing and edge cases

The code is written - that is not the end.

You have to check that the main scenario works. Then check the edge cases: an empty form, a long email, the mobile version, a slow network, an invalid server response, a deploy error, a wrong environment variable.

Testing is a separate stage in the video: built it - checked it - found a flaw - handed it back to the agent

An edge case is a situation at the edge of the normal scenario.

For instance, the main job of a form is to submit a request. Edge cases:

• the user did not enter an email;
• the user entered an email with a typo;
• the server is temporarily unavailable;
• the request was submitted twice;
• the button does not fit on a mobile screen;
• after a successful submit the person did not understand what happened.

Beginners often think development is "writing code". In practice most of the work is getting it to a state where the product does not fall apart at the user's first imperfect action.

AI helps a lot here. But it will not guess all the important edge cases unless you ask.

Part 2. Building the tech stack

Now we move from the map to a working set. A tech stack is not a list of buzzwords. It is a bundle of decisions that lets you create, check, save, deploy and then grow a project.

For a beginner the tech stack should be boring and popular. Boring - because there are fewer surprises. Popular - because AI models have seen plenty of that code, documentation, errors and standard solutions.

A first stack for a beginner

In the video I suggest a minimal stack for a first vibecoding project.

You need:

• a code editor: VS Code or a similar IDE;
• an AI agent: Claude Code, Codex or OpenCode;
• a language and framework: TypeScript and Next.js;
• styles: Tailwind CSS;
• a repository: GitHub;
• deploy: Vercel.

A minimal stack for a first project: IDE, agent, TypeScript, Next.js, GitHub and Vercel

Why not pick something exotic?

Because AI works better with the popular. The more code, documentation, examples and errors there are on the internet, the better the model knows the stack. TypeScript, React, Next.js, Tailwind, GitHub and Vercel are not the only path, but they are a clear starting bundle.

For a first learning project Vercel is the simpler option.

Which agent to take. Use VS Code as the editor: it is free, and Cursor itself is built on it. Install the agent following the instructions on its card — Claude Code, Codex or OpenCode. Who is ahead right now is visible in the AI agent rankings.

• Claude Code or Codex. Together they hold the first four places in that ranking as of Sep 25. Claude Code is included in Claude Pro at $20 a month, Codex is included in ChatGPT Plus for the same $20. Free entry exists only for Codex: the smaller GPT-6 Luna model in the OpenAI desktop app is being opened up to free accounts gradually.
• OpenCode — an open agent in the terminal. It is free itself, and it comes with free models for a limited time. You connect a strong model yourself: a ChatGPT subscription, a provider key or a local one. In the same ranking OpenCode with the open GLM-5.3 model scored 53.6 points against 66 for the leader.

If you want to compare this with a current working set of tools, see my AI stack in 2026. If you need a separate page just about installation, it is here: a beginner's first tech stack. But below I duplicate the key steps right in this article.

Model: what will think and write the code

LLM - large language model. That is what sits under ChatGPT, Claude, Gemini and other AI services.

For vibecoding the model matters. Different models write code differently, understand context differently, fix errors differently, work with tools differently and hold long tasks differently.

In the video I show the benchmarks section of vibecoding.tech: there coding models are compared by aggregated signals from different sources. If you are choosing a model specifically, start with the model rankings. If you are choosing not a model but a working agent, look at the AI agent rankings, which score the "agent + model" pair.

vibecoding.tech benchmarks help you choose a coding model by measurable signals rather than rumor

But there is an important rule: do not memorize the name of "the best model" forever. The video was shot in June, and by Sep 25 the top places in the agent ranking were taken by models that did not exist back then.

Out in front is Claude Code with Opus 5.5 — 66 points. Next come Claude Code with Fable 5.1 and Codex with GPT-6 Astra, at 62.2 and 61.6. All three models came out in September 2026.

So it is better to understand the principle:

• for small fixes a cheaper model will do;
• for complex architecture and big tasks you need a strong model;
• for design and taste what matters is not only the benchmark but real hands-on experience;
• for code what matters is not only the chat but how the model works inside the agent with files, the terminal and the browser.

Code: where the project and the agent live

AI coding tools have spread across different formats by now.

IDE — the AI is built into the development environment. That is how Cursor works. Claude Code and Codex also install as extensions in VS Code.

CLI — the agent lives in the terminal. That is how Claude Code, Codex CLI and OpenCode work.

Desktop app — a separate application where you can open the project and work with the agent. Codex in that format is handy when you want to see the chat, the files, the terminal and the working context side by side.

Cloud agent — you give a task in the cloud and the agent works somewhere out there, often without full visual control.

Web builder — Lovable, Bolt and similar tools where the user builds an app in the browser.

GitHub-native agent — the agent works directly with the repository, issues and pull requests.

In the video I show several surfaces and explain why I take Codex for the practical project.

Cursor in the video: files on the left, terminal at the bottom, code on the right. VS Code is arranged the same way

Claude Code is good as a terminal agent. It lives closer to the classic developer workflow: terminal, files, commands, checks.

Claude Code in the terminal: the CLI format is closer to ordinary engineering work

Codex is convenient in this run because you can work in a separate app and see the chat, the project, the terminal, the file tree and the browser context.

The Codex App interface: chat, project, file tree, terminal and browser context

Important: do not become a fan of one interface. Tools change, the map stays. Tool cards with pricing are collected in the catalog.

Skill: your role in a vibecoding project

The third layer of the stack is skill. It sounds less impressive than "a new model" or "a new agent", but it is what decides whether you end up with a product.

Vibecoding does not mean "I understand nothing and the AI will do everything". The working formula is different:

• the model gives intelligence;
• the tool gives access to code, terminal and browser;
• skill turns chaotic generation into a managed process.

At the first stage a beginner should have four basic skills.

First - setting the task. Not "make it pretty", but "make a landing page for brand X, in the style of Y, on Next.js and Tailwind, with no backend, with a responsive hero section, a catalog and a form".

Second - reading the result with your own eyes. Open the page, walk through the scenario, look at the mobile version, compare with the original task.

Third - turning a feeling into concrete feedback. Not "this is garbage", but "the button gets lost, the hero does not feel like premium retail, on mobile the heading breaks, the Vercel build failed on an import error".

Fourth - taking it to a public link. As long as the project lives only locally, it has not met reality. GitHub and Vercel are not there for show but so the project can be opened, checked and shown to another person.

That is why in this article the stack is built not as a list of apps but as a system: model, code, skill.

Installing the tech stack: do it once and do not go back to chaos

Below is a condensed but working version of the separate guide a beginner's first tech stack. If you are reading this article as an instruction, you can go straight through the steps here.

1. Create a GitHub account. Open github.com/signup, sign up, confirm your email and turn on two-factor protection. GitHub is where the code and the history of changes will live.

2. Open the terminal. On Windows that is PowerShell or Windows Terminal. On macOS - Terminal. The terminal is not for show, it is how you run the project, install dependencies and see errors.

Check:

pwd

The command should show the current folder.

1. Install Git. Download Git from git-scm.com/downloads, install it and restart the terminal.

Check:

git --version

Set your name and email right away:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

4. Install VS Code and an agent. Download the editor from code.visualstudio.com: it is free, and the files, the terminal and the agent all live in one window there. Install the agent following the instructions on its card — Claude Code, Codex or OpenCode.

1. Install Node.js LTS. Open nodejs.org/en/download, pick the LTS version, install it and restart the terminal.

Check:

node -v
npm -v

If versions appear, Node.js is installed fine.

1. Install pnpm. This is the package manager we will use to create and run the project.

   npm install --global corepack@latest corepack enable pnpm pnpm -v

If pnpm did not appear, use the direct install:

npm install -g pnpm@latest-11
pnpm -v

7. Create your first Next.js project. Go to a convenient folder, the desktop for instance, and create the app:

pnpm create next-app@latest first-vibe-project --yes
cd first-vibe-project
pnpm dev

Open http://localhost:3000. If you see the Next.js starter page - the project is alive.

1. Open the project in VS Code. Choose File -> Open Folder, open the first-vibe-project folder, then open the built-in terminal through Terminal -> New Terminal. Check that the pnpm dev command runs from VS Code too.

2. Make your first commit. This is saving the state of the project.

   git status git add . git commit -m "Initial Next.js app"

3. Create a repository on GitHub and push the code. On GitHub click New repository, name it first-vibe-project, do not add an extra README, create the repository and run the commands from the project terminal. Replace USERNAME with your own GitHub username.

   git branch -M main git remote add origin https://github.com/USERNAME/first-vibe-project.git git push -u origin main

4. Connect a backend only once you have data. If the project just shows one page, you do not need a backend yet. If requests, users, tasks, posts or counters appear, you can add Convex:

   pnpm add convex pnpm convex dev

The main rule: first the page and the deploy, then the data. Do not turn day one into an architecture marathon.

1. Deploy to Vercel. Open vercel.com/signup, sign in through GitHub, click Add New -> Project, pick the first-vibe-project repository, check that Framework Preset is set to Next.js, click Deploy.

At the end you should have four things: the project folder on your computer, the code on GitHub, a public link on Vercel and an understanding of how to repeat the cycle.

If something breaks, do not panic. An error is not a failure but concrete text for the agent. You copy the log, hand it to the agent and ask it to fix it while keeping the chosen stack.

Part 3. Your first vibecoding project

Now we connect the map and the stack into real work. The goal of this part is not to memorize every term but to go through the full cycle: task, architecture, code generation, checking, GitHub, Vercel and iteration.

A practical case: redoing the Bonafide site

Theory is needed, but without practice it evaporates fast. So in the video we take a real case: make a new version of the Bonafide site, inspired by Nike.com.

First we formulate the task for the agent: what product, what visual reference, what stack, what should be on the page, where we host it, what we are not doing in the first version.

A prompt for the agent should contain the goal, the stack, the visual reference and the constraints

At the architecture stage we lay the task out on the map:

• frontend: Next.js, TypeScript, Tailwind;
• backend: not in the first version;
• data: static content on the page;
• deploy: Vercel;
• repository: GitHub;
• testing: locally and after the deploy.

Mapping the task onto the IT map: what belongs to frontend, backend, server and deploy

This is an important moment. A beginner often asks the AI to "make a site" and is then surprised that the agent picked a strange stack, did not understand the design, built an unnecessary backend or put the project in the wrong place.

The more precisely you set the frame, the less the agent has to guess.

GitHub: why you need a repository

GitHub is where the project code and the history of changes are stored.

In a first project you do not need to know Git deeply. But you do need to understand the minimum:

• the project should live in a repository;
• changes can be pushed to GitHub;
• Vercel can pull the code from GitHub and deploy the site;
• if something breaks, you have a history and a point to return to.

Creating a new GitHub repository for the project from the video

If you are building a project for yourself or a client, the repository is usually better kept private. In the video the repository can be public, because it is a demo case.

Checking the result

When the agent has generated the page, do not trust it right away. You have to open it, look, click around, check the mobile version, compare it with the task, find the mismatches.

In the video the first result is not perfect. And that is normal. Vibecoding is not about "one prompt and done". It is about the speed of iterations.

You have to look at the first result with your own eyes: the agent can produce a working, but not a final version

Good feedback to the agent does not sound like this:

"bad, redo it".

Better like this:

"The site is too generic, there is no Nike-like motion, the logo has not been made, the hero is weak, the buttons do not look like premium retail, check the mobile version, keep the Next.js and Tailwind stack, do not add a backend".

AI fixes things better when you turn taste and irritation into concrete requirements.

Deploy: local code, GitHub and Vercel

Deploy is publishing the project to the internet.

In the simple version the path is this:

local project -> GitHub -> Vercel -> public URL.

You work on your own computer. The code is pushed to GitHub. Vercel is connected to the repository, builds the project and publishes the site.

The deploy diagram from the video: local codebase, GitHub and Vercel

Why this matters for a beginner: a site that works only on your laptop is not a product yet. A product starts when another person can open a link.

And yes, deploys break often.

In the video Vercel did not immediately recognize the project as Next.js. That is not a disaster. It is a normal part of the work. There is a log, there is an error, there is an agent you can hand the context to and ask for a fix.

Vercel does not always detect the project automatically: deploy errors have to be read and fixed

When the deploy is ready, a public link appears. But that is not the end. After the deploy there is almost always one more flaw: the logo is in the wrong place, the text did not update, the mobile version slipped, a button does not work.

The deploy is done: the project can now be opened as a public site

Iterating after the deploy

The sixth step is iteration. That is what separates "generated a demo" from "took it to a product".

In the video a problem with the logo shows up after the deploy. We do not start over. We give the agent a concrete task, it fixes things locally, pushes to GitHub, Vercel picks up the update.

That is the normal workflow:

1. Set a goal.
2. Laid it out by architecture.
3. Generated the code.
4. Checked it.
5. Deployed it.
6. Spotted a flaw.
7. Fixed it.
8. Repeated.

After the deploy the agent fixes the problem and sends the changes through GitHub to Vercel again

A beginner needs to accept this: there will always be errors. The question is not how to do it perfectly the first time. The question is how fast you go through the error cycle.

Checklist for a first vibecoding project

If you want to repeat the path from the video, use this order.

1. Formulate a concrete goal. Not "I am learning", but "I am making a page/form/tool".
2. Describe the user and the scenario. Who will open it, what they will see, what they should do.
3. Pick a simple stack. For the frontend: Next.js, TypeScript, Tailwind, Vercel.
4. Clarify whether you need a backend. If you can get by without a database in the first version, do that.
5. Open the project in VS Code or another editor.
6. Start the AI agent and give it a task with constraints.
7. Check the local result with your own eyes.
8. Create a GitHub repository.
9. Push the code to GitHub.
10. Connect Vercel and deploy.
11. Read the errors if the deploy failed.
12. Hand the logs to the agent and ask for a fix.
13. Check the public URL.
14. Make the first iteration fix.

That is already a full development cycle. Small, but real.

Where beginners most often go wrong

The first mistake is asking too broadly. "Make an app" is almost always worse than "make a request page with three sections, a form and a deploy to Vercel".

The second mistake is not understanding where the problem is. If you cannot tell frontend, backend, database, API and deploy apart, every bug looks the same.

The third mistake is taking the first result as final. AI often makes a draft. Your job is to refine the task, give feedback, check, repeat.

The fourth mistake is climbing into a complex backend too early. For a first project it is better to take a simple frontend all the way to a public link than to spend a week building perfect architecture and show nothing.

The fifth mistake is ignoring the deploy. Until the project can be opened by a link, it has not met reality.

How this connects to the course

This article gives you the basic map. It is enough to understand where to look and how to put together a first simple vibecoding project.

But systematic vibecoding is broader:

• how to choose tools for the task;
• how to set tasks for agents;
• how to check code;
• how to work with the backend, payments, auth and databases;
• how to build product architecture;
• how to avoid ending up with one-off neuroslop instead of a maintainable project.

If you want to go through this as a system rather than in random pieces, see the Agentic Engineering course. If you want to keep track of the tool market, subscribe to AI FOMO Fix. If you are picking a model or an agent, start with the AI agent rankings and the tool catalog.

FAQ

Can I start vibecoding if I am not a programmer at all?

Yes. But you should start not with "learn every language" but with a small goal, a clear IT map and a simple stack. AI will write most of the code, but you have to understand what it is doing at the level of blocks.

Do I need to learn JavaScript before my first project?

Not deeply. But it helps to understand that JavaScript handles behavior on the web, TypeScript makes it stricter, and Next.js helps you build modern sites and apps.

What should a beginner choose: Cursor, Codex or Claude Code?

Full access to Codex and Claude Code costs from $20 a month. Without a subscription, OpenCode with your own model works. The choice matters less than the ability to set a task and check the result.

Do I need a backend in a first project?

Not always. If you are making a static page, you can do without a backend. If you need users, requests, payments, an account area or data storage, a backend will be needed.

Why Vercel?

For a Next.js project Vercel is the simplest start: it understands Next.js well, connects to GitHub and quickly gives you a public URL.

What do I do if the AI generated a bad result?

Do not take it as final. Describe the concrete problems, give the agent constraints, attach logs or a screenshot, ask for a fix. Vibecoding is an iterative process, not a single prompt.

Where can I watch the original video?

The video this article is based on: Programming is the new Excel. Now even you can program.

Sources and next steps

• The original video on YouTube
• AI agent rankings and model rankings
• The vibecoding.tech tool catalog
• Step-by-step setup of a first tech stack
• My AI stack in 2026
• The Agentic Engineering course
• The AI FOMO Fix newsletter
• Claude pricing and Codex pricing in ChatGPT, checked Sep 26, 2026
• Artificial Analysis Coding Agent Index, snapshot Sep 25, 2026