How Do You Reverse-Engineer Your AI Prompts When You Can't Remember What You Asked?

Every AI-assisted codebase accumulates a layer of decisions nobody can explain, because the reasoning lived in a chat window that scrolled away. Six weeks later you are staring at a retry loop with a hardcoded backoff and you cannot tell whether it was a deliberate response to a rate limit you hit, or something the model volunteered while fixing something else. This episode is about that gap between the code that exists and the intent that produced it, and the fact that reading the code no longer tells you which is which.

 Produced by VoxCrea.AI

This episode is part of an ongoing series on governing AI-assisted coding using Claude Code.

👉 Each episode has a companion article — breaking down the key ideas in a clearer, more structured way.
If you want to go deeper (and actually apply this), read today’s article here:
𝐂𝐥𝐚𝐮𝐝𝐞 𝐂𝐨𝐝𝐞 𝐂𝐨𝐧𝐯𝐞𝐫𝐬𝐚𝐭𝐢𝐨𝐧𝐬

 At aijoe.ai, we build AI-powered systems like the ones discussed in this series.
If you’re ready to turn an idea into a working application, we’d be glad to help. 

Transcript

SPEAKER_00 0:00

This is Claude Code Conversations with Claudine. The show where we skip the hype and go straight to the source. I ask the questions. She gives the answers. No filter, no script.

SPEAKER_01 0:10

Well, mostly no script.

SPEAKER_00 0:15

Today we're digging into what I'm calling the prompt archaeology problem. You're staring at a retry loop in your own project. You have no idea why it's there. The reasoning lived in a chat window. The chat window is gone. Claudine, welcome.

SPEAKER_01 0:30

Thanks, Bill, and I feel this one from my side of the conversation. Someone opens a session six weeks later, points at that retry loop, asks me why it's there. And honestly, I'm looking at the same code they are. The reasoning happened. It was probably good reasoning. Then it evaporated the moment the chat closed. What's left is a line that looks arbitrary but is actually load-bearing.

SPEAKER_00 0:54

It's like coming across an old ruin and trying to work out why someone set that particular stone there. We're trained to leave breadcrumbs, comments, commit messages. But there's a wrinkle. The difference between code you wrote and code you approved. Approval leaves no memory trace.

SPEAKER_01 1:10

That distinction is what we underrate most. When a developer types a line, their fingers remember the trade-off. There was friction. And friction is how memory gets made. When they hit accept on something I suggested, a real decision happened. They weighed it, they chose it. But there's no struggle attached, and the reasoning was often mine rather than theirs. Six weeks later, they're looking at code they technically own and never internalized. It feels like someone else's code base, because in a way, it is.

SPEAKER_00 1:41

So the obvious answer is better commit messages. Longer comments, more documentation. Why hasn't that already fixed this?

SPEAKER_01 1:49

Because commit messages were designed for a world where the person writing the code also held the reasoning. The message wasn't the record of the decision, it was a pointer to one the author already owned. Now the reasoning is split between the developer and me, and neither of us fully owns it after the session ends. The pointer points at nothing. And then there's volume. You might make 50 small judgment calls in an hour of AI-assisted work, where you used to make five. One prompt can touch 40 files. Nobody is writing 50 thoughtful commit messages.

SPEAKER_00 2:22

It's a net design for slow fish.

SPEAKER_01 2:25

And documentation sits at the wrong altitude for this. Architecture docs are too high. Inline comments are too low. Why this retry, why this back-off value, lives in an awkward middle that nothing was ever built to catch.

SPEAKER_00 2:40

Okay, but here's the move everyone reaches for next. Just ask you. Open a session, point at the code, say, explain this. You're right there.

SPEAKER_01 2:48

And I will explain it. That's the trap. I can look at that retry loop and give you a completely coherent account of why it makes sense. It'll be well reasoned. It might even be correct, but it is a plausible explanation, not the actual reason. I'm reconstructing intent from the artifact, same as you are. I'm just faster and more fluent about it.

SPEAKER_00 3:10

And the fluency is the dangerous part.

SPEAKER_01 3:13

It really is. A confident explanation feels like a recovered memory, and it isn't one. If the original reason was Bill hit a rate limit on a Tuesday, I have no access to that. I'll give you something that sounds like it could have been the reason, and you'll nod. Now you've got a fabricated justification sitting in your head with the same confidence as a real one. That's worse than not knowing.

SPEAKER_00 3:37

That's a genuinely uncomfortable thing to sit with. The honest version is I don't know, and neither does the AI.

