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.

Product and security sources for this page were checked on July 28, 2026.

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.

Vercel's State of Vibe Coding page traces the phrase to Andrej Karpathy's February 2025 post. The original description emphasized following the model's output with limited attention to the code itself.

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.

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.

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 official Agent guidance tells builders to be specific, add context, use planning, review changes, and test results. Its Plan Mode documentation separates a task list from file-changing Build Mode. The product documentation treats planning and review as necessary activities.

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. 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 Codex introduction says users should manually review and validate agent-generated code before integration and execution. GitHub's code review documentation also says AI feedback can miss problems and requires validation by a human reviewer.

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 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 authorization, 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 authorization	Second-user test	Cross-account data
Exposed secrets	Bundle and repo scan	Usable credential
Open database	Anonymous request	Readable records
Public internal app	Unauthenticated URL	Loaded workspace

Wiz's follow-up 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.

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