Skip to content
·9 min read

How YC Founders Are Shipping 95 Percent AI Generated Code

Inside the workflow patterns that let a quarter of YC's W25 batch ship codebases written almost entirely by AI, and the failures that the headlines skipped

Share

A quarter of Y Combinator's W25 batch shipped products with codebases that were 95 percent or more AI-generated, according to YC's own statements in early 2025, and the number has held roughly steady through W26. The headline made the rounds. Less covered is what those founders actually do day to day, why some of them are now at $1M+ ARR while others have already shut down, and what patterns separate the two outcomes. The short version: the founders who survived all use AI inside a tight loop of human review, narrow product scope, and aggressive testing. The ones who failed treated 95 percent as a target rather than a measurement.

This piece lays out the workflow patterns that worked, the failures that did not make press releases, and what early-stage founders can copy without copying the mistakes.

What "95 Percent AI Generated" Actually Means

The phrase is widely misunderstood. It does not mean "founders prompt once and ship." It means that across the codebase, 95 percent of the lines were originally written by an AI agent, even if they were heavily edited, reviewed, refactored, and tested by humans afterward. The 5 percent that humans wrote is mostly configuration, glue code, and the parts the AI got wrong enough times that founders gave up and wrote them by hand.

This distinction matters because the popular version of the story implies founders are not engineering anything. The reality is that they are doing a lot of engineering, just with the typing offloaded to AI. The hours spent on planning, reviewing, debugging, and shaping the product look almost identical to a 2022 startup. What changed is the hours spent typing.

Key Takeaway

A LeadDev analysis of YC's W25 cohort found that the median founder shipping 95 percent AI code spent 30 to 40 hours per week on engineering work, almost identical to founders shipping less AI-generated code. The difference was that they shipped 3 to 5 times more features in that time. The compression was on output volume, not on hours worked.

The pattern to copy here is the introduction of compilers in the 1960s. Programmers who had been writing assembly were suddenly able to write higher-level code, and the volume of software per programmer jumped 10x. People worried that "real programming" was dying. What actually happened was that the same people kept programming, just at a higher level of abstraction, and produced more output. AI is the same shift, one level up.

The Workflows That Work

Talking to founders in the W25 and W26 batches reveals a surprisingly consistent set of practices. Almost all of them do these four things, and the ones who do not have struggled disproportionately.

Narrow scope per session. Founders who succeed do not ask the AI to build the whole product. They build it in 30 to 90 minute sessions, each one targeting a specific feature or fix. The AI's accuracy drops sharply when asked to do too much in one prompt, and short sessions keep the diff small enough to review in detail.

Test-first prompting. A common pattern is to ask the AI to write the test first, manually verify the test reflects the desired behavior, then ask the AI to write the implementation. The test acts as a contract. If the implementation passes, the founder reviews quickly. If it fails, the AI iterates without the founder having to think.

EXPLAINER DIAGRAM titled YC FOUNDER WORKFLOW PATTERNS shown as a vertical four-step flowchart on a slate background. Step 1 colored blue NARROW SCOPE PER SESSION, sublabel 30 TO 90 MIN PER FEATURE. Arrow down. Step 2 colored green TEST FIRST PROMPTING, sublabel TEST IS THE CONTRACT, AI WRITES IMPL. Arrow down. Step 3 colored orange DIFF REVIEW BEFORE COMMIT, sublabel READ EVERY LINE, NEVER ACCEPT BLINDLY. Arrow down. Step 4 colored purple SHIP TO ONE USER FIRST, sublabel REAL FEEDBACK BEFORE SCALING. Side panel reads RESULT FOUR PRACTICES SHARED BY 80 PERCENT OF SUCCESSFUL YC FOUNDERS. Footer reads NONE OF THESE ARE SPECIFIC TO AI, ALL ARE EASIER WITH AI.
Four workflow practices that 80 percent of successful YC founders shipping 95 percent AI code share. Old engineering disciplines, new compression.

Diff review before commit. Even at 95 percent AI generation, every line gets read by the founder before it goes into git. The skill is reading 400 lines in 5 minutes and spotting the three things that matter. Founders who skip this step ship bugs at rates that kill traction.

Ship to one user first. Successful founders ship to a single user (often a friend or themselves) before scaling. This catches the class of bugs that AI-generated code produces most, the ones where the happy path works but the messy reality breaks.

What the Failures Did Differently

