Every launch brings a wave of errors. A few are real bugs. Most are noise: a browser extension misbehaving, an in-app browser doing something odd, a bug you already fixed last week. Nobody has time to look at all of them, so usually nobody does, and the real problems hide in the pile.
We decided our own product wouldn't work that way. It's a SaaS platform for consignment shops, heading into launch, and every error it throws now goes to an AI worker that reads it, decides what it is, fixes the ones that are ours and checks the fix before anyone signs off. People still make the calls that need judgment. They just don't spend their mornings digging through the pile anymore.
How it works
Errors from the app land in one place, and an always-on AI worker picks up every new one. It sorts each error as it arrives. Noise, like errors from browser plugins we don't control, gets set aside with a note saying why. Real bugs become tickets.
The same worker takes the ticket from there. It writes the fix on a separate branch and opens it for review, waits for the test site to update, then opens the app in a real browser and confirms the fix works. If it does, the ticket closes with the evidence attached. If it can't confirm it, a person gets the ticket, with everything the AI found so far.
The result is a product that notices its own problems, fixes the routine ones and asks for help with the rest. Some vendors have started calling this "self-healing software." In practice it's less magic than that sounds, and more useful. Here are five things we'd tell anyone thinking about it.
1. Most errors aren't bugs, so sorting comes first
When we first looked, there were a couple dozen errors in the tracker and none of them had been reviewed. Some were real bugs. Some came from browsers and extensions we don't control. Some were already fixed. A few were tests we had broken on purpose.
So we set one rule: every error ends in exactly one of four states.
- Fix. It's our bug. It gets a ticket, a fix with a test, and the error is closed with a link to the fix.
- Resolve. It's already fixed, or it was deliberate. Closed, with the proof.
- Suppress. It isn't our code. Hidden, with a written "not worried because…"
- Watch. Real, but rare. It gets a note saying what would make us act, like "if this shows up three times in a week, fix it."
AI is good at this. It reads the error, checks the code and its history, and writes down its reasoning. The written reason is the part that pays off. Months later, when someone asks why an error was ignored, the answer is already there.
2. The AI has to check its work somewhere real
Passing tests is not the same as working. Tests check what someone thought to test. So our worker doesn't close a ticket because the tests went green. It opens the actual app in a real browser, does what a user would do, and confirms the problem is gone.
When it can't confirm, it says so and hands the ticket to a person. A fix that's marked done but isn't is worse than one that's still open, because nobody goes back to look.
3. No errors doesn't mean no problems
The worst bug we found recently never showed up in error tracking at all.
In testing, the point-of-sale screen on a Windows laptop froze, but only with items in the cart. The same screen on a Mac worked every time. Nothing was logged. A person noticed it and described it.
With remote access to that laptop, the AI drove the same browser on the same machine and measured instead of guessing. Over three idle seconds, the page made more than 56,000 updates and drew one frame. It was stuck in a loop. The cause was a small mistake in one piece of code, there for nearly a year, that only misbehaved when a customer-facing display was plugged in. That's why the Mac never showed it. The fix was a one-line change. The same measurement on the same laptop then showed zero updates, and the screen worked.
Error tracking only sees the failures that announce themselves. Keep a way for people to report "this feels wrong," and treat those reports as seriously as the errors.
4. The AI does the work. A person holds the keys.
In one evening of work, the AI stopped itself several times: before writing directly to a test database, before signing a user out, before granting someone access to a cloud account, and before adding a user to an organization. Each time, it explained why the step was needed and handed over the exact command for a person to run.
Passwords and signing keys never passed through it. Changes to the live product waited for an explicit OK.
We'd set it up this way even if we didn't have to. The AI moves fast on the work that's safe to move fast on, and anything that grants access or touches production goes through a human.
5. Only interrupt people when they need to decide something
Our alpha partner is a consignment shop owner, not a developer. Early on, he got far too many messages from the system in one evening: status updates, progress notes, things he couldn't act on.
Now he hears from it only when he has to do something or decide something. Technical tickets never tag him, the worker's chatter lives in its own channel, and when he does get a reminder, it links straight to the conversation where he can answer.
Automation that creates noise for the people around it costs more than it saves. Decide up front who needs to hear what.
Where to start
If you're launching something, keeping it clean afterward is a practical first job for AI. The work is high volume, mostly routine, and easy to check. It also makes you put the basics in place: errors that reach one place, a test site the AI can use, and clear rules about what it may and may not do on its own.
None of that needs a big team. It does need someone to set it up carefully, with the guardrails in from the first day rather than added after something goes wrong.
Once it's running, the way you look after software changes. Problems get sorted as they happen, routine fixes arrive tested and ready for review, and the people on your team spend their time on the decisions only they can make. Software that looks after itself isn't a research project anymore. We run it on our own product every day.
If you're new to the idea of AI working inside your own systems, our plain-English explainer on MCP covers how that connection works, and our guide to AI tools for small businesses is a gentler place to begin. If you'd like AI doing real work on your own software, that's the kind of custom tools and automation we build.