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
- Core practice: specify intent, accept generated code, run the result, feed back failures, and iterate conversationally.
- Strict meaning: stronger than ordinary AI-assisted programming because the builder may not continuously inspect or understand every generated line.
- Best fit: exploration, prototypes, learning exercises, disposable scripts, UI sketches, internal mockups, and low-stakes automation.
- Handoff trigger: once code touches users, money, credentials, records, public services, regulated data, or another person's workflow, it needs ordinary software-engineering evidence.
- Primary risk: executable software can look correct before the builder understands its data flow, dependencies, failure modes, security posture, or maintenance burden.
- Governance rule: do not ask whether the code was "vibe coded" in the abstract; ask what was verified, by whom, under which permissions, and with what record.
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:
- Purpose and boundary: what the code is for, who will use it, what data it handles, and what it must not do.
- Generation record: tool or model used, prompt summary where appropriate, files changed, commands run, packages added, and whether an agent had shell, browser, network, or repository write access.
- Review record: human owner, reviewer, code areas inspected, architecture assumptions checked, security-sensitive paths reviewed, and known gaps.
- Evidence record: tests run, tests missing, lint and type-check results, static-analysis output, dependency and license checks, secrets scan, accessibility check where relevant, and manual behavior checks.
- Operations record: deployment path, configuration, credentials touched, rollback plan, logging, monitoring, data retention, user notice, and incident contact.
- Decision record: whether the artifact remains a prototype, is accepted for internal use, is approved for production, or is rejected pending engineering work.
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
- Treat generated code as untrusted until it has passed human review, tests, static analysis, dependency review, license review where relevant, and secrets scanning.
- Keep a source trail: prompt, model or product, tool surface, files changed, commands run, packages added, tests passed, tests skipped, known failures, and human reviewer.
- Separate prototypes from production systems. A vibe-coded demo should not silently become infrastructure, customer software, a regulated record, or an internal dependency.
- Require human ownership for authentication, authorization, payments, user data, deployment, infrastructure, public communication, destructive operations, and anything that affects another person's rights or records.
- Use least privilege for coding agents: narrow filesystem scope, deny secrets by default, restrict network access, require approvals for shell commands and file writes, and keep deployment credentials out of exploratory runs.
- Prefer small diffs, typed interfaces, tests, linting, reviewable commits, and branch protection over large opaque code drops.
- Verify every dependency: package name, maintainer, registry, version, license, vulnerability status, install script behavior, and whether the package actually exists for the target ecosystem.
- Require provenance for copied snippets, generated assets, model-produced boilerplate, and dependency changes when licensing, security, or auditability matter.
- Run realistic tests before handoff: unit tests, integration paths, error states, browser-console checks, accessibility checks, privacy checks, and abuse cases that matter for the actual use.
- Do not paste secrets, customer data, regulated data, private keys, production logs, or proprietary code into unapproved tools. Use synthetic data and isolated environments when possible.
- Teach beginners to read and debug the generated code, not only to prompt around it. AI can support apprenticeship only when it exposes the reasoning and standards behind the fix.
- Measure downstream rework, incidents, review time, security findings, rollback frequency, and maintainability when claiming productivity gains.
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
- Which vibe-coded artifacts should be treated as disposable prototypes, and which should trigger formal engineering review?
- How should teams teach debugging and architecture when beginners can generate working-looking systems before they can read them?
- What evidence should accompany an AI-generated patch before another person is asked to review, merge, or deploy it?
- Can coding agents make verification cheaper, or do they mainly move verification work into a new queue?
- How should liability and incident review work when a non-programmer creates software that other people rely on?
Related Pages
- AI Coding Agents
- AI Agents
- Claude
- OpenAI
- Anysphere (Cursor)
- SWE-bench
- Workslop
- AI Slop
- Shadow AI
- Secure AI System Development
- Prompt Injection
- Model Context Protocol
- Agentic Supply Chain Vulnerabilities
- AI Agent Sandboxing
- AI Agent Identity
- AI Agent Observability
- AI Audit Trails
- AI Bill of Materials
- AI Data Provenance
- AI Hallucinations
- Automation Bias
- AI Evaluations
- Human Oversight of AI Systems
- AI Literacy
- AI Change Management
- AI in Employment
- AI Liability and Accountability
- Agent Tool Permission Protocol
- Agent Audit and Incident Review
- Claim Hygiene Protocol
- Vendor and Platform Governance
- The Erosion of Apprenticeship
Sources
- Collins Dictionary, Vibe coding definition, reviewed June 25, 2026.
- Collins Dictionary, The Collins Word of the Year 2025, reviewed June 25, 2026.
- Andrej Karpathy, X post popularizing "vibe coding", February 2, 2025; authentication may be required.
- Advait Sarkar and Ian Drosos, Vibe coding: programming through conversation with artificial intelligence, arXiv, submitted June 29, 2025; revised October 3, 2025.
- Google Cloud DORA, State of AI-assisted Software Development 2025, reviewed June 25, 2026.
- GitHub, Octoverse 2025: A new developer joins GitHub every second as AI leads TypeScript to #1, 2025.
- Stack Overflow, 2025 Developer Survey: AI, reviewed June 25, 2026.
- Stack Overflow, 2025 Developer Survey press release, July 29, 2025.
- OpenAI Developers, Codex glossary, reviewed June 25, 2026.
- Anthropic Claude Code Docs, Configure permissions, reviewed June 25, 2026.
- Anthropic Engineering, How we built Claude Code auto mode: a safer way to skip permissions, March 2026.
- GitHub Docs, About GitHub Copilot cloud agent, reviewed June 25, 2026.
- Google, Jules - An Autonomous Coding Agent, reviewed June 25, 2026.
- Cursor, Cursor product page, reviewed June 25, 2026.
- Hao Li, Haoxiang Zhang, and Ahmed E. Hassan, AIDev: Studying AI Coding Agents on GitHub, arXiv, February 2026.
- Joseph Spracklen et al., We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs, arXiv, June 2024; USENIX Security 2025.
- OpenSSF Best Practices Working Group, Security-Focused Guide for AI Code Assistant Instructions, August 1, 2025.
- OWASP Foundation, Top 10 for Large Language Model Applications, reviewed June 25, 2026.
- OWASP GenAI Security Project, OWASP Top 10 for Agentic Applications for 2026, December 9, 2025.
- UK NCSC, CISA, NSA, FBI, and international partners, Guidelines for Secure AI System Development, November 2023.
- NIST, SP 800-218A: Secure Software Development Practices for Generative AI and Dual-Use Foundation Models, July 2024.
- NSA, CISA, NCSC-UK, and international partners, Careful Adoption of Agentic AI Services, April 2026.