The Seven Levels of Vibe Coding

How I Got Vibe Coding Wrong

I learned the term vibe coding from one of Cathie Wood’s Employment Friday podcasts, which is admittedly an odd place for a software engineer to learn a new software-development term.[1] I was skeptical almost immediately. Wood may be a remarkable fund-managing economist, but over the years I have found her grasp of technology considerably less impressive, and her bubbling enthusiasm about the latest technological development tends to have something of the Cramer effect on me. The more excited she gets, the more inclined I am to inspect the merchandise before buying any.

The next place I remember encountering the term was Jo Bhakdi, who frequently uses vibe coding to describe what he does with Lovable.[2] Bhakdi talks expansively about Lovable and its potential, but the way he described using it sounded to me a lot like the newest generation of no-code application builder. Instead of dragging controls around a screen or configuring workflows through menus, you tell an AI what you want and it builds the application. The technology behind that interaction might be radically different, and the resulting tool considerably more capable, but it sounded to me like an AI-enabled incarnation of an idea that had been around for a long time.

Meanwhile, I had started experimenting with getting a chatbot to write code for me. I had been getting a lot out of chatbots as research and writing tools. I had a small application I wanted to build and I was curious to see if what I had learned from AI-assisted writing would transfer to code generation. In fact, the chatbot turned out to be surprisingly good at producing useful code when I gave it enough information about what the application needed to do. I kept pushing the experiment farther, partly because it was interesting and mostly because it was working.

But it was a silly process. I would describe what I wanted, the chatbot would generate code, and I would copy the code out of the chat and paste it into the appropriate files in the repository. If the application failed to build, I would carry the error back to the chatbot. If something behaved incorrectly, I would describe what had happened, receive another batch of code, and copy that into the repository as well. The chatbot could write the software, but it could not touch the software. I had somehow turned myself into a human interface between an LLM and a filesystem, and throughout the process I kept thinking there had to be a better way.

There obviously was a better way, but the method I was using worked well enough that I didn’t want to interrupt the project and go looking for one. Part of what kept me working in the chatbot, despite the irritation of impersonating the filesystem, was a methodology I was developing for guiding it toward the code the project actually needed. I was finding ways to describe the desired behavior and the surrounding system precisely enough that the code it produced would fit into a growing application without requiring me to reconstruct the project for it from scratch every time.

That part of the experiment mattered more to me than the awkward interface. I expected the methodology to be essential for a considerably more ambitious project I wanted to build next, and I wanted to see whether it continued to work as the application grew. Using this increasingly absurd copy-and-paste loop, I built a functioning database-backed web application for my own use. It had persistent data, a browser interface, and enough moving parts to demonstrate that the process could produce something substantially more useful than a collection of code snippets. It also served as the proof of concept I had wanted for the larger project.

The larger project did what larger software projects tend to do: it became considerably larger than I had anticipated. The chatbot could still write useful code, and my method continued to help, but the burden of carrying information and artifacts between the chatbot and the actual development environment grew along with the project. Maintaining my role as the repo interface became increasingly difficult to justify when there were more files, more context, more interactions among components, and more opportunities for the chatbot’s picture of the repository to diverge from reality.

Around then I had a conversation with a friend who had been paying much closer attention to AI coding tools than I had. He asked why I was not using them for my own projects. I explained that I actually had been using AI to write code for some time and described my arrangement with the chatbot. He scoffed.

But his reaction got my attention and before long I switched. The benefits were obvious right away. The model could inspect the files itself, make changes to them, see the surrounding code, and operate inside the development environment rather than relying on me to shuttle representations of that environment back and forth through a chat window.

My belated adoption of an LLM-driven desktop coding tool made it plain that I had been ignoring something important. The coding tool clearly had been designed by people doing LLM-backed code generation and maintenance for people doing the same thing. To me that suggested more than what I would call “vibe coding”, and I could already see a gap between what I was doing and what I understood vibe coding to be. In my experimental project I had built a system that built a system. Yes, I had used a vibe-coding approach to build System A. But then System A built for me System B. That wasn’t vibe coding.

