Is 37,000 lines of AI code per day a real productivity story?

37,000 AI code lines a day: what founders should learn

Garry Tan's 37,000-lines-per-day claim went viral in 2026, then a Polish engineer audited the resulting site: 169 requests, 6.42MB per page load, one logo shipped in eight formats. The lesson is not that AI coding does not work; it is that lines of code is the wrong metric, and taste is now the scarce resource.

The Tan story became a Rorschach test for how founders feel about AI-generated code, so it is worth being precise about what actually happened. In March 2026 Y Combinator's Garry Tan posted that he was on a 72-day shipping streak producing about 37,000 lines of AI-generated code per day across five projects via a workflow he called gstack. A senior game engineer working under the handle Gregorein then audited Tan's personal AI blog — reportedly built with the same setup — and reported that a single page load fired 169 server requests totalling 6.42MB, that the site shipped 28 test files and 78 unused JavaScript controllers to every visitor's browser, and that a single logo was present in eight different formats including a zero-byte broken AVIF file. Even Sam Altman weighed in, saying that measuring engineering by lines of code is, in his words, an "insane way" to assess output.

I have used a similar workflow for two production projects and I have opinions. The first is that Tan is not lying and Gregorein is not wrong — both things are true at once, and the tension between them is the actual signal for founders. AI agents genuinely can generate tens of thousands of lines of technically-functional code per day. They also generate the boilerplate, dead code, redundant assets, and unused abstractions that produce a 6.42MB blog homepage when the same page done by a human of Gregorein's caliber would be 15KB. The productivity is real. The waste is also real. The interesting founder question is which one you optimise for.

Here is the mechanism that makes the waste look invisible from the driver's seat. An agent operating in a loop — Claude Code, Cursor's background agents, Devin, gstack, take your pick — always finds a solution. If your test fixture is missing it generates one. If it cannot import a helper it writes a new helper. If the AVIF export failed it silently ships the broken file next to the working PNG. From the outside, and from inside the diff, it all looks like forward progress. Nothing errors. Nothing gets flagged. The tab count in your terminal keeps climbing. This is why Daniel Kahneman's WYSIATI ("what you see is all there is") from Thinking, Fast and Slow is the single most useful frame I know for using these agents responsibly — the feedback loop shows you everything the agent did and nothing it should not have done. The absent code review is what breaks you.

The failure mode is not that AI writes bad code. It is that AI writes plausible code, at volume, and a founder without the taste to say "this is one logo file, not eight; this is one controller, not 78" ships all of it. Gregorein caught it because he is a senior engineer with twenty years of pattern-recognition for smells. Most founders using these tools do not have that recognition, and the agent will not develop it for them. This is the real thing Ethan Mollick means in Co-Intelligence when he talks about the "cyborg" versus "centaur" split — the cyborg who fuses with the tool ends up producing whatever the tool suggests; the centaur who supervises it produces whatever they, the human, would have produced if they had unlimited hands.

So what should founders actually do? First, stop counting lines. The metric that matters is roughly: what fraction of shipped code would survive review by an engineer you respect? At my own bar right now that number is somewhere between 40% and 70% depending on task type — significantly higher for tests, migrations, and glue code, significantly lower for anything involving performance, security, or non-obvious architectural choices. Second, add an aggressive review layer. I run every AI-generated PR back through a second-pass "critique" prompt (a different model, different context window, framed as an adversarial reviewer) before I even look at it myself, and I still catch things the critique missed. Third, treat the output as a first draft the way you would treat any junior's first draft — not as a shippable artifact.

The larger point is that founders who read Tan's 37k number as a productivity ceiling to chase are optimising the wrong variable. The real leverage in 2026 is not "how much can I generate" but "how much of what I generated is worth keeping." That is a taste problem, not a throughput problem. And taste, as Cal Newport keeps pointing out, is the one thing these tools have not made easier to acquire.