Vibe Coding

A person who runs a small yoga studio wants a web page where customers can book a time slot. The owner has never written a line of code. They open an AI coding tool and type one sentence describing the page. A few minutes later there is a working booking page on the screen.

The owner did not read the code that was produced. They did not open the files at all. They looked at the page, tried it, and asked for changes in ordinary words.

This way of building software is called vibe coding: describe what you want, accept what comes back, and never look at the code. The term was introduced in early 2025 by the AI researcher Andrej Karpathy and spread quickly. It sits at the opposite end from agentic engineering, where an experienced developer reads and directs everything the agent writes.

After this lesson you can explain what vibe coding is, say how it differs from agentic engineering, describe the risk in code nobody has read, and judge which kinds of projects it suits.

1. What the whole job looks like

Here is the full extent of what the studio owner typed:

Build me a page where people book a slot and I get an email.

This sentence describes the result. It is not a specification, which is a precise and detailed statement of what a piece of software must do. A specification would say which times can be booked, what happens when two people pick the same slot, what the email contains, and much more. The sentence says none of that.

Now look at what the owner needed to know before typing it:

A framework is a ready-made set of code building blocks that a project is built on, so that not everything has to be written from nothing. Choosing one is normally an early decision for a developer. Here the agent made that choice, along with all the others.

And here is what came back:

Pick a time          >
Thursday, 10:00      chosen
Your email address   >
[ Book it ]

It is a page with a time picker, a field for an email address, and a button. It runs. That was the whole of the request, and the request was met.

2. Where the person's attention stops

A piece of software has two levels. On top is the result: the page you can see and click. Below it is the code that makes the page work.

flowchart TB
    A["The output, the result<br/>what the page shows and does"]
    B["The code underneath<br/>how the code is written<br/>which architecture it uses<br/>which rules it follows"]
    A -.-|"the person's attention stops here"| B

In vibe coding, the person looks at the top box and stops at the dotted line. Everything in the bottom box goes unexamined:

• How the code is written. Whether it is clear or confusing, short or repetitive.
• Which architecture it uses. Architecture means how the parts of a program are organised and how they connect to each other.
• Which rules it follows. Whether it keeps to any consistent conventions, including rules about safety and about handling personal data.

The agent made all of these decisions. Nobody checked them.

3. Two ways of getting software built

Agentic engineering and vibe coding both use an AI agent to write code. They differ in what the person steers.

In agentic engineering, the developer can open a file, see that the agent stored a price in an unsafe way, and say exactly what to change. The developer's judgement reaches into the code.

In vibe coding, the only test is using the result. If the page does not do what was wanted, the person describes the wish again in different words and tries again. There is no way to say "this part of the code is wrong", because the code was never read.

The two are ends of a range, and real work often falls between them. A developer may read the important parts of a change closely and skim the rest. The term vibe coding in its strict sense means the far end: no reading at all.

4. Every instruction is about the result

A vibe coding session looks like this:

You:    Make the button bigger and move the form to the top.
Agent:  Done.

You:    Now email me whenever somebody books.
Agent:  Done.

You:    That's it. Put it online.

Not one of these sentences is about code. Each one describes how the page should look or what it should do. The last one asks for the page to be published on the internet for real customers.

Compare this with the request from the lesson on agentic engineering, which named a rules file and asked for a test to be written first. That request was about how the code should be made. These are only about what the result should be.

The third message changes the situation. "Put it online" turns an experiment into a live service. From that moment, real people enter their email addresses into software that no person has inspected.

5. Tidy on top, tangled underneath

The result of vibe coding often looks finished. The page is clean and does what was asked. What lies under it can be very different.

Each new request ("make the button bigger", "now email me") is added on top of what is already there. The agent tends to make each change in whatever way works at that moment. Without anyone checking, the same logic may be written in three places, old code that is no longer used may stay behind, and quick fixes may pile up on quick fixes. Developers call this build-up technical debt: problems in the code that make every later change harder, the way an unpaid debt grows with interest.

None of this is visible from the page. It becomes visible on the day something breaks. A booking is lost, or two customers get the same slot, or the email stops arriving. The cause is somewhere in the code, and the code is the one place the person has never looked. They have two options: ask the agent to fix it and hope that the fix does not break something else, or find someone who can read code.

There are specific risks that cannot be seen by trying the page:

• Security. The page may store email addresses where outsiders can read them, or accept harmful input.
• Edge cases. These are unusual situations, such as two people booking the same slot in the same second. A quick try does not reveal them.
• Cost. The software may use paid services in a wasteful way.

6. Where it fits and where it does not

The property that makes vibe coding attractive is the same property that makes it risky: the person does not have to deal with the code. Whether that is a strength or a weakness depends on the project.

A prototype is a quick first version made to try out an idea or to show it to someone. If it is thrown away after the demonstration, the state of its code does not matter.

For a person who cannot code, the comparison is different. The choice is not between vibe-coded software and well-engineered software. It is between vibe-coded software and none. A personal tool that sorts your own photos or tracks your own expenses carries little risk, because a failure affects only you.

These questions help decide:

7. The code that is never read still runs

Vibe coding gets working software built. What it leaves out is any check of the code, and that has a consequence: code that nobody read is still the code that runs. Not looking at it does not make it correct, safe, or cheap to operate. The software behaves according to what the code says, whether or not anyone has seen what it says.

So the decision depends on what a failure would cost. For a throwaway prototype or a private tool, a failure costs little, so unread code is an acceptable trade. For anything that holds other people's data, takes payments, or has to keep working for years, the trade changes, and at some point someone with the skill to read the code has to do so. That is the point where vibe coding ends and agentic engineering begins.

Interview points

• Vibe coding means building software by describing the desired result to an AI agent, accepting the output, and not reading the code. The term dates from early 2025.
• The person needs no programming language, no knowledge of project layout or frameworks, and no view on what the code should look like. The request is a description of the result, not a specification.
• The person's attention stops at the output. How the code is written, its architecture, and the rules it follows are all decided by the agent and left unexamined.
• In agentic engineering the person steers the code: reads it, understands its structure, and can identify what is wrong. In vibe coding the person steers the result: describes, tries, and rephrases.
• Every instruction in a vibe coding session is about behaviour or appearance. None is about code.
• The visible result can be tidy while the code underneath is tangled. When something breaks, the cause lies in the code that was never read.
• Risks that testing by hand does not show include security flaws, unhandled edge cases, and accumulated technical debt.
• Vibe coding suits rapid prototypes and personal tools, and it makes building possible for people who cannot code. It suits complex, long-lived software poorly, because problems compound.
• Unread code is still the code that runs, so software that handles other people's data or money needs review by someone who can read it.

Summary

• Vibe coding is describing what you want and never opening the code.
• It needs no programming knowledge to get started.
• The person checks only the visible result.
• Agentic engineering steers the code. Vibe coding steers the result.
• All instructions are about what the software does or looks like.
• The code underneath can be disordered without anyone noticing.
• When the software breaks, the answer is in the unread code.
• It fits prototypes, private tools, and people who cannot code.
• It does not fit complex software that must be maintained.
• The code runs as written, whether anyone has read it or not.