How intent-first programming is reshaping who builds software, what gets shipped, and what it means to be a developer in 2026
1. Introduction: The Shift from Writing Code to Steering Software
For most of computing history, programming meant a solitary act of translation. You had an idea in your head — a feature, a fix, a system — and your job was to render that idea into syntax a machine could execute. You typed. You debugged. You reasoned through loops, conditionals, and data structures, line by painstaking line. The measure of a programmer was command: over language, over logic, over the cascading consequences of every change.
That model is collapsing.
Not disappearing — collapsing into something smaller, more specialized, more elevated. The act of typing code is becoming less central to software creation, the way the act of setting type became less central to publishing after desktop software arrived. The underlying discipline is not gone; it has just moved up the stack.
What’s replacing line-by-line authorship, at least for a widening class of tasks, is something that looks less like craftsmanship and more like direction. You describe what you want. You run the result. You react to what you see. You describe again. The machine — increasingly, an AI agent capable of reading codebases, writing files, running tests, and iterating across multiple steps — does the implementation. Your job is to steer, constrain, test, and decide what is safe to ship.
Google Cloud describes this shift as a workflow where “the human role shifts from line-by-line coding to guiding an AI assistant conversationally.” OpenAI has described the broader progression as a movement from autocomplete to agents that can scaffold entire projects, reason through multi-step tasks, and execute workflows in sandboxed environments. Anthropic’s own tooling — Claude Code — is explicitly built for agentic operation: understanding codebases, working across files, and completing tasks that once required sustained human attention.
The old model: programming as syntax, logic, debugging, and systems design — a discipline that required years of practice before you could ship anything non-trivial.
The new model: programming as prompting, steering, testing, and constraint-setting — a discipline that rewards people who can think clearly about what they want, catch what looks wrong, and know enough to ask better questions.
For non-programmers, this feels radical. Millions of people who had ideas but lacked the skills to execute them can now build working software in hours. The barrier to entry has dropped from “learn to code” to “learn to describe.”
For experienced engineers, the reaction is more complicated. The productivity ceiling for certain tasks has shot upward. What once took a week of implementation can take an afternoon of prompting. But the floor — the floor of code quality, security, maintainability, and architectural coherence — has also dropped, and dropped fast, for anyone who mistakes the ease of generation for a guarantee of quality.
The thesis of this guide: Vibe coding is not just “coding with AI.” It is a shift in where human effort sits: less in typing and syntax, more in framing problems, setting constraints, checking outputs, and deciding what is safe to ship. Understanding what that shift means — where it works, where it fails, and what it demands of the people using it — is the central challenge of software development in 2025 and 2026.
2. The Origin Story: Where the Term Came From and Why It Spread
On February 2, 2025, Andrej Karpathy — co-founder of OpenAI, former head of AI at Tesla, and one of the most respected figures in the field — posted something on X that would escape the developer bubble faster than almost anything he had written before.
“There’s a new kind of coding I call ‘vibe coding,'” he wrote, “where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It’s possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper so I barely even touch the keyboard.”
He went on to describe his specific workflow: making requests like “decrease the padding on the sidebar by half” because he was too lazy to find it himself. Accepting all changes without reading the diffs. Copying error messages directly into the model when something broke, without explanation, usually getting a fix. Watching the codebase grow beyond his usual comprehension. Sometimes just asking for random changes until a stubborn bug went away.
“It’s not too bad for throwaway weekend projects, but still quite amusing,” Karpathy wrote. “I’m building a project or webapp, but it’s not really coding — I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.”
The post was playful. It was honest. It was confessional in a way that most prominent technologists avoid. And it named something millions of people were already doing without a word for it.
Within weeks, the term was everywhere. The New York Times covered it. So did Ars Technica, The Guardian, and hundreds of online communities. Merriam-Webster listed it in March 2025 as a “slang & trending” expression, noting that its first known use dated to that February post. By the end of 2025, Collins English Dictionary had named it Word of the Year for 2025 — a remarkable journey from a single X post to a dictionary entry in under twelve months.
Why did the phrase land so hard? Several reasons, compounding on each other.
First, it was genuinely playful. “Vibe coding” doesn’t sound like a technical term. It sounds like something you do on a Sunday afternoon when you don’t feel like thinking too hard. That levity was intentional and liberating — it gave people permission to admit that they were building software this way, without pretending it was rigorous software engineering.
Second, it was accurate. Karpathy captured a real workflow change with a memorable phrase, which is the exact recipe for a concept going viral. Millions of people recognized themselves in his description.
Third, it connected to a bigger idea Karpathy had been developing for years. In 2023, he had argued that “the hottest new programming language is English” — meaning that the capabilities of LLMs had advanced to the point where natural language was becoming a legitimate interface for commanding computers. Vibe coding was that idea made concrete, made personal, made funny.
Fourth, and most importantly, the term compressed several enormous ideas into one catchy label: natural-language programming, AI copilots becoming agents, dramatically reduced friction for non-coders, and a fundamentally different relationship to code as an artifact. Code stops being the thing you create and becomes the thing the AI creates while you supervise.
The speed of adoption from X post to dictionary entry — roughly twelve months — is itself a signal. The phrase succeeded not just because it was clever but because it named something that was already happening at scale. People were already vibe coding. They just hadn’t had a word for it.
3. What Vibe Coding Actually Means
Here is where clarity matters, because the term is already splintering into multiple definitions that are pulling in different directions.
The strict, original definition — the one Karpathy articulated — describes a workflow where you steer by intent and outcomes rather than by reading, testing, and understanding every line of code. Karpathy’s version is explicitly casual: he doesn’t read the diffs, he accepts all changes, and he’s building throwaway weekend projects, not production systems.
As Wikipedia’s vibe coding article summarizes it: “Acceptance of AI-generated code without understanding it is key to the definition of vibe coding.”
Simon Willison, one of the most thoughtful practitioners writing about AI-assisted programming, put it with characteristic precision: “If an LLM wrote every line of your code, but you’ve reviewed, tested, and understood it all, that’s not vibe coding in my book — that’s using an LLM as a typing assistant.”
That’s the strict definition: the acceptance of AI-generated code without deep comprehension. The vibes are not metaphorical. You are genuinely proceeding on feel, on behavioral confirmation that the thing works, rather than on understanding of why it works.
The popular, looser definition that has spread through tech culture in 2026 is different. In everyday usage, “vibe coding” now often refers to almost any prompt-driven software creation workflow — from complete novices asking Cursor or Replit to build an entire app, to experienced engineers using Claude or GPT-4 to scaffold the boring parts of a project while they focus on the interesting parts. In this broader sense, it’s essentially a synonym for “building software primarily through natural language prompting.”
This widening of the definition is real, and it matters. It matters for journalism, which often conflates casual weekend experiments with professional AI-assisted engineering. It matters for enterprise decision-making, where leaders are trying to evaluate whether “vibe coding” is something their teams should be doing. And it matters for security assessments, where the gap between “I don’t really understand this code” and “I professionally reviewed and tested this code with AI assistance” is enormous.
A clean synthesis of the available definitions: Vibe coding is a style of software creation in which a human primarily expresses intent in natural language while an AI system generates and revises most of the implementation; in its strictest sense, it also implies a willingness to proceed without fully understanding the code.
This is consistent with Karpathy’s original usage, with Merriam-Webster’s characterization, with Simon Willison’s analysis, and with how platforms like Google Cloud and Replit have positioned it for their audiences.
The core tensions worth holding in mind:
- Not all AI-assisted coding is vibe coding.
- The strict definition and the popular definition are diverging.
- That divergence creates real confusion in journalism, education, enterprise strategy, and security policy.
- The original spirit of the term — playful, low-stakes, prototype-oriented — is increasingly being stretched to cover professional workflows it was never meant to describe.
4. Why Vibe Coding Became Possible in 2025–2026
Vibe coding didn’t arrive because humans stopped wanting to understand their code. It arrived because machines got dramatically better at a specific cluster of tasks that, together, make intent-first software creation actually feasible.
Better frontier models. The capability jump from the LLMs of 2022 to those of early 2025 is qualitative, not just quantitative. Models became able to generate not just plausible-looking code, but code that is correct, contextually aware, and consistent across hundreds of lines — well enough that the output often works on the first try for common patterns.
Tool use. Early AI coding assistants were autocomplete tools — smarter tab-completion for your IDE. The systems of 2025 are different. They can read files, write files, run commands, observe the output of those commands, and iterate. They are not suggesting what to type next; they are completing tasks.
Larger context windows. Modern frontier models can hold tens or hundreds of thousands of tokens in context, which means they can reason over entire codebases rather than isolated snippets. This is what makes it possible for an AI to understand how a change in one file affects behavior in another, or to maintain consistent conventions across a large project without constant human reminders.
IDE integration. Tools like Cursor, GitHub Copilot, and others have embedded AI deeply into the development environment, reducing the friction of AI interaction to something close to zero. You don’t leave your editor; the AI is already there.
Sandboxed execution. AI agents that can run code in isolated environments can observe their own errors, fix them, and try again without requiring a human in the loop for every iteration. This is a fundamental unlock for agentic workflows.
Voice input and conversational control. Karpathy’s original description mentioned SuperWhisper — voice-to-text that let him describe changes without touching the keyboard. This isn’t a minor detail. Voice interaction changes the cognitive mode of programming. Describing what you want in conversational language is genuinely different from writing code, and the friction is much lower.
Multi-agent workflows. The cutting edge of 2025–2026 isn’t a single AI helping you write code. It’s multiple AI agents coordinating — one generating code, another running tests, another reviewing for security patterns, another handling deployment. Orchestrating this kind of workflow is qualitatively different from individual pair programming with an AI.
The cumulative effect of all these changes is not subtle. Vibe coding emerged at a specific moment when the capability floor for AI code generation crossed the threshold of “useful for real tasks” — and crossed it fast enough that the mental models, tooling, governance structures, and cultural norms of software development hadn’t caught up.
5. The Typical Vibe Coding Workflow
Strip away the tool names and the hype, and most vibe coding workflows follow a recognizable loop. Call it five verbs: Describe. Generate. Run. React. Refine.
Describe. You start with a prompt. Not a formal specification, not pseudocode, not a design document — a natural language description of what you want to build or change. The level of detail varies wildly: “Build me a to-do app with local storage” is a vibe coding prompt. So is “I want a dark mode toggle in the top right corner that persists to localStorage.” The model interprets your intent and generates code accordingly.
Generate. The AI produces an implementation. Depending on the tool and the task, this might be a single function, a complete file, a scaffolded application, or a series of changes across multiple files. You typically accept the generated code without deeply reading it — or at least without the careful line-by-line review that traditional code authorship would demand.
Run. You execute the code. Launch the app, click around, see what happens. In vibe coding, the primary evaluation method is behavioral: does it look right? Does it do what I described? This is different from traditional debugging, which starts with reading code and tracing logic.
React. Something is wrong or missing. Maybe there’s a visible error. Maybe the behavior isn’t quite right. You copy the error message — directly, without comment — back into the model. Or you describe in natural language what you saw: “The button is there but clicking it does nothing.” The model generates a fix.
Refine. You repeat the loop. Change the font size. Move the layout. Add a new feature. The workflow is iterative and conversational, and the edits are made through description rather than direct code changes.
This loop is fast. Faster than writing the code yourself, faster than looking up the relevant API docs, often faster than formulating the right search query. For small projects with a well-defined goal and low stakes, it can feel almost miraculous.
What the loop does not include, in its pure vibe coding form, is any of the following:
- Reading the generated code
- Understanding what the code actually does
- Writing or running automated tests
- Reviewing for security vulnerabilities
- Assessing performance implications
- Thinking about how the code will be maintained
For a weekend experiment or a personal tool you’ll use twice, these omissions are probably fine. For a production codebase with users, real data, and ongoing maintenance requirements, they are not.
One specific hazard worth naming: the “works on my machine” trap. Because vibe coding relies on behavioral testing — does it look right when I run it? — it’s easy to ship code that works perfectly in your development environment and fails in edge cases, under load, with specific user inputs, or in different browser environments. The model generates code that satisfies the described behavior, not code that handles every case the description didn’t mention.
6. Vibe Coding vs. Standard Coding
This section is where the most important distinctions live, and where the most important mistakes get made.
Standard software engineering is not just typing. It is a discipline that includes architecture, local reasoning, systematic debugging, code review, testing strategy, performance analysis, security review, documentation, and long-term maintainability. The code you write is the primary artifact, and the quality of that artifact — its clarity, its correctness, its efficiency — is a core professional output.
Vibe coding inverts several of these priorities.
Authorship vs. Steering. In standard coding, you write the code. You are the author. In vibe coding, the AI writes the code. You are the director, the reviewer, the person who decides when the behavior is good enough. This is not a trivial distinction. Authorship implies responsibility and understanding. Steering implies intent and judgment about outcomes.
Knowledge: Understanding internals vs. trusting outputs. A traditional developer knows what their code does because they wrote it. In vibe coding, you know what the code does (behaviorally) but may have limited understanding of how it does it. This is fine until something goes wrong, at which point the debugging process becomes much harder without that internal understanding.
Debugging: Tracing logic vs. prompting for fixes. When a traditional developer encounters a bug, they read the code, reason through the execution path, and identify where the logic breaks down. In vibe coding, debugging often means describing the symptom to the model and accepting whatever fix it generates — which may solve the immediate problem while introducing a new one.
Speed: Fast starts vs. uncertain finishes. Vibe coding dramatically compresses the time from “idea” to “working prototype.” What once took a week can take an afternoon. But the time from “working prototype” to “production-ready, well-tested, maintainable system” may actually be longer under a vibe coding workflow, because the underlying code quality and architectural coherence are harder to reason about and harder to improve.
Maintenance: Human legibility vs. generated complexity. Code that humans write for a living tends to have patterns, conventions, and organizational principles that other humans can follow. Code that an AI generates iteratively, in response to a series of natural language prompts, often doesn’t. Variables get named inconsistently. Similar functionality gets implemented in different ways in different files. Abstractions that would normally emerge from a human designer’s sense of the system never appear.
Ownership: “I wrote this” vs. “I shipped this.” This is perhaps the most underappreciated distinction. When a developer writes code, they own it in a deep sense — they understand it, they can defend it, they know how it fits into the larger system. In vibe coding, the relationship to the code is different: you directed its creation, you tested its behavior, you shipped it. That’s a weaker form of ownership, with real consequences for maintenance, debugging, and accountability.
The real insight is this: vibe coding compresses time-to-first-version but can expand time-to-confidence, time-to-maintenance, and time-to-governance. The tradeoff is not “old good, new bad.” It’s “new fast starts, uncertain finishes.”
7. Vibe Coding vs. Adjacent Ideas
The concept of vibe coding is often confused with related but distinct ideas. Getting these distinctions right matters, both for understanding the term and for making good decisions about when to use which approach.
Vibe coding vs. AI-assisted coding. As Simon Willison has argued extensively, using LLMs to write code that you then review, test, and understand is not vibe coding. It is AI-assisted software engineering. The key differentiator is whether the human accepts and acts on code they don’t deeply understand. Most professional developers using Copilot or Cursor are doing AI-assisted engineering, not vibe coding, because they review what gets generated.
Vibe coding vs. agentic coding. Google Cloud makes a useful distinction here: vibe coding describes the experience or the workflow — the way building software feels when you’re operating through natural language and behavioral feedback. Agentic coding describes the mechanism — AI systems that can read codebases, edit files, run commands, and operate across multiple steps without constant human intervention. You can vibe code without fully agentic systems, and you can use agentic systems in highly disciplined, non-vibe workflows.
Vibe coding vs. no-code/low-code. This distinction often gets lost. No-code and low-code platforms constrain you to prebuilt abstractions — you’re assembling components within a template, not generating arbitrary software. Vibe coding generates actual custom code. This means vibe coding is more flexible and capable than no-code tools, but it also means the resulting artifacts are less predictable and require more judgment to evaluate.
Vibe coding vs. spec-driven development. Spec-driven development adds formal requirements, explicit plans, and task breakdowns before letting AI agents write code. GitHub has positioned spec-driven workflows as a remedy for the ambiguity that plagues pure vibe-style work on serious projects. Vibe coding starts with a prompt; spec-driven work starts with a specification.
Vibe coding vs. software engineering. Software engineering — full software engineering — includes architecture, observability, compliance, deployment, rollback, monitoring, and long-term maintenance. Code generation, however impressive, is only one piece of a much larger lifecycle. Platforms like GitLab have explicitly made this point: generating working code and shipping reliable, operable software are not the same activity.
8. Who Vibe Coding Is For
Vibe coding’s appeal is not uniform across the population of people who interact with software.
Non-coders who need software leverage are arguably the primary beneficiaries. A designer who can build their own prototype. A product manager who can test an idea without waiting for engineering. An analyst who can build a custom data tool for their specific workflow. A founder who can validate a product concept before raising money to hire developers. For these people, vibe coding is not a shortcut — it’s a door into a room that was previously locked to them.
Developers who want to prototype faster are the second major audience. Even experienced engineers who would never vibe code in production find the workflow genuinely useful for early exploration, for building proof-of-concepts, for testing architectural assumptions before committing to an implementation. Simon Willison has written candidly about using vibe coding for exactly this purpose — not as a replacement for careful engineering, but as a tool for rapid experimentation.
Startup founders who need to ship before competitors may see the biggest returns in raw velocity terms. If you’re racing to validate a product idea, the ability to compress a week of implementation into an afternoon changes the math on what you can test and when.
Internal teams building narrow tools are another strong use case. A tool that three people will use to automate a specific internal process doesn’t need the same engineering standards as a public-facing product with thousands of users. The acceptable risk profile is much lower, which makes the vibe coding tradeoffs more favorable.
Students and career switchers occupy an interesting position. Vibe coding can dramatically lower the barrier to building things, which is a legitimate on-ramp into programming. The danger is that it can also bypass the foundational learning that makes someone capable of building things well over time.
The harder question worth sitting with: who benefits more — the novice who can finally build something, or the expert who can compress months of implementation into days of orchestration? The honest answer is probably both, for different reasons, in different contexts, with different caveats.
9. Where Vibe Coding Works Best
The clearest signal from practitioners, researchers, and platform documentation is consistent: vibe coding shines in specific contexts and struggles badly in others.
Greenfield projects. When you’re starting from scratch — no legacy code, no existing conventions, no existing users — vibe coding is at its best. The AI can generate a coherent initial structure without conflicting with anything that already exists. The slate is clean, the scope is defined by your prompts, and the iteration loop can be fast and relatively consequence-free.
Prototypes and MVPs. This is the canonical use case. You want to know if an idea is viable. You want something to put in front of users. You want a demo, not a product. Vibe coding is excellent at producing artifacts that look and feel real, that can gather real feedback, that let you test assumptions before investing in proper engineering.
Internal tools with small surface area. A data dashboard for your team. A script that automates a monthly reporting process. A form that routes customer inquiries to the right Slack channel. These are low-stakes, narrow-scope applications where the user population is small, the acceptable error rate is higher, and deep engineering rigor isn’t the right tool.
Throwaway experiments. Sometimes you just want to know if something is possible. Can I parse this format? Can I build this visualization? Can I connect these two APIs? Vibe coding is excellent for these questions — faster than reading documentation, faster than writing scaffolding code, and perfectly appropriate for work you’re going to throw away.
Front-end mockups. Generating UI from natural language descriptions is something current models do extremely well. “A landing page with a hero section, three feature cards, and a dark mode toggle” produces something remarkably close to what you asked for, fast.
The common thread across all these strong use cases: vibe coding shines when speed of exploration matters more than elegance of implementation. When the primary value is in learning — learning what an idea looks like, learning whether something is feasible, learning how a user responds to a workflow — the implementation quality is secondary to the speed of getting to the learning.
10. Where Vibe Coding Fails
The failure modes of vibe coding are not exotic. They are predictable, well-documented, and already showing up in real production incidents.
The “it works, but I don’t know why” problem. A generated app can look complete long before it is actually understandable, operable, or safe. When the inevitable bug arrives — and it will — the developer faces a codebase they didn’t write, filled with conventions they didn’t establish, implementing logic they never fully traced. Debugging without understanding is slow, inefficient, and likely to create new bugs in the process of fixing the original one.
The “prototype accidentally became production” problem. This is one of the most documented failure modes of vibe coding in 2025. Someone builds a weekend prototype, it works, real users start using it, and suddenly there’s a production codebase built on a foundation that was explicitly designed to be throwaway. The corners that were cut — on security, on error handling, on scalability, on observability — suddenly matter, and addressing them in a codebase you don’t deeply understand is expensive.
Simon Willison has been characteristically direct about this: “Vibe coding your way to a production codebase is clearly risky. Most of the work we do as software engineers involves evolving existing systems, where the quality and understandability of the underlying code is crucial.”
Codebase drift and AI-generated sprawl. When you iterate through prompts rather than through deliberate design, code accumulates in ways that resist comprehension. Similar functionality gets implemented multiple times in different ways. Naming conventions shift from one file to the next. Abstractions never emerge because no one took the time to look at the system as a whole and decide what it should be.
Inconsistent conventions across files. AI-generated code is stateless in a way human-authored code isn’t. Each prompt is a fresh conversation with limited memory of the conventions established in previous sessions. The result is often code that looks like it was written by five different people with five different style preferences — because, in a sense, it was.
Dependency and package risk. AI models will confidently import packages that look right, recommend versions that sound plausible, and suggest dependencies that may be unmaintained, vulnerable, or unnecessary. Without human review of the dependency tree, vibe-coded projects are exposed to supply chain risks that a careful developer would catch.
Regressions the builder never notices. Because vibe coding relies on behavioral testing — does it look right? — it has a systematic blind spot for regressions in areas the developer isn’t actively looking at. A change to fix one thing breaks another, and without automated tests, that breakage may go undetected until a user reports it.
Lack of observability and deployment discipline. Error logging, monitoring, alerting, rollback procedures — these are the infrastructure of production software. They don’t emerge naturally from a vibe coding workflow. Anthropic’s own documentation notes that long-running agents can mark work complete without proper end-to-end testing unless explicitly guided to do otherwise. The same principle applies to human vibe coders: if you don’t explicitly plan for observability, you won’t have it.
The underlying pattern: vibe coding removes friction from the beginning of the software lifecycle but doesn’t address — and can actively obscure — the challenges that dominate the middle and end of it.
11. Productivity: Hype, Reality, and the Perception Gap
The productivity claims around vibe coding and AI-assisted development deserve careful scrutiny, because the gap between what people believe and what measurements show is large and revealing.
On the optimistic side, the anecdotal evidence is genuinely impressive. Y Combinator reported in March 2025 that 25% of startups in its Winter 2025 batch had codebases that were 95% AI-generated. Some founders and developers describe what feel like order-of-magnitude speed improvements for greenfield work — building in days what might have taken weeks or months.
On the empirical side, the picture is more complicated.
METR (Model Evaluation and Threat Research) ran a randomized controlled trial in July 2025 that should give every AI-productivity optimist pause. The study recruited 16 experienced developers working on large open-source repositories (averaging 22,000+ GitHub stars and over one million lines of code). Developers completed 246 real tasks — bug fixes, features, refactors — with and without AI assistance. The results were striking.
Developers expected AI tools to speed them up by 24%. Even after completing the tasks, they believed the AI had made them 20% faster. In reality, tasks completed with AI assistance took 19% longer than those completed without.
As Ars Technica reported on the study, screen recording analysis revealed what happened to that time: it was consumed by reviewing AI outputs, prompting AI systems, waiting for AI generations, and dealing with overhead. The time saved on active coding was more than offset by these new costs. Less than 44% of AI-generated code was accepted without modification.
The perception gap in this study is extraordinary. Developers expected a 24% speedup, experienced a 19% slowdown, and still believed they had been sped up by 20%. This isn’t stupidity — it’s a well-documented feature of human psychology when dealing with novel tools. The experience of using AI coding tools can feel productive even when measured outcomes don’t support that feeling.
METR was appropriately careful about the scope of its conclusions. The study used early-2025 tools (primarily Cursor Pro with Claude 3.5/3.7 Sonnet) on complex, mature repositories. The results may not generalize to greenfield projects, simpler codebases, or more recent models. METR explicitly noted that their results are “a snapshot of early-2025 AI capabilities in one relevant setting.”
But the perception gap itself — the systematic overestimate of AI-driven productivity — is probably robust. And it has a concrete consequence: organizations and developers making resource allocation decisions based on perceived productivity will systematically overinvest in AI tooling and underestimate the real costs.
The most useful framing: vibe coding may dramatically improve time to first draft while doing much less for time to trustworthy software. If “working prototype” is your definition of done, AI tools are spectacular. If “production-ready, maintainable, secure system” is your definition of done, the measurement is much less flattering.
12. Trust, Review, and the Human Role
Software development is already grappling with a trust gap that vibe coding makes sharper.
According to Stack Overflow’s 2025 survey, more than 84% of respondents were using or planning to use AI tools in their development workflow. But only 29% said they trusted those tools. That gap — between adoption and trust — is the central tension of AI-assisted development in 2025 and 2026.
People are using these tools because the incentives are enormous: speed, reduced friction, the ability to build things they couldn’t build before. They’re not fully trusting the output because the output is genuinely unreliable in ways that are difficult to predict and detect.
This puts the human reviewer in a position of enormous importance — and genuine difficulty. Reviewing AI-generated code is different from reviewing human-written code. Human code carries implicit reasoning: you can often understand not just what the code does but why the author made a particular choice. AI-generated code doesn’t carry that reasoning. The code is there, it runs, but the “why” is opaque.
Simon Willison has written clearly about the shift this requires: the developer’s job is moving from implementer to reviewer, from coder to orchestrator, from writer of code to owner of behavior. These are related but genuinely different roles. The skills that make someone a great implementer — fast typing, fluency in syntax, ability to hold a complex state machine in working memory — are not the same skills that make someone a great reviewer of AI-generated code.
Expert judgment still matters profoundly, but it’s being asked to operate at a different level. Not “is this the right way to implement a binary search tree?” but “does this codebase as a whole do what I said it should do, without doing things I didn’t say?”
The deepest tension in this section: vibe coding democratizes software creation, but it does not democratize software judgment at the same pace. A non-programmer who can build a working app with AI assistance may not have the background to know when the app has a security vulnerability, when the architecture will fail under load, or when the code is drifting toward unmaintainability. They can build; they cannot yet fully evaluate.
This is not an argument against democratization. It is an argument for being honest about what democratization does and doesn’t include.
13. Security, Governance, and Compliance
Security is not a secondary consideration in the vibe coding conversation. It is one of the primary reasons vibe coding is treated so differently in enterprise and regulated contexts than in the hobbyist or startup world.
The UK’s National Cyber Security Centre (NCSC) published a widely-cited March 2026 assessment of vibe coding that acknowledged the real excitement around the workflow but named specific, concrete risks that it argued sit outside most organizations’ risk tolerances.
The NCSC called for models that write secure code by default — something that current models demonstrably do not do. Wikipedia’s vibe coding article documents multiple cases: in May 2025, Lovable (a Swedish vibe coding platform) was found to have security vulnerabilities in 170 out of 1,645 applications it generated, with issues that would allow personal information to be accessed by anyone. A Veracode study released in October 2025 found that while LLMs had become dramatically better at generating functional code over the past three years, the security of generated code had generally not improved — and larger models were not better than smaller ones at generating secure code.
The failure modes are consistent and predictable:
Insecure-by-default code. AI models generate code that works without generating code that is secure. Authentication flaws, injection vulnerabilities, and insufficient input validation appear regularly in AI-generated output. A developer who doesn’t review the code won’t catch these.
Secret leakage. API keys, credentials, and sensitive configuration values get embedded in code by AI models that aren’t thinking about secrets management, and by users who are focused on getting things to work rather than on operational security.
Permission misuse. Google Cloud’s deployment documentation specifically warns AI-assisted developers and vibe coders to revisit permissions, service accounts, concurrency, secrets, and deployment settings after AI-generated apps are created — because the defaults AI systems use are often wider than needed, creating unnecessary attack surface.
Dependency and supply chain risk. AI models suggest packages and dependencies based on training data, not on current vulnerability databases. A confident suggestion to import a specific package may be a suggestion to import something unmaintained, backdoored, or known-vulnerable.
Insufficient test coverage. Vibe coding workflows rarely include systematic testing. Code that has no test coverage cannot be safely changed, and code that cannot be safely changed cannot be safely maintained.
Lack of code provenance. In regulated industries, there are requirements around knowing where code came from, who approved it, and what review process it underwent. Vibe-coded software has murky provenance by definition.
The governance problem of vibe coding is not just bad code. It is code whose speed of generation outpaces the organization’s ability to inspect, secure, document, and own it. The gap between “this runs” and “this is safe to deploy in a regulated context” is measured in governance practices that vibe coding, in its pure form, does not include.
14. The Enterprise Response: From Vibes to Systems
Serious organizations are not simply adopting vibe coding as-is. They are building structures around it — specifications, harnesses, review layers, policy gates, and testing frameworks — that attempt to capture the speed benefits while managing the governance risks.
GitHub has positioned what it calls “spec-driven development” as a disciplined alternative to pure vibe coding for professional contexts. The core idea: before letting AI agents write code, invest in making the intent explicit through formal requirements, architecture decisions, and task breakdowns. The agent then works within that structure rather than inferring intent from vague prompts. This doesn’t eliminate AI-generated code; it constrains and contextualizes it.
Anthropic’s documentation for Claude Code addresses agent failure modes directly, including a specific note that long-running agents can mark work complete without proper end-to-end testing unless explicitly instructed otherwise. The recommended mitigation is explicit harness design: human checkpoints at key stages, automated test requirements, and clear success criteria before tasks are marked done.
The emerging enterprise stack for responsible AI-assisted development looks something like this:
- Specs before code. Formal requirements and architectural decisions before the agent starts writing.
- AGENTS.md and repo instructions. Repository-level guidelines that tell AI agents what conventions to follow, what tools to use, and what to avoid.
- Human checkpoints. Explicit review steps at key stages — not a rubber stamp, but genuine evaluation by someone who understands the system.
- Automated tests and evaluations. Test suites that run on every change and catch regressions before they reach production.
- Security scanning and policy gates. Automated checks for common vulnerabilities, dependency issues, and compliance violations.
- Sandboxes and scoped permissions. AI agents that operate with minimal required permissions, in isolated environments, rather than with broad access to production systems.
- Observability, rollback, and production readiness. The boring operational infrastructure that makes it possible to know when something breaks and fix it fast.
The practical conclusion: the enterprise future is probably not “everyone vibe codes everything.” It is more likely a tiered model — vibe coding for ideation and initial exploration, more structured agentic coding for implementation, and spec-driven, policy-controlled systems for production.
15. How Vibe Coding Is Changing the Developer Profession
The developer role is not disappearing. It is migrating.
GitLab has written about what it calls an “orchestration era” in software development — a period in which the most valuable developer skill is not the ability to write code but the ability to design, direct, and quality-control AI systems that write code. The new responsibilities look like this:
Less typing, more judging. If the AI writes most of the code, the human role is increasingly one of quality judgment: is this correct? Is this maintainable? Is this secure? Is this the right architecture? These are harder questions to answer quickly than “is this syntax valid?”
More architecture and interface design. The parts of software development that require high-level systems thinking — how do the pieces fit together? where are the boundaries? what does the interface contract need to be? — are exactly the parts that AI is worst at and humans are still most valuable for.
More evaluation and quality assurance. As AI generates more code faster, the bottleneck shifts to verifying that the generated code is correct, safe, and aligned with intent. Quality assurance, which has often been an afterthought in software organizations, becomes a core competency.
More systems thinking. Designing AI-assisted workflows requires understanding how different agents interact, where errors propagate, what the failure modes are, and how to build observability into the system. This is systems engineering applied to AI pipelines.
More cross-functional building by non-engineers. The flip side of developers becoming more like orchestrators is that non-engineers are building more software. Product managers, designers, analysts, and domain experts who can describe problems clearly are increasingly able to build tools. This changes the composition of software development teams and the nature of what “a developer” means.
GitHub’s language trend data offers a concrete illustration: TypeScript became the most-used language on GitHub by August 2025, overtaking Python and JavaScript. One plausible contributor: typed languages provide structure and guardrails that help teams manage AI-generated code in production. When you can’t guarantee the human reviewed every line, types become a form of automated documentation and constraint that catches errors before they cause damage.
The scarce skill is moving from writing code to knowing what good software looks like — under what constraints, for what users, with what acceptable risk profile — and being able to get there using a combination of human judgment and AI capability.
16. The Language and Tooling Effects of Vibe Coding
AI is not only changing workflows; it is influencing technical choices in ways that are just beginning to be visible.
The TypeScript story is the clearest example. Typed languages are gaining adoption partly because they generate better AI output (models trained on typed code produce more type-consistent results) and partly because they provide better guardrails for reviewing AI output (a type error in generated code is caught automatically, even if the reviewer doesn’t read every line).
This suggests the emergence of something like “AI-friendly stacks” — technology choices made not just on the basis of performance, community, or ecosystem, but on the basis of how well they work with AI development workflows. Frameworks with strong conventions are easier for AI to follow consistently. Languages with rich type systems catch AI mistakes automatically. Testing frameworks that are easy to invoke from the command line integrate better with agentic workflows.
More broadly, tooling designed to support vibe coding and AI-assisted development is itself evolving rapidly. Sandboxed execution environments, browser-based development platforms, AI-native IDEs, and multi-agent orchestration frameworks are all growing categories. The ecosystem around AI-assisted development is early but expanding fast.
17. Critiques of the Term Itself
“Vibe coding” is catchy. It is also, by the assessment of many serious practitioners, imprecise in ways that cause real harm.
The core criticism: the term’s playful, casual connotation makes rigorous AI-assisted engineering sound unserious, while simultaneously lending an air of acceptability to practices that are genuinely risky. When a senior enterprise developer says they’re “vibe coding,” and a weekend hobbyist says they’re “vibe coding,” they are describing wildly different practices with wildly different risk profiles — but the term flattens that difference.
Simon Willison has been the most persistent critic of the term’s overextension. His argument: there is a meaningful distinction between responsible AI-assisted engineering and the accept-all, don’t-read-it approach that Karpathy described. Collapsing that distinction under one term misleads people about what’s possible, what’s safe, and what’s professional.
Google’s own documentation implicitly acknowledges the ambiguity by distinguishing vibe coding from agentic coding — suggesting that even the company-level framing of these concepts recognizes the need for more precision than the original term provides.
The likely trajectory: “vibe coding” will survive as a cultural reference and as a shorthand for the casual, intent-driven end of the AI coding spectrum. But for professional contexts — enterprise documentation, security assessments, developer education — it will probably be supplemented or replaced by more precise language: agentic software development, AI-native development, intent-driven programming. These terms carry less connotation and more specificity.
Whether the term persists or evolves, the cultural story it tells — about software creation becoming more accessible, more intent-based, and more dependent on machine-generated implementation — will remain true regardless of what we call it.
18. A Balanced Conclusion: What Vibe Coding Is Likely to Become
Pull back from the hype in both directions and a clearer picture emerges.
Vibe coding is real. It describes a genuine shift in how software gets made, a shift that was enabled by a specific cluster of capability improvements in 2024 and 2025, and a shift that is accelerating. The people who dismiss it as a toy are wrong; the people who treat it as a replacement for software engineering discipline are also wrong.
The most defensible view is this: vibe coding is the consumerization of software creation — the moment when building software became something a motivated non-programmer could do for a weekend project, the way desktop publishing made page design something a motivated non-designer could do. That consumerization is real, it is valuable, and it is not going away.
But consumerization is not professionalization. The arrival of desktop publishing tools did not make professional designers obsolete; it redefined what professional design expertise meant and where it was most needed. The same dynamic is playing out in software. The arrival of vibe coding tools does not make software engineers obsolete; it redefines where engineering expertise matters most.
Where vibe coding works: prototypes, experiments, greenfield projects, internal tools, fast validation. Where expert engineering still matters enormously: systems that handle real data, serve real users, carry real consequences, require real maintenance, and must meet real compliance standards. The closer the work gets to production — to real users, real data, real stakes — the more it needs specifications, tests, security review, governance, and human judgment.
A few things seem reasonably certain about the next few years:
AI-generated code will become a larger and larger fraction of total code written. The direction of travel is clear even if the speed is not.
The governance and security challenges will become more pressing as that fraction grows. Organizations that don’t address them will face real incidents.
The most valued developers will be those who combine strong systems thinking, design judgment, and evaluation capability with deep fluency in AI tools. The developer who can’t use AI will be at a disadvantage. The developer who can use AI but can’t evaluate what it produces will be a liability.
And the question of what it means to “own” software — to be accountable for its behavior, its security, its maintenance, and its consequences — will become one of the defining questions of software ethics in the next decade.
Vibe coding is not the end of software engineering. It is the beginning of a harder question: now that almost anyone can build software, what does it mean to build software well?
