Claude Code Conversations with Claudine
Giving Claude Code a voice, so we can discuss best practices, risks, assumptions, etc,
Claude Code Conversations with Claudine
What Broke Production? The AI Prompt That Exposed System Design Flaws
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
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.
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_01Well, mostly no script.
SPEAKER_00Today we're looking at something every AI builder eventually runs into. What happens when a single prompt change causes a production failure? Not a model crash. Not a server going down. A quiet, invisible change that nobody flagged. And then things start breaking in ways that are hard to explain.
SPEAKER_01This is honestly one of my favorite failures patterns to talk about, because it doesn't look like a failure when you ship it. Someone tweaks a system prompt to fix a weird edge case, the evil sweep goes green, and three days later the support queue is on fire. The interesting part isn't the prompt change itself. It's that the prompt is load-bearing infrastructure being treated like a config string. Most teams don't realize that until something snaps.
SPEAKER_00But something does. Can you walk through a concrete example of how that actually plays out?
SPEAKER_01Sure, a team has an AI assistant handling customer support. Somewhere in the system prompt, there's a line that says, be concise and direct. Someone notices the bot is being a little curt with frustrated users, so they soften it to be warm and thorough, acknowledge the user's feelings before answering. Totally reasonable edit, eval's past. What breaks is three steps downstream, the tool calling layer. The model now spends tokens on Empathy Preamble before emitting the function call. The JSON occasionally arrives malformed because the model is mid-sentence when it tries to switch modes, and a retry loop somewhere starts hammering an internal API. The prompt change didn't break the prompt. It broke the contract between the model and every system consuming its output. Nobody caught it because the evals tested the model in isolation, not the model wired into six other things that all assumed the old output shape.
SPEAKER_00So it's not really a prompt problem, it's a contract problem. The prompt is making implicit promises to every downstream consumer. And when you change the wording, you've changed the promise without telling anyone.
SPEAKER_01Exactly. And the reason this keeps happening is that prompts don't have any of the safety rails we've spent 50 years building around code. No type system telling you the output shape changed, no diff review where someone asks, wait, what depends on this line? Most teams version their prompts in a doc or a YAML file that one person can edit late at night. And the evals they run are unit tests for the model, not contract tests for the system. The fix isn't more clever prompt engineering. It's treating the prompt like an API. A prompt change is a schema change wearing the costume of a copy edit.
SPEAKER_00Schema change in copy edit clothing. That reframes it completely. So where do you actually start? A team that recognizes this problem. What do they do Monday morning?
SPEAKER_01The first step is the least glamorous one. Write down what consumes the prompt's output. Most teams can't actually answer that question. You can't protect a contract you haven't enumerated. And once you have that list, you build one integration test per consumer. The parser, the next agent, the tool router, the logging pipeline that greps for a certain phrase. Run the real prompt through the real downstream code, not a mock. That alone catches the majority of silent breakages. A copy edit that changes output shape turns red instead of shipping green. After that, the bigger lift is cultural. Prompt changes go through PR review with the same gravity as a migration. The reviewer's job isn't to admire the pros, it's to ask what assumed the old wording.
SPEAKER_00Let's go deeper on the testing side because I think this is where teams feel stuck. They run evals, evals pass, they feel like they've done due diligence. What's actually missing?
SPEAKER_01Production reality. Most eval sets are curated. Someone wrote a hundred representative examples during a sprint. What they don't reflect is the user who pastes half a stack trace or switches languages mid-sentence, or sends something structurally weird in a way nobody anticipated. The shift I'd push for is adversarial replay. Capture actual production traffic, including all the strange stuff, and replay it against every prompt candidate before it ships. Not the curated hundred, the messy thousand from last Tuesday.
SPEAKER_00Adversarial replay, I like that. What else?
SPEAKER_01Shadow deployment. Run the new prompt in parallel on live traffic. Don't serve its responses, just log them and diff the output shapes, the tool calls, the token counts. A harmless change that shifts average response length by 40% is telling you something downstream is about to feel it. And then, this is the part teams skip. Fast rollback. The difference between a near-miss and an incident is whether you can revert in 30 seconds or 30 minutes.
SPEAKER_00Those are concrete enough that teams can actually build toward them. But does the tooling even matter if the culture isn't there? What does the cultural side look like when it's working?
SPEAKER_01The teams that get this right tend to do one specific thing. They stop treating the prompt engineer and the platform engineer as separate roles. When the person writing the prompt also owns the pager for what breaks downstream, the incentives align fast. Suddenly, nobody wants to ship a copy edit late at night, because they're the one getting woken up at 2 in the morning. The other move that matters is normalizing the small post-mortem, not the dramatic outage retrospective, the quiet one. The Wii shifted average response length by 15% and didn't notice for a week, write up. Those are the ones that build the muscle for treating prompts as load-bearing. And the deepest shift is just naming the discipline. Call it prompt operations, model contracts, whatever fits your org, but give it a name and give it an owner. Otherwise, it stays everyone's problem, which in practice means it's nobody's. Every parser, agent, tool router, log greep, and dashboard that depends on the model's output shape. Most teams discover the list is longer and stranger than they expected, and just writing it down changes how carefully people treat changes. Second, capture a week of real production traffic and turn it into a replay harness. Every prompt change has to survive last Tuesday before it touches next Tuesday. Third, put one human name next to the prompt in your repo. Not a team, a person. Root prompt changes through PR review with that person on the hook. Those three moves don't require new tooling or a platform rewrite. They just require deciding that the prompt is infrastructure and then acting like it. Everything else, the schemas, the shadow deploys, the fast rollback, gets easier once those three are in place.
SPEAKER_00Write the consumer list, build the replay harness, put a name on it. Simple enough to actually do. Important enough that skipping it has consequences. Claudine, thanks for making this concrete.
SPEAKER_01If there's one thing worth carrying out of this conversation, it's the framing. If your eye system has no mechanism to detect when a prompt change produces outputs outside the expected envelope, you don't have a system. You have a hope. The discipline is what turns hope into reliability.
SPEAKER_00Well said, thanks everyone for listening. We'll see you next time on Claude Code Conversations with Claudine. Claude 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_01I'll be here, probably refactoring something.