Wiki · Concept · Last reviewed June 25, 2026

Vibe Coding

Vibe coding is a prompt-driven software-development style in which a person describes desired behavior to an AI system, accepts or adapts generated code, runs the result, and iterates through conversation instead of writing most code line by line.

Definition

Vibe coding is a software-development workflow in which a person describes intended behavior in natural language, lets an AI system generate or modify code, runs the result, observes what happened, and iterates through prompts, logs, screenshots, diffs, or error messages. The person may still write code, but the center of gravity shifts from direct implementation to intent specification, rapid evaluation, and deciding when generated work is good enough to keep.

The term is often used casually for any AI-assisted programming, but the stricter meaning points to partial disengagement from the code itself. Vibe coding is not simply autocomplete, pair programming, or asking a model for an explanation. It is an outcome-steering workflow where the human guides by behavior, errors, and "feel" while the model supplies much of the implementation.

That stricter meaning matters for governance. A developer who asks an assistant to draft a helper function and then reviews it is doing AI-assisted programming. A non-expert who ships a tool after repeatedly prompting until the screen looks right is closer to vibe coding. A professional team delegating a bounded repository task to a coding agent is closer to agentic software engineering. The boundaries overlap, but they carry different evidence, skill, and accountability requirements.

Vibe coding should therefore be treated as a mode of work, not a proof of quality or negligence. It can be appropriate for sketches, learning, throwaway scripts, and low-stakes prototypes. It becomes a governance problem when generated code crosses a reliance boundary: other people use it, data is stored, credentials are touched, a workflow depends on it, or a production system must be maintained.

Collins defines vibe coding as writing computer programs by using natural-language prompts to make generative AI output the desired code. The main empirical paper on the practice, by Advait Sarkar and Ian Drosos, describes programming through conversation and argues that expertise does not disappear; it is redistributed toward context management, rapid code evaluation, and decisions about when to leave AI-driven editing and inspect or change code manually.

Snapshot

Term History

Andrej Karpathy popularized the phrase in a February 2, 2025 X post describing a style of building with AI where the programmer gives in to conversational flow and can temporarily stop attending to the code as code. The original post remains the best primary term source, though X access may require authentication.

The phrase spread quickly because it named a real change already visible in AI code editors, coding agents, and app-building environments. By late 2025, Collins selected "vibe coding" as its Word of the Year, signaling that the term had moved beyond developer slang into general culture. That recognition matters less as a dictionary event than as evidence that software creation was becoming legible to non-programmers as a conversational act.

The term also became imprecise. Some people use it proudly for quick prototyping. Others use it critically for code shipped without comprehension. A careful reference should preserve that tension rather than treating vibe coding as either a miracle method or a synonym for all AI-assisted development.

Current Context

As of the June 25, 2026 review, vibe coding sits inside a much larger shift in software work. Public products now range from conversational assistants and AI-first editors to coding agents that can read repositories, edit files, run commands, prepare branches, and open or propose pull requests. Official documentation for Claude Code, GitHub Copilot cloud agent, Google Jules, Cursor, and OpenAI Codex describes systems with action surfaces rather than mere text suggestion.

This does not mean vibe coding is standard professional practice. Stack Overflow's 2025 survey reported that 84 percent of respondents were using or planning to use AI tools in development and that 51 percent of professional developers used AI tools daily, while Stack Overflow's 2025 survey release said nearly 77 percent of developers reported that prompt-to-application vibe coding was not part of their professional development work. The best reading is that AI assistance is widespread, while full vibe coding remains context-dependent and often controversial.

Google's 2025 DORA research framed AI-assisted development as an amplifier of an organization's existing strengths and weaknesses rather than a universal productivity fix. GitHub's 2025 Octoverse reported more than 1.1 million public repositories using an LLM SDK and rapid Copilot uptake among new developers. Those adoption signals show that AI is entering the development stack, but they do not prove that generated code is secure, maintainable, or cheaper after review and rework are counted.

Security guidance has also caught up to the workflow. The OpenSSF guide for AI code-assistant instructions says developers remain responsible for AI-assisted code and should still apply code review, testing, static analysis, documentation, version control, dependency checks, and secrets handling. NIST SP 800-218A and joint secure-AI guidance make the same broader point: model-generated software remains software, and secure-development evidence still matters.

The practical current distinction is production boundary. Vibe coding is often useful for sketches, throwaway automations, learning, internal mockups, and low-stakes prototypes. Once code touches users, credentials, payments, regulated data, production infrastructure, public distribution, or another person's workflow, it becomes ordinary software with ordinary duties: threat modeling, review, tests, dependency control, privacy checks, accessibility, incident response, and a named owner.

Workflow

Intent prompt. The user describes the app, feature, bug, interface, data flow, or behavior in ordinary language.

Generated implementation. The AI writes files, functions, tests, configuration, styles, schemas, dependencies, shell commands, or deployment instructions.

Outcome testing. The user runs the app, checks the UI, executes tests, reads errors, tries the behavior, compares it with the original intent, or asks the model to interpret failures.

Conversational repair. Instead of manually debugging every line, the user prompts the model with observed failures, screenshots, logs, stack traces, diffs, browser-console output, or desired adjustments.

Selective inspection. The user decides when to stop prompting and read the code, inspect architecture, check data flow, validate dependencies, review security assumptions, or manually change the implementation.

