Is Vibe Coding Real Programming?

Calling vibe coding "real programming" can start an argument before anyone defines the work. A person may be describing a disposable script, a deployed customer portal, or a regulated service built through the same chat-shaped interface. Those projects call for different standards of proof.

The useful test concerns the work and its consequences. Identify who chose the behavior and who owns the failure when generated code exposes data or becomes impossible to operate.

What Vibe Coding Means

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.

Two Tests Behind the Question

The dispute about whether the work is real often 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.

Vibe Coding vs Agentic Coding

Agentic coding describes what a tool can do: take a goal, read the codebase, edit files, and run commands in a loop until it reports the job done. Anthropic's documentation calls Claude Code "an agentic coding tool" for exactly that reason. Vibe coding, in Karpathy's original sense, describes the person, who accepts what the model produces and stops reading the code.

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	Nobody, before it ships	Throwaway and personal projects
Agent-accelerated development	A person who reads diffs and runs checks	Shared codebases
Hand-written code	The author, line by line	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.

Intent Is Part of Programming

Programming work begins well before anyone writes the first line of syntax. Someone decides which problem deserves automation, translates it into behavior, chooses what happens on failure, and defines where permissions change. A prompt can carry part of that intent.

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.

Authorship Is an Incomplete Measure

Counting human-written lines offers a simple test for authorship and a poor test for programming. A small configuration change can redirect an entire deployment. A long generated component can add little meaningful behavior.

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.

Natural-language generation can make the shift larger. The model may create many files from one instruction, and the person directing it may struggle to explain a particular function. That gap increases the verification burden because the generated surface is larger than the builder's direct authorship.

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.

Users Turn Output into a System

A generated preview can remain a private artifact. Once another person depends on it, the surrounding system grows. Accounts need an owner, and stored records need retention and deletion rules.

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.

Responsibility Survives Automation

Automation can move implementation effort without moving accountability. The organization publishing an app remains responsible for data collection, access control, billing behavior, licensing, and user harm.

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, a retry is idempotent, 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 amount typed by a human is a weak proxy for operational responsibility.

Security Changes the Stakes

Security determines whether releasing the result is responsible. The activity's classification as programming carries no safety guarantee.

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.

Verification Is a Separate Skill

Generating software and verifying software draw on overlapping skills, yet they produce different evidence. Generation creates a candidate implementation for someone to inspect. Verification compares that candidate with requirements and investigates ways it can fail.

A useful verification pass moves through layers:

1. Behavior: exercise the stated user flows and failure states.
2. Permissions: test with different users and anonymous requests.
3. Code: inspect sensitive paths, dependencies, and generated diffs.
4. Operations: deploy, observe, back up, restore, and roll back.
5. Handoff: start a fresh clone from written setup instructions.

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. The safe boundary moves as the builder becomes able to predict failures, read generated code, and design stronger checks. The project's consequences should remain inside that boundary.

A Practical Test for a Vibe-Coded Project

Labels become less useful once a real project exists. Ask for evidence across these seven areas:

• 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?

AI code 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 generated application can reach 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. Production readiness is evidence about the finished system.

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 project is real?

A public repository proves that files are available under stated access and licensing terms. It does not prove that the application runs, serves users, protects data, or can be maintained. Runtime evidence, repeatable setup, tests, and a clear owner provide stronger signals.

Does Vibe Coding Count as Real Programming?

The answer is yes 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.

Updated 25 September 2026: added vibe coding vs agentic coding section; freshness and wording review.