Topic 41

Vibe Coding: the Rise

Concept

Milo's estimate was two days. His junior colleague at the agency, given the job on a quiet Thursday, has something on screen by four in the afternoon: a page with a box for the booking reference, Waymark's colours, three sensible messages for confirmed, waitlisted and cancelled, and a polite line for a reference that does not exist. Tessa clicks around it for ten minutes and cannot break it.

The junior has not read a line of the code behind it. Not skimmed it, not glanced at it — not read it. The whole afternoon went like this: describe what the page should do, watch the tool build it, click around the result, say what felt wrong, watch it change, click again.

There is a name for working this way. It is called vibe coding: building software by steering on whether the result feels right, and never on the code itself. The code exists, it scrolls past, and nobody looks at it.

This page takes that seriously. The next page counts what it costs — that page is coming and it is unsparing — but the honest half of the story goes first, because the honest half is that the afternoon was real and the page works.

The afternoon loop, and what piles up underneath it
Say what you wantin ordinary language
The tool builds itfiles written, the result started up
Click around itdoes this feel right?
Say what is wrongand round again, thirty times

The Loop, Described

Four steps, repeated until the thing is good enough.

Say what you want, in ordinary language: a page where a guest types a booking reference and sees whether their trip is confirmed. The tool builds it — files written, the result started up, ready to click. You use it as a person would, looking for anything that is missing, ugly or wrong. Then you say what is wrong, in ordinary language again: the cancelled message should be softer, and it should not show the guest's phone number. Round and round, twenty or thirty times in an afternoon.

Notice what that is. It is Chapter 2's iteration craft — steer, do not restart; say what was right as well as what was wrong; expect rounds — applied to software instead of prose. Tessa recognizes every move.

With one difference, and it is the difference the whole chapter turns on. When Tessa iterates on a brochure, she reads the draft. Reading the draft is how she knows what to say next. The junior is iterating on something they have never read, judging it only by how it behaves when clicked.

Why It Genuinely Works

It would be easy, and wrong, to treat the afternoon as luck. Three things made it work, and all three are mechanisms from earlier in this book.

The model has seen an enormous number of pages like this one. A form, a lookup, three outcomes, a friendly error — the patterns from the last page, at their strongest. This is not the model doing something surprising. It is the model in the middle of its range.

The project was small and brand new, so all of it fitted in the window. There was no decade of accumulated decisions to gather up and squeeze past the limit from Chapter 1, no tangle of files where changing one breaks another. A fresh project of a few hundred lines is close to the friendliest thing you can put in front of these tools.

And "does this look right when I click it?" is real feedback. Not complete feedback, but real: it catches missing buttons, wrong labels, broken flows and ugly layouts, in seconds, without anyone needing to know how any of it works. Cheap, fast signal is genuinely valuable, and the loop runs on it.

So here is the plain statement, without a wink. For a demonstration to show a client on Friday, for a prototype that answers "would this even be useful?", for a personal tool nobody else will ever run, for a one-off script that reshapes a file once and is deleted — vibe coding is not a compromise. It is the right tool, and it has compressed work that used to take a week into an afternoon. Anyone who tells you otherwise is not looking at what is on the screen.

What Made It Possible Now

None of this would have worked five years ago, and the reason is the top rung from the last page.

The older tools handed you code and stopped. Somebody still had to put the code where it belonged, start it, read whatever the computer complained about, and understand the complaint well enough to ask a better question. Every one of those steps needed a person who could read code, which meant the loop always passed through somebody who was looking at it.

Agentic tools closed that loop. The tool runs the code itself, reads its own errors, and fixes them, without anybody being told an error happened. What reaches the human is the outcome, and only the outcome.

Sit with that for a moment, because Chapter 3 already warned about it in a different costume. Judging by the outcome alone, with no view of what produced it, is exactly the stance that made the Harbourview Annex convincing: the prose read beautifully, so it must be right. Here the substitute for reading is clicking. It is the same swap — surface evidence standing in for verification — moved from a brochure to a booking page. Say it flatly and move on; the next page is where it comes due.

The Seduction, Named Precisely

What makes vibe coding so easy to overuse is not that it hides its flaws. It is that the experience of it is excellent.

Progress is visible every few minutes. Friction is close to zero — no learning curve, no waiting, nothing to install in your head first. Every round ends with something that works better than the round before. Compared with any previous way of getting software built, this feels less like work and more like being listened to.

And nothing about that experience signals what is being skipped. Not a warning, not a pause, not a moment of friction. The things that were left out are ordinary and invisible: nobody read the code, nothing checks it automatically, and there is no record of what it looked like yesterday.

Those three absences have names — review, tests, and versions — and they are the cast of the next page.

Milo's junior demonstrates the page to Waymark on Friday morning. It works. Tessa is impressed, and says so, and she is right to be. Everyone in the room agrees it should go live on the booking site next week.

The page ends there, deliberately, on the applause.

Common Confusions
  • "Vibe coding is just bad practice with a fashionable name." It is a practice with a fit. For demos, prototypes, personal tools and throwaways it is the right choice. What goes wrong is scope creep — a demo quietly becoming a product — and that is the next page, not this one.
  • "The demo works, so the software is finished." "Works when I click around" is one afternoon of evidence from one person who knew where to click. Software's real costs arrive later, when it has to be changed, handle the odd case, and be understood by somebody else.
  • "If the tool wrote it, the tool can maintain it." The model holds nothing between sessions — Chapter 1's no-memory, one more time. A tool can keep notes on disk and re-supply them next month, which helps; what it cannot do is read the code back to a person who never read it. Maintenance lands on whichever human owns the code, if anyone does.
  • "Nobody read it, so it must be badly written code." It is usually fine code, which is exactly what makes this hard. The problem this chapter is building toward is not the quality of what was generated; it is that nobody knows what is in there.
Why It Matters
  • Tessa will be shown software built exactly this way — sometimes appropriately, sometimes as the thing Waymark's booking site is about to depend on. She now has the term and the honest half of the ledger, which is what makes the other half credible.
  • An afternoon that used to be a week is a real change in what a small company can afford to try. Recording that plainly, before the accounting, is the difference between a warning worth reading and a warning that sounds like nostalgia.

Knowledge Check

What does this page mean by vibe coding?

  • Building software without any code being written at all
  • Steering only on whether the running result feels right
  • Generating code and then reviewing it before keeping it
  • Writing software as fast as the tool can possibly produce it

Why did the loop work so well on Waymark's booking-status page?

  • The junior wrote the difficult parts and generated the rest
  • The tool verified the finished page against Waymark's rules
  • A familiar task, a small new project, and quick usable feedback
  • The model reused a finished page it had memorized in training

What did agentic tools change, that made this way of working possible?

  • They removed the context window limit from Chapter 1
  • They made the model stop producing code with errors in it
  • They gave the tool a lasting understanding of the project
  • They run the code and fix their own errors, unseen

What was silently skipped during the junior's afternoon?

  • Any testing at all, of any kind, before the demonstration
  • Reading the code, automatic checks, and a record of changes
  • Describing the task clearly enough for the tool to follow it
  • Showing the result to anybody outside the agency's own team

You got correct