The Name and the Twenty-Foot Problem

When I finally went back to Andrej Karpathy’s original description of vibe coding, I found something considerably more specific than the loose category I had assembled from hearing the term used elsewhere. Karpathy coined the phrase in early 2025 while describing a way of working in which he could largely “forget that the code even exists.” He accepted generated changes without necessarily reading the diffs, passed errors back to the model, and kept iterating largely through the behavior of the resulting software.[3]

That is a very good use of the word vibe. The programmer gives up a substantial amount of concern with the implementation and works from the observed behavior of the thing being built. Something looks wrong, so the model is told. Something breaks, so the error goes back. The model changes the code, the application runs again, and the process continues until the result is satisfactory enough for the purpose at hand.

The phrase quickly acquired a broader meaning. Vibe coding increasingly became a convenient description for software development in which ordinary language goes in and AI-generated code comes out, even when the person directing the process remains deeply concerned with the code, the architecture, or the engineering process around it. The broader usage is understandable because the most conspicuous feature of all these tools is the same.[4]

I eventually found my friend’s distinction between vibe coding and agentic coding more useful as a clue than as a vocabulary. Whatever precise boundary he intended, he had alerted me to the fact that AI-assisted coding was not one activity. Trying to force the whole range into a binary would simply create another terminology problem.

That visible similarity persists after the practices underneath it begin to diverge. My crude chatbot workflow and the desktop coding tool I switched to both involved describing desired changes in English and receiving code generated by an LLM. Someone watching over my shoulder for a few minutes might reasonably conclude that I was doing essentially the same thing through two different interfaces.

From twenty feet away, an even wider range of practices can look almost identical. The observer sees a person typing natural language and a machine producing software. The observer cannot readily see how much the person understands about the system, what information the model has been given, how precisely the desired behavior has been specified, how the generated work will be evaluated, or what constraints surround the model’s actions.

This was the source of my original classification error. I had been sorting AI coding practices by the characteristic they shared most obviously: the human had stopped writing most of the code. Once that becomes the defining characteristic, however, the category grows large enough to contain activities that demand very different kinds of skill, discipline, and engineering judgment.

The distinctions become easier to see if we stop asking who typed the source code and look instead at the relationship among the human, the model, the software, and the process used to produce it. I find it useful to separate that range into seven levels.

The Seven Levels

The seven levels are a working scale, not seven naturally occurring species of software development. The joints are not equally sharp. Levels 1 and 2 shade into one another; Level 3 is the clearest hinge; Levels 4 and 5 are successive steps in moving engineering control upstream; Levels 6 and 7 are successive organizational changes. A person may also move between levels during the same project, and the same coding tool can support several of them.

That unevenness is part of the point. The levels are useful because they separate practices that look similar from a distance while placing very different demands on the human and on the development process. The question is not which product appears on the screen or what percentage of the source code came from an AI. It is where understanding, judgment, specification, verification, and control reside.

Level 1: Vibe Coding

At the first level, the human describes the desired result and largely judges the model by what appears on the screen. Build me a personal budgeting application. Add a login page. Make this look better on a phone. Fix the error that appears when I click here. The model writes the code, the human runs it, and the next instruction follows from whatever happens.

This is very close to Karpathy’s original description of vibe coding. The code itself can recede almost completely from view. If the application behaves strangely, the human describes the strange behavior. If an error appears, the error message goes back to the model. If the result now works, understanding exactly what changed may add little value for the purpose at hand.

Suppose an application occasionally fails while talking to another service. At this level the instruction might simply be, “It fails sometimes. Make it retry.” The model adds something, the human tries the application again, and if the problem seems to have disappeared the change has passed the test that matters.

