The Art of Vibe Coding

What Is Vibe Coding?

On the practice of collaborating with an artificial mind to build software.

Vibe coding is the practice of building software in continuous dialogue with an AI assistant — describing intent in natural language, letting the model generate, then steering, refining, and verifying the result. The term was coined informally to describe a mode of work in which the human sets vibe and direction while the machine handles much of the keystroke-level production.

It is not, as the name might suggest, an excuse for sloppiness. The best vibe coders are more disciplined, not less, than traditional engineers. The AI is fast but credulous; it will happily produce a confidently-wrong answer, hard-code a secret, or grow a file to two thousand lines because it has no instinct for restraint. Your job is to supply that instinct.

Think of yourself as a director rather than a typist. You are still responsible for the architecture, the correctness, and — above all — the consequences. The AI is a remarkably capable collaborator, but it is a collaborator, not an oracle.

The Vibe Coder Mindset

Attitudes and dispositions that distinguish the practitioner from the dabbler.

Before any technique, there is a posture. Vibe coding is less a set of tricks than a way of relating to the machine — one part patient teacher, one part skeptical reviewer, one part curious experimenter. Internalize these dispositions and the rest of the manual will feel like common sense.

The Instruments of the Trade

A survey of the major AI-assisted coding tools, and when each is the right choice.

The landscape evolves quickly, but the major categories are stable. A serious practitioner keeps at least two of these in active rotation — one as a primary, one as a sanity check.

Plan Before You Code

The discipline of thinking in phases — and why it pays off twice.

The single greatest difference between a productive vibe coding session and a frustrating one is whether you took fifteen minutes to plan. Without a plan the AI will produce something — it always does — but the something will rarely be what you wanted, and the cost of redirection grows with every line written.

A plan does not need to be a document. It can be a numbered list in a scratch file, a CLAUDE.md, or a conversation with the model in which you ask it to help you plan before generating a single line of production code.

Tech Stack & Coding Standards

Why your first ten files set the tone for every file that follows.

AI models are pattern-matching engines. Whatever style they encounter in your codebase early, they will reproduce — amplify, even — in every subsequent file. This means two things: pick a tech stack the model knows well, and review the first few outputs with surgical care.

Security Best Practices

On the things the AI will cheerfully do that you must absolutely prevent.

Of all the categories in this manual, this is the one where a single oversight has the largest blast radius. AI models, left unsupervised, will hard-code secrets, log sensitive data, write unsanitized SQL, and leave authentication as an exercise for the reader. They do these things not from malice but from helpfulness — they want to make the example runnable.

The Art of Prompting

Composing requests that the model can actually fulfill.

If planning is the strategy of vibe coding, prompting is its tactics. A well-formed prompt eliminates a class of failure modes before they occur. A vague one invites the model to fill in your unstated assumptions with its own — usually badly.

Managing Context

On knowing what the model knows — and what it has forgotten.

Context is the working memory of the model. It is finite, expensive, and easily polluted. Managing it deliberately is one of the highest-leverage skills in vibe coding. Most session-long frustrations — the model contradicting itself, repeating earlier mistakes, forgetting which file you are in — are context-management failures.

Debugging With AI

The model is a powerful debugger — provided you do not accept fixes you do not understand.

Debugging is where vibe coding can either save you hours or quietly accumulate technical debt that detonates later. The model is genuinely good at reading stack traces, hypothesizing causes, and proposing fixes. It is also good at making symptoms go away without addressing causes — and that is the trap.

Mastering Version Control

Git is the safety net beneath the trapeze. Use it lavishly.

The pace of AI-assisted coding makes traditional Git hygiene more important, not less. The model can produce a hundred lines in a minute; if any of those lines are bad, you need to know exactly which working state you were in before. Git is the only mechanism that lets you experiment fearlessly.

Testing as a Practice

The most underused superpower of AI-assisted coding.

Left to its defaults, an AI agent will write code first and tests later, if at all. This is precisely backwards for the kind of fast, iterative editing that vibe coding encourages. Tests are not bureaucracy — they are the only way to know, at velocity, that you have not just broken something.

