For ten years, the error monitoring platform has been at the centre of production engineering. Sentry, Rollbar, Bugsnag, Honeybadger and Airbrake capture exceptions, group similar ones together, route alerts to the right engineer, and give the team a dashboard for triage.
These tools are good at what they do, and they keep getting better. Capture is faster, grouping is smarter, and most of them now cover performance, session replay, release health and profiling as well.
What happens after the alert has mostly been a person's job: read it, find the cause, write the fix, open a pull request, merge. That part of the loop is now changing too.
Why the Work After the Alert Was Manual
For most of the history of software, only a person could read a stack trace, understand the code around it, and write a correct fix. Error monitoring was designed around that fact, and designed well.
Ownership rules exist so an alert finds the right person. Triage workflows exist so people can decide which bugs matter. Grouping and deduplication exist because nobody can read 500 identical alerts. All of it gets the right information to the right engineer quickly, and that is still what you want for any problem that needs a person.
What Changed
Three things happened over the last two years.
Frontier AI models can write production code. As recently as late 2023, AI-generated code needed heavy review before it could ship. By 2025, models like Claude and GPT-4o could read a stack trace, locate the bug in the source, write a fix in the style of the surrounding code, and explain their reasoning.
CI pipelines became universal. Almost every codebase that ships to production now runs automated tests, linting, and type checking on every commit. This is the safety net that makes automated fixes practical. An agent's change goes through the same checks as anyone else's before it can merge.
Developer time got more expensive. Engineering salaries continued to climb while the volume of production code grew faster than headcount. Having a senior engineer spend 30 minutes diagnosing a null pointer exception costs more every year.
Together, these mean the fix step can now be automated for a meaningful share of production problems.
What Maintenance Adds
Monitoring surfaces information. Maintenance acts on it. For a production error, the pipeline looks like this:
- Capture. The error arrives with its context: stack trace, route, request shape, environment. It can come from an SDK in the application or from the monitoring tool the team already runs.
- Reproduce. The agent pulls the relevant source code from the repository and reconstructs the error condition.
- Fix. The agent generates the patch. With bugstack, a crash fix over 3 files or 30 lines always waits for review.
- Validate. The fix runs through the existing CI pipeline. Tests, linter, type checker.
- Ship. The fix arrives as a pull request. Depending on the autonomy level set for the repository, a person merges it, or it merges on its own once CI passes and a reproduction proves the fix.
Monitoring vendors are building in this direction as well. Sentry's Seer analyses issues inside Sentry and can draft a pull request. We think that is good news for everyone: it shows the work after the alert can be automated, and teams get to choose where that work happens.
Errors are also only one input. The same system can act on failed deploys and scan the repository for known-vulnerable packages, committed secrets, and outdated packages. That is why we call the category autonomous software maintenance.
For a deeper technical breakdown of how this works in practice, see our complete guide to autonomous software maintenance.
What Monitoring Does That Maintenance Does Not
A maintenance system does not replace your monitoring. Monitoring does several things that maintenance has no answer for:
Visibility into errors that can't be auto-fixed. Many production bugs are stack-trace-anchored and small enough to fix automatically. The rest are logic errors, architectural problems, business rule violations, and silent failures. Those need people, and people need visibility. bugstack, for example, captures uncaught server-side errors. It does not do performance monitoring, browser-side errors, or silent failures.
Aggregate trend analysis. Knowing that errors are up 30 percent week-over-week is useful whether or not the individual errors get fixed automatically.
Long-tail debugging. When a complex bug takes hours of investigation, the context a monitoring tool provides (breadcrumbs, session replay, related events) is what the engineer works from.
Most engineering teams will run both: a monitoring tool for visibility, and a maintenance system that takes the routine fixes off their plate.
Where the Person Sits
In a maintenance system the agent reads the error and writes and tests the fix. A person decides what merges. That decision is the control that matters, so it should be explicit.
bugstack makes it a setting on each repository: draft fixes, open pull requests for a person to merge, or merge once the proof is green. New accounts start at the level where a person merges everything. Sensitive changes, such as rotating a secret or rolling back a deploy, always wait for a person.
What to Expect
Monitoring is staying. The share of production problems that software can fix on its own will grow each year, and more teams will hand that share over as they come to trust it.
The teams running production codebases in 2030 will still open their monitoring dashboard. They will also review the pull requests their maintenance system opened overnight.
Want to see what this looks like in practice? bugstack is an autonomous maintenance department for your software. It takes problems from its own SDK or the telemetry you already run, writes the fix, runs your CI, and sends you a pull request you control. bugstack is in early access. Personal onboarding, set up with you.