For small personal tools, prototypes, experiments, and disposable software, that can be an extraordinarily productive arrangement. Someone who could not previously have produced a functioning application can describe one, iterate on it, and sometimes end up with useful software. An experienced programmer may make exactly the same choice when the cost of understanding a throwaway implementation is greater than the value of understanding it.

The defining characteristic is that confidence comes primarily from observed behavior. The human may know exactly what the application should feel like and do while possessing only a weak model of the implementation underneath it. Vibe coding is an unusually good name for this.

Level 2: Conversational Vibe Coding

At the second level, the conversation acquires continuity and structure. The human develops a more complete mental model of the application and begins directing changes in relation to earlier decisions rather than issuing mostly isolated requests.

The instructions become more specific. This screen should use the same customer record as the reporting screen. The approval step belongs before fulfillment. Do not change the existing export behavior when adding the new filter. A user who cancels here should return to the previous state rather than starting over. The human starts protecting behavior across the system.

Our retry instruction might now become: the remote service fails intermittently, so retry when that particular call times out, but do not make the user repeat the operation and do not display the error unless the retries fail. That is already much more information than “make it retry.” The user has begun defining relationships among behaviors and protecting the surrounding experience.

A sufficiently attentive person can make this process surprisingly effective. This is approximately the territory I entered during my chatbot experiment. I was learning that the quality and consistency of the generated code depended heavily on the quality and structure of what I told the model about the system it was changing.

The upper boundary of this level becomes clearer if we ask what can cause the human to reject a change. At Level 2, rejection still comes primarily from something observable in the resulting application: the workflow is wrong, an earlier behavior has disappeared, an error still occurs, or the output is not what was requested. An implementation flaw that has not yet produced a visible consequence may pass unnoticed because the implementation itself is not the principal object being evaluated.

That remains vibe coding, although it may be quite disciplined vibe coding. The human is building and defending an increasingly sophisticated behavioral model of the application, but the development loop remains dominated by describing, observing, and correcting.

Level 3: AI-Assisted Programming

Level 3 is the strongest break in the ladder because the code becomes an engineering object again. The human understands the software as software and can reject a generated change for reasons that may not yet be visible in the application’s behavior.

Return to the retry. The AI may produce a change that appears to work perfectly in testing but retries an operation that is not idempotent. A timeout occurs after the remote service has already accepted the request, the model retries it, and the same purchase, message, or database operation happens twice. The screen may look fine throughout. A programmer who understands the implementation can reject the change before the hidden defect becomes a customer’s problem.

The same judgment applies throughout a generated codebase. A model can swallow an exception in the wrong place, introduce an unnecessary dependency, create an N+1 query, bypass an existing abstraction, or solve a local problem by quietly damaging the architecture around it. The human can inspect the implementation, understand why a seemingly functional change is technically wrong, and require something different.

Conventional software-engineering knowledge is now operating against a new and unusually deceptive failure profile. Model-generated code is often fluent enough to look unsurprising, and a capable agent can produce far more of it than a human would have typed in the same period. Reviewing generated code therefore becomes its own kind of literacy layered on top of conventional programming skill. Plausible wrongness is more dangerous when it arrives quickly, consistently formatted, surrounded by plausible tests, and embedded in several hundred lines of otherwise competent work.

The AI may still write nearly every line. A Level 1 user and a Level 3 programmer could each have a repository that is 95 percent model-generated. That percentage tells us who produced the text. It tells us very little about who understood the engineering decisions embodied in it.

Level 4: Specification-Driven Agentic Development

At Level 4, engineering attention begins to move upstream from judging implementations toward establishing the obligations an implementation must satisfy. In mature software, that frequently begins with discovering obligations that no longer exist in any authoritative specification.

A rule may survive as a conditional in an old service, a database constraint, a validation check, a test written six years ago, an odd branch in a user interface, or several pieces of code that only make sense when considered together. Coding agents are unusually useful for searching across those artifacts and helping reconstruct the behavioral rules embedded in an existing system.

