The Evolution of Vibe Coding (Part 1): The Birth, Distortion, and Viral Rise of a Term

On February 2, 2025, former Tesla Director of AI and OpenAI founding member Andrej Karpathy shared a post on X.

Less than ten months later, on November 6, 2025, the UK’s Collins Dictionary officially crowned the coinage from his post—“vibe coding”—its Word of the Year 2025.

In less than a year, a half-joking remark morphed from insider engineer jargon into a mainstream buzzword.

Along the way, however, the term underwent a profound mutation. A year later, its creator introduced a new term to distance himself from it, while researchers launched rigorous empirical studies to examine the reality behind the hype.

As the first installment of a two-part series, this article traces the full arc of this techno-cultural phenomenon: reconstructing Karpathy’s original workflow, breaking down the three forces behind its viral explosion, examining the guardrails Simon Willison and Karpathy himself placed around the term, fact-checking the “vanishing junior engineer” narrative against primary sources, and analyzing its capabilities through the lens of “The 70% Problem.”

The second part will balance the ledger: exploring declining code quality, real-world security vulnerabilities, empirical productivity benchmarks, and practical decision-making frameworks for engineering teams.


1. Setting the Scene: What Did Karpathy Actually Say?

To understand where vibe coding began, start with the creator’s background and context.

Karpathy is one of the rare figures straddling the highest echelons of academia and industry practice. A founding member of OpenAI and former Director of AI at Tesla, he has long argued that natural language would become the dominant programming interface, famously declaring in early 2023: “The hottest new programming language is English.”

Vibe coding was no spur-of-the-moment whim; it was the natural progression of that thesis into his daily experiments.

In his early-2025 post, Karpathy documented a playful, self-deprecating experiment: using the voice-input tool SuperWhisper to dictate commands to Cursor’s Composer mode (powered by Claude 3.5 Sonnet, capable of autonomous multi-file editing) with his hands barely touching the keyboard.

Whenever tweaks were needed, he spoke them aloud; in the editor, he instinctively clicked “Accept All,” abandoning line-by-line diff inspections altogether; and whenever error messages popped up, he pasted the raw stack traces straight back into the chat prompt. Soon, the codebase swelled past anything he could hold in his head.

He closed the post with the now-famous confession:

“It’s not really coding - I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.”

The detail most frequently overlooked by commentators came just before that closing line, where Karpathy explicitly defined its scope: “It’s not too bad for throwaway weekend projects.”

In other words, original vibe coding hinged on three prerequisites:

Yet as the term entered the cultural slipstream, these three guardrails were completely stripped away, birthing the popular myth that engineers would never need to understand code again.


2. Behind the Viral Surge: Three Drivers of Adoption

Look back at the tech landscape of 2025, and vibe coding’s meteoric global rise was fueled by three forces converging at the exact same moment.

1. Tooling: Agentic Workflows Cross the Usability Threshold

Cursor’s Composer mode, referenced in Karpathy’s post, matured in early 2025. That same year, tools like Claude Code and Replit Agent hit their stride, chaining requirements analysis, multi-file edits, and automated debugging into one complete cycle.

Earlier AI completion was confined to inline suggestions (like early GitHub Copilot), where developers still drove line by line. The agent model shifted execution to the AI, relegating humans to prompting and acceptance testing. A wave of platforms doubled down on “no terminal, no environment setup,” allowing users without a software background to deploy applications from scratch.

2. The Messenger: Elite Endorsement and the Power of Contrast

Had vibe coding been coined by a marketing or PR team, it would have struggled to gain traction in an engineering culture anchored in empirical evidence.

Karpathy commands immense academic and pedagogical credibility in deep learning. Hearing him say, “This is how I code now, and it’s a lot of fun,” offered powerful psychological validation for what had previously seemed like a reckless fringe practice.

This endorsement carried a striking contrast: when an undisputed master of deep learning proclaims that he doesn’t read code, observers instinctively assume, “If even he works this way, it must be the future”—blithely overlooking the boundaries he attached to the claim.

3. Memes: Viral Self-Deprecation and Media Amplification

Catchphrases like “fully give in to the vibes,” “Accept All,” and “coding purely on vibes” proved irresistibly memeable, easily remixed and repurposed across everyday contexts.

Throughout the first half of 2025, tech channels overflowed with experimental screenshots and self-deprecating memes. Mainstream business media quickly caught the scent. In March 2025, Y Combinator CEO Garry Tan told CNBC that founders can simply talk to large language models and have them code entire apps, catapulting the phrase into the broader business lexicon.

Finally, Collins Dictionary declared it Word of the Year in November 2025, putting an official seal on the frenzy.


⭐️3. Semantic Battles: From Vibe to Agentic

Once the term went viral, serious debates over its definition erupted across the engineering community.

