Vibe Coding: Writing Software by Describing It

WHAT IT ACTUALLY MEANS

Vibe coding, as Karpathy described it, is the practice of building software almost entirely through natural language prompts — describing what you want the code to do, accepting the AI's output, and iterating by describing corrections rather than writing them. You "fully give in to the vibes," as he put it, without reading the code in detail.

This is distinct from using AI as a coding assistant. A coding assistant helps you write code you understand. Vibe coding is closer to directing a contractor: you specify outcomes, not implementations. The codebase becomes something the AI manages and you describe, rather than something you author line by line.

The tools that made this practical are AI-native editors like Cursor, which allow you to describe changes in plain language and have the model apply them across multiple files simultaneously. The quality of modern code models — particularly after Claude 3.5 Sonnet in mid-2024 and continuing through early 2025 — made the outputs good enough that most small-to-medium changes just worked on the first attempt.

THE Y COMBINATOR DATA POINT

In March 2025, Y Combinator published data from its Winter 2025 batch that immediately circulated across every engineering community: 25% of the companies in that cohort had codebases where more than 95% of the code was AI-generated. These weren't toy projects — they were funded startups building real products for paying customers.

The practical implication was clear. Small founding teams without dedicated engineering resources were shipping software at a pace that would previously have required a full engineering team. A two-person founding team with domain expertise but limited coding experience could build and iterate on a functioning product in weeks.

This was genuinely new. The previous wave of no-code and low-code tools had targeted non-technical users but always hit a ceiling when customisation requirements exceeded what drag-and-drop interfaces could express. Vibe coding with AI doesn't have that ceiling — if you can describe it, the model will attempt to build it.

WHERE IT WORKS

Vibe coding is most effective for greenfield projects with well-defined requirements, prototypes and proof-of-concepts where the goal is to validate an idea quickly, internal tools where the blast radius of bugs is limited, and UI work where the feedback loop is visual and immediate. These are scenarios where the cost of imperfect code is low and the benefit of rapid iteration is high.

It also works well for developers who understand the domain but don't want to hold the boilerplate in their head. Writing a FastAPI endpoint with JWT authentication, a React component with specific state behaviour, a SQL migration script — these are tasks where you know exactly what you want and the model knows exactly how to express it. Vibe coding compresses the distance between intent and implementation.

WHERE IT QUIETLY FALLS APART

The problems tend to accumulate invisibly. When you don't read the code you're shipping, you accumulate technical debt you can't see. The AI will make architectural decisions — about state management, data flow, error handling — that are locally reasonable but globally inconsistent. Over time, the codebase becomes harder to reason about, even for the AI model that generated it.

Security is the other sharp edge. AI models will generate code that works but isn't hardened: SQL queries without parameterisation, API endpoints without rate limiting, authentication logic that passes the happy path but fails on edge cases. In a vibe-coded codebase, these gaps are invisible until they're exploited.

The Wall Street Journal reported in July 2025 that senior engineers at several startups were being brought in specifically to remediate vibe-coded codebases that had become unmanageable. The pattern was consistent: rapid early progress, then a point at which adding new features reliably broke existing ones, and no clear path to understanding why.

THE RIGHT MENTAL MODEL

The most durable framing we've landed on is this: vibe coding is a powerful tool for exploration and acceleration, not a replacement for engineering judgment. The output of a vibe coding session is a draft, not a finished product. It needs the same review, testing, and hardening that any draft requires — just faster to produce.

Teams that get sustained value from AI-assisted coding tend to use it to move fast on the parts of the problem that are well-understood, and slow down on the parts that carry real risk. The model writes the boilerplate; the engineer owns the architecture. That division of labour is productive. Handing the architect's role to the model as well is where the trouble starts.