Your AI is fixing the wrong line

You've seen this happen.

Something crashes. You paste the error into your AI. It finds the line that blew up, adds a check, and the crash is gone. Tests pass. You ship it.

A week later, the same bug is back. Different symptom, same cause.

I work in reliability engineering, and I've watched this happen again and again since AI started writing our fixes. The AI isn't bad at code. It's being shown the wrong evidence.

The crash is the smoke alarm

Here's the rule most of us learn the hard way: the line that crashed is almost never the bug.

A crash is a smoke alarm. It goes off in the room where the smoke reached it. The fire started somewhere else, usually a room or two away, where a bad value was created.

When you paste an error into your AI, you hand it the smoke alarm and nothing else. So it does the obvious thing: it turns off the alarm.

Proof in 30 seconds

A tiny shop program, asked for order 1003, which doesn't exist:

The error points at total. Show your AI only this, and it adds a check there. Crash gone.

But total did nothing wrong. load_order quietly returned nothing for a missing order, and total was just the first place that touched it. The real question, "what should happen when an order doesn't exist?", never gets asked.

"Just paste the whole stack trace"

Fair. For a three-line Python script, that's often enough.

Real crashes are messier. The stack trace is 40 frames, mostly framework code. The code that matters is in files the AI hasn't opened. The log line that explains it scrolled away an hour earlier. And for apps written in C, C++ or Rust, there's often no readable trace at all, just "Segmentation fault (core dumped)".

A good engineer doesn't stop at the trace. They pull up every function the crash passed through, the code around each one, and who changed it last. Your AI needs the same thing, handed to it in one piece.

Every crash leaves a black box. Most of us delete it.

When a C, C++ or Rust program crashes, the system can save a snapshot of its memory at that exact moment. It's called a core dump, and it's the program's flight recorder.

Most people throw it away. Many machines don't even save it by default. Reading one used to take an expert, a debugger and an afternoon.

So I tried the hardest version: a production-style C program with no source code and no function names, crashed on what looked like random garbage. I gave an AI agent the core dump and two open-source tools that can read it.

It confirmed the program matched the crash, and then wrote about the function that crashed:

"This function has no bug of its own. It trusted the object it was given."

It walked one step back, to the code that called it, and found the real fire: the program freed a piece of memory, reused it, then called through the old pointer. It proved it from the memory snapshot. It never ran the program.

I ran that kind of test on 7 different crashes. With function names, it found the real cause 7 out of 7 times. With no names and no source, 6 out of 7, and part of the answer on the last one.

Give your AI the whole story

The two tools are REA, a reverse-engineering toolkit by @morluto that reads black boxes and machine code, and crashlens, which I built on top of it to turn any crash (Python, JavaScript, Java, Go, Rust, C) into the report an engineer would write. Both are free and open source.

The two tools are REA, a reverse-engineering toolkit by @morluto that reads black boxes and machine code, and crashlens, which I built on top of it to turn any crash (Python, JavaScript, Java, Go, Rust, C) into the report an engineer would write. Both are free and open source.

The two tools are REA, a reverse-engineering toolkit by @morluto that reads black boxes and machine code, and crashlens, which I built on top of it to turn any crash (Python, JavaScript, Java, Go, Rust, C) into the report an engineer would write. Both are free and open source.

Using Grok Bot as an example, send these two messages and click Add it after each:

1. Add a custom MCP server called rea that runs: npx -y rea-agents@6.7.0 mcp

2. Add a custom MCP server called crashlens that runs: npx -y github:mingleiw/crashlens mcp

Next time something breaks, paste the whole error and ask: "Find the real bug, not just the line that blew up."

Not on Grok Bot? It works with any agent that supports MCP:

• Claude Code: claude mcp add rea -- npx -y rea-agents@6.7.0 mcp, then the same for crashlens.

• Hermes: hermes plugins install rea (crash triage is built in).

• Codex, Cursor, Gemini CLI: npx rea-agents@latest setup, then add crashlens in your MCP settings.

One caution: a core dump is a copy of your program's memory and can hold passwords or customer data. On your own computer it never leaves. A cloud agent like Grok Bot runs elsewhere, so think before uploading one.

Stop turning off the alarm

The next time your AI says "fixed", ask one more question: where did the bad value come from? If the answer is the same line that crashed, it probably isn't fixed.

The crash tells you where it hurt. The bug is where it started.

I'm curious: what's the worst "fixed" bug that came back to bite you?

crashlens is free and open source (MIT). Built on REA by @morluto.

crashlens is free and open source (MIT). Built on REA by @morluto.

crashlens is free and open source (MIT). Built on REA by @morluto.