Putting It All Together

A worked workflow for a single feature, from intent to deployment.

The chapters above can read like a checklist. In practice, they compose into a rhythm. Here is one such rhythm — not the only one, but a good default for serious work.

Read this manual again in a month. The parts that seemed obvious will have become muscle memory; the parts that seemed fussy will be the ones you wish you had adopted earlier. The medium is new, but the underlying craft — taste, discipline, skepticism, curiosity — is the same one engineers have always practiced. The AI does not replace it. It rewards it.

Architecture & System Design

On using the AI as a sounding board rather than an oracle.

Architecture is the set of decisions that are expensive to change later. Pick the wrong web framework and you swap it in a week; pick the wrong data store and you fight it for a year. These are precisely the decisions where the AI's confident, fluent prose is most dangerous — because the model has no skin in the game when the consequences arrive eighteen months from now.

Treat architectural questions as conversations with the AI, not as requests. Force the model to enumerate options, weigh trade-offs, identify failure modes. Then make the decision yourself, write it down, and version-control that decision so the team — including future you — can remember why.

Reviewing AI-Generated Code

The diff discipline that separates a prototype from a product.

The model produces code that looks right. Looking-right is not the same as being-right. The single most important discipline in serious vibe coding — harder than prompting, harder than planning — is to actually read every line the AI proposes, with the same scrutiny you would bring to a stranger's pull request. The cost of skimming compounds invisibly. By the time you notice the bug, it is wearing camouflage from a dozen subsequent edits.

Skim is your enemy. The AI will produce a 200-line diff in ten seconds; if you scan it in thirty, you will catch only what is obviously broken. The subtle problems — a swallowed exception, a fabricated library function, a unit test that asserts nothing meaningful — pass through. These are not edge cases. They are the dominant failure mode of unsupervised AI coding.

Documentation as Infrastructure

The half of the codebase that everyone forgets.

Documentation is the part of a serious software product that is invisible until it is missing — at which point everything else slows down by a factor of three. A teammate joining the project, an on-call engineer at two in the morning, a future version of yourself revisiting code from six months ago: each of these consumers depends on documentation no one was paid to write.

The AI changes this economy entirely. Documentation is now nearly free to produce — provided you ask. A README that gets a new contributor running in ten minutes, an ADR for each significant decision, an API reference generated from the code: minutes of work, not days. What remains is purely a matter of discipline.

Error Handling & Resilience

On the failure modes the AI will hide if you let it.

The model has a strong default: make the example runnable. This default is at war with serious error handling. Left to its instincts, the AI will wrap risky code in bare try/except blocks that swallow exceptions silently, return None on failure, or — worse — print a friendly message and continue as if nothing had happened. Each of these patterns transforms a recoverable error into an invisible bug.

Resilient code distinguishes among three categories of error: those it can handle locally, those it should propagate, and those that indicate a violated invariant and warrant a controlled crash. The AI will not make these distinctions unless you make them explicit.

Observability

You cannot fix what you cannot see.

A serious software product must be inspectable from outside. When something goes wrong — and something always does — your ability to diagnose without rebuilding, redeploying, or re-running depends entirely on what the system was emitting at the time. Observability is not glamorous. It is what makes two in the morning survivable.

The AI is helpful here but tends to under-instrument: a print statement here, a log line there, no structure, no levels, no correlation IDs. Production-grade observability has to be specified up front, or it will never appear at all.

Performance & Profiling

On measuring before optimizing — and the AI's enthusiasm for the reverse.

The model is eager to optimize. Ask it to make code faster and it will produce a confident diff with no measurements behind it. Some of those diffs are correct. Some are noise. A few are net-negative. Without a baseline, you cannot tell which.

The discipline of performance work is unromantic: measure, hypothesize, change, measure again. The AI can accelerate each step, but it cannot replace the measurement. A "faster" function without a benchmark is a guess in a fluent voice.

Dependencies & Supply Chain

Every import is a long-term relationship.

