Vibe Coding Is Cowboy Coding

No right answer to which stack to build on, just a hundred defensible ones. Vibe coding hands every one of those choices to a model that knows none of them. Andrej Karpathy, who meant it for the weekend. A spectrum, not a category. A founder with the keys to the kingdom, and a team watching in despair. The discipline being written against it has a name.

People often ask me which stack they should build on, and I always tell them the same thing: there is no right answer to that question. It depends. It depends on how well the stack fits the project. Flutter belongs in a mobile-first, web-second project. It is the wrong call elsewhere. It depends at least as much on the team: their skills, their instincts, what they already reach for without thinking. You do not point a team with Node.js in their sights at Ruby on Rails and expect them to thank you for it. There are hundreds of stacks and thousands of defensible reasons to choose between them, and a good engineering decision is the one that weighs those reasons honestly.

Vibe coding, at its bitter heart, hands every one of those decisions to an LLM that has none of that context. There may be nothing wrong with what it picks. There may be nothing right about it either. You get what you ask for, which was the whole argument of Chapter 4, and if you ask for nothing in particular you get whatever the model happened to settle on. That is vibe coding: not really a tool, more the quiet surrender of the decisions to something that does not know your team, your project, or what you are actually trying to build.

Andrej Karpathy gave the thing its name in early 2025.

There’s a new kind of coding I call vibe coding, where you fully give in to the vibes … and forget that the code even exists.

You prompt, you accept, you run it, and if it works you move on. Karpathy was describing weekend projects, throwaway things you will never have to maintain, and for that he was right. For a Saturday prototype that gets deleted on Sunday, reading the code would be a waste of the Saturday. In Chapter 1 I called this way of working the slot machine, the version of AI you pull rather than the instrument you play.

I want to be more exact about it now. Vibe coding is not really a category of work, it is a spectrum, and the measure along that spectrum is how much of what you are getting you actually understand and control. Own the decisions that matter, the stack and the architecture and the trade-offs between them, and you are doing professional AI development whatever tool you happen to be holding. Let those decisions drift out of your hands and into the model’s, and you slide towards vibe coding. The honest question is rarely whether you are vibe coding. It is how far along that line you have let yourself drift.

There is nothing new about it, either. We have done this before, under an older and less flattering name.

The cowboy

Before Agile, before Beck, there was cowboy coding. It was never a compliment. The cowboy worked alone and on instinct, kept the whole design in his own head, shipped when it felt right, and left no trail behind him. It often worked, which was the dangerous part, because a clever cowboy could outrun a careful team right up until the moment the work outgrew one person’s memory. The second engineer to touch the code could not. The original author had left, and the why had only ever lived in one head. This was the era before Git, when Subversion was the best most teams had and a surprising number of teams used no source control at all. Code was a zip file with a date in the name. I had more run-ins than I can count with cowboys who saw no reason to use a version manager. Unthinkable now.

Kent Beck’s Extreme Programming Explained was, among other things, the discipline written to retire the cowboy from serious software. Pair programming, so no design lived in only one head; tests, so the reasons were written down in a form a machine could check; short iterations and continuous integration, so that nothing accumulated in the dark. Vibe coding is the same instinct in new clothes, with one difference that ought to worry us more than it does. The head holding all the reasons is no longer even human. The small decisions live inside an agent’s run, which is to say they live nowhere, because the next conversation begins from a clean slate.

Shipping is not building

This is the fork the chapter is named for. Vibe coding wants to ship something; professional engineering wants to build something. On the first day the two are indistinguishable, because both produce running software, and the vibe-coded version often arrives first. They come apart on the second day, and on every day after it. Shipping asks only whether the thing runs now. Building asks whether anyone can change it later, and that second question is what the whole of this discipline is organised around.

This is why the speed argument for working loosely is a mirage. A vibe-coded feature is never actually faster. Its cost is front-loaded, moved quietly onto a later date and usually a different person, and presented to you in the moment as a saving. What feels like a week saved tends to cost a fortnight a few weeks on. On a larger system, built this way for a year, the bill does not come in fortnights.

When a vibe coder walks into someone else’s codebase

Almost everything I have said so far assumes a new build, and there I want to be fair. If you are spinning up a prototype you fully intend to throw away, vibe coding is not a sin, it is the right tool, exactly as Karpathy meant it. The danger begins the moment the prototype stops being a prototype. Someone demos it, someone important likes it, and the throwaway code quietly becomes the foundation of a product nobody ever decided to build properly. What worked for a weekend is now load-bearing, and no one chose for it to be.

