37,000 Lines of Code a Day Is Not a Flex
When Gary Tan, CEO of Y Combinator, talks about writing 37,000 lines of code a day across multiple projects, most people hear the future. I hear a warning.
Not because I'm anti-AI. I use it every day, and it's one of the best productivity tools we've gotten in years. But I also think we're starting to believe the wrong things about it.
The wild claim is not that AI can help you write code faster. The wild claim is that raw output is the same thing as engineering quality. It isn't. And when that claim comes from someone with YC's reach, it shapes how founders and engineers think about what "good" looks like. That's why it's worth pushing back on.
The audit that made it concrete
We don't have to speculate about what that looks like in practice. Scott Tolinski's video breakdown made the problem painfully concrete. He wasn't arguing that AI is useless. He was arguing that if your metric is output volume, you can end up shipping something that technically works while still being full of engineering mistakes.
In the audit he walks through, the problems weren't subtle: test files shipped to production, scaffolding files ending up in the bundle, oversized assets, duplicated DOM output, missing accessibility basics like alt text.
"It shipped" is not the same thing as "it was engineered well".
AI learned from the average of the internet
Part of the problem is that people talk about AI as if it were trained on the best engineering judgment humanity has to offer. It wasn't. It learned from a public corpus of code and text, and the internet is not a handbook of great software engineering.
Most code out there is average. Duplicated, outdated, or just wrong. So if you point an AI at a codebase without strong guidance, what you usually get back is not great code. You get plausible code. Code that looks right, passes the glance test, and often solves the problem locally while quietly making the system worse globally.
Recommended by LinkedIn
In my own work, the most common thing I catch when reviewing AI-generated code isn't bugs. It's duplication. Functions that do the same thing, written differently, scattered across the codebase. The AI didn't know that logic already existed somewhere else. It solved the local problem and moved on.
That's why I don't believe wild productivity claims about AI at face value anymore. If someone tells me they generated tens of thousands of lines of code in a day, my first question isn't "How did you do it?" It's "Who read it?"
Stop outsourcing your brain
This is also why Mario Zechner's post, Thoughts on slowing the fuck down, resonated with me. His point isn't to stop using AI. His point is to stop outsourcing your brain.
Let the agent do the boring parts. Let it explore. Let it save you time. But keep the human bottleneck where it matters: architecture, API design, review, deciding what should ship, and deciding what should not exist at all. That's where taste lives. That's where reliability and maintainability come from. And that's exactly what disappears when the only thing you celebrate is speed.
Software is getting more brittle
Software feels more brittle lately. Outages that shouldn't happen. Regressions in products that used to be stable. I don't think AI alone caused that. But the industry is normalizing a dangerous idea: that more output, faster shipping, and fewer human bottlenecks automatically mean better software. They don't. Once you remove too much friction, you often remove the very thing that was preventing bad changes from compounding.
What to do instead
So use AI. But read the code, shape the code, and own the code. Add deterministic checks that catch the kind of slop AI is good at producing -- dead code, duplicate code, unnecessary complexity, architectural hotspots. Not because any tool will save you, but because it gives you a faster way to see where your codebase is quietly getting worse.
I'm still bullish on AI for software engineering. I'm just not bullish on hype. The future doesn't belong to the people generating the most code. It belongs to the people who use AI without giving up judgment, who move faster without confusing speed for quality, and who know that a thousand lines of intentional code are worth more than 37,000 lines nobody understands.
Use AI. Be productive. Just don't outsource your brain.
I feel this partly a you problem. Have you set guardrails, have you told their role and are your prompts accurate (inputs/outputs)? I've used AI all week and I've maybe got 600 line of code out of it (of which, 10% are useless or just bad)
Humans can only reasonably write or review no more than about 1000 lines of code per work day.
I think the deeper problem is not just the raw volume of AI-generated code, but what happens after that code enters real repositories. The real risk is that humans will eventually be forced to maintain a massive codebase full of low-value or poorly reviewed code. Without enough review, pruning, and careful human judgment, the repository gradually fills with noise. At that point, the problem is no longer “AI wrote too much,” but that both humans and AI may struggle to tell what is actually valuable and what is just garbage. That is how software becomes unmaintainable — not in one dramatic moment, but through the slow accumulation of code that nobody truly understands or confidently owns.
When someone boasts about how many lines they’ve produced, I just know they’re an amateur.
Actually, writing code usually takes less than 10-20%, and that's including cumbersome tests. Sometimes it is less than 5%, or even 1%. I bet you would be able to re-type a project worth several man/years in just a matter of weeks. If you've just finished implementing some bulky feature that took you, say, months of development, and by accident lost all the source code it will take you a week at most to recover it by memory. So, where did all those months go? If you start from a false preposition that coding is the problem you’ll move into the wrong direction and end up exactly where you started. Interestingly, on the diagrams there is not a single word about requirements and requirements management.