The first systematic pushback came from Django co-creator and veteran open-source developer Simon Willison.

On March 19, 2025—just six weeks after the initial post—Willison published an essay titled “Not all AI-assisted programming is vibe coding.”

He proposed a narrowed, rigorous definition for vibe coding: “building software with an LLM without reviewing the code it writes.”

ParadigmDegree of ReviewTarget ContextCore Dynamic & Cost
Vibe CodingNo reviewLow-risk, throwaway toy projectsBlazing speed, but accumulates heavy “cognitive debt”
AI-Assisted DevelopmentLine-by-line reviewRoutine features and standard product developmentHuman-in-the-loop, balancing velocity with discipline
Agentic EngineeringSpec-driven & automated test verificationComplex architectures and production systemsHumans direct agents, assuming full liability for the system

The boundary lines between the three are crisp: vibe coding skips review and targets disposable toys; AI-assisted development relies on human line-by-line scrutiny; agentic engineering is driven by specifications and automated tests, with engineers bearing full responsibility for the end result.

Willison worried that lumping all AI-assisted development under “vibe coding” would not only dilute professional discourse but also erase the discipline maintained by rigorous engineers.

He laid down a rule that became widely quoted across the tech community: never commit code you cannot explain to someone else.

In Willison’s framework, as long as developers conduct thorough reviews, write tests, and understand system mechanics and code logic, AI’s role remains that of an assistive tool; the work itself is still standard software engineering.

He also introduced the concept of “cognitive debt”: while traditional “technical debt” refers to sub-optimal architecture where developers still understand how pieces fit together, cognitive debt goes a step further. AI generates code so quickly that developers can no longer maintain a sound mental model of the system—leaving them unable to explain how it actually works. Eventually, that debt comes due at steep interest during maintenance and incident triage.

Even so, Willison did not dismiss vibe coding wholesale. He acknowledged that it lowers barriers for beginners, speeds up the creation of personal automation scripts, and lets senior engineers rapidly probe the outer limits of LLM capabilities.

Subsequent moves by Karpathy himself echoed this definitional reckoning.

On February 4, 2026, Karpathy formally introduced a new term on X: “agentic engineering.”

He argued that the new baseline is one where engineers spend 99% of their time orchestrating, constraining, and verifying AI agents rather than writing code by hand. Shortly after, he hosted a conversation with Sequoia Capital titled From Vibe Coding to Agentic Engineering. Through this new term, the creator himself drew a clear line between rigorous professional engineering and casual, code-blind experimentation.

By mid-2026, Willison was watching this very line blur in his own work: in a May essay, he admitted that as coding agents grew reliable, he no longer reviewed every line of production code, instead having agents add automated tests and documentation—vibe coding and agentic engineering were converging in his own workflow, a shift he found unsettling.

Zoom out to the tooling level, and spec-driven workflows, plan reviews, and automated testing were becoming standard equipment in modern development environments, and rapid generation and rigorous verification began coexisting within the same pipeline. The terminology disputes cooled down precisely because tooling evolution had begun bridging the practical divide between the two.


4. Have Junior Engineers Vanished?

Trailing the vibe coding craze was the tech industry’s most pervasive workplace anxiety: “AI can now generate code automatically, so entry-level developer roles are doomed.”

Such claims routinely cite two influential studies. But examining their original methodology—how these figures were actually defined and measured—reveals that popular narratives stripped away crucial context and exaggerated the findings.

Report & SourcePopular NarrativeBaseline Methodology & Ground Truth
SignalFire 2025 State of Talent ReportBig Tech new-grad hiring plunged 50% due to AIThe 50% decline is measured against a 2019 baseline across six years of compounding macro cycles (pandemic hiring sprees, freezes, layoffs, and high interest rates). Startup new-grad hiring also dropped below 6% (down >30% vs. 2019) as companies prioritized immediate productivity.
Stanford Study (Brynjolfsson et al.)13% to 19% of young engineers lost their jobsHighlights a 19% lag in employment growth trajectories among young workers in AI-exposed roles (a relative trend gap), while senior employment in the same fields held steady or grew slightly.

1. The SignalFire 2025 State of Talent Report

Headlines frequently sensationalized the data with claims like “Big Tech new-grad hiring plunges 50% due to AI.” Tracing back the methodology in the SignalFire report, however, reveals a macroeconomic cycle spanning six full years:

The “50% collapse” is the cumulative result of multiple overlapping cycles: post-pandemic overhiring, subsequent hiring freezes, industry-wide layoffs, and sustained high interest rates. The report explicitly frames this as the combined outcome of productivity tooling, cost discipline, and macro headwinds—never identifying AI as the sole culprit.

