Why Writing Code Was Never the Software Bottleneck

TL;DR

Writing code was never the real bottleneck in software engineering. The actual constraints are code reviews, mentoring, testing, debugging, and the human overhead of coordination and communication. AI generates working code faster than ever, but the cost of understanding, testing, and trusting that code is higher than ever, so shipping does not speed up proportionally.

Transcript

I think it's fair to say that a lot of people are writing way more code today than they were a few years ago. And I don't mean literally typing it all out themselves. I'm talking about all these cool vibe coding tools, AI agents that help you produce and write a bunch of code. That said, I don't feel like I'm seeing a lot more shipping happening. A... Read More

Key Insights

• Writing lines of code was never the bottleneck of software engineering. The real bottlenecks are code reviews, knowledge transfer through mentoring and pairing, testing, debugging, and the human overhead of coordination and communication.
• The marginal cost of adding new software is approaching zero with LLMs, but the price of understanding, testing, and trusting that code is higher than ever, so faster code generation does not translate into faster shipping.
• More code is being produced today thanks to vibe coding tools and AI agents, yet the speaker sees no increase in shipped features, real-product innovation, or everyday improvements, and if anything less is happening.
• Shipping fast without compromising quality came from finding the right corners to cut, trimming the right edges to simplify the problem space, rather than building perfectly on the first try.
• Building something wrong but working quickly, then improving it rapidly through cycles of user feedback, works because a well-structured system makes changes easy and confident to make.
• The T3 stack was born from finding a way to get the full-stack type safety and agility benefits of GraphQL without requiring the large team and huge buy-in that GraphQL demanded at Twitch.
• A common tactic was requesting a fake deadline two weeks to two months earlier than the real one, hitting it, then spending the extra time fixing bugs, finding performance issues, and polishing, as done with Twitch's ModView.
• The product design process at Twitch ran eight steps from a PM identifying a problem to a dev-ready spec, and often took 6 to 18 months, showing how much non-coding overhead surrounds actually building features.

Questions & Answers

Q: Why hasn't AI coding led to more features shipping?

Because code was never the bottleneck of software engineering. The actual bottlenecks are code reviews, knowledge transfer through mentoring and pairing, testing, debugging, and the human overhead of coordination and communication, all wrapped in tickets, planning meetings, and agile rituals. AI makes generating code faster, but these processes require thought, shared understanding, and sound judgment, so removing the coding step alone does not produce more shipped features or innovation.

Q: What is the real bottleneck in software engineering?

The real bottlenecks are code reviews, knowledge transfer through mentoring and pairing, testing, debugging, and the human overhead of coordination and communication. These live inside the labyrinth of tickets, planning meetings, and agile rituals. Meant to drive quality, these processes often slow teams down more than writing code itself because they require thought, shared understanding, and sound judgment, none of which AI can simply generate away.

Q: Does cheaper code generation from LLMs make software cheaper overall?

Not really. The marginal cost of adding new software is approaching zero, especially with LLMs generating working code faster than ever. But the price of understanding, testing, and trusting that code is higher than ever. A new narrative claims writing code was the bottleneck and that it has been cracked, but that is not quite right because the surrounding costs of comprehension and trust rise instead of disappearing.

Q: How did the speaker ship fast without sacrificing quality?

He had a strange, unique skill for finding the right corners to cut so he could ship fast without meaningfully compromising quality, usually by trimming the right edges. He would look at a team's plan and find an edge to remove that simplified the problem space, creating a better path to success. He also built things wrong but working quickly, then improved them rapidly through cycles of user feedback.

Q: What is the fake deadline strategy the speaker used at Twitch?

He asked his manager or PM to give him a fake deadline set between two weeks and two months earlier than the actual release date, then convinced himself it was real so he would hit it. Once the work was done and working, the team spent the remaining time fixing bugs, finding performance issues, and polishing. Twitch's ModView launched in a strong state this way, finished a month before the real release.

Q: How was the T3 stack created?

The speaker admired the full-stack type safety of GraphQL, which was a massive win for his teams at Twitch, but making GraphQL work well for both developers and users required an entire team of people, so a company needed many employees before it was worthwhile. He wanted the same safety and agility without GraphQL's huge buy-in, and the T3 stack was born when he found the right way to glue those parts together to ship faster.

Q: What were the steps in Twitch's product design process?

First a product manager identifies a problem through user voice, events, or gap analysis. Second, they talk to users about the problem, though many PMs skipped this. Third, they work with design to define the solution literally and spiritually, sometimes making mocks. Fourth, they write a five to thirty page product proposal spec and present it for PM and exec approval. Then developers take over, review the spec, and write their own long spec.

Q: How long did the traditional product development process take?

From step one, a problem being identified, to step eight, a developer-ready spec, the process took roughly 6 to 18 months to go from top to bottom. More urgent problems, such as safety issues, were handled much faster by skipping many steps because they needed fixing as soon as they were known. But in other orgs it could take months, if not years, to move from an identified problem to a ready document.

Summary & Key Takeaways

• People write far more code today using vibe coding tools and AI agents, but the speaker sees no more shipping, features, or innovation in real products. Since code was never the bottleneck, removing the need to wait for code does not automatically produce more releases.

• The true bottlenecks are code reviews, knowledge transfer, testing, debugging, and human coordination, all wrapped in tickets, planning meetings, and agile rituals. These require thought, shared understanding, and judgment, and often slow teams more than writing code does.

• The speaker's edge was finding corners to cut and simplifying problems to ship fast without sacrificing quality, using fake early deadlines to leave time for polish. AI agents can now do some of that shipping work, but the surrounding non-generatable process remains.