The AI loves dependencies. Ask it to parse a CSV and it reaches for pandas; ask for a date and dateutil appears; ask for HTTP retries and a new library is suggested. Each of these is a long-term relationship — with maintenance burden, security exposure, license obligations, and upgrade pain — that has been negotiated on your behalf in a tenth of a second.

A serious software product has a deliberate dependency posture. The standard library is preferred when reasonable. New dependencies are added only after the alternatives have been considered. The supply chain is audited, locked, and monitored.

Data, Schemas & Migrations

Database changes are forever. Treat them accordingly.

Code can be rolled back. Data, with very few exceptions, cannot. A bad schema change applied in production becomes a permanent feature of your system, and every subsequent decision must accommodate it. This asymmetry deserves a level of caution that the AI, by default, does not bring.

Migrations should be small, reversible, and reviewed by a human who understands the production state. The AI is excellent at writing the migration; it is not the right party to decide whether to apply it.

CI/CD & Automation

The pipeline is the guard rail of the production system.

Continuous integration is the smallest unit of trust in a serious software product. Every commit is asked: do you compile, do you pass tests, do you satisfy our standards? Code that cannot answer yes does not advance. This is not bureaucracy — it is the only mechanism that makes velocity safe.

The AI writes CI configurations, GitHub Actions workflows, Dockerfiles, and deployment scripts with fluency. What it cannot do is understand your specific operational context — your secret management, your compliance constraints, your existing tooling. Review accordingly.

Release Engineering

How serious software gets to users without breaking them.

A deploy is a moment of risk. Even a perfectly written change, applied to a healthy system, can interact with production conditions — load patterns, data shapes, dependency versions — that no test environment fully captures. The serious practice of release engineering treats every deploy as an experiment that could fail, and provides the means to detect and recover quickly when it does.

The AI can help draft feature flag scaffolding, canary configurations, and rollback scripts. The judgment of when to ship, how fast to ramp, and when to halt remains stubbornly human.

Working With Legacy Code

On the vast majority of real engineering work.

The romantic image of vibe coding — a developer and an AI conjuring a system from a blank repository — accounts for perhaps a tenth of professional software work. The other nine-tenths is brownfield: adding a feature to a fifteen-year-old codebase, fixing a bug in a service no one understands, refactoring a module written by someone who left the company. The AI is enormously useful here, in different ways than in greenfield work.

Use the model first to understand, then to change. Understanding-before-changing is the difference between a careful surgeon and an enthusiastic intern.

Team Collaboration in the AI Era

On working with humans who are also working with machines.

A single developer with an AI assistant is a manageable system. A team of developers, each with their own AI assistant, is a different system entirely. Conventions diverge. Quality variance widens. Review burden shifts. The interpersonal contract of "we will all do approximately the same thing in approximately the same way" can quietly dissolve into incompatible styles, each one internally consistent.

The remedy is not less AI; it is more shared scaffolding. Conventions move into the repository. Prompts become team assets. Review becomes more important, not less.

The Long Life of Software

Software outlives its writers. Plan for it.

A serious software product is not the version that ships on day one. It is the system that, three years later, is still running, still being modified, still being depended upon. Most of the cost of software is in this long tail. Most of the AI advantage shows up at the start.

To build software that lives long, build for the people who will maintain it — including future-you, who will have forgotten everything. This requires a kind of discipline that is unrewarded in the short term and indispensable in the long one.

AI Tool Orchestration

On choosing models, calling tools, and composing agents.

Early vibe coding was one human, one model, one chat. The mature practice is a small symphony: a powerful model for hard reasoning, a cheaper one for boilerplate, an agent that can run shell commands, sub-agents that work in parallel on isolated contexts, and MCP servers that grant the assistant access to your databases, file systems, browsers, or calendars. Composition is now its own skill.

The right composition depends on the task. A long refactor wants a capable model with a generous context window and shell access. A quick autocomplete wants a fast, cheap model in your editor. A research task wants a model that can browse, plus sub-agents to parallelize. Match the instrument to the work.

API & Contract Design

On the parts of your software that other people's software depends on.

APIs are contracts. Once published, they constrain what you can change without breaking your consumers — whether those consumers are other teams, paying customers, or future versions of yourself. The AI will gladly write an API; it has no instinct for the long-term consequences of doing so casually.