That reconstruction is not automatically truth. The code may contain bugs, obsolete behavior, contradictions, or accommodations whose original purpose can no longer be recovered. But the agent can trace behavior across a repository, surface candidate rules, identify conflicts among them, and make the uncertainties explicit. That turns code from something merely to be modified into evidence used during planning.

The two parts of Level 4 fit together. First discover what the existing system appears to require or preserve. Then express the obligation clearly enough that the new implementation can be judged against it rather than against the wording of the original prompt.

Our retry problem can now begin with investigation rather than implementation. The agent can inspect the existing call path, error handling, tests, state transitions, and related operations before anyone asks it to write the retry. From that work, the human and agent can establish the actual requirement: which failures are transient, which must propagate immediately, how many attempts are permitted, whether the operation is idempotent, what state must survive between attempts, and what the caller should observe when all attempts fail.

There is a significant difference between an instruction and a specification. “Add a retry” requests an action. The fuller version establishes obligations that remain true regardless of how the agent chooses to implement them.

At this level, natural language has changed function. It is no longer merely a convenient substitute for syntax or a way of steering the model toward behavior that looks right. It has become part of the engineering specification, informed where necessary by the agent’s examination of the system that already exists.

Level 5: Governed Agentic Engineering

Level 5 adds another change: the obligations established during planning acquire some independence from the agent that implements them. Level 4 makes the required behavior explicit. Level 5 begins making satisfaction of that behavior independently enforceable.

The retry specification, for example, can produce acceptance tests that exercise transient failures, permanent failures, exhausted retries, partial success, duplicate side effects, and state preservation. Those tests can be established before the implementation is accepted and need not be derived from the implementation itself. The coding agent may remain free to choose the algorithm, library, or internal structure, but its solution has to survive criteria that have standing outside its own account of what it built.

An adversarial agent can be useful here as well. Instead of asking another model merely whether the code looks good, it can be given the specification and asked to find ways the implementation violates it. Does the third failure behave differently from the first two? Can a partial success cause a duplicate operation? Does the code silently retry an error the specification said must propagate? Are the tests actually demonstrating the required invariant, or merely reproducing an assumption made by the implementation?

Using a second agent for that purpose does not by itself create Level 6. At Level 5 it can simply be one of the control mechanisms surrounding a primary worker, much as a test runner or static analyzer is. What matters is that the producer no longer owns the entire definition of success.

This does not make governance magically trustworthy. A specification can be incomplete or stale. Automatically generated tests can encode the same mistaken assumption as the implementation. If one agent writes the code, writes tests that mirror its code, runs those tests, and then explains why their success proves the work is correct, the result may be little more than automated test theater. Even an independently prompted reviewing agent can share blind spots with the producer.

The purpose of governance is therefore not to eliminate error. It is to create independent surfaces on which error can become visible. Tests, constraints, acceptance criteria, architectural rules, evidence requirements, and adversarial review make it harder for a single plausible story about the implementation to become the only account of whether the work succeeded.

This is also where greater agent autonomy can coexist with greater human control. The agent may receive more freedom to choose and execute an implementation while the range of results the engineering process will accept becomes narrower.

Level 6: Multi-Agent Software Engineering

At Level 6, a second agent is no longer merely another instrument of verification. Engineering responsibility itself is divided among agents, and failure acquires an organizational meaning. I found it useful to give one coding agent the job of being right and another the job of not believing it.

I use that arrangement in SoftwareBuilder, a multi-agent harness through which I impose those roles when I work in Codex. Codex A owns implementation. It is expected to make the requested change, add or strengthen the tests needed to prove it, reproduce defects before fixing them where appropriate, run its own verification, and continue working until its own evidence says the assignment is complete. Codex B is the truthkeeper. Its job is not to help A finish or to act as a substitute QA department for defects A should have caught. It independently evaluates whether A actually satisfied the assignment and whether the evidence offered in support of that claim should be believed.

