We've optimized the wrong thing. Error monitoring tools got really good at catching problems and alerting you about them. But then what?
The 3 AM Alert
You know the drill.
Your phone buzzes. It's 3 AM. Your error monitoring tool has detected a spike in TypeError: Cannot read property 'email' of undefined.
You groggily open the dashboard. There it is—a beautiful stack trace, complete with breadcrumbs showing exactly what the user did before the crash. Your monitoring tool did its job perfectly.
Now what?
You rub your eyes. Open your laptop. Clone the repo (if you're not on your work machine). Read the stack trace. Find the file. Understand the context. Write a fix. Test it. Push it. Deploy it.
Two hours later, you're back in bed. The alert is resolved. The monitoring tool marks it as "fixed."
Here's my question: If we can build AI that catches errors in milliseconds, why does fixing them still take hours?
We've Optimized the Wrong Thing
Over the past decade, error monitoring has gotten incredibly sophisticated:
- Real-time detection — Errors captured the instant they happen
- Smart grouping — Related errors clustered together automatically
- AI root cause analysis — Some tools now tell you why it broke
- Session replay — Watch exactly what the user did
- Integrations everywhere — Slack, PagerDuty, Jira, you name it
All of this optimization has made us really, really good at knowing about problems.
But knowing isn't fixing.
And here's the uncomfortable truth: the time between "error detected" and "error resolved" hasn't meaningfully changed. We've just made the alert prettier.
The Resolution Gap
Think about what actually happens after an alert:
- Alert fires (instant)
- Human notices (minutes to hours)
- Human investigates (15 min to 2 hours)
- Human writes fix (30 min to days)
- Review and deploy (15 min to hours)
- Monitor for regression (ongoing)
Steps 3-5 are where all the time goes. And no amount of dashboard polish helps there.
This is the Resolution Gap: the delta between error detection and error resolution. For most teams, it's measured in hours or days. Not because they're slow—because fixing bugs is genuinely hard work.
What If We Skipped to Step 5?
Here's the thought experiment that led me down this rabbit hole:
Modern AI can:
- Read and understand codebases
- Identify patterns and anti-patterns
- Write syntactically correct code
- Understand error messages and stack traces
So why is it just telling us about errors instead of fixing them?
Imagine an alternative flow:
- Error fires
- AI reads error + stack trace + your codebase
- AI generates a fix
- Pull request opens automatically
- You review and merge
From "error detected" to "fix ready for review" in seconds. The Resolution Gap collapses.
"But AI Can't Write Good Code"
I hear this objection a lot. Here's my take:
AI doesn't need to write perfect code. It needs to write reviewable code.
When a pull request lands in your inbox, you don't blindly merge it. You review it. You check the logic. You test it. That's true whether the author is an AI or a junior developer.
The value isn't in AI being infallible. The value is in AI doing the grunt work of:
- Reading the error
- Finding the relevant file
- Understanding the context
- Writing a first-pass fix
Even if the AI is right 70% of the time, that's 70% of bugs where you skip straight to code review instead of debugging from scratch.
The Future of Error Monitoring
I think we're at an inflection point. The tools that win the next decade won't be the ones with the prettiest dashboards or the most integrations. They'll be the ones that close the Resolution Gap.
Error monitoring → Error resolution.
Detection is table stakes. Speed to fix is the new battleground.
We're Building This
Full transparency: I'm working on Shipd, an error monitoring tool that opens pull requests automatically when your production code breaks.
The premise is simple: if AI can understand your error and your codebase, it should write the fix. You review and merge. Done.
It's not magic. The AI isn't perfect. But it turns hours of debugging into seconds of code review—and that's a trade-off I'll take every time.
What do you think? Is automated bug fixing the future, or is there value in manually debugging that I'm missing? I'd love to hear your perspective in the comments.
Top comments (0)