YC CEO's 37,000-Lines-a-Day AI Coding Claim: What It Actually Means for Your Career

Quick Answer: Y Combinator CEO Garry Tan claimed he shipped 37,000 lines of AI-generated code per day; a developer audit and Tan's own follow-up showed the real, logical output was closer to 5,700–11,400 lines/day, with lines of code (LoC) itself widely regarded as a poor productivity metric. For your career, the real signal isn't the number — it's that reviewing, directing, and shipping AI-generated code is becoming the differentiator, not typing it.

What happened / What changed

In mid-2026, Garry Tan — CEO of Y Combinator — posted on X that "agentic engineering" let him ship an extraordinary volume of AI-generated code across five personal projects during a 72-day continuous shipping streak, citing a figure of roughly 37,000 lines of code per day. The post spread fast, picked up by outlets including Fast Company and AI Weekly, and became a Hacker News flashpoint precisely because it collided with decades of engineering wisdom that lines of code is a near-meaningless productivity metric.

A Polish developer using the handle Gregorein then did what any good engineer does with an extraordinary claim: audited it. Crawling Tan's public site, they found roughly 78,400 total lines — which, averaged over the claimed period, was actually double the daily rate implied by the original post. More importantly, the audit characterized a meaningful share of that output as "AI slop code": bloated assets, unreviewed boilerplate, and rookie-level bugs sitting in production.

To his credit, Tan walked the number back publicly. He acknowledged that lines of code is a "garbage metric," clarified that his cumulative 600,000 lines over 60 days included roughly 35% test code, and reframed his actual logical output at closer to 11,417 lines/day — or about 5,708/day after accounting for AI-generated verbosity. That's still enormous by historical standards (Fred Brooks' classic benchmark from The Mythical Man-Month puts a professional engineer at roughly 10 LoC/day when you average in planning, testing, and debugging), but it's an order of magnitude away from the viral 37K headline.

This is also not an isolated stunt. Y Combinator's own data shows the shift is structural: in the Winter 2025 batch, 25% of startups had 95% of their codebase AI-generated, and YC's Jared Friedman has pointed to "vibe coding" — letting models generate software with minimal manual line-editing — as now standard practice for a meaningful chunk of the cohort. Teams are hitting $10M in revenue with fewer than 10 engineers, a headcount that would have been unthinkable pre-2023.

How it works / How to use it

You don't need to chase a viral LoC number to benefit from what's actually happening here. What's useful is adopting the workflow implied by "agentic engineering" — and doing the verification step Gregorein did, on your own code, before you ship.

1. Treat AI code generation as a first draft, not a final answer. Use tools like Cursor, Claude Code, or Bolt to scaffold features, but budget explicit review time — don't count generation time as your only cycle.

2. Instrument your own "logical LoC" the way Tan eventually did. Before reporting output anywhere (standup, performance review, resume), strip out: generated tests, boilerplate/config, auto-formatted diffs, and vendored code. What's left is closer to a defensible number.

3. Run an audit pass like Gregorein's on your own repos. Concretely:

- Diff AI-authored PRs against a checklist: duplicate logic, unused imports, inconsistent error handling, missing edge-case tests.

- Use a second AI model as a reviewer on the first model's output (cross-model review catches more than self-review).

- Track a "revert/rework rate" on AI-generated commits — this is a far more honest productivity signal than raw line count.

4. Document decisions, not just diffs. When you direct an AI agent to build a feature, keep a short log of the architecture calls you made, the prompts/constraints you set, and the bugs you caught. This becomes your evidence trail for skill demonstration — see the career section below.

5. If you manage engineers, replace "lines shipped" with a rubric. Ship velocity, defect rate post-merge, review turnaround, and architectural judgment on ambiguous problems are all more defensible signals than counting output.

Level up your career with SuperCareer. Daily 10-minute challenges, AI tutoring, and real workplace skills. Try today's challenge free →

Why it matters for your career

