What is vibe coding?

Vibe coding is a way of building software where you steer an AI assistant with natural language—describing intent, reviewing diffs, running tests, and iterating—instead of typing every line yourself. The phrase went viral in early 2025; for engineering teams, the useful question is not whether to use AI, but how much review and ownership you keep while moving faster.

Who coined vibe coding?

Andrej Karpathy introduced the term in February 2025, building on his earlier idea that English is becoming a programming language—you describe what you want, and models translate that into code.

His original framing was deliberately playful: you "fully give in to the vibes," accept AI suggestions, paste errors back into the chat, and let the codebase grow beyond your usual comprehension. That meme definition spread fast through social media and tools marketed for "build an app in a weekend."

The term stuck because it names something real: a generation of developers who default to conversation with an assistant as the primary interface to a codebase, not only to autocomplete on the current line.

Two meanings: meme vs engineering

Not every use of Copilot, Cursor, or Claude in the IDE is vibe coding in Karpathy's sense. Simon Willison drew a useful line: if you read, test, and understand the code the model wrote, that is responsible AI-assisted programming; vibe coding, in the strict sense, is when you refrain from checking and let the assistant drive.

Aspect	Meme vibe coding	Engineering vibe coding
Prompts	Vague, exploratory	Outcomes, constraints, file scope
Code review	Often skipped	Diff review, same bar as human code
Testing	"Paste the error back"	Automated tests, CI, local runs
Ownership	"Forget the code exists"	You own architecture, security, merges
Best for	Throwaway demos, learning	Production features with guardrails

WavePillars recommends the right column for anything that ships: keep the speed and intent-first workflow, but not the autopilot mindset.

How vibe coding works in practice

A productive loop looks like this:

State intent — what should change, for whom, and what must not break (APIs, auth, performance).
Scope the task — one module, one file, or one vertical slice; avoid "rewrite the app."
Let the assistant propose — implementation, tests, or refactors as a diff you can inspect.
Verify immediately — run tests, lint, hit the endpoint, read the diff for security and conventions.
Iterate or merge — small follow-up prompts; you approve merges and production config.

Tools such as Cursor, GitHub Copilot, Claude, and VS Code agents all support this loop. Differences are mostly UX: inline edits vs chat vs multi-file agents, plan mode vs agent mode, and how well the tool sees your repo (indexing, rules, MCP servers).

Practices that make the loop reliable

Use plan mode or a short spec for non-trivial work before large diffs land. For a structured approach, see What is spec-driven development (SDD)?.
Attach constraints the model cannot infer: "no new dependencies," "keep existing error shape," "must pass npm test."
Prefer small prompts over one giant request; each step should be verifiable.
Treat assistant output as draft code until tests and review say otherwise.

Where MCP fits

Chat alone cannot safely reach your database, CRM, or internal APIs. Assistants need structured context and actions—that is what Model Context Protocol (MCP) standardizes: tools for actions, resources for read-only context, prompts for repeatable workflows. See What is the MCP Protocol? for the full picture.

You (intent)  →  IDE / Claude / Cursor  →  MCP tools  →  Docs, APIs

Vibe coding + MCP means you still describe intent in natural language, but the assistant invokes audited, typed tools instead of hallucinating API shapes or asking you to paste secrets. That is especially valuable when vibe coding would otherwise stop at "generate a client for our REST API" without access to the real spec or staging environment.

Concrete patterns:

Resources — attach OpenAPI specs, runbooks, or schema descriptions so the model grounds answers in your systems.
Tools — lookup_order, create_ticket, run_readonly_query with explicit auth and logging.
Prompts — team workflows like /security-review or /incident-triage with fixed structure.

To build or deploy MCP servers yourself, continue with Building MCP Server Using .NET and Run MCP Server in Docker.

Core ideas

Intent-first — Start with outcomes and constraints; let the assistant propose implementation details you validate.
Tight feedback loops — Small prompts, immediate runs, fast correction; avoid long unverified chains of generated code.
Human ownership — You remain responsible for architecture, security, data handling, and merges—the assistant does not sign the release.

When it helps—and when to slow down

Good fits

Greenfield modules, UI prototypes, and spike solutions
Boilerplate: tests, DTOs, config scaffolding, adapter stubs
Exploring unfamiliar APIs or frameworks with a tight read-review-run cycle
Refactors where behavior is covered by existing tests

Slow down or avoid pure "vibes"

Authentication, authorization, and secrets handling
Payments, PII, and regulatory scope (HIPAA, PCI, SOC2)
Performance-critical paths without benchmarks
Changes to shared libraries used by many teams without design review

Use the meme style for learning and demos; use engineering vibe coding for anything users depend on.

Benefits

Faster exploration of APIs and frameworks—you try ideas in minutes, not days of boilerplate.
Less mechanical typing for tests, configs, migrations, and repetitive adapters.
More time for design — reviews, observability, and production hardening move up the queue when implementation drafts arrive faster.
Lower cost to iterate on product direction when the assistant handles syntactic churn.

Example: you describe "add integration tests for the checkout happy path with our existing test harness"; the assistant scaffolds cases and mocks; you adjust assertions and merge after CI passes.

Risks to manage

Hallucinated APIs — libraries, method names, or config keys that do not exist; always run the project and read diffs.
Secret leakage — tokens or credentials pasted into prompts or committed in generated env samples.
Dependency sprawl — the model adds packages you did not approve; lock versions and scan licenses.
Convention drift — naming, folder layout, and error handling diverge from the repo without lint rules and CI.
Over-reliance — shipping code you cannot debug at 2 a.m.; if you cannot explain a change, do not merge it.

Mitigate with the same controls you use for human contributors: lint, typecheck, tests, code review, and secret scanning.

Practices that work

Keep prompts scoped to one module or file when possible.
Require tests for generated logic—especially branches that touch money, auth, or data writes.
Use the same code review bar as human-written code; no "AI exemption" in pull requests.
Document decisions the model cannot infer: SLAs, compliance rules, allowed dependencies, deployment constraints.
Add project rules (for example .cursor/rules, AGENTS.md) so assistants inherit team conventions.
Wire CI and lint on every branch; generated code must pass before merge.
Prefer MCP tools over pasting production data or credentials into chat for system access.

Team adoption

Rolling vibe coding out across a team is less about tools and more about shared expectations:

Agree when AI-generated code is allowed (all PRs vs spikes only) and what review evidence is required (tests, security checklist).
Publish rules and examples in the repo so every assistant session sees the same patterns.
Track incidents and revert rate on AI-heavy PRs; tune prompts and rules when quality slips.
Train people on effective prompting and on when not to vibe—same as any new framework adoption.

Leads should model diff review in PRs and call out good vs risky assistant output so the culture stays disciplined collaboration, not speed at any cost.

Summary

Vibe coding names a real shift: natural language and fast iteration as the default path to code. Karpathy's meme version—trust the vibes, skip the details—is a useful warning about what goes wrong at scale. For production engineering, keep intent-first speed, tight loops, tests, review, and human ownership of merges.

Teams that treat AI as a pair programmer, not a black box, move faster without lowering the bar. That is vibe coding as disciplined collaboration with assistants, not autopilot generation.