I’m always here talking about how important it is to use AI. So let me say something that might sound contradictory at first: sometimes you might be interpreting my message the wrong way.
Notice that I’ve always talked about the importance of fundamentals, long before we had this massive accessibility to LLMs that we have today. And just because I say you should use AI and agents doesn’t mean you should reach for them in 100% of cases.
Here’s a silly example. I personally don’t think it makes sense to have an agent that answers all your emails for you. 😅 Sounds amazing, right? But think about it: if you’re not the one answering the email, then why is someone even asking you? Why do you exist in that loop? A spellchecker or a drafting assistant? Sure. But automating the content of the message? That defeats the whole point.
And I’d say the same about a lot of things. But today I want to talk about a specific one that’s been bugging me: learning from failure, and why letting AI write your incident reports can be a mistake.
The Seduction of “Just Ask It to Write the Report”
Writing incident reports is painful. It’s time-consuming, and let’s be honest, most of the org has zero incentive to actually read them. So the temptation is obvious: why not have an LLM write the whole thing? You just ask, and it produces a clean, plausible document in seconds.
That’s exactly what scares me.
Let me be clear about where AI genuinely helps. There’s a ton of toil in gathering the raw material for a good incident report: pulling logs, correlating timelines, collecting metrics, stitching together what happened across services. LLMs are fantastic at reducing that toil. No complaints there.
But there’s a world of difference between using AI to assemble the ingredients and using AI to write the report itself.
Writing Is How You Discover You Don’t Understand
There’s a famous quote from cartoonist Dick Guindon: “Writing is Nature’s way of showing you how sloppy your thinking is.”
You think you understand what happened during the incident. But it’s only when you actually try to explain it, in your own words, for a real reader, that you discover how fuzzy your understanding really is.
Let me give you a personal example. Early in my career at IBM, basically my first job, there was a super senior engineer I’d reach out to whenever I got stuck. And the funny thing is, I’d often solve my own problem before I even hit send. Just the act of writing out the question forced me to ask myself: “Wait, am I sure about this? Did I actually check it?” Half the time I was really just covering my own back before bothering him, but that habit taught me more than the answers ever did. 😄
When an LLM generates the write-up, it bypasses that thinking step entirely. What you get is a document that sounds right to someone who wasn’t in the room. But the LLM may have invented couplings between systems that don’t exist, or missed the interaction that actually caused the incident. And because nobody did the hard work of synthesizing the data, nobody will notice.
Why This Is Uniquely Dangerous
Here’s a distinction I want you to sit with.
For coding, there’s always a testing step: the build and production itself tell you whether it works. For AI-assisted incident response, it’s the same. Either it helps you resolve the incident, or it doesn’t. In both cases, reality is the arbiter.
But incident write-ups aren’t like that. A flawed report has the superficially correct form, with no obvious test for correctness. It just sits there, misinforming everyone who builds their mental model of the system on top of it. And in SRE, the blameless postmortem exists for exactly one reason: to learn. It’s how we turn a painful incident into better SLOs, sharper alerting, and simpler architecture.
Outsource the writing to an LLM and you keep the artifact but lose the learning. Worse, someone will then use AI to summarize the report nobody actually wrote, compressing insights that were never really there to begin with. That’s not observability. That’s the illusion of it.
Here’s a simple line to draw:
| Use AI for this ✅ | Don’t hand AI this ❌ |
|---|---|
| Collecting logs, metrics, timelines | Writing the narrative of what happened |
| Drafting the incident timeline skeleton | Deciding root cause and contributing factors |
| Summarizing raw data you’ll verify | Producing the final report nobody double-checks |
| Suggesting remediation options | The thinking that turns failure into learning |
Wrapping Up
I’ll keep saying it: use AI. Automate the toil. Kill the repetitive work that drains your day. But don’t confuse generating an artifact with doing the thinking. Some tasks exist precisely because the act of doing them is where the value lives, and the incident report is the clearest example I know.
Failure is one of the best teachers we have as engineers. Don’t let a tool quietly take that lesson away from you.
Cheers,
Douglas Mugnos
MUGNOS-IT 🚀
