Is Vibe Coding Real Programming?

Vibe coding can count as programming when a person defines a computer’s behavior through natural-language instructions. That is our view, not a settled definition. Some developers reserve “programming” for work that includes understanding the implementation. Either way, a working AI-generated preview does not prove that an app is ready for other people to rely on.

Our standard is that someone can state the intended behavior, show evidence that it works, and take responsibility when it fails.

What Does Vibe Coding Mean?

Vibe coding usually means describing software in natural language and allowing an AI system to generate a substantial part of the implementation. The builder evaluates a preview, reports errors, requests changes, and may inspect less code than a conventional development workflow requires.

The phrase comes from Andrej Karpathy's February 2025 post, which described accepting whatever the model produced until you "forget that the code even exists." He framed it as a way to build throwaway weekend projects.

Current tools cover a wider range of behavior. A session can include planning, file-by-file review, direct edits, automated tests, source control, and deployment. The label now spans many degrees of delegated implementation.

The degree of delegated work changes what must be checked. A builder who accepts every generated change and refreshes the preview is doing different work from a builder who writes acceptance criteria, reviews diffs, tests permission boundaries, and diagnoses failures. Both may use prompts as the main input.

Why Do Developers Disagree About Vibe Coding?

Developers disagree about vibe coding because they use different definitions of programming and different standards for a finished product. The debate combines two questions:

• Classification: does directing a machine through language count as programming?
• Responsibility: can the person shipping it verify and maintain the system?

Classification is mostly a dispute about where programming begins. Programming already includes layers of delegation: compilers translate languages, frameworks supply behavior, libraries hide algorithms, and cloud services hide infrastructure. Natural-language generation adds one more layer of delegation.

Quality can be measured through observable behavior and repeatable checks. The app either enforces its access rules or it does not. A clean deployment either follows documented steps or depends on hidden workspace state, and a recovery either preserves data or loses it.

Responsibility still has an identifiable human or organizational owner. A generated file cannot approve a launch, accept legal obligations, respond to an incident, or explain a product decision. The person or organization releasing the software keeps those duties.

How Does Vibe Coding Differ from Agentic Coding?

Vibe coding describes how a person delegates and checks the work; agentic coding describes a tool that can plan, edit files, and run commands. An agent can support either unreviewed generation or carefully reviewed development.

Because one term describes the software and the other describes the builder's attention, a single session can be either. A developer who approves every change a terminal agent makes without opening the diff is vibe coding with an agentic tool. A founder who reads each change a browser builder proposes and tests each permission is doing careful work on a platform sold for vibe coding.

Practice	Who Checks the Code	Typical Setting
Vibe coding	No systematic code review	Throwaway and personal projects
Agent-accelerated development	A person who reads diffs and runs checks	Shared codebases
Hand-written code	The author or a reviewer; checks still vary	Any project

The companies building coding agents describe the careful end in their own documentation. Anthropic's best-practice guide for Claude Code says that without a check the agent can run, "looks done" is the only signal available, and you become the verification loop for every mistake. It tells users to have the agent show evidence, such as test output, instead of asserting success.

That careful practice now goes by names such as agentic engineering, the phrase in the title of DHH's Lex Fridman episode. "Vibe coding" stays most useful as the name for the unreviewed end, because a term that covers every use of AI in programming stops telling you anything.

DHH, the Ruby on Rails creator and 37signals CTO, drew the boundary more sharply on episode #501 of the Lex Fridman Podcast, published August 26, 2026. Asked whether agentic engineering should simply be called programming, he said no, because programming to him means understanding the constructs of a language, such as loops and variables.

His definition of the other side was blunt: "vibe coding, if we define it here, is you tell an agent to build software for you. You do not look at the implementation." He added: "That, to me, is what separates vibe coding from programming or, let's say, agent-accelerated development."

His comparison was a CEO who hires programmers, tells them what to build, and sells the software that comes out. He doesn't think most people would call that CEO a programmer, and he said the same applies to the vibe coder.

DHH is no purist about the practice itself. He says he has several vibe-coded projects of his own, including a C++ writing app whose code he deliberately never looked at. He also argues that product judgment, deciding what the software should do and for whom, matters more than programming skill once an agent handles the implementation.

Where other people depend on the result, he checks more. On the Quattro release of his Omarchy Linux distribution, none of the shipped code was written by hand, yet he says he reviewed its overall shape and read every line of the critical model-layer code. At 37signals, letting designers vibe code features in February 2026 produced pull requests that together "destroyed the architecture of the system," and the team cleaned it up by hand.