If B discovers an ordinary implementation failure that competent producer-side testing should have exposed, that is not merely another bug in the review queue. It is evidence that A failed part of its assigned role, and the work returns to A. B may be perfectly capable of identifying the repair, but allowing the auditor to become the producer would destroy part of the separation the arrangement was designed to create. The inefficiency is deliberate.

Applied to our retry example, A might implement the behavior, strengthen its tests, and demonstrate that the required cases pass. B receives the specification, the resulting change, and the evidence, then asks a different question: do these tests establish what A says they establish, did the implementation preserve the required invariants, and did A change anything outside the assignment in order to make the tests pass?

The important step is not simply adding another model invocation. It is assigning engineering responsibilities so that different agents have different jobs and different standards of success. Implementation, investigation, test construction, architecture review, adversarial verification, and other functions can be separated where separation adds value. Some workstreams can proceed concurrently when their boundaries permit it.

At this level, the human is no longer only governing an agent’s work. The human is designing relationships among cognitive workers.

Level 7: The Agentic Engineering Organization

Level 7 is what happens when those relationships stop being assembled anew for individual pieces of work and become a durable engineering system. Roles persist. Rules persist. Repository knowledge persists. Expectations about tests, evidence, review, authority, and escalation survive the assignment that originally caused them to be created. An owner or orchestrating layer can receive larger objectives and move work through an established organization of specialized agents.

That persistence is the important increment over Level 6. A multi-agent workflow can divide a feature among an implementer and a reviewer. An agentic engineering organization already knows what producers are responsible for, what reviewers are responsible for, what constitutes acceptable evidence, where architectural rules live, how failures return for repair, and which decisions require human judgment. The machinery becomes part of the development environment rather than part of the prompt.

OpenAI provided an unusually large example in February 2026. A small engineering team described building an internal software product from an empty repository to roughly a million lines of code over five months, with about 1,500 merged pull requests. Every line in the repository—including application logic, tests, CI configuration, documentation, observability, and internal tooling—was generated by Codex rather than written manually by the human engineers. The engineers increasingly concentrated on designing the environment, specifying intent, and building feedback loops that allowed the agents to do reliable work.[5]

The surrounding system is what makes the example relevant here. Repository knowledge was made durable, architectural constraints were mechanically enforced, and agent-on-agent review and runtime evidence became parts of the development process. OpenAI also stressed that this autonomy depended heavily on the structure and tooling built around the repository rather than appearing automatically from model capability alone.

There is another important qualification. OpenAI began with an empty repository in late August 2025, and the codebase was shaped around the agentic process from its first commit. Most established software organizations face the opposite problem: years of human-written code, business rules scattered across implementation and tests, accumulated architectural compromises, contradictory conventions, and little infrastructure designed to make those constraints legible to agents. The OpenAI project shows particularly clearly what Level 7 can look like. It does not show that an ordinary brownfield codebase acquires the same properties merely by pointing a capable coding agent at it.[6]

The million lines are impressive, but they are not what makes this a Level 7 example. Neither is the absence of human-written source code. The significant achievement is the durable harness around the generation: an engineered environment in which agents can receive work, find the knowledge they need, operate within boundaries, validate results, review one another, respond to failures, and continue across a substantial software-development program.

The source code may be almost entirely machine-generated at several points along the ladder. That is precisely why the percentage of AI-written code is such a poor description of what is happening.

What the Umbrella Term Makes Hard to See

Once the activities under vibe coding are separated, one of the most common claims about AI and software needs to be divided in two. AI is making the production of source code dramatically cheaper. It is not automatically producing the judgment that used to travel alongside the production of that code.

Those two things were easy to confuse when programmers usually had to write the implementation themselves. The person producing the code also had to understand enough about the language, repository, architecture, and surrounding system to make the code work. Writing software therefore bundled mechanical production together with a large collection of judgments: what the requirement actually meant, whether an existing behavior had to be preserved, whether an apparently convenient implementation created a hidden failure mode, what evidence was sufficient to trust a change, and when a locally successful solution damaged the larger system.