The worse case is not a new project at all. It is a vibe coder let loose inside an existing one. This is happening everywhere now, because the roles have all moved about. A product manager, tired of waiting on an engineering estimate that lands somewhere next year, decides to vibe the feature himself. He does not really know the codebase, but the agent appears to, and within a few days the feature exists, ships, and lands inside a system whose constraints he could not have named.

It is worse still when the person doing it has seniority. The business-minded founder who finally has the keys to the kingdom she always wanted. The engineering team she hired looking on in genuine despair, or quietly working out whether they are still needed now that coding has become a group sport. I see it all over the place, and I am torn about it. I am genuinely in favour of the democratisation of coding. I am not in favour of it arriving at the expense of professionalism, and I will not pretend it is a compliment to the craft when it is so often the opposite.

Why it pays you now and bills you later

It feels fast because the reward is immediate and the cost is deferred, which is the design of more or less every habit that is bad for us. You prompt, you accept, you ship, and something exists that did not exist sixty seconds ago. That is a genuinely lovely feeling, and I have had it many times. The danger is that the loop teaches you to value the appearance of progress over the fact of it. A team that runs on it for a few months wakes up owning a codebase it cannot reason about, full of decisions nobody recalls making, because in the meaningful sense nobody did.

Ani Khandelwal put the mechanism more sharply than I have managed to:

AI doesn’t remove thinking; it amplifies whatever level of thinking you bring. Vibe coding might ship faster today, but it compounds technical debt tomorrow. The real edge is still structured thinking and clear intent.

A debt you decide to take on is a loan you can plan around. A debt you never noticed yourself taking on accrues quietly, against code no one read, until the interest arrives all at once and usually at the worst possible moment.

There is a quieter cost folded into the same habit. The teams most drawn to vibe coding tend to be the ones that have already stopped hiring juniors, and the two facts reinforce each other. A senior who never has to explain a decision to another person never has to bring anyone up behind them, and the craft that used to pass from one engineer to the next stops being said out loud. The codebase nobody can read and the profession that stops restocking itself are the same problem viewed from two distances.

None of this is an argument against the agent. It is the most remarkable instrument any of us has been handed, and the answer is not to use it less but to use it well. The discipline being written against vibe coding has a name people are starting to use: spec-driven development. The premise is small and stubborn. Write the spec before the code, and treat the spec as the thing both the human and the agent serve.

The idea is not new. Earlier attempts ran under names like formal specification, contract-first design and model-driven development, and most teams found them too heavy to sustain. What is new is that there is now something at the other end of the spec that actually wants the precision. The current burst of interest in specs as the contract between a human and an agent, most visibly GitHub’s Spec Kit, points at the same instinct. The honest critique of where that work has landed so far is that it has fixated on the specification half and left the verification half largely untouched, and a spec that nobody checks the output against is in the end just a more articulate prompt.

The spec is only the first beat of it. The shape of professional AI-first work is a closed loop with three deliberate steps: you specify what you want, the agent builds it, and you verify that what came back is what you asked for. On a team running half a dozen agents in parallel that loop has to close itself automatically, because nobody manages a cycle of that shape by hand for long. The human sits in the middle of it, setting the intent at the start, judging the output at the end, and owning the decisions that matter across the whole thing. The agent is the instrument the loop runs on, and the loop is what makes the instrument useful in something more serious than a Saturday.

Do that, and the surrender stops being the default.

There are two tracks running in parallel here. The methodology track is what almost every chapter that follows is about: how a team reorganises itself when the developer is not always a person, where the human’s judgment is most needed once the implementation is the agent’s, which of the ceremonies survive and which retire. That is the part you can read your way into. The other track is technology. The loop I have just described, with its specification, its build and its verification, only holds if there is a harness around the agent strong enough to enforce it: insisting on the spec before the work begins, holding the agent to the established rules (standards), and checking the output against the spec when the work is done. That kind of tooling has not really existed before, in part because nothing before now needed it. It is the second track, and it is why we are building Memex.AI alongside writing these essays.

Barrie

The rest of this book is what that actually looks like in practice. Flagging the obvious: this is the part of the thesis we are building a product around, and Memex AI is going into open source as a harness for coding agents on roughly the same timetable as the book. I will keep writing whether you ever try it or not. The shape of the work is the shape of the work, whatever harness you reach for.