If understanding our code no longer matters because AI can explain it to us, why do we still need Root Cause Analysis?
Rhetorical question, y’all. Don’t answer it. I’m going to answer it.
The purpose of an RCA isn’t to document that a problem happened. Everyone already knows that. The outage happened. The bug made it to production. The incident occurred. The service was degraded. But what also degraded was your users’ trust in you.
The purpose of an RCA is to demonstrate that you understand why it happened, why your existing controls didn’t catch it, what you’re doing to fix it, and what you’re doing to reduce the chances of it happening again.
In other words, the whole point of an RCA is to reestablish trust that we understand our own systems… (“trust me… my AI friend has been thinking for me” isn’t going to fly).
That’s why I find the idea that understanding code is becoming optional a little strange…. Read: ridiculously off-base.
AI can help investigate an incident and it can help summarize findings. It can help draft documentation and of course it can even help write code.
But when a critical system fails, nobody wants reassurance that a model generated an explanation or that an AI tool understands why the code it wrote was problematic—understanding, I might add, that lasts only as long as its context window.
“It’s all good, y’all. Claude says it’s fine.”
That’s not engineering judgment.
Customers want reassurance that the engineers responsible understand what happened. Reestablishing trust happens by demonstrating understanding and a plan to make it better going forward.
In many ways, that’s what customers are paying for. Even when they don’t understand the RCA, they trust that you do.
The RCA is the document where we prove it… because understanding your system and your code does in fact matter.