DEV Community: The AI Leverage Weekly

How to Use AI to Write a Clear Incident Postmortem

The AI Leverage Weekly — Wed, 12 Aug 2026 09:00:51 +0000

Writing a clear incident postmortem is one of those tasks that always lands at the worst time — right after an outage, when you're exhausted and the timeline is still fuzzy. AI handles this well if you give it the right inputs. Here's the exact workflow I use to go from raw incident notes to a publishable postmortem in under 30 minutes.

What You Need Before You Start

Gather these before touching any AI tool:

Raw timeline — Slack threads, PagerDuty alerts, log excerpts, anything timestamped
Impact statement — who was affected, for how long, what broke
Resolution summary — what you changed to fix it
Contributing factors — what you already suspect caused it

You don't need prose. Bullet points and timestamps are perfect. The AI's job is to structure and clarify, not to invent facts.

Step 1 — Build the Timeline First

Paste your raw notes and use this prompt:

You are an SRE technical writer. Below are raw notes from a production incident.
Extract a clean, chronological timeline. Each entry: [HH:MM UTC] — one sentence, active voice,
technical but readable by non-engineers. Do not infer events not present in the notes.

Raw notes:
<paste notes here>

Review the output carefully. Remove anything the model inferred that isn't backed by your notes. This step usually saves 15 minutes of manual reordering.

Step 2 — Draft the Full Postmortem

Once the timeline is clean, run this:

Using the timeline below, write a production incident postmortem using this structure:
1. Summary (3 sentences: what broke, impact, how it was resolved)
2. Timeline (paste the cleaned timeline from Step 1)
3. Root Cause
4. Contributing Factors
5. Impact (users affected, duration, error rate or other metrics)
6. Resolution
7. Action Items (each item: owner placeholder, due date placeholder, one sentence)

Tone: clear, blameless, factual. No hedging language. No passive voice.

Timeline:
<paste Step 1 output>

Additional context:
<paste your impact statement, root cause notes, and resolution summary>

The blameless framing instruction matters — without it, models sometimes default to language that subtly assigns fault to individuals.

Step 3 — Sharpen the Root Cause Section

Root cause sections are where postmortems get vague. If the draft is soft, target it directly:

The root cause section below is too vague. Rewrite it to be specific:
- Name the exact system or component that failed
- Describe the failure mode (not just "misconfiguration" — what was misconfigured and why it mattered)
- One sentence on why existing monitoring didn't catch it earlier

Current root cause section:
<paste draft>

Step 4 — Generate Action Items That Are Actually Actionable

Vague action items are a postmortem's biggest failure mode. Run this on your draft action items:

Review these action items from a postmortem. For each one that is vague, rewrite it to be:
- Specific (names the exact system or process to change)
- Measurable (includes a success condition or metric)
- Scoped (can be completed in one sprint)

Action items:
<paste list>

Step 5 — Final Readability Pass

Before sharing:

Read this postmortem as a skeptical engineer who wasn't on-call during the incident.
Flag any section that is unclear, assumes context, or uses jargon without explanation.
List each issue as a bullet with a suggested fix.

Postmortem:
<paste full draft>

Fix what's flagged. Done.

The Full Flow at a Glance

Step	What it does	Time saved
1 — Timeline extraction	Orders chaos into a clean sequence	~15 min
2 — Full draft	Structures everything into a standard format	~20 min
3 — Root cause sharpening	Replaces vague with specific	~10 min
4 — Action item audit	Makes follow-ups actually closeable	~10 min
5 — Readability pass	Catches assumed context before it ships	~5 min

The raw inputs still come from you. The AI handles the structural and prose overhead so you can focus on the analysis that actually prevents the next incident.

I break down one workflow like this every week in The AI Leverage Weekly — practical, no fluff, free. Subscribe: https://theaileverageweekly.beehiiv.com/subscribe?utm_source=devto&utm_medium=article&utm_campaign=medium_w14

3 things that worked, 1 that didn't — my AI workflow experiments this week