Software engineers: Your differentiator is shifting from typing speed to review judgment — the ability to catch "AI slop" before it ships is now a marketable, interview-testable skill. Start being able to narrate why you rejected or reworked AI output, not just that you used AI.
Engineering managers: If LoC-style metrics creep into performance reviews (even informally, via "look how much this person ships"), you need a counter-framework ready — defect rate, review quality, and architectural ownership — before a bad metric becomes your team's incentive.
Startup founders: YC's own data (25% of W25 startups at 95% AI-generated code, sub-10-engineer teams hitting $10M revenue) means your hiring bar and team-size assumptions from 2022 are stale; plan headcount and equity around AI-fluent generalists, not headcount-per-feature.
Junior developers: The entry-level job that used to be "write the boilerplate the senior engineer specs out" is being automated first. Your path in is demonstrating you can review, debug, and extend AI output correctly — build a portfolio that shows caught bugs, not just shipped features.
Job seekers / all levels: Expect interview questions to shift toward "here's AI-generated code, find what's wrong with it" rather than pure whiteboard algorithms. Practice code review, not just code writing.
Recruiters / hiring managers: Resume claims about AI-assisted output volume ("shipped X features in Y weeks using AI") need the same skepticism Gregorein applied to Tan's site — ask candidates to walk through a specific review or rework decision, not just a shipped-count.
Sales / non-technical roles at tech companies: Understand that "we ship faster with AI" claims from engineering are now a live area of internal scrutiny — don't repeat unverified velocity numbers to customers or investors without checking they survived a technical audit.

Skills to learn now

A short roadmap, roughly in order of leverage:

AI-assisted code review — Learn to prompt a second model as an adversarial reviewer of a first model's output. This is now a distinct, teachable skill, not just "using AI."

Prompt-to-architecture translation — Practice specifying constraints (data model, error handling, performance budget) precisely enough that an agent's output needs minimal rework. Ambiguous prompts produce the "AI slop" Gregorein found.

Static analysis and test-coverage tooling — Lean harder on linters, type checkers, and coverage tools as a first-pass filter on AI output before human review, since volume has gone up faster than human review capacity.

Debugging AI-generated code specifically — This differs from debugging your own code: you're reconstructing intent you didn't set, often across inconsistent patterns from different generation sessions.

Metrics literacy — Be able to explain, in a review or interview, why LoC is a weak signal and what you'd propose instead (cycle time, defect escape rate, review depth). This positions you as senior-minded regardless of title.