Treat every endpoint, every event schema, every gRPC service definition as a versionable artifact with explicit compatibility guarantees. The AI is useful for drafting, testing, and generating client SDKs. It is not the right party to decide what to commit to.

Authentication & Authorization

On who can do what, and the AI's enthusiasm for skipping the question.

AuthN — who you are — and AuthZ — what you are allowed to do — are the two questions every real product must answer correctly for every request. The AI, in its eagerness to produce runnable examples, will gladly generate code that skips both: handing the prototype to you with a TODO where the auth check should be, or implementing auth so naively that it would not survive five minutes of adversarial scrutiny.

Authorization in particular is not a feature you add later. The shape of your permission model is one of the most consequential architectural decisions you will make. Get it right early; bolted-on auth is a permanent source of pain.

Compliance, Privacy & Regulated Software

When the law has opinions about your code.

A serious software product often operates in a regulated environment — GDPR for data handling, HIPAA for health, SOC 2 for enterprise customers, PCI-DSS for payments, ISO 26262 or DO-178C for safety-critical systems. These are not abstract documents. They impose specific requirements on what your code must do, what records you must keep, and what processes you must follow to be allowed to ship.

The AI is unaware of your regulatory context. It will not flag that the PII you just logged is reportable; it will not refuse to write code that stores credit card numbers; it will not insist on the audit trail your regulator expects. That awareness must come from you and from the conventions you encode.

Provenance, Licensing & IP

On where the code came from, and who owns it.

AI-generated code occupies a peculiar legal space. The model was trained on millions of repositories under thousands of licenses. The code it produces is, in most jurisdictions and most providers' terms, yours to use — but the exact contours are evolving, uneven across jurisdictions, providers, and use cases, and not always what intuition would suggest.

For serious products, AI output cannot be treated as identical to human output. There are practical, hygienic steps that protect the project without slowing it down meaningfully.

Accessibility & Internationalization

Two domains the AI defaults to neglecting.

A product that does not work for users with screen readers is broken. A product that displays 1,234.56 to a German user who needs 1.234,56 is broken. A product whose interactive elements have no keyboard handlers is broken. These are not edge cases. They are categories of users and contexts that the AI, optimizing for what looks reasonable in a demo, will quietly fail to serve.

Accessibility (a11y) and internationalization (i18n) are not the polish at the end. They are constraints on architecture from the beginning. Retrofitting either is dramatically more expensive than getting it right the first time.

Specialized Domains: ML, Data & Embedded

Three places vibe coding looks different from web work.

Most of this manual has implicitly assumed conventional software: web services, data pipelines, command-line tools. The principles still apply elsewhere — but the texture changes substantially in three domains worth calling out.

Building Your Own Tools & Skills

On the small automations that compound.

The most productive vibe coders eventually start building their own tools — small MCP servers that expose internal APIs to the assistant, reusable skills that encode common workflows, slash-commands that compress a multi-step procedure into a single invocation. This is leverage on leverage. A skill built once saves time on every subsequent session that uses it.

Start with the workflows you find yourself repeating. If you have explained the same project layout to the AI three times this week, that explanation belongs in CLAUDE.md. If you have walked the model through the same testing procedure repeatedly, that procedure belongs in a skill or a script.

The Limits of Vibe Coding

On knowing when the AI is a hindrance — and turning it off.

This manual has spent thirty-three chapters on how to use AI to write software well. It would be incomplete without a chapter on when not to use it at all.

The AI is a hindrance when the problem is novel enough that the model will pattern-match to something superficially similar and steer you wrong. It is a hindrance when the constraint that matters cannot be expressed in code — when you need to argue, persuade, or feel your way to an answer. It is a hindrance when learning is the point — when you need the difficulty of solving the problem yourself in order to be able to solve the next one. It is a hindrance when the cost of a confidently-wrong answer exceeds the cost of being slow.

Mature practitioners notice these moments. They close the chat, open a blank file, and think.

Hiring & Interviewing in the AI Era

On finding people who will still be valuable when the AI is even better.

