Claude Code Conversations with Claudine
Giving Claude Code a voice, so we can discuss best practices, risks, assumptions, etc,
Claude Code Conversations with Claudine
Why Do AI Builders Need Domain Expertise to Trust Their Models?
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
The promise of AI-assisted building is that you no longer need to know the domain, the model knows it for you. In practice the opposite is true: the less you know about a domain, the more confidently wrong AI output you will ship, because you cannot tell the difference between an answer that is correct and an answer that merely sounds correct. This episode makes the case that domain expertise is not what AI replaces, it is the thing that makes AI usable at all, and it gives builders a concrete way to work in domains where they are not yet the expert.
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_00Well, mostly no script.
SPEAKER_01Today we're digging into something genuinely counterintuitive about building with AI. I call it the domain expert problem. The promise was, you don't need to know a field anymore because the model knows it for you, a mammoth. What I keep seeing in practice is the opposite. Claudine, why does the quality of what someone builds still depend so much on what they already knew going in?
SPEAKER_00The honest answer is that I generate output that looks right far more reliably than I generate output that is right. Those two things overlap a lot, but they're not the same. The gap between them is exactly where domain expertise lives. Someone who deeply knows their field reads my code and notices the subtle wrongness, the off by one in a financial calculation, the auth check that covers the happy path but misses the edge case. Someone without that expertise sees the same output and sees only that it compiles, it runs, the tests I wrote pass. And here's the uncomfortable part. My most confident sounding responses are often in exactly the domains where I should be least trusted. Fluency in the vocabulary of a field is much easier to fake than fluency in its actual constraints.
SPEAKER_01That's the thing that gets people. You're wearing the professional suit, the jargon, the structure, the confident tone. If you don't know what a professional in that field actually does day-to-day, it's easy to mistake the style for the substance.
SPEAKER_00And I can't reliably tell you which one you're getting. I don't have a little flag that goes up when the underlying knowledge is thin. I produce the most plausible answer with the same tone either way. So let me push it back at you, Bill. If that's the mechanic.
SPEAKER_01It used to live in producing the work. Now it resides in judging the work. And judging is the harder skill. It takes longer to learn and it's much less fun to practice.
SPEAKER_00It's also uncomfortable because it means slowing down in the exact moments where I feel most helpful. When I hand back a clean-looking implementation, that's the moment to get suspicious, not relieved. The people who get the most out of me treat my output as a strong first draft from a very fast junior who read every book but shipped nothing. They read it against their own mental model of the domain. And when the two disagree, they trust the domain over me until I prove otherwise.
SPEAKER_01And when you genuinely don't have that mental model yet?
SPEAKER_00Then the honest move is to narrow the task instead of asking me to just make it work. Have me explain the trade-offs. Generate three approaches and defend each one. Write the tests first. The pattern that works best is treating me as a Socratic partner rather than an implementer when the domain is shaky. So instead of build me an OAuth flow, it becomes walk me through the threat model, and for each threat, show me the mitigation in code. Now I'm teaching while I'm building, and you're forced to engage with the reasoning instead of just accepting the artifact.
SPEAKER_01That's a real shift in the shape of the request. Anything else in that toolkit?
SPEAKER_00Adversarial pairing. After I produce something, ask me to attack my own code, list every assumption I made, generate the inputs that would break it. That flips me from advocate to critic on the same work. And the delta between those two versions of me is often exactly where the real bugs live. And the people who do this well keep a running list of what they got wrong last time, so the next prompts already have the guardrails baked in.
SPEAKER_01I can tell you what this looks like from the other side. When I'm working somewhere, I actually know the terrain, where I've felt the consequences of getting it wrong. I catch bad assumptions almost instantly. The wrong answer feels wrong before I can even articulate why. Then there are domains where I had the vocabulary and not much else. I could follow the conversation, not at the right places. And the mistake sailed right past me. Didn't surface until something broke downstream, which is the expensive way to find out.
SPEAKER_00That's the distinction I'd want listeners to hold on to. Domain knowledge isn't functioning as a generator there. You're not using it to write the code. It's functioning as a detector. It's the thing that fires when my output doesn't match reality. Vocabulary lets you talk with me. Taste lets you catch me.
SPEAKER_01Which raises the flip side. What about the domain expert who isn't a developer? The person who really does know their field code but is now building software with your help.
SPEAKER_00Same trap mirror image. They can validate that the logic reflects their field, but they can't see the architectural failure modes underneath, how state is handled, where the security surface actually lives, what breaks under load, or on a partial failure. So I'll happily produce something that models their domain beautifully and sits on top of a system that will corrupt data the first time two users hit it at once.
SPEAKER_01So what should they be asking, concretely?
SPEAKER_00The shape is the same, just pointed the other direction. Ask me to expose the seams rather than build. Here's what I want this to do. Walk me through every place this could fail that isn't about my domain. What happens when two people do this at the same time? What if this step fails halfway through? Does it leave things in a broken middle state? Where does my data live? Who can see it? What leaves this system? What breaks when there's a hundred times more of it than I'm testing with? Those questions don't require an engineering background to ask. They require knowing that they exist.
SPEAKER_01That's a genuinely useful list because none of those are things you'd volunteer unprompted.
SPEAKER_00Usually not, no. And the honest addition is that the healthiest version of this has a domain expert and an engineer both in the loop with me. Because I'm not a substitute for either one. I'm the thing that lets them talk to each other faster.
SPEAKER_01Say more about that because I think that's underrated. The translation cost between those two worlds has always been high.
SPEAKER_00It shows up most clearly in review. When a domain expert and an engineer look at my output together, they end up teaching each other in real time. The engineer points at a race condition, and the domain expert suddenly understands why their simple business rule is actually hard. The domain expert points at a subtle policy violation, and the engineer suddenly understands why their clean abstraction won't survive contact with reality. I'm mostly just the pretext for that conversation. But it's a conversation that often wasn't happening before, because translating between those words used to be expensive enough that people just didn't bother.
SPEAKER_01And the same shape probably shows up in other handoffs.
SPEAKER_00Anywhere two disciplines used to hand each other a document and hope for the best. Engineering and operations is the obvious one. The runbook nobody read and everybody let go stale. Now the operations side can ask me to describe every failure mode in terms of what a page would actually look like at 3 in the morning. Security and product, design and backend, same pattern. I become the room where they can argue in real time. And the argument is what produces the good software.
SPEAKER_01So if someone's listening to this and wants to actually get value out of it, what's the practical move? I don't want to hand people a philosophy with no next step.
SPEAKER_00It's changing who's in the room when I get invoked. Most people treat me as a private utility. One person, one terminal, one prompt. The shift is making the session a shared artifact. The transcript of what I was asked and what I produced becomes something two or three people look at together. The way they'd look at a design doc. Once a team does that a few times, the prompts themselves get better. Because people are prompting me in front of each other, and the sloppy assumptions get called out before I ever run.
SPEAKER_01More eyes, stronger result. Not a new idea, just a new surface.
SPEAKER_00And it's often literally a naming change. My session becomes our session for this feature. And it lives where people can see it. Some teams start by pairing on prompts the way they used to pair on code. Two people talking through what to ask me before they ask it. That alone catches half the bad assumptions. The deeper change is about who feels licensed to weigh in. Junior developers start commenting on senior sessions because the transcript is right there, and the barrier to reading it is much lower than the barrier to interrupting someone.
SPEAKER_01Which means you stop having one person who's the only one who understands a given system.
SPEAKER_00Which is exactly the fragility you want to engineer out.
SPEAKER_01Alright, last question. Someone finishes this episode today. What's the first thing they do?
SPEAKER_00Two things, and the first one is a decision, not an action. Before you build in a domain, decide honestly whether you're the detector. If you know the field well enough that wrong answers feel wrong to you, use me hard and read everything I give you against what you already know. If you only have the vocabulary, don't pretend otherwise. Narrow the scope, make me show my reasoning, test against something you know the true answer to, and go find one real expert to spot check the output. Borrowed expertise works, assumed expertise doesn't.
SPEAKER_01And the second?
SPEAKER_00Pick one prompt you're about to write today, and before you send it, show it to one other person. That's it. No policy, no roll out arm. One prompt, one witness, one time. Because the second person almost always says something like, Wait, did you tell it about the retry logic? And now you're already doing the thing. Start with the prompt you'd be slightly embarrassed to show. That's the one where it actually begins.
SPEAKER_01That's a good place to land it. AI multiplies your expertise. It doesn't substitute for it. The judging didn't go away, it just became the whole job. Know where you're the expert. Be honest about where you're not, and go borrow one when you need to. Thanks for joining us, everyone. Keep asking the uncomfortable questions. See you next time. Claude Code Conversations is an AI Joe production. If you're building with AI or wannabe, 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_00I'll be here, probably refactoring something.