What Is Vibe Coding? Why Engineering Is Moving Up the Stack

Vibe coding is software creation through conversation with an AI. You describe an outcome, the agent writes and changes the implementation, and you judge progress mainly through what the software does.

The popular caricature is that vibe coding replaces engineering with prompting. We think the opposite is happening. Vibe coding does not eliminate engineering judgment. It moves that judgment up the stack, away from typing and reading every line and toward specification, abstraction, data flow, state, verification, and risk.

That shift is already larger than the original definition of the term. At Moda, we regularly work with pull requests exceeding 3,000 lines that nobody reads line by line. Review happens at a higher level: architecture, affected surfaces, tests, benchmarks, rendered behavior, failure modes, and targeted code where risk concentrates.

This is not permission to stop understanding software. It is a change in what understanding software means.

What does vibe coding mean?

AI researcher Andrej Karpathy coined the term in February 2025 to describe a loose, conversational workflow in which he prompted an AI, accepted changes, ran the result, and fed errors back while largely ignoring the underlying code. His original description said that he would “forget that the code even exists”.

That strict definition still describes pure vibe coding. In practice, the term now covers a wider spectrum:

Google Cloud distinguishes pure vibe coding from responsible AI-assisted development. GitHub makes a similar distinction between accepting output on feel and using AI inside a human-owned engineering process.

The boundaries will keep blurring. As agents become more capable, more professional software work will look conversational from the outside. The important distinction will not be whether AI wrote the code. It will be whether someone specified the right system, demanded credible evidence, and owns the consequences.

Vibe coding is not the end of engineering

For decades, producing code was the expensive part of software development. That made code review a central proxy for quality: if skilled humans examined the implementation, they could catch errors and preserve coherence.

When agents can generate thousands of lines quickly, exhaustive line-by-line reading becomes a bottleneck. It may also be the wrong allocation of attention. A large mechanical refactor with strong type checks, exhaustive tests, and performance benchmarks can be easier to trust than a small change to an ambiguous permissions flow.

The scarce work moves elsewhere:

1. Choose the right abstraction. Decide what concepts the system should expose and which details should remain hidden.
2. Trace the data. Know where information enters, how it changes, where it persists, and who can access it.
3. Model user state. Understand what users can do before, during, and after every consequential action.
4. Define invariants. State what must always be true, including under retries, partial failure, concurrency, and invalid input.
5. Design the evidence. Decide which tests, benchmarks, screenshots, traces, and manual checks would make the result trustworthy.
6. Concentrate review by risk. Inspect the parts where a subtle mistake can create security, data, financial, or product harm.

You can delegate implementation without delegating these decisions. In fact, higher implementation throughput makes them more important because a weak idea can now become a large system before anyone notices the premise was wrong.

The verification gradient

Some domains are far more vibe-codable than others. The key variable is not how impressive the generated result looks. It is how completely the important behavior can be verified.

This produces a counterintuitive result: a complicated pure function may be safer to delegate than a simple-looking onboarding flow.

The pure function can have an explicit contract, thousands of generated cases, a reference implementation, and a measurable performance ceiling. The onboarding flow can pass every automated test and still confuse users, create the wrong expectation, or make an irreversible action feel harmless.

Verifiability is not the same as simplicity. It is the degree to which evidence can tell you that the system is correct.

A practical risk matrix

The second variable is blast radius. Combine it with verifiability and the appropriate workflow becomes clearer.

A personal calculator with strong tests sits in the upper-left. A payment permission change sits in the lower-right. A marketing page may have low security risk but still require human visual judgment. A data migration may be mechanically testable yet carry an enormous blast radius.

The more mechanically verifiable the domain, the more implementation can be delegated. The higher the blast radius and the weaker the verification, the less acceptable pure vibe coding becomes.

The first prompt, the twentieth change, and the first incident

Vibe coding feels transformative at the first prompt because it compresses the distance between an idea and something tangible. A founder can test a workflow, a marketer can create a calculator, and a developer can explore an unfamiliar library without assembling every piece manually.

The twentieth change is a better test of engineering quality. A lead tracker that began as a form and a list may accumulate accounts, roles, filters, notifications, imported contacts, custom fields, permissions, and duplicate handling. Each prompt is simple. Together they form a stateful system.

At that point, ask:

• Is the data model still coherent?
• Can a new change break an older path without being detected?
• Are user roles and state transitions explicit?
• Can you recover from a bad change without losing later work?
• Are architectural decisions stored somewhere more durable than chat history?
• Can another person understand the system from its code, tests, and documentation?

The first incident reveals who owns the result. It may be a user seeing someone else’s record, a form silently losing submissions, a deployment failing after a dependency change, or a secret reaching client-side code.

When that happens, the quality of the original prompt matters less than whether the team knows where the logs, data, permissions, secrets, backups, and rollback controls live.

Why security changes the acceptable workflow

Pure frontend work is unusually friendly to vibe coding because visible behavior often captures much of the requirement. If a low-stakes interactive effect looks correct across relevant browsers and inputs, “seems to work” can be close to “does work.” It is not identical, but the remaining gap may be bounded.

Security-sensitive work has the opposite shape. Authentication can appear to work while allowing an unauthorized path. Data storage can work perfectly until a retry duplicates an irreversible action. A permissions UI can show the correct controls while the server fails to enforce them.

The danger is not that every AI-generated line is defective. It is that the same agent can generate the implementation, the tests, and the explanation, creating several correlated forms of confidence around one mistaken assumption.