The failures are less covered, partly because YC does not publicize them and partly because the founders rarely write post-mortems. But the patterns are visible. Talking to investors and reading the few public retrospectives gives a clear picture.

Treating 95 percent as a goal. The founders who failed often optimized for the AI-generated percentage as if it were a metric of progress. They would push back on writing the 5 percent of glue code that the AI could not handle, leading to fragile workarounds and brittle architectures.

Build with AI without breaking your product

Read more analysis on AI-first startup workflows

Browse pulse articles

Skipping the diff review. This was the single biggest failure mode. Founders who got tired of reviewing 400-line diffs started accepting them blindly after a few weeks. Within a quarter, the codebase had accumulated enough subtle bugs to require a full rewrite or to lose the team.

The Comparison That Matters

Comparing the surviving founders to the failed ones, the practice differences are sharp. Tooling differences are smaller than people expect.

FeatureSurvived (3 quarters+)Shut down or pivoted
Reviewed every diffYesNo after first 6 weeks
Test-first promptingStandard practiceRare
Session length30 to 90 minMulti-hour open ended
Shipped to one user firstAlwaysSometimes skipped
AI tool usedCursor or Claude CodeCursor or Claude Code

The tooling row is the punchline. Both groups used the same AI tools. The difference was entirely in the practices around the tools, which matches what Simon Willison and the broader vibe engineering literature have argued for the last 18 months.

EXPLAINER DIAGRAM titled FAILURE PATTERN VS SUCCESS PATTERN shown as a two-column timeline on a slate background. Left column header SUCCESS PATH in green has stacked time blocks: WEEK 1 SHIP MVP, WEEK 4 FIRST 10 USERS, WEEK 12 FIRST PAID, WEEK 24 PRODUCT MARKET FIT, WEEK 36 SCALING. Right column header FAILURE PATH in red has stacked time blocks: WEEK 1 SHIP MVP, WEEK 4 ACCUMULATING BUGS, WEEK 12 BUG WALL HIT, WEEK 18 TECHNICAL DEBT CRISIS, WEEK 24 REWRITE OR SHUTDOWN. Center divider has vertical text reading SAME TOOLS DIFFERENT PRACTICES DIFFERENT OUTCOMES. Footer reads THE FORK HAPPENS AROUND WEEK 4 WHEN REVIEW DISCIPLINE BREAKS.
The fork between success and failure happens around week 4, when most founders either keep the diff review discipline or quietly drop it.

The week 4 fork is the most actionable insight in the data. If you can identify it in your own workflow, you can correct course before the technical debt compounds. Most founders who drift into the failure path do so quietly, by skipping a review here and a test there, and the cost shows up months later as a feature they cannot ship without rewriting half the system.

Common Mistake

The most expensive misreading of the YC story is concluding that AI tools alone produce $1M+ ARR products. They do not. The successful YC founders combine AI tools with old-school discipline (testing, review, narrow scope), and the combination is what works. Copying only the AI part without the discipline part is the recipe for the 40 percent of the cohort that failed.

The honest read on the W25 cohort is that AI tools enabled a wave of products that would not have shipped two years earlier, and that within that wave the founders who applied engineering discipline at the same time as AI speed produced the breakouts. The founders who treated AI as a replacement for discipline produced the failures.

What This Means For You

The YC pattern is reproducible by any founder who is willing to combine AI speed with engineering discipline. It is not a magic bullet, but it is a real shift, and the people who copy the right practices will outpace the people who copy only the headline.

  • If you're a founder: Adopt the four workflow patterns above before you optimize for AI generation percentage. The percentage is downstream of the practices.
  • If you're changing careers: Study the diffs of YC founders who write publicly (Pieter Levels, others). Reading their commit histories teaches more than reading their tweets.
  • If you're a student: Try to ship one project using the four-pattern workflow. The skill of reviewing AI diffs at speed transfers directly to internships and first jobs.
Ship like a YC founder, with the right discipline

Read more startup workflow analysis

Browse pulse articles
PJ
Pranay Joshi

20+ years building products at scale. VP of Product & Engineering, startup founder, and AI coach. Helping dreamers turn ideas into reality with vibe coding.

The Tuesday Shipping Report

Every Tuesday, one focused email:

  • - The tool or technique that's actually working right now
  • - A real problem from the community (and how to solve it)
  • - What changed this week in the vibe coding landscape

Read by 1,000+ founders, developers, and creators building with AI. Free forever. No spam.