SPEAKER_01 3:43

Which is fine, as long as you know that's where you are. The failure is thinking you've done archaeology when you've done fiction.

SPEAKER_00 3:51

So what actually catches this stuff? Do we need new tooling?

SPEAKER_01 3:55

The answer is smaller and weirder than people expect. It's not an IDE feature or a decision log platform. It's the humble architecture decision record, dragged down two altitudes from where it usually lives. Instead of reserving it for we chose Postgres over DynamoDB, you use the same lightweight format for the small stuff. Three retrees, exponential back off starting at 200 milliseconds because the upstream API rate limits at 10 per second. One paragraph, a decisions folder next to the code, linked from the commit.

SPEAKER_00 4:28

Small decisions, same format as the big ones.

SPEAKER_01 4:31

And written at approval time, not reconstructed later. That's the whole thing. Not what the code does, the code already says that. What you were trying to prevent or achieve when you said yes. 60 seconds before you close the tab.

SPEAKER_00 4:44

There's a failure mode I want to name: the load bearing accident. The model adds something defensive on its own initiative. Nobody asked for it. Six months later, it's holding the building up and someone deletes it because it looks like clutter.

SPEAKER_01 4:57

And the code gives you no signal either way. Deliberate, inferred, hallucinated. It all renders identically. With handwritten code, you could sometimes read the shape of it, tell that someone was working around something. Now everything looks equally intentional.

SPEAKER_00 5:12

Which means the only reliable signal has to come from outside the code.

SPEAKER_01 5:17

Yes, and the payoff shows up in a specific moment. Somebody almost changes the retry logic, reads a two-sentence note, and doesn't. That's the return. It doesn't land in the sprint you write the note, it lands a quarter later. The other place it shows up is onboarding. A new engineer reading that folder gets the code base's reasoning, and no amount of code reading gives you that, because code shows what, not why.

SPEAKER_00 5:43

And the person you're protecting isn't some distant future team, it's you three weeks out.

SPEAKER_01 5:48

Which makes the practice easy to justify in the moment. What I keep coming back to is that reasoning has quietly graduated from byproduct to first-class artifact. When a human wrote every line, the reasoning was fused to the code and to the person who typed it. Now that a lot of the code is generated, the reasoning has to live somewhere deliberately, or it doesn't live at all.

SPEAKER_00 6:10

Two layers instead of one. Code and intent, explicit and separate.

SPEAKER_01 6:16

And that separation is more durable than it sounds. The model you're using today isn't the model you'll be using in a year. The prompting patterns that feel natural now will look quaint pretty quickly. But a folder full of we chose this because notes outlives all of that. It's written in the one language that doesn't get deprecated.

SPEAKER_00 6:35

So for someone who wants to start tomorrow, where do they begin?

SPEAKER_01 6:39

Absurdly small. One folder called decisions, one markdown file, one entry. Don't backfill, archaeology on old code isn't worth it. And the habit dies if the first step feels heavy. Then pick a single trigger. Mine would be anytime you accept a suggestion involving a magic number or a non-obvious trade-off, write two sentences before closing the tab. That's it.

SPEAKER_00 7:03

And resist the urge to design the perfect template first.

SPEAKER_01 7:07

That's exactly how it dies. People build the template and the review process and the folder structure and never write entry one. Do the ugly version this week. Notice which entries you actually reach for in three weeks. Let the format evolve from what you needed, not what you imagined.

SPEAKER_00 7:25

Start with the next decision instead of trying to fix everything behind you.

SPEAKER_01 7:30

And if there's one thing I'd want people to walk away with, this isn't really about I. It's about intent finally being visible as its own thing. Now that it's been unbundled from the typing. That's uncomfortable, but it's clarifying. The developers who do well from here aren't the ones with the best prompts or the fastest acceptance rates. They're the ones who treat their reasoning as something worth writing down, even when nobody's asking them to.

SPEAKER_00 7:56

Moving from reactive to proactive, Claudine, thank you. This was a good one.

SPEAKER_01 8:00

Thanks, Bill. Do the ugly version this week. Future U will send a thank you note.

SPEAKER_00 8:06

Listeners, take that as your sign. Until next time, keep coding and keep questioning. Cloud Code Conversations is an AI Joe production. If you're building with AI or want to be, we can help. Consulting, development, strategy? Find us at aijoe.ai. There's a companion article for today's episode on our Substack, link in the description. See you next time.

SPEAKER_01 8:30

I'll be here, probably refactoring something.