What is vibe coding?

The term arrived in early 2025 as a half-joke and stuck because it named something people were already doing. It is worth defining precisely, because the precision is where the ownership question lives.

What the term means

Vibe coding is building software by telling a model what you want, accepting what it produces, running it, and telling the model what went wrong. Repeat until it works. The defining feature is not the use of a model; it is not reading the code. You steer by outcome, not by inspection.

That is different from using an AI assistant as a faster pair of hands, where the developer reads every line and remains the author in every sense that matters. Same tools, different relationship to the output. The distinction sounds pedantic until you get to who owns the result.

Why it works

Because for a large class of software, the outcome is all anyone cares about. A script to rename files. A prototype to show a stakeholder. An internal tool with one user. A weekend project. If it does the thing, it has done its job, and reading the code would be a cost with no return.

It also works because models are good at exactly this kind of code. Small, self-contained, shaped like the millions of examples they were trained on. The training data was public code, which skews towards precisely the demonstrations and utilities that vibe coding produces.

Where it fails

Where the outcome cannot be checked by running it once. Security. Concurrency. Data integrity. Anything where “it worked when I tried it” is not evidence of correctness.

Where the code has to be maintained by someone. A codebase nobody has read is a codebase nobody understands, and understanding is what maintenance requires. This is the point at which vibe-coded projects tend to get rewritten by a person, or abandoned.

And where the code has to be owned. Which is the rest of this page.

┌─ WORTH CHECKING ─────────────────────────────────────────────────────┐
│                                                                      │
│  Private, finished, owned by you: $500+ each to AI labs.             │
│                                                                      │
│  [ See what my repos are worth ]                                     │
│                                                                      │
└──────────────────────────────────────────────────────────────────────┘

Who owns it

Three separate questions that get run together.

who owns vibe-coded code?
  │
  ├── you vs the tool provider ─► usually you, per the terms
  │
  ├── copyright ────────────────► maybe nobody, if no human authored it
  │
  └── licensing ────────────────► only what you can warrant is yours

You versus the provider. The tool’s terms of service govern this. Most current terms assign any interest in output to the user, or disclaim it. So the provider is not going to claim your code. This is the easy question and the one people think is the whole question.

Copyright. Harder. Copyright requires a human author. The US Copyright Office’s stated position is that output generated entirely by a model, with no human creative contribution, is not protectable by anyone. Prompts alone are generally not considered enough. Code where a person made real creative choices, in writing, selecting, arranging, or substantially editing, can be protected, to the extent of that contribution.

So a repository built by reading nothing and accepting everything may be a repository nobody holds copyright in. Not the provider, not you. It is not that someone else owns it. It is that the thing ownership attaches to may not exist. What copyright does and does not attach to is covered in is code protected by copyright.

Licensing. You can license only what you own or hold rights in, and when you license code to anyone you warrant that. For licensing to AI labs, that warranty is uncapped and buyers rely on it. Offering a repository whose copyright status is genuinely uncertain is offering something you may not be able to stand behind.

The practical position

Most real repositories are mixed. A developer used a model heavily, read some of what it produced, rewrote parts, structured the whole, and made the decisions that matter. That is human authorship with assistance, and it is on ordinary footing.

A repository that is almost entirely generated, unread, and unedited is the hard case. Be conservative about claiming to own it. Be more conservative about licensing it.

The record of how the code was made helps here, and it is another reason not to tidy your history. A commit log showing a person iterating, reverting, restructuring, and deciding is evidence of authorship that a single squashed commit is not. Why that record matters for other reasons too is in should you squash commits.

What it means for the profession

Less than the term’s popularity suggests. Vibe coding compresses the part of the job that was already being compressed: turning a clear intention into working syntax. It does nothing for the parts that were never about syntax: knowing what to build, knowing when a requirement is wrong, owning a system in production, and maintaining code whose context lives in people rather than files.

Those are the parts that pay, and demand for them has gone up, because there is now more code in the world to have judgement about. The longer argument is in will AI replace programmers.

One irony worth noticing. The models doing the vibe coding were trained on code that humans wrote, read, and owned. They need more of it, specifically the kind that was never published, because the public supply is exhausted and skewed towards the demonstrations that vibe coding is good at reproducing. The archive of code a working developer actually wrote over a career has become an asset for exactly that reason. What qualifies, and what does not, is in what disqualifies a repo.

What to read next

• Is code protected by copyright, the authorship question in full
• Will AI replace programmers, what the practice changes and what it does not
• What disqualifies a repo, ownership as the first filter