This essay is part of an ongoing series on how enterprise software delivery changes when agents become participants in the engineering system. The series starts with Your Platform Has a New User: The Agent.
"Welcome to PlatformGPT. What can I help you with?"
Most platform teams are one sprint away from shipping that sentence. The pieces are lying around: a chat widget or a Slack bot, a model endpoint, and a vector index of the developer docs. Wire them together, drop the result into the developer portal, and the AI box on the roadmap gets checked. I get the appeal and you get points from your leadership for adding AI to your platform.
The chatbot is the easy checkbox
The portal chatbot wins planning meetings because it is legible, demoable, and countable. You can screenshot it for the quarterly review and report how many questions it answered. What the screenshot hides is that the chatbot relocates friction instead of removing it. The developer still has to notice the failure, copy the error, find the chat window, and know what to ask. We moved the search box and called it intelligence.
The chatbot also inherits the oldest problem in developer support. It waits. Help that waits to be asked only reaches the developers who ask, and the most expensive friction belongs to the ones who never do.
The failure that was not yours
Start with the least interesting failure your pipeline produces. Not the compile error, and not the failed test. I mean the run that dies because a registry timed out, a runner got evicted, or a mirror went briefly unreachable.
The developer who opened the pull request has no idea any of that happened. What they see is red. The build broke, their name is on it, and the log ends in a stack trace pointing somewhere they have never been.
So they do what everyone does. They read the trace, search the error string, and check whether they touched anything nearby. Then they rerun the job to see if it fails the same way twice. Somewhere in that loop they ask in a Slack channel whether anyone else is seeing it. A platform engineer who already knew about the registry problem tells them to retry.
Every minute of that is waste, and almost none of it is the developer's to fix. The information that would have ended the loop existed the entire time. It was sitting in the platform, on the wrong side of a question nobody thought to ask.
Now run the same failure through a platform that is paying attention. The step fails on an image pull. The platform checks the registry and sees elevated errors in that window. It finds several other runs failing the same way, and it confirms that nothing in this pull request touches that path. That is enough to make a call. So it repairs what it owns, reruns the job, and the run goes green.
The developer opens their laptop to a passing build and a note:
This run failed once pulling an image from the shared registry, which reported elevated errors during that window. Several other runs failed the same way. Nothing in your changes touches that path, so the platform switched to the fallback mirror and reran. Tracking as PLAT-2291.
Nobody had to notice the failure. Nobody had to ask what it meant. The most valuable thing that platform did was decide the failure was not the developer's, and then act like it.
Three rungs
Most conversations about AI in developer experience are stuck arguing about the first rung of a three-rung ladder.
On the first rung, the developer goes to the AI. They notice the failure, carry it to a chat window, and phrase a question well enough to get a useful answer. This is the portal chatbot, and teams ship it first because it is the easiest thing to build.
On the second rung, the AI comes to the developer. The failure explains itself where it happened. Nobody has to know what to ask, because nothing was asked.
On the third rung, the platform handles it and reports what it did. The failure gets diagnosed, the platform-side cause gets repaired, the run goes green, and the developer reads a note instead of a stack trace.
I want to be precise about where we actually are. For most failure categories we are on the second rung, and for a narrow set we are on the third. That narrow set is the interesting part, because it is where the ladder stops being a diagram and starts being a Tuesday.
Fix what you own, propose what you do not
The rule that keeps self-healing honest is an ownership rule rather than a capability rule.
If the failure belongs to the platform, the platform repairs it and reruns. A registry that flaked, a runner that got evicted, a stale cache, a credential the platform rotates. The developer did not cause any of it and cannot fix any of it, so asking them to participate is theater.
If the failure is in the developer's code, the platform proposes and stops. It can be certain. It can have the diff ready and the tests green. It still stops, because the branch belongs to the developer and a merge is a decision.
The tempting exception is the mechanical fix. A stale lockfile, a formatter violation, a missing license header. The remedy is deterministic, and the platform could apply it without thinking hard. I would still open a pull request instead of pushing the commit. Deterministic describes the fix, not the ownership of the branch. Once the platform writes into developer branches because it felt confident, you trade a little friction for a lot of ambiguity about who changed what.
That line also gives you a clean escalation path. Platform-side failures get quieter over time as the heals accumulate. Developer-side failures get faster, because the proposal arrives before the developer has finished reading the error.
Where the help belongs
Once you start looking for these placements, they are boringly consistent from one platform to the next:
- The failed pipeline names the cause in the run output, and repairs it when the cause is ours.
- The deployment workflow proposes the compliant fix instead of a link to the policy.
- The CLI names the missing permission and drafts the access request.
- The control that cannot be satisfied files the exception with its own evidence attached.
- The incident tooling correlates the relevant signals before the responder starts hunting.
- The platform generates compliant, inspectable configuration from stated intent.
Notice what is missing from that list: a destination. The developer never goes to the AI. The AI is already standing where the developer was about to stumble.
Two surfaces, on purpose
The response belongs in two places, and the split follows the ownership rule.
The run output carries the record of what the platform did to its own side. That is where the developer is looking when they are confused, and where a heal has to stay legible after the fact. The pull request carries anything that needs a human decision. A comment on the pull request outlives the log. It is still there tomorrow when someone asks why this branch was retried. It is there for the reviewer who was never watching the pipeline run.
The pattern generalizes past pipelines. Repairs go where the work happened. Decisions go where the owner is standing.
The platform should know where help is required
That is the principle underneath all of it. AI developer experience gets more valuable as the AI stops being a destination and becomes how the platform behaves. A chatbot waits to be asked. A platform knows its own failure points, because they are the same points every week, and it can meet developers there. In Complexity Is Inevitable. Drag Is Optional. I argued that good platforms turn unavoidable complexity into defaults and automation, so people can do complex work without absorbing all of its friction. Self-healing is that same conversion, applied to the moment things break.
None of it works without the context layer underneath. A platform that cannot see the registry, the recent runs, and this pull request is guessing with better grammar. That is the argument I made in Context Is a Platform Capability Now, and self-healing is the reason it matters more now. Diagnosis needs context. Acting on the diagnosis needs to be right.
The pattern holds beyond failures. The intent interface is invisible AI at the front of the journey. The self-healing pipeline is invisible AI in the middle. The pre-correlated incident view is invisible AI at the worst moment of the week, which is where it earns the most.
Nobody argues with the pipeline
Self-healing has an ugly cousin that has lived in CI for decades. Blind retry. Rerun the flaky test until it passes, ship it, and let the intermittent defect find a customer instead of an engineer.
One rule separates them. Never retry without a reason you can name. A retry that follows a diagnosis is a repair. A retry that follows a failure is a coin flip you are paying for in compute and in confidence.
The trust problem sits underneath that rule. A chatbot answer arrives with skepticism already attached, because the developer knows they are talking to a model and discounts accordingly. A platform action arrives wearing the platform's uniform. It looks like the same tooling that has told the truth about exit codes for decades, so it inherits trust it has not yet earned.
Go back to the registry timeout. The platform decided the failure was infrastructure rather than the developer's change, and then acted on that decision without asking. That is the most useful call it can make and the most expensive one to get wrong. If the diagnosis is wrong and the failure was real, the platform cleared the path past a live bug while nobody was in the room.
Those risks set the price of admission. Four obligations come with every placement:
- Show the evidence, not only the conclusion. Name the registry, the window, and the other runs. A developer who can check the reasoning can overrule it.
- Say how confident it is, and mean it. Probably infrastructure and definitely infrastructure deserve different actions, and only one of them should trigger an automatic rerun.
- Keep the label findable even when it is out of the way. A developer should never have to notice what produced the fix, and should always be able to find out.
- Evaluate each placement on its own. Six placements are six products with six failure modes, and one shared model does not give you one shared evaluation.
That last obligation is the honest reason teams pick the chat widget. One surface is one thing to test. Six surfaces are six, and the work does not get cheaper because the model is the same.
Invisible to the developer, visible to you
There is a second trap, and it is quieter than the first. A platform that heals the same failure every day has stopped reporting a problem it is still paying for.
The registry timeout is a real defect somewhere. Someone should fix the registry, add capacity, or move the mirror. If the heal is silent to everyone, the pressure to fix the cause disappears. You have converted a loud, annoying failure into a permanent tax paid in compute, latency, and one more thing your platform quietly carries. The developers are happier and the platform is rotting underneath them.
So the heal is invisible in exactly one direction. The developer sees a note. The platform team sees a rate, a trend, and a ranked list of what the platform is absorbing on everyone's behalf. Healed failures belong in your backlog and not only in your logs. If the heal rate climbs while the underlying failure rate holds flat, the platform is absorbing a problem instead of solving it.
That is the discipline that separates self-healing from technical debt with good manners.
The part that is hard to count
The chatbot hands you a number that measures itself. Questions asked, answers given, thumbs up collected. Self-healing hands you a harder number that points outward. Failures diagnosed, failures repaired, reruns that went green without a human, and developer time that was never spent.
The last figure is the only one an executive should care about, and it is the hardest to defend rigorously. The instrument for defending it is the subject of the next essay in this series, so I will leave it there.
Finding the placements
You do not have to guess where the friction lives. Your ticket queue already knows, and so do your failed pipeline runs. Rank the failures by how much developer attention they consume, then work down that list one placement at a time. The queue deserves an essay of its own, and it will get one, because it is the most honest friction map a platform team owns.
Start where the failures are frequent, well understood, and cheap to get wrong. Transient platform failures qualify on all three, which is why they are the right first heal. Standards, policy, and compliance decisions qualify on none of them. Those stay on the second rung until your evidence and your risk model justify more.
The test
Here is the test I now apply to every AI feature we consider for the platform. Remove the label. If developers would describe the result as a better platform, the feature is placed correctly. If it only makes sense with the AI label attached, it is probably a demo.
Chat still has a job, by the way. It is a good door for open-ended exploration, for onboarding, and for the questions a new engineer does not yet know how to phrase. A door is a fine thing to have. It is not a strategy.
The chatbot passes demos. The pipeline that diagnoses its own failure and fixes what it owns passes Tuesday. The best AI feature in your developer platform may be the failure your developer never had to see.
