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.
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.

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.
Read more analysis on AI-first startup workflows
Browse pulse articlesSkipping 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.
| Feature | Survived (3 quarters+) | Shut down or pivoted |
|---|---|---|
| Reviewed every diff | Yes | No after first 6 weeks |
| Test-first prompting | Standard practice | Rare |
| Session length | 30 to 90 min | Multi-hour open ended |
| Shipped to one user first | Always | Sometimes skipped |
| AI tool used | Cursor or Claude Code | Cursor 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.

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.
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.
Read more startup workflow analysis
Browse pulse articles