DHH's definition and Anthropic's guidance point at the same working test for any session, which is whether anyone reads the result before it ships. If someone reviews the diff and can explain the change, the work is what DHH calls agent-accelerated development. If nobody does, it's vibe coding whatever the tool calls itself, and the responsibility test from the previous section applies with full force.

A Spectrum from Experiment to Production

The spectrum from experiment to production describes rising consequences rather than fixed technical stages.

A private experiment can tolerate rough setup, incomplete tests, and a manual reset. Its purpose may be learning whether an interaction feels useful. The builder can discard the result with little external cost.

An MVP serves real people or informs a real product decision. It needs explicit acceptance checks, basic access control, reliable data handling, and enough observability to interpret feedback. A tiny audience still creates obligations when users supply personal information.

Production adds operating conditions that a private experiment can avoid. Backups, incident response, audit logs, rate limits, dependency maintenance, accessibility, privacy, and rollback plans become part of the software. A generated interface is one part of that system.

Does Writing a Prompt Count as Programming?

A prompt can perform part of the programming work when it specifies behavior, rules, and failure conditions. A vague request such as “build an app” leaves most of those decisions to the generator.

Consider the instruction "build a customer portal." It leaves the generated system to guess which records a customer may see, how identity is established, what staff can change, and what happens when a request fails. The prompt contains a product category and very few requirements.

A stronger brief identifies observable behavior before any files change:

Customers sign in by email and can view only invoices linked to their account. Staff can issue a credit after confirming the amount. Reject duplicate submissions, log every credit, and preserve the form when the payment service times out.

That brief still needs design and implementation decisions. It gives the generator and the reviewer a shared target. The shift from wish to acceptance criteria is programming work because it shapes the machine's behavior.

Replit's own Agent guidance lists five habits for builders: be specific, plan the work, add context, review and test, and use checkpoints. Its Plan Mode produces a task list for approval before Build Mode changes any files. Even a vendor selling prompt-driven building treats planning and review as part of the job.

Do You Have to Write Code Yourself to Be Programming?

You do not have to type every line yourself to do programming work. Choosing requirements, configuring existing components, and checking how they behave can be substantive work even when libraries or AI supply the implementation.

Software work already includes assembling code written elsewhere. A developer can install a library, configure a framework, call a hosted API, or compile a higher-level language without personally authoring the implementation below it. Each abstraction shifts attention toward choices made at another layer.

An AI model may create many files from one instruction, leaving the person directing it unable to explain a particular function. That makes review harder because there is more unfamiliar code to check before anyone can rely on it.

Two records provide more useful evidence than a line count:

• The requirement that explains why the behavior exists.
• The test or observation that shows the requirement was met.

These records connect intent to implementation and implementation to evidence. They also let another person challenge a result without debating whether the original builder deserves an identity label.

What Changes When Other People Use a Vibe-Coded App?

When other people rely on a vibe-coded app, the builder must account for access, stored data, failures, and ongoing support. A private prototype becomes a service with users who can lose work or information.

A scheduled job needs an owner and a monitoring signal. A paid feature needs billing recovery and a way to resolve disputes.

Revenue is one signal of dependence, although it is never required for software to matter. An internal accessibility tool, a family scheduling app, or a volunteer database can carry real consequences without charging anyone.

The number of users also gives an incomplete measure. One person may place sensitive health information into a small tool, while thousands may use a disposable public calculator that stores nothing. Data sensitivity, reversibility, and the cost of failure tell more than audience size alone.

Write one concrete consequence statement before any public launch:

If this application fails, these people lose this capability or data. The owner will detect the failure through this signal and restore service through this procedure.

A builder who cannot complete that statement has found the next piece of engineering work. The answer may justify keeping the project private, reducing the data it stores, adding a manual fallback, or asking a qualified reviewer to inspect the risky path.

Who Is Responsible for AI-Generated Software?

The person or organization publishing AI-generated software remains responsible for reviewing, operating, and maintaining it. Delegating code generation does not assign those duties to the model.

OpenAI's May 2025 Codex launch post says users should manually review and validate all agent-generated code before integration and execution. GitHub's Copilot code review documentation says Copilot won't spot every problem and tells teams to supplement its feedback with a human review.

Those cautions also apply to prompt-to-app builders and hosted agents. A successful preview verifies one route through one environment. It cannot establish that another user lacks access, a secret stayed server-side, retrying an action will not duplicate it, or a restore works.

Ownership becomes visible through the actions a team can prove:

• The requirements name users, permissions, data, and failure behavior.
• Generated changes receive a review proportionate to their risk.
• Tests cover acceptance criteria and important abuse cases.
• Deployment and rollback both follow written, repeatable instructions.
• A named person or team monitors and maintains the application.

A project can satisfy those conditions while AI writes most of its files. A hand-written project can fail every one of them. The number of lines a person typed tells you little about how well the app is maintained.

Does Vibe Coding Make Software Safe?

Vibe coding does not establish that software is safe. Generated applications still need checks for exposed credentials, data access, authentication, and unintended public access.

Wiz's September 2025 vendor research on vibe-coded apps reported that one in five organizations in its observed population had vibe coding platforms exposed to risk. The article names client-side authentication, exposed secrets, open databases, and publicly reachable internal applications.

That figure is limited to Wiz's telemetry and methodology. The concrete failure modes are useful because each can become an acceptance check.

Risk	Verification	Failure Signal
Client-side login	Browser bundle review	Password in the code
Exposed secrets	Bundle and repo scan	Usable credential
Open database	Anonymous request	Readable records
Public internal app	Unauthenticated URL	Loaded workspace

An earlier Wiz article on rules files for safer vibe coding shows one way to place security constraints into the generation context. Rules can keep the same instruction in every generation. Tests and review still need to prove that the resulting application follows them.

What Skills Do You Need to Check AI-Generated Code?

Checking AI-generated code requires skills in testing behavior, reading changes, reviewing permissions, and diagnosing failures. Generating a plausible implementation and proving that it meets its requirements are different tasks.

Prompting skill helps a builder describe a candidate. It cannot recognize every requirement that the builder forgot to state. Domain knowledge matters where the interface hides taxes, health records, financial authorization, or tenant isolation.

Learning can happen alongside a low-stakes project. As builders learn to spot failures, read generated code, and design better tests, they can take on more demanding projects. They should still be able to check the parts that other people will rely on.

How Can You Judge Whether a Vibe-Coded Project Works?

Judge a vibe-coded project by whether it meets its stated purpose, protects its data, and can be run and repaired by its owner. Check the following areas at a depth that matches the consequences of failure:

• Purpose: the project solves a named problem for a named user.
• Behavior: acceptance checks cover success and failure.
• Access: authorization is tested across user roles.
• Data: collection, retention, export, deletion, and recovery are documented.
• Supply chain: dependencies and external services are known and maintained.
• Operations: deployment, monitoring, rollback, and incident ownership are repeatable.
• Handoff: another person can run and understand the project from its repository.

An experiment may intentionally leave several areas incomplete. Write that boundary down beside the project's saved version. An MVP with test users needs stronger access and data evidence.

A production service should have answers across the list at a depth that matches its risk.

This evidence test avoids two common errors in opposite directions. A polished screen receives no automatic credit for hidden behavior. A rough internal tool receives no automatic rejection when its limited purpose, access, and recovery are clear.

Keep the evidence with the repository so future changes can be judged against the same expectations.

Frequently Asked Questions

Is vibe coding the same as AI code completion?

Vibe coding is different from AI code completion: completion usually suggests a small continuation while the developer directs the implementation. Vibe coding delegates a larger outcome through natural-language instructions and generated changes. The boundary can blur when a person alternates between prompts, direct edits, tests, and review.

Can vibe-coded software ever be ready for production?

A vibe-coded application can be ready for production after its behavior, security, data handling, accessibility, operations, and recovery paths have been checked to the standard its users require. The generation method supplies no shortcut through those checks. The finished app must meet those standards regardless of how its code was written.

Do you need to learn programming before vibe coding?

A beginner can use a vibe coding tool before learning a language in depth. Shipping consequential software requires skills for decomposing requirements, reading failures, testing behavior, reviewing security, and operating the result. Those skills can grow alongside a project, provided the project's stakes stay within the builder's current ability to verify it.

Does a public repository prove a vibe-coded app works?

A public repository does not prove that a vibe-coded application works; it shows that its files are available. Runtime evidence, repeatable setup, tests, and a clear owner provide stronger evidence that the app works, protects data, and can be maintained.

Does Vibe Coding Count as Real Programming?

In our view, vibe coding counts as programming when natural-language direction defines and changes a computer’s behavior. The decisive standard for a real project is responsibility: someone can state the intended behavior, produce evidence that it works, and respond when it fails.

Some experienced developers draw that line much tighter than this. DHH keeps the word "programming" for work that rests on understanding the language itself, and a session where nobody reads the result before it ships stays vibe coding in Karpathy's original sense, whatever tool runs it.

Generated code changes the route to implementation while leaving quality, security, ownership, and production readiness to be proved.