The first time was an incident. The second time was a failure not of a person, but of our process.

We did everything by the book. We ran a blameless post-mortem. We wrote action items. We documented the root cause. The document was beautifully structured —and utterly useless. Because a few months later, a new developer made the same logical mistake in a different file, and history repeated itself.

The truth hit me hard: our post-mortems were not broken; our system of memory was.

We had the knowledge, but it was trapped in a Confluence folder titled “Post-Mortems 2025.”
A knowledge graveyard.

And that’s when it clicked the problem wasn’t that developers forget. It’s that our tools don’t remember.

The “Aha” Moment — What If Our Tools Could Remember?

I started asking myself: What if our tools could remember for us?
What if every lesson from a production incident could automatically resurface when we’re about to repeat it?
What if post-mortems weren’t static documents, but active safeguards that scanned our pull requests in real time?

I looked for a tool that could do this. None existed. So, I built it.

And today, I’m incredibly proud to launch it on Product Hunt and Peerlist

Introducing Ship Guard : The AI Code Reviewer That Learns From Your Mistakes

Ship Guard is the AI code reviewer with a memory.
It doesn’t just review your code it remembers your incidents, learns from them, and prevents you from shipping the same bug twice.

The Core Feature: Incident Memory

Here’s how it works:

1. You experience a production incident say, an unhandled NullReferenceException.

2. You summarize the incident and add it to Ship Guard’s Incident Memory.

3. Weeks later, when a new PR introduces semantically similar code (like another missing validation), Ship Guard’s RAG-based system automatically retrieves that memory.

4. It then posts a detailed comment directly on the PR:

   ⚠️ “This code looks similar to INC-042, which caused a production outage in April. Here’s what we learned from that incident and how it was fixed.”

No shaming. No guesswork. Just context right when it matters.

Your team doesn’t have to remember what went wrong last quarter.
Ship Guard does that for you.

More Than One Feature: A Full Platform

Incident Memory is the heart, but Ship Guard is a complete platform for intelligent, automated reviews:

• AI-Powered Reviews: High-signal, low-noise PR reviews that catch logical bugs, anti-patterns, and risky changes.

• Deterministic Rules: Simple YAML-based rules to block TODOs, enforce changelogs, or require tests.

• Secure & Async Architecture: Built as a multi-tenant app with BullMQ + Redis for async job handling, ensuring performance even under high webhook volumes.

• Private by Design: All code is processed securely; your repository data never leaves your workspace.

Ship Guard plugs directly into your GitHub workflow, it’s like adding an engineer who never forgets.

The Proof — Why You Should Trust This

I didn’t just build Ship Guard for fun I built it because I was tired of the same post-mortem déjà vu that every engineering team lives through.

We’ve been testing it with a few early pilot teams over the last few months, and the results have blown me away:

• 40% fewer repeat bug incidents across their repos.

• PR review turnaround time cut in half.

• Engineers reporting fewer “false alarms” and more trust in their AI reviewer.

One lead engineer put it perfectly:

“Ship Guard doesn’t just review code — it remembers who we’ve been.”

That’s the point. We don’t need smarter reviewers; we need remembering ones.

The Launch — And a Personal Ask

After months of late nights, false starts, and too much caffeine, I’m thrilled to finally share Ship Guard with you.

👉 Try it today: shipguard.dev
You can start a 14-day free trial — no credit card required.

I built Ship Guard because I believe our tools should carry our institutional memory for us. Not in docs. Not in wikis. But in the actual systems that guard our code.

If you’ve ever shipped the same bug twice this one’s for you.
Come say hi, give feedback, or tell me what you’d love to see next:
👉 Join the conversation on Product Hunt or Join the conversation on Peerlist

See you there.
— Edet, Founder & Principal Engineer Ship Guard

Good process. Good intent. Zero guarantee we won't ship the same bug again.

Let’s be honest. The modern blameless post-mortem is one of the proudest rituals in engineering. We’ve moved away from finger-pointing. We document timelines. We identify root causes a NullReferenceException, un-validated config, a race condition in the dispatcher. We produce a tidy list of actions: a new test here, a code review guideline there, an alert tuned in PagerDuty.

Then that document quietly dies.

The Knowledge Graveyard

Where is that post-mortem a month later? In Confluence, in a Google Drive, in a wiki with a dozen other post-mortem documents. A knowledge graveyard. Someone might skim it before an annual audit. Maybe an engineer links it in a Slack thread and we all feel virtuous for 2 hours. Mostly, it sits. Passive. Waiting for someone to remember it when the next incident comes along.

That’s the real problem. We treat institutional knowledge like osmosis: hire more people, create more docs, and assume lessons will soak in. They don’t. New hires don't magically inherit your team's failure history. The person who introduces the same bug six months later has read the handbook the same amount as the rest of us: not enough.

The Inevitable Repeat

And then it happens. A fresh pull request lands. Different developer. Different file. Different microservice. But the same bug pattern: the same unchecked input, the same race window, the same edge case that previously brought your system to its knees.

The first time you face it, you learn. The second time, you get angry. The third time, you start to doubt your processes.

This isn’t a human failing. It's a process failing. The post-mortem document is a passive artifact.

A lesson that sits in a doc is indistinguishable, for practical purposes, from a lesson that was never learned.

We measure success by whether the doc exists, not whether the failure class is prevented. If you want to prevent repeat incidents, the value of a post-mortem is not its prose. The value is the lesson. And a lesson only counts if it changes behavior before the next deploy.

From Passive History to Active Safeguards

So what does that look like? Let me be provocative: stop treating post-mortems as history, and start treating them as code.

Imagine moving the lesson from a page into the places where code actually changes.

• What if your CI/CD pipeline could remember that incident?

• What if your code review process could surface relevant past failures the moment a pull request touches similar logic?

• What if, during a review, a developer could instantly see: “Heads up this block looks like the code that caused INC-245 in Q2. Here’s the root cause and the mitigation that worked.”

That’s not magic. It’s making lessons active and programmatic instead of passive and archival.

This would change incentives immediately. Action items listed in a doc would no longer be checkboxes for compliance; they’d become enforcement points in the workflow. When a past failure is represented as something the pipeline can reason about, a new engineer gets protection from day one. The system carries institutional memory for the team.

Stop Documenting, Start Enforcing

I’m not arguing we stop writing post-mortems. Write them. They’re invaluable for analysis and growth. But don't stop at the doc. Treat the post-mortem like a spec: extract the invariant that caused the incident, codify it into checks, and push those checks as early as possible in your delivery chain.

A lesson is only learned if it prevents a repeat failure. Anything else is vanity.

We’ve perfected blameless post-mortems as a cultural practice. Now let's perfect them as a technical practice.

Ask yourself honestly: how many bugs has your team shipped more than once? Not how many have we documented, but how many have we prevented the second time?

What's a bug your team has shipped more than once?