AI Coding: the end of papercuts?
A $1TN opportunity hiding in plain sight
Thank you Nan Yu, Head of Product at Linear, Tristan Homsi, Founder & CTO at Readwise, and Dani Grant, CEO at jam.dev, for draft input.
We’re in a new era of app creation.
AI is dramatically and exhilaratingly accelerating software development.
The first wave accelerated existing workflows — through GitHub Copilot, Cursor, Windsurf, and others. The second wave handled end-to-end app creation — through Replit, Bolt, v0, and others.
We wake up each day to fresh memes, from vibe coding to apps that make apps.
Yet despite this, there’s limited focus on AI’s potential to directly and radically improve software quality.
20% tax
Quality affects us all.
Every bug represents user confusion, disappointment, frustration. Each bug is encountered until fixed.
As a result, companies pour enormous energy into fixing bugs.
A 1978 study found that 17% of development effort was spent fixing bugs. Research on GitHub repositories in 2020 found the median had risen to 20% (source).
$1TN opportunity
In the US, software engineer salaries sum to around $225BN per year ($150k x 1.5M engineers). 20% represents an opportunity cost near $50BN per year.
And the worldwide engineering market is 20x larger: from $50BN to $1TN.
This doesn’t even consider…
time non-engineers like business leaders, PMs, and customer support spend on bugs
the opportunity cost of that time not being applied to more impactful work
Enduring brands
The case for quality stretches further: high quality software builds brand, loyalty, and love. And these things drive growth.
At Superhuman, a core value is, and has always been, “Deliver Remarkable Quality”. The definition includes:
Deliver work so good that it compels others to talk about it. We stand behind the excellence of our work and set new standards in the industry.
Product quality has undoubtedly driven both growth and industry influence for Superhuman.
In a software-abundant world, there will be increasing rewards for producers who cultivate enduring brands.
So, what can companies do about this?
Bugs will always exist
e/acc optimists might ask: “Won’t AI coding preemptively fix all bugs?”
Let’s consider the arguments for:
A human is limited by their coding experience; an AI is trained on an incomprehensibly vast code library.
A human might write a couple of unit tests; an AI could push towards mythical 100% coverage.
A human might cursorily review a PR before declaring “lgtm”; an AI can aggressively scan for regressions, security risks, and performance issues.
We see all these and more with AI IDEs. But let’s now consider the countervailing forces:
More AI coding means more lines of code. More lines of code means more bugs.
More AI tooling means more engineers. More engineers means more bugs.
More software created means more software used. More software used means, yes, more bugs.
Most important are the fundamentals. From Nan Yu, Head of Product at Linear:
Bugs will always exist because the definition of a bug is not: "it doesn't work as we intended", it's "it doesn't work as a user expects it to”
Bugs will always exist because of the halting problem
A vast amount of willpower
Every app has some version of this loop:
User encounters bug
User reports bug
Company logs bug
Engineer fixes bug
Large companies fall at the first hurdle by not even facilitating step 2. We’ve all experienced hunting for a support email only to discover that it is deliberately obfuscated.
It’s existential for most startups to strongly prioritize steps 2, 3, and 4. And those that seek to differentiate push further. They add “step 2.5” to provide workarounds, and “step 4.5” to notify users when their issue is fixed.
But maintaining this consumes a vast amount of willpower:
Step 2 requires users to go out of their way to report issues. Most don’t. Those who do rarely describe problems accurately.
Steps 2.5 and 3 require a Support team that isn’t just well-versed in the product, but also the issue tracker, and with enough time in their day to file.
Step 4 consumes the aforementioned 20% of engineering team bandwidth.
Step 4.5 demands data to pinpoint the exact users who encountered each issue, and dependable workflows to share when their issue is resolved.
Valiant attempts exist to streamline the loop, but they tackle each step in isolation. For example, Intercom speeds up communication. But it doesn’t help with triage or resolution.
Like every other part of product development, this loop is due a shakeup.
A wildly better reality
Let’s imagine a wildly better reality. It might look like the following:
User encounters bug
AI agent notices
AI submits fix with tests
Engineer approves
Of course, as before, this could be pushed further to include “step 2.5” of the AI helping users in realtime, and “step 4.5” of the AI notifying users when their issue is fixed.
What is needed to pull this off? The agent needs access to:
Signs of issues
Intended functionality
Gathered from PRDs, mockups, commit messages, and support docs.
Supplemented by product owners.
Developer environment
Read/write access to the code and version control system.
User access
A means of communicating with users.
Does every step of the chain need to be implemented? Certainly not. Each step holds huge value. And it’s beginning:
However, I suspect the most value exists in the leap from well-described issues to review-ready pull requests.
At the time of writing, few good solutions exist for this. A Google search for “AI bug fixer” yields hacky ‘paste code into a textbox’ web apps, and custom GPTs.
Humans still, for now, have to parse issues and prompt the machine.
Bug hunters
A new class of roles could emerge in this world.
As the marginal cost of fixing issues approaches zero, companies have incentive to maximize finding bugs. In doing so, they can ship products at never-before-seen quality levels.
Every role can shift closer to value creation:
Engineers spend less time fixing issues, and more time on big swings. Junior and new devs normally cut their teeth on bugfix. Instead they could machine through a few dozen automatically prepared fixes, then move onto feature work.
QA spends less time reproducing issues, and more time fixing them. Triaging tickets could elevate to maintaining an army of QA bots that hunt down and fix issues.
Support spends less time fielding complaints, and more time accelerating product improvement. With freed up time the role could shift towards the “success” end of the spectrum.
And companies might extend financial reward to anyone who finds any bug — so long as there are reproduction steps detailed enough for an AI to run with.
Incredibly simple vs. fiendishly hard
Of course, anybody who has touched a codebase knows that fixing bugs ranges from incredibly simple (e.g. copy fix) to fiendishly hard (e.g. sporadic race condition on rare hardware).
They also know that bugs are often symptomatic of deeper issues: problematic abstraction levels, brittle architecture, and more.
So how far can LLMs realistically go?
Today’s LLMs can already fix a meaningful percentage of encountered bugs. And they can already accelerate humans towards the rest.
As LLMs get more powerful, the line will constantly shift, with more and more falling on the side of direct fix.
A handsome pot of gold
Software engineering continues to be one of the most exciting applications of AI.
And bugs will always exist.
A handsome pot of gold exists for startups building tools that directly deliver working fixes from described issues.
Those who extend the chain into realtime issue detection and proactive customer communication can deeply embed themselves in business stacks.
What’s holding back startups back from seizing this opportunity? I sense two barriers:
We have the components, but not the workflow. Adopting software often means adopting a practice. Superhuman means Inbox Zero. Linear means cycles. Slack means channels. Someone needs to opinionatedly define a new bugfix paradigm, meld it into working software, then go forth and proselytize. The hard work must happen.
Fixing bugs just isn’t as flashy as helping engineers crank out features 10x faster, or creating apps that create apps. The goldrush has — reasonably — tackled building, not fixing. What’s visual is viral, and what’s viral sells. But software engineering is entering its next phase — where AI steadily seeps its way into every corner and crevice.
On the other side of this pot of gold, companies adopting these tools can dodge a huge portion of the 20% bug tax, ship better products, and build enduring brands.