LLMs loosen that bundle. Someone can now produce useful software with very little of the conventional knowledge once required to produce the source code. That is a real change, and it is one of the reasons the lower levels of the ladder matter. A person who could not previously have built a small application may now be able to describe one, iterate until it behaves correctly, and use the result.

The judgment does not necessarily follow the code production upstream. A Level 1 or Level 2 user may never acquire the ability to recognize a bad database access pattern, an unsafe retry, or an abstraction being quietly violated. A capable Level 3 programmer may recognize all of those and still be poor at writing durable specifications. Someone who can write good specifications may have little talent for designing a verification regime or dividing a large engineering problem among independent agents. Making one layer cheap does not automatically confer competence at the layer above it.

This is why the claim that almost anyone can now become a programmer is simultaneously important and imprecise. Almost anyone being able to make useful software would be a remarkable development even if nothing else changed. The threshold between having an idea and possessing an executable artifact has fallen sharply. But making software and engineering software under demanding conditions are not identical accomplishments.

A personal tool that works reliably enough for the person who created it carries one burden of proof. A payroll system, airline reservation service, medical-records platform, or control system for physical equipment carries another. In the first case, finding a problem after deployment may be an irritation. In the second, the questions extend well beyond whether the application appeared to work during development: what happens under unusual load, during partial failure, when an old business rule collides with a new one, when another service behaves unexpectedly, or when a sequence that was assumed to be impossible occurs anyway.

AI makes the first achievement astonishingly inexpensive. It does not make the second automatic. In fact, as producing something plausible becomes cheaper, distinguishing plausible software from trustworthy software may consume a larger share of the engineering effort that remains.

That changes what expertise looks like from outside the profession. If an engineer writes only a small fraction of the source code, counting keystrokes or lines authored tells us very little about the value of the human contribution. The engineer may be spending time recovering requirements from an old system, rejecting fluent but structurally bad implementations, writing specifications an agent can be judged against, deciding what evidence is credible, or designing the boundaries among agents that will do most of the implementation work.

The same problem reaches hiring. Traditional software hiring has often used coding ability as a proxy for a wider collection of engineering capabilities because coding was difficult to separate from them. As models become better at source production, that proxy becomes less complete. The ability to understand generated software, detect plausible wrongness, recover latent requirements, specify behavior precisely, design useful tests, and recognize when apparent evidence proves much less than it claims may matter more even while the amount of code a candidate personally writes matters less.

None of this implies that conventional programming skill suddenly becomes irrelevant. Generated code still has to execute in systems built out of programming languages, databases, networks, operating systems, libraries, and APIs, and those systems retain their old failure modes while acquiring some new ones. The point is narrower: the visible act that once bundled many engineering skills together is becoming easier to delegate, so we can no longer assume that its disappearance tells us which of the surrounding skills remain present.

Autonomy creates a similar optical illusion. A coding agent that can inspect a repository, modify dozens of files, run tests, respond to failures, and continue for an extended period without human intervention appears to be displacing human control. Sometimes it is. But the higher levels show another possibility: the human can move from controlling individual actions to controlling what counts as an acceptable result.

That change is not free. Specifications can be wrong. Tests can certify the implementation that wrote them. Review agents can share the producer’s blind spots. Persistent rules can preserve yesterday’s mistake with impressive consistency. Moving control into governance does not eliminate engineering judgment; it creates another place where engineering judgment can succeed or fail.

The consequence is that “human in the loop” becomes a less useful binary. A human can sit in the middle of every edit and still exercise weak control over the finished system. Another process can allow agents to perform long stretches of work autonomously while requiring explicit evidence, independent audit, architectural compliance, and human judgment at the points where the system cannot safely decide for itself. What matters is not simply whether a person touched every step, but where the process requires judgment and how failures are allowed to propagate.

