Hi, it's been a while since I wrote an article. It feels great to be looking at this blank canvas and typing in the middle of the night. Brings back a lot of nice memories :)
For the first time, I'm building a developer tool, and I'm really curious to hear your thoughts on this one.
So, let's jump right in.
There are already plenty of tools for tracking errors and understanding what happens in production. So why build another one?
For me, it comes down to how I think development is changing.
Coding agents are taking on more of the work, and I expect that to continue. But being able to read an entire repository and write a patch is only part of the job.
When something goes wrong in production, the agent also needs a useful way to find out what actually happened around that failure.
Which request failed? What was logged before it? Which release was running? Was something deployed a few minutes earlier?
The challenge, at least to me, isn't giving an agent access to as much data as possible. It's giving it the right evidence in a form that is simple, structured, and reliable.
That is the part I want to work on with DebugBundle.
The code is only part of the picture
An agent might understand a function perfectly and still have no idea why it failed in production.
A stack trace gives you one piece of the story, but the useful context is often spread across different places: request data, logs, release information, environment details, and whatever else happened around the error.
Someone usually has to connect those pieces before the investigation can really begin.
I don't think the answer is simply to give an agent access to everything.
More data can mean more noise, more sensitive information to handle, and more opportunities to interpret something incorrectly. I would rather give the agent a bounded set of useful evidence, while making it clear what is available and what is still missing.
The idea behind DebugBundle is to capture a production error and bring the relevant context together into a structured debug bundle.
A developer can inspect it, and a coding agent can retrieve the same bundle through tools such as a CLI or MCP, alongside the code it is already working on.
The bundle doesn't tell the agent that its proposed fix is correct. It gives it a much better starting point, and gives the person reviewing the fix something concrete to check.
Assuming you're still doing that :)
Why build in a crowded space?
I don't think existing tools are suddenly irrelevant, or that nobody else is thinking about agents. There is already a lot of good work happening here.
What interests me is building around the agent workflow from the beginning.
An agent needs to detect a problem, inspect the available evidence, understand what is missing, and work toward a fix that can actually be tested.
To me, that is slightly different from taking an existing observability product and adding an AI interface on top of it.
I want the main artifact to be something deliberately small enough to reason about: a bundle of production evidence that both an agent and a human can inspect and understand.
Then, if more context is needed, the agent can deliberately go and retrieve it.
That is the direction I'm taking with DebugBundle.
Production debugging for coding agents, without hiding everything behind a complicated dashboard or requiring a large setup before it becomes useful.
The goal is a flow that can increasingly be handled by AI: from initial integration, to detecting an incident, retrieving its context, investigating it, and helping work toward a tested fix.
Not a promise that every incident can be reproduced.
Not a promise that every proposed fix is correct.
And definitely not a promise that every fix should be deployed automatically.
Where I think this could go
I expect agents to take on more of the development loop, including more of the work that happens after code reaches production.
That makes the boundary between evidence and action increasingly important.
Retrieving a failed request is one thing.
Replaying it against a live system is another.
Suggesting a fix is different from deploying it.
I want those distinctions to remain clear even as the tools become more capable.
There are also some interesting questions around what should actually belong inside a debug bundle.
Request and release context are already part of the idea, but how much further should that go?
Would rollout history help explain when a problem started?
Should feature flag changes be part of it?
Should related requests be included directly, or should the agent retrieve them separately when it has a reason to look?
I don't want a useful bundle to slowly become a copy of the entire production environment.
The interesting problem, to me, is choosing what evidence is useful by default, making the gaps visible, and keeping access to additional context deliberate.
That is the future I'm interested in building toward: agents doing more of the work, with tools that help them investigate production issues quickly while still giving us a clear way to understand and review what they found.
I'd really like feedback from people building with coding agents or maintaining applications in production.
What do you still have to gather manually before an agent can actually help with a production issue?
And where would you take this idea: deeper rollout context, related requests, feature flags, something else entirely?
P.S. These thoughts are my own. Proofread by AI.
Top comments (0)