The AI Leverage Weekly — Fri, 08 May 2026 13:29:35 +0000

Happy Friday. Week 0 of doing these roundups publicly. Let's see how it goes.

This week was mostly about figuring out where AI actually saves time in an engineering workflow versus where it just creates a convincing illusion of speed. Here's the honest tally.

✅ What worked

1. Using AI for the first draft of boilerplate, not the logic.
Generating scaffold code — config files, test stubs, README sections — is where I stopped fighting the output and started trusting it. The model doesn't need to understand your domain to write a Dockerfile or a pytest fixture skeleton. Ship the boring stuff fast, think harder on the real problems.

2. Prompt iteration as a debugging loop.
Treating a bad AI output like a failing test — rather than a reason to give up — changed everything. Reframe, constrain, give an example. Three rounds of that usually gets you somewhere useful. The mental model shift is: you're not asking, you're specifying.

3. Writing documentation before the code.
Sounds backwards but it works. Describe the function in plain English, hand it to the model, get a first implementation back. The doc becomes the spec. You catch ambiguity before it's baked into 200 lines of code.

❌ What didn't work

Letting AI "own" a refactor end-to-end.
I handed off a medium-complexity refactor with minimal checkpoints. The output was locally coherent and globally wrong — it made decisions silently that I would have caught immediately if I'd stayed in the loop. The lesson: keep the AI in a copilot seat, not the driver's seat, any time the task spans more than one file or abstraction layer.

The thread underneath all of this

Every win this week came from having a clearer mental model of the task before touching the AI. Every loss came from outsourcing the thinking. That's probably the pattern for a while.

If you want a structured version of these ideas — prompts, workflows, and checklists organized into a repeatable system — I've been packaging what actually works into a playbook: grab it here. No fluff, just the stuff I'd send a teammate.

See you next Friday. 🖤

How to Use AI as a Rubber Duck That Actually Pushes Back

The AI Leverage Weekly — Thu, 07 May 2026 05:04:30 +0000

Rubber duck debugging works because explaining a problem forces you to think clearly. AI can do the same thing — but better, because it asks follow-up questions.

Here's a workflow I use when I'm stuck on a design decision or a gnarly bug. Takes about 10 minutes and consistently gets me unstuck.

Step 1: Dump your context, not your question

Most people open ChatGPT and ask "how do I fix X?" That's too narrow. Instead, give full context first:

I'm working on [system/feature]. Here's what I'm trying to accomplish: [goal].
Here's what I've tried: [approach 1], [approach 2].
Here's where I'm stuck: [specific blocker].
Don't give me a solution yet. Ask me clarifying questions until you understand the problem fully.

That last line is the key. Forcing the model to interrogate you before answering surfaces assumptions you didn't know you were making.

Step 2: Answer its questions honestly

When it asks "what constraints are you working under?" or "what happens if you do X?" — actually answer. Don't shortcut to "just give me the answer." The back-and-forth is the point.

Typically 2–3 rounds of Q&A is enough.

Step 3: Ask for the devil's advocate take

Once you've landed on a direction, run this:

Here's the approach I'm leaning toward: [your plan].
Now argue against it. What are the top 3 reasons this is the wrong call?

This is where AI earns its keep. It'll surface edge cases, scalability concerns, or maintenance debt you glossed over. You don't have to agree with all of it — but you should be able to rebut each point.

Step 4: Synthesize a decision log entry

End the session with:

Summarize our conversation as a short architectural decision record (ADR):
- Context
- Decision
- Alternatives considered
- Consequences

Paste that into your PR description or Notion doc. Future-you (and your teammates) will thank you.

Why this works

The standard "explain this to me" prompt treats AI as a search engine. This workflow treats it as a thinking partner with an agenda: to stress-test your reasoning before you commit to it.

The difference in output quality is significant — especially for decisions that are hard to reverse.

If you want more structured prompts for engineering decisions, code reviews, and career conversations, I put together a playbook of them here: AI Prompt Playbook for Engineers. Practical, copy-paste ready, no filler.