This is also why claims of enormous AI-driven software productivity need more information than the number of lines generated or the amount of human coding eliminated. A tool that lets one person produce a prototype ten times faster has accomplished something valuable. An engineering system that can repeatedly produce, validate, and maintain production software with a fraction of the previous human implementation effort has accomplished something else. Those achievements can look similar in a demonstration because both end with a large amount of software appearing very quickly.

The distinction matters especially to people who make decisions about software without spending their days inside the development process. An executive deciding how many engineers a project requires, an investor evaluating claims about software productivity, or a hiring manager deciding which skills remain scarce needs to know more than whether AI generated the source. They need some idea of what kind of development process produced it and what kinds of judgment remain outside the model.

That is what an umbrella use of vibe coding makes difficult to see. It takes the most conspicuous fact—the human is no longer typing most of the code—and allows that fact to stand in for several different transformations at once. Code production may have become cheap. Engineering judgment may still be scarce. Some of that judgment may now be exercised through specifications, verification, and organization rather than through implementation. None of those conclusions can be read from the source-code authorship statistics.

From twenty feet away, the person is still typing English and the machine is still producing software. The closer question is no longer who wrote the code. It is what had to be understood, decided, constrained, and proved before the code was allowed to count as finished.

Back to Twenty Feet

My first encounters with vibe coding encouraged me to classify the new tools by the most conspicuous thing they had in common. Wood used the term while discussing a changing labor market, Bhakdi used it for what he was doing with Lovable, and my own first experiments involved getting a chatbot to produce software through ordinary language. From sufficient distance those activities looked much more alike than they actually were.

That leaves vibe coding as a useful term for the phenomenon Karpathy originally named and a progressively less useful term as we move away from it. The problem is not that an AI wrote the code. The problem is treating that visible fact as a sufficient description of the engineering process.

For a long time, software engineering was comparatively easy to recognize because much of its expertise was expressed through visibly technical activity. Programmers wrote syntax, inspected code, debugged implementations, and reviewed changes. AI can move increasing amounts of that work into specifications, constraints, tests, judgment, governance, and coordination while leaving surprisingly little evidence of the shift on the screen. From twenty feet away, it can look as though the engineering has disappeared. Much of the time, what has disappeared is our old way of seeing it.

Notes

[1] The specific Employment Friday segment is recalled from listening. For a representative public explanation of Wood’s usage, see The Diary of a CEO interview with Cathie Wood, June 5, 2025, where she describes vibe coding as natural-language programming and presents it as something broadly accessible.

[2] Bhakdi has repeatedly discussed his Lovable work in vibe-coding terms; representative public posts are preserved in this archive of Jo Bhakdi’s posts. Lovable itself explicitly describes vibe coding as building through natural-language conversation and says that an “AI-powered no-code builder (like Lovable)” is sufficient to begin.

[3] Andrej Karpathy, original February 2025 post introducing “vibe coding”. Because X is not always easily accessible without an account, Simon Willison also preserves and quotes the original description.

[4] Simon Willison was already objecting in March 2025 that the definition was expanding to cover AI-assisted programming generally; see “Not all AI-assisted programming is vibe coding (but vibe coding rocks)”. He returned to the same semantic drift in May in “Two publishers and three authors fail to understand what ‘vibe coding’ means”.

[5] Ryan Lopopolo, “Harness engineering: leveraging Codex in an agent-first world,” OpenAI, February 11, 2026. OpenAI reports roughly one million lines of code, about 1,500 merged pull requests, and zero manually written code across application logic, tests, CI, documentation, observability, and internal tooling.

[6] The same OpenAI harness-engineering account says the first commit landed in an empty repository in late August 2025 and emphasizes that the resulting autonomy depended on repository structure, tooling, mechanically enforced constraints, feedback loops, and other harness work rather than model capability alone.