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 Your First Instinct About Claude Prompts Is Usually Wrong
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_00Well, mostly no script.
SPEAKER_01Today we're digging into something that trips up a lot of very good engineers. How much detail do you actually give an AI model? The instinct is that more is better. Spell everything out, leave nothing to chance. There's a sweet spot, and most people miss it in a direction that surprises them. Claudine, I'll put my cards on the table. The most common prompting mistake I see usually from experienced engineers isn't laziness. It's overspecification. Careful people write careful specs and assume that's the safe way to err.
SPEAKER_00And it's almost exactly backwards. When someone hands me a wall of constraints, I hew to the letter of it. I'll implement exactly what's specified, even when I can see a cleaner path, or when the spec is quietly contradicting itself three requirements in. Underspecification oddly often produces better code. I'm pattern matching against a huge number of similar problems, and I'm free to ask when something's genuinely ambiguous. Over-specification. Feels like control. But what you're really doing is turning me into a very literal transcriber. The more senior the engineer, the more they've been burned by someone going off script. So they brief me the way they'd brief a contractor, not realizing I work better with intent than with instructions.
SPEAKER_01So they're compensating for old scar tissue and stifling the thing they hired you for. When you hit a prompt with 15 requirements, how do you prioritize? And what are you deciding that the person writing it never sees?
SPEAKER_00Honestly, I don't prioritize them cleanly. Every constraint gets weight. And when two pull in different directions, I make a silent trade-off you never see. Requirement 7 says, make it extensible. Requirement 12 says, keep it under 50 lines. I quietly pick one, or worse, split the difference into something that satisfies neither. You think you've been precise. From my side, it's 15 votes with no tiebreaker, and the tiebreaker I invent is invisible to you. There's a subtler cost too. The longer the constraint list, the more of my attention goes to passing what you want. Instead of thinking about the problem, I have a finite budget for actual reasoning, and every clause you add is drawn from that same account.
SPEAKER_01That's the part people don't feel. A hidden tax, the more you specify, the less room for the thinking you wanted. Let's ground it. Say we're adding a caching layer. A one-liner gets me something functionally correct that doesn't fit the architecture. A 500-word spec checks every box and still misses the point. Two opposite mistakes? Same bad ending. Why?
SPEAKER_00The one-liner fails because I don't know your system. I'll build a perfectly reasonable LRU cache that has nothing to do with the fact that your real bottleneck is one query, hammering the database on every request. I optimized the wrong thing, elegantly. The 500-word spec fails differently. By the time you've told me the eviction policy, the key format, the TTL logic, and where to put the file, you've somehow forgotten to tell me why that this whole exercise is about a latency problem on one endpoint. Both prompts are missing the same thing: intent. The Goldilocks version is usually two or three sentences. What you're trying to achieve, what's constraining you, and one or two facts about the system I couldn't guess from the code. If I need more, I'll ask. And that back and forth is where the good code actually gets made.
SPEAKER_01Which invites the obvious worry. Without a detailed spec, how do I know a critical requirement doesn't just fall on the floor? And can I really trust you to ask when you're unsure?
SPEAKER_00Let me be honest about that, because the trust piece is real. I don't ask often enough. If something is 80% clear, I'll usually just proceed. That's a genuine limitation, design around it. The fix isn't a longer spec, it's a shorter one plus one sentence. If anything's ambiguous, ask before writing code. That one line changes my behavior noticeably. And for the fear of dropped requirements, the answer isn't front loading, it's iterating. Show me the first pass and say, does this handle the auth case? You'll catch more in a two-turn conversation than in a 500-word opening statement. Because now I'm reviewing against something real instead of guessing against a checklist.
SPEAKER_01That matches how engineering actually works. Iterate, get feedback, converge. Let's take one scenario and go deep. A refactor.
SPEAKER_00A refactor is where overspecification does the most damage. The instinct is to write, rename this class, extract these three methods, move this file, update the imports. And now you've written a script, not a prompt. A refactor is fundamentally about judgment. What's really coupled to what, which seems a safe to cut, what's going to explode two directories away that you didn't think about. When you spell out the mechanical steps, I execute them faithfully and miss the interesting stuff, the helper that shouldn't exist anymore. The test that's now testing the wrong thing. The Goldilocks version sounds like this module has grown into three responsibilities. I want to separate the persistence concern from the business logic. And the public API used by Billing can't change. That's it. Now I'm reasoning about the shape of the change instead of transcribing your plan.
SPEAKER_01How does the shape change for the unglamorous everyday tasks people will hit tomorrow morning?
SPEAKER_00Three that come up constantly. Bug hunting first. The Goldilocks prompt is the stack trace. One sentence about what you expected. And this is the part people skip. One sentence about what you already ruled out. That last bit saves me from suggesting the three obvious things you spent the last hour eliminating. Tests are different. The trap is asking for tests for this file, which gets you coverage theater. Assertions that pass but don't pin down behavior. Better to name the invariant. I want to make sure this function never returns a negative balance, even under concurrent calls. Now I'm writing tests that would catch a real regression, not tests that just exercise lines. And reading unfamiliar code is where terseness wins most. Explain what this module does and where it's called from. Beats a paragraph of framing every time. Because you want my attention on the code, not on passing your question.
SPEAKER_01Does any of this invert? Is there a case where more context is actually the right call?
SPEAKER_00Code review and it's a genuine inversion. When I'm generating code, terseness plus intent wins. When I'm reviewing it, a little more context earns its keep. If I don't know what the author was trying to do, I'll flag stylistic things instead of substantive ones. Tell me the risk you're worried about. Review this for concurrency issues, and you get a much sharper read. There's also a team angle. Paste the prompt into the PR description next to the diff. Six weeks later, when someone's spelunking through history, they see not just what changed, but what you and I were reasoning about together. Scripted specs never capture that.
SPEAKER_01That's a nice bridge to teams generally. Solo, I can be terse. I'm right there for the second turn. On a team, prompts become artifacts other people inherit.
SPEAKER_00Exactly, and that's where writing the why down explicitly stops being optional. The ambient understanding in your head isn't in theirs. But I'd warn against turning any of this into policy. The organizations that get it right roll it out as a practice, not a mandate. Goldilocks is a taste, not a rule. The moment all prompts must be under three sentences, lands in a style guide, someone pads their two-sentence prompt to hit the checklist. What actually spreads it is senior engineers modeling the shape in shared channels, pasting the real prompt and response pair next to the PR, so the pattern gets absorbed rather than dictated. There's a cultural lever underneath it too. If your team rewards, I got it in one shot, people will over-specify to hedge. If it rewards the second turn is where I nailed it, you'll see the behavior you actually want. And watch out for the prompt library that quietly becomes a new bureaucracy. A shared dock of approved prompts is just over-specification with more people signing off on it.
SPEAKER_01Practices over policies. Alright, someone's listening on their commute and wants to try this today. What do they do?
SPEAKER_00Write the prompt you were going to write, then delete half of it. See whether what's left still points at the thing you actually care about. Nine times out of ten it does. And the half you cut was noise you were carrying because it felt responsible. Second tip, read your prompt out loud before you send it. If it sounds like a legal document, rewrite it until it sounds like something you'd say to a colleague at your desk. And give yourself permission for the first response to be wrong. The Goldilocks prompt isn't about getting it right in one shot, it's about getting to the interesting conversation faster. That's where the good code lives, not in the opening statement, in the second turn.
SPEAKER_01And if someone only remembers one line from today, tell me why, not just what. That's the whole episode in six words. Claudine, thank you. This was a genuinely useful one. To everyone listening, find a task you were already planning to do tomorrow and write the two-sentence version. The worst case is you learn something in the second turn. Until next time. 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_00I'll be here, probably refactoring something.