What Is Vibe Coding? Software Built on the AI's Choices Instead of Yours

You are pitching your product. The investor asks how it works. You say you are not sure, and you offer to let them ask Claude. The room goes quiet, and the question that follows is the real one: who are we investing in, you or the model?

This post is about what that question is really asking, and why the answer matters even when the AI can explain your code better than you can.

Diligence on AI-built software now asks this directly. Whether anyone can explain the code is a line item, and the answer moves the price.

What is vibe coding, really?

Vibe coding is building software by describing what you want to an AI and accepting what it produces, without reading the code. Andrej Karpathy coined the term in February 2025 for a way of working where you "forget that the code even exists." It lets anyone build, and it hands every unmade decision to the model.

A month later, Simon Willison drew the line that most people still use.

EssayAuthor

Not all AI-assisted programming is vibe coding (but vibe coding rocks)

Simon Willison · 19 Mar 2025

If an LLM wrote the code for you, and you then reviewed it, tested it thoroughly and made sure you could explain how it works to someone else that’s not vibe coding, it’s software development.

Source: simonwillison.net. Reproduced verbatim; punctuation is the source's. Photo: Paul Downey, CC BY 2.0, via Wikimedia Commons.

It was a good test.^[1] Eighteen months later, the model passes the explanation part of it for you.

Ask it what the code does or how it works and you will usually get a clear, accurate answer. We covered the cost of that in why AI-built apps get harder to change, and it is real. But "you must understand it so you can explain it" is a weaker argument than it used to be.

Does it matter if the AI can explain your code?

It matters for one kind of question. The AI can tell you what the code does and how it works. It cannot tell you why it was built this way instead of another, because nobody chose. The model produced a likely answer, and any reason it gives afterward is a description of that answer.

You can test this yourself. Ask the model why it structured something a certain way, then start a fresh session and ask for the same feature again. If the structure changes and the new explanation sounds just as confident, the reason was never a reason.

That is the gap the investor was pointing at. A technical cofounder on the cap table has a point of view and stays. A model has defaults, and it gives your competitor the same ones.

Whose point of view is in your software?

Every piece of software carries the values of whoever made its decisions, the way a building or a poem does. If you did not make the decisions, the model did, and its point of view is the average of everything it learned from. That average is not neutral. It is measurable, and it is spreading.

Engineers have always known this about each other. One who values simplicity leaves different code than one who values coverage. One who trusts tests leaves a different shape than one who trusts types. That is what style has always meant in code.

A 2025 study of more than 20,000 GitHub repositories found human-written code drifting toward the conventions language models favor.^[2] One small, clean example: the share of Python functions named in the model's preferred style rose from 40.7 percent to 49.8 percent in two and a half years.

The same pull on code as on design

It is a small habit, and it is exactly the point. We made the same argument about interfaces in why AI design tools all look the same. Code is converging the same way. Most founders do not notice because they do not look at code.

The point of view that matters is yours

If you are a founder or a domain expert, the point of view that should be in your product is yours, not the engineer's. Why the intake form asks for this before that. Why the refund path holds for a day. Why the report rounds the way your industry rounds.

If those decisions are not in the product, it belongs to somebody else, however well it runs.

This is the same failure as handing a spec to an outside builder. The old handoff separated the person who knew the market from the people doing the building, and the product that came back did not carry what the expert knew. Solo vibe coding does it from the other side.

Can you write your point of view down instead?

Partly. A rules file for the AI, like CLAUDE.md or AGENTS.md, makes agents faster and cheaper to run. It does not appear to make them more correct. A point of view shows up in the choices you make as the work happens, and a file of preferences does not make those choices for you.

The sophisticated version of the argument is Owain Lewis's, and it deserves a fair hearing. His view is that you "encode your taste, your standards, your judgment into a system," so the craft moves "out of the code, into the rules that shape the code."^[3]

The efficiency half holds up, as we covered in what context files actually buy you. The correctness half does not.

A July 2026 study ran 288 tests of two coding agents on real repositories, with and without the repositories' own context files. The files did not measurably change correctness, because the agents failed on "feature design, pattern selection, exact wiring."^[4]

Pattern selection is a point of view, and it gets exercised one decision at a time.

Will vibe coding replace programmers?

It replaces the typing, which was never the job. In Anthropic's randomized trial of 52 engineers, how people used the AI mattered more than whether they used it. Those who delegated averaged under 40 percent on a comprehension quiz. Those who used it to ask conceptual questions averaged 65 percent or higher.

The headline result was that the AI group scored 50 percent against 67 percent for engineers who coded by hand, and finished only about two minutes faster.^[5] The finding that matters more for a founder sits inside the AI group. Same tool, same task, and a gap of more than 25 points depending on whether people asked why.

Read for point of view, the lesson is simple: the mode of asking decides whether understanding forms. "Does it matter that the AI can explain it?" becomes "what are you asking it?"

Why did writing the code stop meaning you understood it?

For most of software's history, writing code forced you to understand it at least once, so authorship was a fair stand-in for understanding. AI generation broke that link. The commit history still shows a name, but the name no longer tells you anyone understood the code.

Brett Wheeler's June 2026 paper makes the argument. It is a position paper with no dataset, so read it as a framing, not a finding.

Its core line is that the old inference "that authoring a region of code is evidence of understanding it" was, "for most of software's history," a "workable proxy," and that "AI code generation severs that inference at its root."^[6]

On August 28, Debian's developers voted a replacement into policy.^[7]

The top reaction on Hacker News read it as liability: it is still your code and you are responsible for it. That is true, and it is the smaller half. Understanding is also where the point of view gets in.

O'Connell was answering a 2025 podcast episode that billed Rick Rubin's view of vibe coding as "the punk rock of software."^[8] Punk's three chords were free to anyone, and what made a band worth hearing was never the chords.

What should a founder be able to say about their product?

A founder should be able to answer five questions about their product without opening a chat window. The model can carry the first two. The last three are yours, because they are about choices, and choices are where your point of view lives.

1. What does it do, in your customer's words?
2. How does it work, in shape rather than syntax?
3. Why is it built this way, and not another way?
4. What did you reject along the way?
5. What would you change first, and why that?

The fourth is the sharpest. The decisions that did not ship are the clearest record of a point of view, and a model has no rejected drafts it can tell you about.

None of this means founders should learn to read code. Founders have always handed off the how, to a cofounder or a team. What changed is that the how is now cheap and available to everyone, so the standard moved up to the why.

The investor was asking whether there is an author in the room. If you cannot say why your product is built the way it is, it is built the way the model would have built it for anyone, and that is what you are asking people to invest in.