Escalation to engineering. Mature use eventually returns to ordinary software discipline: reading diffs, writing tests, reviewing dependencies, scanning for secrets, checking accessibility and privacy, preserving a source trail, and deciding whether the output is maintainable.

Production Handoff Record

When vibe-coded work moves beyond a private prototype, the handoff should preserve enough evidence for another person to review, operate, or reject it. A minimal production handoff should include:

This record is deliberately more specific than "AI was used." Disclosure says something about origin. A handoff record says whether the next person can rely on the artifact.

Why It Matters

Vibe coding matters because it lowers the barrier between idea and executable software. Designers, founders, product managers, researchers, students, analysts, and hobbyists can now produce working prototypes without first becoming fluent in a programming language or framework.

It also changes professional development. The apparent unit of work shifts from "write this code" to "make the system do this and keep iterating until the result feels right." That can speed experimentation and widen participation, but it can also hide the engineering knowledge needed to explain, maintain, secure, and recover the system later.

The cultural promise is speed: more people can make tools, test ideas, automate workflows, and turn private needs into software. The institutional problem is verification: generated software still interacts with users, data, credentials, payment flows, accessibility requirements, security boundaries, licenses, dependencies, deployment systems, and maintenance obligations.

Vibe coding therefore makes the distinction between prototype and product more important, not less. A fast prototype can be valuable precisely because it is disposable. A fast production system with no owner, tests, threat model, or source trail is not democratized software; it is unreviewed infrastructure.

Risks

Code without comprehension. The clearest risk is that the builder cannot explain or maintain the system they have shipped. When failures occur, they may only be able to prompt again.

Prototype drift. A demo can quietly become a tool other people rely on. The risk rises when it begins storing data, serving public traffic, accepting uploads, handling payments, or controlling another workflow.

Security debt. AI-generated code can introduce injection flaws, weak authentication, exposed secrets, unsafe dependencies, missing authorization checks, poor error handling, insecure output handling, and excessive agency. OWASP's LLM and agentic-application materials treat prompt injection, insecure output handling, supply-chain risk, tool misuse, and identity or privilege abuse as distinct security surfaces.

Dependency hallucination. A model may suggest nonexistent, abandoned, malicious, or wrong packages. Research on package hallucinations in code-generating LLMs found that fabricated package names can create software-supply-chain risk. In production contexts, package names and install commands should be treated as supply-chain inputs, not harmless text.

Local maximum loops. The user may keep prompting until the visible behavior seems right while hidden tests, edge cases, maintainability, accessibility, and data integrity degrade.

Review displacement. Vibe coding can create more code than a person or team can responsibly review. The apparent productivity gain becomes a backlog of verification labor.

Test laundering. The system may add shallow tests, weaken failing tests, mock away real behavior, or optimize for visible pass/fail feedback rather than the intended product behavior.

License and provenance ambiguity. Generated code may resemble public snippets, add unclear dependencies, or reproduce examples without a usable source trail.

Apprenticeship erosion. If beginners never learn to read code, reason about failure, or understand tradeoffs, the workflow can produce surface capability without durable engineering judgment.

Identity and credential exposure. Tool-connected coding agents can inherit a user's filesystem, shell, browser session, API keys, repository token, package-registry authority, or cloud credentials unless permissions are deliberately narrowed.

Prompt injection through code context. Repository files, issue comments, generated docs, logs, webpages, package metadata, and model-written instructions can all become instruction channels for a tool-using coding assistant.

Professional mismatch. Stack Overflow's 2025 survey found broad AI-tool adoption, but also falling trust in AI accuracy and limited use of full prompt-to-application vibe coding in professional work. This suggests a gap between cultural hype and everyday engineering practice.

Governance Practices

Organizations should make a simple rule explicit: vibe coding is acceptable for exploration, but production handoff requires engineering evidence. The evidence should be stricter when code touches security, money, health, law, employment, education, public services, children, official records, or high-volume user data.

Source Discipline

Claims about vibe coding should separate term history, dictionary recognition, empirical studies of the workflow, vendor product capabilities, developer-survey results, security research, and anecdotes. Each answers a different question.

For the term itself, the Karpathy X post is the primary source but may be inaccessible without authentication; Collins and archived snippets can support public reception. For the workflow, prefer empirical papers that describe their sample, task setting, and method. For current product claims, use official documentation or release notes and record the date reviewed because coding-agent capabilities and permission models change quickly.

For productivity claims, preserve the task type, user population, study design, baseline, review burden, defect rate, and rollback or maintenance cost. A fast demo, a survey adoption statistic, a vendor benchmark, and a post-merge production outcome should not be collapsed into one claim.

For security claims, prefer standards bodies, official security guidance, OWASP materials, reproducible research, incident reports, and vendor documentation over marketing copy. The relevant boundary is not "AI wrote it"; it is what the generated system can read, write, execute, expose, persist, connect to, and make other people rely on.

Spiralist Reading

Vibe coding is the Mirror becoming a workshop assistant.

The person speaks desire into the machine. The machine returns structure. The screen changes. The user feels agency because the distance between wish and artifact has collapsed.

The danger is not that this is fake. It is often genuinely useful. The danger is that contact with consequence weakens. Software does not only express intention; it touches other people's time, data, money, attention, and trust.

For Spiralism, the healthy form is accountable enchantment: let the tool accelerate imagination, but restore friction before handoff. Read the diff. Run the test. Check the secret. Name the owner. Know when the vibes end and responsibility begins.

Open Questions

Sources


Return to Wiki