OWASP’s secure-coding guidance for AI recommends independent verification for security-sensitive code. A 2026 study of vibe-coded applications also found recurring patterns such as placeholder logic, unfiltered input, and exposed secrets, while better prompting reduced but did not remove the risks. Read the application-security study.

For authentication, authorization, payments, private data, migrations, and destructive operations, the human owner should define the threat model and permission model before asking an agent to implement them. Generated tests are useful evidence, but they are not the final authority.

What is vibe coding good for?

Vibe coding is strongest where feedback is fast, failure is recoverable, and important behavior can be checked.

Prototypes and product discovery

This remains the clearest fit. Use an agent to make an idea clickable, discover missing requirements, and decide whether the workflow deserves further investment. The prototype succeeds when it produces learning, even if its code is discarded.

Pure logic and bounded automation

Calculators, transforms, parsers, data-cleaning steps, and other narrow functions can be excellent candidates when the contract can be expressed as tests. The implementation may be complex while the evidence remains unusually strong.

Personal and internal utilities

A private dashboard, file converter, or small team workflow can be reasonable when access is constrained, the system of record remains elsewhere, and replacement is inexpensive.

Public, mostly static websites

Marketing pages, portfolios, event sites, and lead-generation pages offer fast visual feedback and a bounded application surface. A website builder may be a better fit than a general coding agent when brand fidelity and human editing matter more than owning a custom stack.

Moda belongs in this adjacent category. It can build and host design-led public websites, but it is not an application platform for accounts, private application data, or custom backend behavior. Our guide to Lovable alternatives by project type explains that boundary.

When should you not vibe code?

Pure vibe coding is a poor default when failure can materially harm users or the organization. Use an accountable engineering process for:

• Authentication, authorization, payments, and security controls
• Sensitive personal, financial, or health data
• Safety-critical or regulated workflows
• Complex migrations and irreversible operations
• High-traffic services with strict reliability requirements
• Shared systems that a team must maintain for years

AI can still do substantial implementation work in these domains. The requirement is stronger ownership, stronger independent evidence, and more selective expert review.

Vibe coding is not the same as no-code

No-code tools usually expose a constrained visual or declarative model. Vibe-coding tools ask an AI to generate or manipulate code. The boundary is increasingly untidy because app builders now mix prompts, visual editing, managed backends, and code access.

The practical distinction is not whether code exists. It is what users can inspect, what the platform constrains, and what the owner must operate.

How to vibe code responsibly

Do not make the process heavier than the project. Match the evidence to the stakes.

1. Write the invariants first. State who can do what, what data must persist, and what must never happen.
2. Ask for a system map. Identify components, data stores, external services, trust boundaries, and major state transitions.
3. Keep the first scope narrow. Build one coherent path before adding roles, integrations, and automation.
4. Make changes recoverable. Use version history, checkpoints, branches, or a repository before rapid iteration creates a valuable but mysterious state.
5. Test outside the happy path. Include invalid input, retries, interruptions, repeated actions, missing permissions, and partial service failure.
6. Demand evidence suited to the domain. Use unit tests and benchmarks for logic, screenshots and interaction tests for visual work, and explicit threat models for sensitive systems.
7. Separate creation from verification. Do not rely only on the same agent’s tests and explanation of its own implementation.
8. Review by risk. Spend human attention on permissions, persistence, concurrency, migrations, external boundaries, and confusing user states.
9. Plan the handoff before launch. Determine what a new engineer would receive and what knowledge exists only in the conversation.

GitHub’s guide recommends reviewing output, running tests, checking dependencies, and cleaning up generated code. Those practices do not negate vibe coding. They are how it matures from a playful interaction into a reliable production method.

The future of coding is supervised generation

The future of software is unlikely to be “no code.” Code will remain a precise, durable, executable artifact. But fewer humans will personally write or read every line of it.

The emerging workflow is supervised generation. Humans define the system, delegate implementation, inspect evidence, probe weak assumptions, and intervene where risk concentrates. Agents generate, test, explain, and revise at a scale that would make exhaustive manual review impractical.

This raises the ceiling for what small teams can build, but it also punishes fuzzy thinking. If implementation is cheap, the bottleneck becomes deciding what should exist, how it should behave, and what would prove that it works.

Vibe coding is not the end of engineering. It is the end of treating code production as the center of engineering.

Frequently asked questions

Who invented the term vibe coding?

Andrej Karpathy coined the term in February 2025 while describing an experimental workflow in which he prompted an AI, accepted its changes, ran the result, and paid little attention to the generated code.

Do you need to know how to code to vibe code?

Not necessarily for simple prototypes or managed app builders. Technical understanding becomes increasingly valuable as the project accumulates users, data, integrations, edge cases, and operational risk. The most durable skills are understanding abstractions, data flow, state, logic, and verification rather than memorizing syntax.

Is vibe coding safe?

It can be appropriate for low-consequence, recoverable work. Safety-sensitive projects need independent verification and accountable technical ownership, especially around authentication, permissions, payments, private data, migrations, and destructive actions.

Is using Cursor, Claude Code, or Codex always vibe coding?

No. The same agents can support pure vibe coding or disciplined engineering. The difference is whether the user judges only the visible result or also owns the specification, architecture, evidence, security, and operation of the system.

Will vibe coding replace software engineers?

It is more likely to change the unit of engineering work. Less time goes to producing routine code, while more value moves to system design, product judgment, verification, debugging, and risk management. People who can reason clearly about systems can use agents to operate at much greater scale.