Moreover, the report highlights an “experience paradox” sweeping startups: companies exclusively seek candidates with day-one productivity, pushing the new-grad share of startup hiring below 6% (a drop of over 30% compared to 2019). The report’s central warning is the risk of a “lost generation”: when new graduates lose access to structured on-the-job training, skipping that formative stage risks breaking the industry’s long-term talent pipeline.

2. The Stanford Study: What Real ADP Payroll Data Actually Shows

Another frequently cited study is the Stanford paper “Canaries in the Coal Mine” by economist Erik Brynjolfsson and colleagues, which analyzed real-world payroll records from millions of workers managed by ADP.

The researchers found that between late 2022 and mid-2025, entry-level workers aged 22 to 25 in AI-exposed roles (including software development, customer support, and basic bookkeeping) saw their relative employment growth lag behind peers in low-exposure occupations by roughly 13% (a figure the team revised to 19% in 2026). Meanwhile, employment among senior workers aged 35 and older in the same fields remained steady.

Public retellings commonly introduced two distortions:

Strip away the hype, and the objective reality is clear: junior engineers have not vanished into thin air; rather, the bar for entry has been substantially raised. The real challenge for newcomers is that, unlike two years ago, landing a job by simply knowing basic syntax is no longer an option.


⭐️5. The 70% Problem: Testing Engineering Fundamentals in the Deep End

When it comes to assessing the limits of vibe coding, the framework most cited across the engineering community is “The 70% Problem,” formulated by Google Chrome engineering lead Addy Osmani.

Chronologically, Osmani published his essay on December 4, 2024—two full months before Karpathy coined the term. While Osmani originally explored the boundaries of early LLM code generation, the tech community swiftly adopted his framework to explain why vibe coding cannot simply carry over into production environments.

DimensionThe First 70%: Rapid PrototypingThe Last 30%: The Deep End
Typical TasksBoilerplate code, basic CRUD, UI scaffoldingEdge cases, concurrency safety, memory leaks, architectural refactoring
Developer ExperienceHigh dopamine, rapid progressDiminishing returns; easily trapped in a “fix A, break B” loop
Tooling RoleAI generates a working 70% autonomouslyAI frequently suggests flawed fixes, requiring continuous developer verification
Competence ThresholdAccessible to beginners and non-technical usersDemands skilled engineers equipped with solid mental models of system architecture

1. The Patching Quagmire: A “Two Steps Forward, One Step Back” Loop

The 70% framework posits that non-engineers and novices, armed with modern AI, can build a seemingly functional 70% software prototype at astonishing speed.

Yet the remaining 30%—encompassing edge-case handling, architectural refactoring, concurrency safety, memory leaks, and deep debugging—lies in the murky depths of diminishing returns.

When builders lack foundational knowledge, asking an AI to patch a defect often triggers a “two steps forward, one step back” cascade: fixing module A breaks module B. Without a working mental model, users can do little more than feed error messages back into the prompt, trapped in an endless prompting loop.

2. The Knowledge Paradox: An Accelerator for Seniors, a Casino for Juniors

From this dynamic, Osmani distilled the “Knowledge Paradox”: AI tools deliver vastly greater value to senior engineers than to beginners. Experienced developers use models to rapidly implement architectures they’ve already mapped out in their heads; beginners, by contrast, tend to accept outdated or insecure code at face value, assembling fragile “houses of cards” that look sleek until they collapse.

His practical prescription is straightforward: treat AI as a “first-draft generator,” not the “finished product.” Let AI scaffold the prototype quickly, then hand it over to human engineers to review, refactor, write tests, and flesh out documentation.

This resonates strongly with Simon Willison’s perspective:

For engineers who understand architecture, AI is a powerful accelerator; for those who do not, using AI is like gambling at a table with unknown odds.

When citing this framework, be honest about its evidential weight: it is an insightful synthesis of senior engineering wisdom, not a quantitative empirical study. The figure “70%” represents a qualitative heuristic rather than a measured statistical threshold, and should not be misread as a rigid scientific metric.


Conclusion: The Real Fault Line After the Hype Cools

Look back across 2025 and 2026, and a viral buzzword ran its entire lifecycle in just two years: genesis, explosion, distortion, peak cultural recognition, and eventual demarcation by the engineering vanguard.

Yet the fading hype does not mean the underlying tension has vanished. When popular culture flattened the nuanced spectrum of software development into “vibe coding,” the foundational boundaries of engineering—whether you inspect the code, whether you verify it, and whether you take responsibility for production—were dangerously blurred.

What real-world costs did this conceptual blurring incur?

In Part 2, we will balance the ledger with hard data and case studies: from Y Combinator’s disclosures on real-world development ratios and high-profile security incidents to code-quality audits spanning hundreds of millions of lines, academic evaluations of LLM-generated software vulnerabilities, and DORA performance metrics—distilling actionable decision-making principles for engineering teams navigating the AI frontier.