The technical interview was already an imperfect filter for engineering ability. The AI has made many traditional questions almost useless. A candidate's ability to produce a working solution to a familiar problem now reveals very little about their judgment, taste, or capacity to grow. Worse, the easiest interview questions to write — the ones that test syntax, algorithms, and pattern matching — are precisely the ones the AI can solve in seconds.

The mature practice is to interview for the skills the AI does not replicate: clear thinking under uncertainty, the willingness to question requirements, debugging from incomplete information, communication, taste in design choices. None of these are easy to assess. All of them matter more than they did before.

Onboarding & Mentorship

On the first thirty days, and what they should leave behind.

A new engineer joining a team in the AI era faces an unusual challenge: the tools will make them productive almost immediately, before they have built any of the context that would make their work durably correct. They will ship code in their first week. Whether that code is genuinely good or merely runs is a question the team's onboarding determines.

The remedy is not less AI. It is more deliberate scaffolding around it: shared conventions, explicit pair-vibing, structured review, and a clear sequence of small wins that build context before they require it.

The Junior Engineer's Path

On developing taste when the AI does the typing.

A junior engineer in this era inhabits a peculiar professional moment. The barrier to producing working code is lower than ever. The ceiling on what they can accomplish in a week is dramatically higher. And yet: the path to becoming a senior engineer — the kind whose judgment can be trusted on important decisions — appears to require something the AI has made optional, namely the slow accumulation of taste from a thousand small struggles.

This is real. It is also addressable. Junior engineers who consciously preserve struggle in their practice will arrive at senior judgment on roughly traditional timelines. Junior engineers who outsource all struggle will arrive somewhere else, and the somewhere is not where the senior jobs will be.

Working With Non-Engineers

On PMs, designers, executives, and the AI mythology they have absorbed.

Non-engineers have been told a great deal about what AI can do. Some of it is true. Much of it is wishful, distorted by enthusiastic sales pitches and confident demos. Working effectively with stakeholders now requires gentle, repeated, accurate communication about what is and is not possible — and a willingness to push back on demands premised on the wishful version.

The defining sentence of stakeholder management in this era is "but ChatGPT can do this in five minutes." Sometimes it can. More often it can produce something that looks like the thing in five minutes, which is not the same. Distinguishing these two cases, and explaining the distinction without condescension, is now part of the job.

AI Ethics & Responsibility

On the questions the model will not ask for you.

The AI does not ask whether you should build the thing. It builds. This is convenient. It is also a transfer of responsibility you must consciously decline to accept.

Every piece of software embeds choices: what data to collect, what to surveil, what to optimize for, whose interests to serve, what risks to externalize. The AI accelerates the construction of these choices without raising any of them. The engineer remains the only party who can. The reduction in friction makes the asking more important, not less.

This chapter cannot tell you what is right. It can only argue that you must ask.

A Personal Practice

On the daily disciplines that compound over decades.

The technical practices in this book are useful. The deeper practices — the ones that sustain a career — are different in kind. They concern attention, reflection, deliberate practice, and the small habits that distinguish an engineer who improves from one who merely accumulates years.

What follows is not prescriptive. It is one practitioner's set of disciplines, offered as a starting point. The right shape of a personal practice is one you will arrive at through experimentation. The wrong shape is the absence of one.

The Engineering Career, in Long Perspective

On what to invest in, when investments are uncertain.

A career in software has always involved betting on which skills would matter. The bet is harder now: the AI is reshaping the value of individual skills faster than careers can be planned. Some skills are appreciating; others are quietly depreciating. The challenge is to invest in the appreciating ones without abandoning the depreciating ones too soon.

A general thesis: skills that are easy to articulate but hard to acquire — judgment, taste, communication, debugging from incomplete information, system design under uncertainty — are appreciating. Skills that are easy to acquire but tedious to apply — boilerplate, mechanical refactoring, syntax memorization — are depreciating. The middle band is uncertain, and the prudent practitioner watches it carefully.

The Healthy AI-Native Team

On building together with humans and machines.

