Vibe Coding Is Real
Vibe coding lowers the cost of generation. It does not lower the cost of responsibility.
Chapter 1 - Vibe Coding Is Real
Part: I - The New Discipline
Thesis
Vibe coding is not fake. It is a real change in the labor economics of software.
Key Line
Vibe coding lowers the cost of generation. It does not lower the cost of responsibility.
Natural Language Is Now A Software Interface
Something changed.
Not in the theory of software. Not in the fundamentals of systems. In the interface.
For most of software history, the interface between human intention and working code required programming skill. You learned the syntax, the types, the paradigms, the build tools, the frameworks, the deployment steps, and the debugging rituals. That learning curve was long. The cost of entry was real.
Natural language was not a software interface. It was a description of what you wanted. Turning the description into a working system required a programmer.
That is no longer uniformly true.
A person with a clear idea and a capable model can now produce working code, functional APIs, deployable prototypes, and working data pipelines without knowing how to write the code being generated. They can navigate a codebase with questions instead of syntax, debug with descriptions instead of stack trace analysis, and ship a first version without months of learning first.
That is a real change. Dismissing it as hype misses what is actually happening.
The interface changed. The labor required to cross the gap between idea and code dropped. Nontraditional builders entered the field. New software appeared that would not have appeared before.
Generation Now Happens Twice
The story so far is the one everybody tells: a person describes what they want, and a model turns the description into a running system. That is accurate, and it undersells what changed.
Cheap generation created two openings, not one.
The first is the one this chapter has been describing. Models can help construct software: draft the code, the tests, the migrations, the docs. The output moves toward a repository, and a person, or a pipeline standing in for one, decides what merges. Vibe coding, as most people use the word, lives here.
The second opening gets less attention and matters just as much. Models are now cheap enough to run inside the finished product, not only in the session that built it. A support tool interprets a request and proposes a refund. A game master narrates a battle and proposes the outcome. A research assistant drafts a claim and proposes to publish it. The model does not clock out when the repository stops changing. In a growing number of products, it keeps generating on every request the software receives, for as long as the product stays live. A single response like that can mix narration, a claim, and a tool call in one breath - Chapter 6 treats how those pieces get separated and checked, and Chapter 9 treats the tools that bound what the model can even attempt to do.
This book calls the first case AI-assisted development and the second AI-native application design. The introduction set out why the two share one control problem running on different clocks.
Responsibility now attaches to two boundaries instead of one. A development commit boundary: the point where generated code or configuration becomes part of the shipped system. A runtime commit boundary: the point where a live model’s output becomes a database write, an executed action, a published claim, or any other user-visible state. Neither boundary is staffed by a perfectly reliable gatekeeper - reviewers miss things too, under the same deadline pressure that makes a model’s context grow past what it can actually track. The real difference is contract expectations, not purity: a database or a payment processor is built to obey a bounded contract, and drift from that contract is a bug to fix. A model is an open-ended generator by design, producing a plausible continuation rather than a guaranteed one. That is exactly why both boundaries need controls that do not depend on anyone, human or model, getting it right on the first try.
This chapter stays mostly at the first boundary - the one vibe coding made famous. The rest of the book spends more time at the second.
Vibe Coding Is Not One Thing
The term “vibe coding” gets used loosely, and that looseness is worth naming.
At one end: a skilled engineer using AI assistance for speed. Tests drafted faster. Documentation updated from diffs. Boilerplate generated in seconds. The model accelerates work that the engineer understands and owns.
At the other end: a person with minimal software knowledge prompting a model to generate a complete system, accepting what appears, and deploying it without deep understanding of what it does.
Both happen. Both are called vibe coding.
The danger is not the approach. The danger is the assumption that generation equals understanding, and that a working prototype equals a reliable system.
The senior engineer using AI assistance is not vibe coding in the dangerous sense. They bring judgment to every commit. They know what the model got wrong. They know what to test.
The newer builder generating a full authentication system without understanding sessions, tokens, expiry, revocation, or storage is vibe coding in the dangerous sense - not because they are using AI, but because the gap between what was generated and what they can own is too wide.
The tool is not the problem. The accountability gap is the problem.
Why New Builders Can Now Ship
The democratization is real.
A designer with a product vision can now ship a functional web app. A domain expert with no programming background can now build a working internal tool. A founder can now produce a working prototype without hiring an engineer first. A researcher can now write scripts that process data without learning to code from scratch.
These builders can produce things that work. The models are good enough at generation that the basic plumbing often comes out functional on the first pass. The scaffolding runs. The endpoints respond. The UI renders.
That is not nothing.
The models have absorbed an enormous amount of code, documentation, patterns, and common structures. When a new builder describes a common task, the model has usually seen many versions of it. The result is often recognizable, often functional, and often better than what the builder could have produced alone in the same time.
This represents a genuine expansion of who can create software. That matters. Gatekeeping that expansion in the name of craft would be the wrong response.
The correct response is to be honest about what “working” means and what “reliable” requires.
Why Experienced Developers Underestimate The Shift
Many experienced engineers are skeptical of vibe coding because they see the failures up close.
They have reviewed the generated code and found the subtle bugs. They have seen the hallucinated API calls. They have inherited the prototype that worked until it had real users. They have watched someone deploy generated auth code with no understanding of what it was doing. They have cleaned up the AI slop.
That experience is valid.
But the skepticism sometimes overcorrects into dismissal.
The experienced developer grew up with a longer learning curve. The cost of entry shaped their career. Deep craft was the price of admission. It is hard to watch that price disappear without feeling that something important is being lost.
Something is changing. Craft still matters. Understanding still matters. Systems still break in the same ways.
But the on-ramp shortened dramatically, and the people on it are real, and some of the things they are building are real.
The right response from experienced engineers is not to protect the old moat. It is to be clear about what the moat was actually protecting: reliable systems, not just working ones.
Why New Builders Overestimate What The Machine Understands
The model produces confident output.
It does not hedge like a junior engineer. It does not ask for clarification like a careful colleague. It does not pause to say “I am not sure this is right.” It writes the code. The code runs. The builder assumes the model knew what it was doing.
That assumption is expensive.
The model does not understand the system. It understands patterns. It generates the most plausible continuation of the conversation, given the training data. That plausibility often aligns with correctness. It sometimes diverges from it in ways that look correct but are not.
The model does not know what the user’s production traffic looks like. It does not know the security assumptions the system depends on. It does not know the edge case that will hit in the third week after launch. It does not know which dependencies are about to break. It does not know the implicit contract between this service and the one that calls it.
The model knows patterns. The builder owns the system.
That distinction is the gap that new builders most often underestimate. The model can appear to understand the whole problem. That appearance is convincing. It is the same appearance that makes the output useful - and the same appearance that makes unchecked output dangerous.
The Difference Between Appearing And Reliable
A prototype can appear to work.
A reliable system works under the conditions it will actually face.
These are different properties. They often look identical at demo time. They diverge in production.
Appearance: the login endpoint accepts a username and password and returns a session token.
Reliable: the session token expires, can be revoked, is stored with appropriate security properties, is not logged in plain text, is not accepted after logout, is scoped to the right user, and handles concurrent sessions according to a deliberate policy.
A model will generate the first version. The first version may work in the demo. The gap between that and the reliable version is not code. It is judgment.
Who decided what the session lifetime should be? Who verified the storage behavior? Who tested the logout path? Who reviewed the scope? Who decided what happens when a second login arrives while the first is active?
These questions do not live in the code the model generated. They live in the decisions a person made - or failed to make - when reviewing what the model produced.
Vibe coding lowers the cost of getting to appearance.
The cost of getting from appearance to reliable has not changed.
What AI Can Do Well / What AI Cannot Own
The table below started as a build-time list, and the first eleven rows still are one. Cheap generation opened a second list too: what a live model can propose once it is running inside a shipped product, answering a request nobody is reviewing line by line. The same two columns hold for both.
| AI can do well | AI cannot own |
|---|---|
| Generate first drafts | Product responsibility |
| Explore alternative implementations | Commit authority |
| Write tests from described behavior | Judgment about sufficient test coverage |
| Summarize diffs and suggest review notes | Accountability for correctness |
| Draft documentation from code | Truth of the system |
| Produce boilerplate and scaffolding | Architectural decisions |
| Suggest fixes for described bugs | Verification that the fix is correct |
| Draft schema from examples | Validation that the schema is complete |
| Generate negative test cases from edge descriptions | Confirmation that the cases are realistic |
| Propose migration plans | Responsibility for data integrity |
| Summarize changed files for handoffs | Verification that the handoff is accurate |
| Interpret a request and propose an action or tool call | Permission for the action to execute |
| Draft a claim, citation, or public-facing sentence | Truth of the claim |
| Propose or explain a calculation | The authoritative numeric result |
| Propose a state change | The verdict that the change is legal |
| Narrate state in natural language | The state being narrated |
| Produce output that feels random or improvised | Ownership of actual, reproducible randomness |
The left column describes where AI provides leverage. The right column describes where a human, or a system standing in for one, cannot hand off accountability.
The failure mode is not using the left column. The failure mode is assuming the right column follows automatically - whether that means merging a patch nobody understood or letting a live model’s output reach a user because it sounded confident.
Vibe Coding Is The Entry. Engineering Discipline Is The Floor.
Vibe coding is not the destination.
It is the entry point for a generation of builders who now have access to software creation without the old prerequisites. That access is real and worth protecting. The cultural shift that made it possible is real and worth understanding.
But entry is not mastery. Generation is not ownership. Appearance is not reliability.
The builders who will create durable systems out of AI assistance are not the ones who generate the most. They are the ones who combine AI leverage with enough discipline to know what they are accepting into their systems.
That discipline does not require years of traditional software engineering. But it requires something.
It requires understanding that the model proposes and the person commits.
It requires a system where generation can be verified before it becomes state.
It requires the willingness to ask: what did this produce, what would break it, and am I actually willing to own this?
That question does not disappear once the software ships. It changes shape. At the keyboard, reviewing a diff before a merge, the person asking it is human. In a live product, the “someone” asking it on every request is a validator, a permission check, or a rules engine, because no one is watching that particular request in real time. The commit boundary moves - from Git, to a database write, to an executed action, to a published sentence - but the question does not: is there something other than the model’s confidence deciding what becomes real? Chapter 4 picks up that question where this chapter leaves it. Chapter 13 ties the development and runtime versions of the loop together.
Vibe coding is real.
The responsibility has always been real too.
The new question is whether the system is designed to catch what the model gets wrong - before the wrong thing becomes permanent, whether “permanent” means merged into the repo or executed against production.
Practical Artifact - Generation vs. Ownership Checklist
Use this checklist when reviewing AI-generated output before committing.
| Question | What it protects |
|---|---|
| Do I understand what this does? | Prevents opaque commits |
| Can I explain why it is structured this way? | Prevents blind acceptance of model preferences |
| Have I tested the behavior I care about? | Prevents appearance-only verification |
| Have I reviewed the edge cases? | Prevents happy-path-only coverage |
| Do I know what this fails on? | Prevents overconfident deployment |
| Is there a validator that would catch a regression? | Prevents silent drift |
| Have I removed anything the model added that I do not need? | Prevents scope creep from generation |
| If someone else takes this over, can they understand it? | Prevents tribal-knowledge dependencies |
| Am I willing to debug this at 2am? | Forces real ownership assessment |
The checklist is not a ritual. It is a forcing function for the question: do I actually own this commit, or did I just generate it?