Multi-agent orchestration basics — Directing several agents on different parts of a codebase (what Tan's "five projects" workflow implies) is becoming a real workflow pattern, distinct from single-chat prompting.

AI coding productivity claims vs. alternatives

Approach	What it measures	Gaming risk	Career signal value	Best use
Lines of code (LoC) / day	Volume of text output	Very high — trivially inflated by verbosity, formatting, boilerplate	Low — actively misleading if reported alone	Rough internal sanity check only, never a headline metric
Feature/ticket velocity	Throughput against planned work	Medium — ticket sizing can be gamed	Medium — useful with context on complexity	Sprint planning, team-level tracking
Defect/revert rate on AI-assisted commits	Quality of AI output post-review	Low — hard to fake once tracked over time	High — directly shows review judgment	Individual performance conversations, hiring evidence
Logical LoC (Tan's revised metric, ex-tests/boilerplate)	Closer approximation of genuine new logic	Medium — still self-reported, definitional disputes remain	Medium — better than raw LoC, still needs context	Personal tracking, not cross-team comparison
Review depth / catch rate	How much problematic AI output a person catches before merge	Low	High — closest to the actual differentiating skill in 2026	Interview evaluation, senior-role differentiation

Honest limitations & criticism

The LoC-per-day framing has real, well-documented problems that this episode only reconfirmed:

It rewards bloat, not skill. A skilled engineer often reduces line count while adding functionality. Bill Gates' old line about measuring a plane's progress by its weight still applies directly to AI-generated verbosity.
It's trivially gameable. Unnecessary line breaks, redundant boilerplate, verbose AI-default formatting, and copy-paste instead of reuse can inflate any count without adding value — exactly what Gregorein's audit flagged in Tan's codebase.
Coding is a minority of the job. Estimates put actual typing/coding at roughly 30–35% of development effort; the rest is design, debugging, review, and collaboration — none of which LoC captures, and all of which matter more as AI absorbs the typing.
Cross-language and cross-tool comparisons are meaningless. The same feature can be 100 lines in one language/framework and 10 in another; AI tools generate at wildly different verbosity depending on model and prompt style, so even Tan's own "logical LoC" figure isn't comparable to another engineer's.
The audit itself has limits. Gregorein's review was of a public site, not the full private codebase or commit history, so "AI slop" characterizations, while credible, are based on partial visibility — worth noting before treating the critique as a complete technical audit.
Tan's walk-back is itself unverified beyond his own follow-up post. There's no independent audit confirming the corrected 11,417 or 5,708 figures either — treat both the original and revised numbers as self-reported until someone replicates the analysis.
"Vibe coding" has real quality costs that YC's own adoption data doesn't measure. A startup having 95% AI-generated code says nothing about defect rates, security posture, or maintainability — metrics that matter far more once that code is in production and under real usage.

SuperCareer's take

Learn the workflow, ignore the number. The 37K figure is a distraction — it's already been walked back by the person who made the claim. What's real and durable is the underlying shift: AI has compressed the cost of generating code toward zero and left the cost of verifying code roughly where it was. That means review skill, architectural judgment, and the ability to specify intent precisely to an agent are now the scarce, valuable parts of the job — the same skills that separated senior from junior engineers before AI, just with higher stakes and higher throughput.

If you're an engineer, don't wait for your company to formalize new evaluation criteria — start building your own evidence trail of catches, reworks, and architectural calls now. If you're a manager or founder, get ahead of LoC-style metrics creeping into reviews before someone on your team starts optimizing for the wrong number. This is a "learn now" signal on review/verification skills, and a "wait and verify" signal on any raw output-volume claim you see cited as evidence of individual or team productivity.

Frequently Asked Questions

Is lines of code a good measure of developer productivity?

No. Experts have criticized LoC as a productivity metric since Fred Brooks' 1975 The Mythical Man-Month. It rewards verbosity over elegance, varies wildly by language, and ignores debugging, design, and review — the majority of real engineering work. In the AI era it's even less reliable, since AI can generate large volumes of low-value "slop" code.

How much code can AI coding tools actually generate per day?

Technically, tens of thousands of raw lines is possible with agentic tools working across multiple projects, as Garry Tan's original claim suggested. But "logical" output — new, meaningful code excluding tests and boilerplate — is far lower; Tan's own revised estimate was roughly 5,700–11,400 lines/day.

Will AI coding tools replace software engineers?

Not wholesale, based on current evidence. Y Combinator data shows some startups running with 95% AI-generated codebases and much smaller teams, but human engineers remain essential for architecture, review, and catching errors AI introduces — the skill mix is shifting, not disappearing.

What skills matter most for developers in the AI coding era?

Code review and debugging of AI-generated output, precise prompt/constraint specification, cross-model verification, and metrics literacy (knowing which productivity signals are meaningful). These skills catch the "AI slop" that raw generation speed introduces.

How do you evaluate engineer performance when AI writes the code?

Favor defect/revert rate, review depth, architectural decision quality, and cycle time over any raw output-volume metric like LoC. These are harder to game and better reflect the actual differentiating skill: verifying and directing AI output rather than typing it.

What is "vibe coding" and how does it affect code quality?

Vibe coding refers to letting AI models autonomously generate large portions of a codebase with minimal manual editing, a term popularized in this context by Garry Tan. It can accelerate shipping speed significantly but, per the Gregorein audit of Tan's own site, risks bloated, under-reviewed, bug-prone output without disciplined review processes.

Should developers report AI-assisted output in performance reviews?

Only with context, not raw numbers. Reporting a bare LoC or feature count invites the same scrutiny Tan's claim received. Better to report specific outcomes: features shipped and stable in production, defects caught before merge, and architectural decisions you made while directing AI tools.

How can engineers stand out when AI tools write most of the code?

Build a visible track record of catching and fixing AI-introduced problems, not just shipping fast. Document review decisions, maintain low defect/revert rates on AI-assisted work, and be able to explain your architectural reasoning — the human judgment layer AI still can't reliably replace.

Join the SuperCareer AI career newsletter for your personalized roadmap.