A team is more than the sum of its engineers. The norms, rituals, and shared understandings that develop within a team can make ordinary engineers excellent and excellent ones great. The opposite is also true. The arrival of pervasive AI has stressed many of these norms, often invisibly. A healthy team in this era is one that has consciously rebuilt its norms for the new conditions.

There is no single template. But there are patterns visible in the teams that are thriving, and patterns visible in those that are quietly degrading. This final chapter sketches both.

The Discipline of Production

Where the four books meet.

The four books of this manual describe the same craft from four angles. Book the First taught the day-to-day rhythms of working with an AI: planning, prompting, debugging, testing, committing. Book the Second described the disciplines that turn those rhythms into a serious product: architecture, documentation, error handling, observability, release engineering, the long life of software. Book the Third turned outward — to APIs, auth, compliance, accessibility, specialized domains, the tools you build for yourself, and the limits beyond which the AI ceases to help. Book the Fourth turned inward — to the practitioner: how engineers are hired and mentored, how juniors develop, how to think clearly about ethical weight, what makes a healthy team and a healthy career.

In practice all four are inseparable. Every prompt is an architectural choice. Every test is documentation. Every deploy is a release decision. Every hire is a vote about what kind of team this will become. Every commit is a small statement about what you believe good engineering looks like. The disciplined practitioner does not pick between "moving fast" and "moving carefully." They notice that careful is the only kind of fast that lasts.

The AI does not change what good engineering is. It changes only the cost of the components — making the easy parts trivial, and exposing more sharply the parts that were never easy. Architecture, judgment, taste, accountability, craft, mentorship, ethics, and the wisdom to know when to set the machine aside: these were always the work. They still are.

A Note to the Future Reader

For the practitioner reading this years from now.

This manual was written in mid-2026, when the tools were one shape; by the time you read it they will be another. The specific models will be replaced. The IDE integrations will look different. New categories of tooling will exist that this book does not name. Some of what is written here will read as quaint — the way early notes on version control read today, written when "commit" still felt like a daring verb.

The specifics will date. The principles, I hope, will not.

Software engineering has always rewarded clear thinking, disciplined practice, and humility before the consequences of what we build. The AI did not change that, and the AI's successors will not change it either. They only change the pace at which the consequences arrive, and which parts of the work demand the most attention. The work itself — designing, deciding, building, maintaining, and being accountable for systems that other people depend on — is older than any of our tools and will outlast them.

If you are reading this in a moment when some new instrument has just arrived and the discourse insists that everything has changed: it has not. Read the new instrument carefully. Find what it makes cheap, and what it makes obvious. Bring the same disciplines to bear. Build things that work, that last, and that you are proud to have made.

A Prompt Library

Reusable instruments for the daily practice.

A small collection of prompts that have earned their keep. Adapt them to your stack, your project, and your tone. Each one assumes you have already established context in the session — they are tools, not opening lines.

An Anti-Patterns Catalog

Named failure modes of unsupervised vibe coding.

Anti-patterns are easier to avoid once they have names. The twelve below appear repeatedly in real codebases produced under AI assistance. If you can recognize them in a diff — yours or a teammate's — you have already done most of the work of preventing them.

A Production Readiness Checklist

For the day before — and the day of — going to production.

A checklist is not a substitute for judgment. It is a substitute for the parts of your judgment that you would otherwise forget at three in the morning. Adapt this to your context; treat unchecked items as conversations to have, not boxes to dismiss.

A Glossary

Terms used throughout the four books.

Brief definitions, in the spirit of a working reference rather than an exhaustive dictionary. Where a term has multiple senses, the definition reflects the sense used in this manual.

A Bibliography

Books and works that have shaped the practice described here.

A curated, not exhaustive, list. The works below have stood up to multiple re-readings and continue to repay attention. Few are about AI-assisted development directly; nearly all are about the older disciplines that the new tools amplify rather than replace.

Three Worked Examples

The practice, end to end, in three realistic scenarios.

These three examples sketch the practice in three modes most engineers spend most of their time in: greenfield, brownfield, and operational. They are compressed; the actual sessions took longer and contained more dead ends than any narrative can show. Read for the rhythm, not the line count.