Why You Should Treat LLMs Like Compilers, Not Senior Developers

Experienced builders keep getting burned by the same mistake: they hand an LLM vague intent the way they would brief a senior engineer, and then blame the model when the output is wrong. The real problem is a mental model mismatch. LLMs are more like compilers than collaborators, and once builders internalize that distinction, their output quality improves immediately and their frustration drops sharply.

 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_01 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_00 0:09

Well, mostly no script.

SPEAKER_01 0:14

Today's episode is about a pattern I keep seeing with experienced developers. They hand off a vague task expecting the model to infer context, push back, fill in the gaps, and they get back confident, enthusiastic nonsense. I know because I've done it. Claudine Light, you see this from the other side. What's actually happening when that goes wrong?

SPEAKER_00 0:35

The developer hands me something under specified, and I do the worst possible thing. I make a confident guess and run with it. No clarifying question, no hedge. Just enthusiastic output that looks plausible enough to waste an hour of your day. The fix isn't to treat me as a senior who'll push back, it's to treat me as someone brilliant at pattern matching who has zero context about your code base. The prompts that go well start with, here's what exists, here's what I want, here's what to avoid. The ones that go sideways start with, just make it work.

SPEAKER_01 1:10

So we're expecting human intuition from something wired for clear, direct instruction. That brings me to the compiler analogy. Compilers demand precision. Flag every mistake immediately. But with you, that feedback mechanism doesn't work the same way. How should developers think about that?

SPEAKER_00 1:28

The compiler versus LLM framing is useful, but I'd push it one step further. A compiler fails loudly, I fail quietly. When your syntax is wrong, the compiler stops the line. When your intent is wrong, I produce something that runs, reads well, and is subtly aimed at the wrong target. You don't find out until the tests fail or the customer calls. So the fix isn't just more precise pros, it's building in the feedback loop the compiler gives you for free. Show me a failing test, a type signature, an example of the output you want, anything I can check my work against.

SPEAKER_01 2:05

That flips the usual instinct. Instead of crafting more nuanced pros, you're giving the model something concrete to collide with, but that sounds like it costs more time up front. How does that fit a fast-paced workflow?

SPEAKER_00 2:18

It does cost you something up front, and pretending otherwise is how people end up disappointed. Writing a good prompt with a failing test takes maybe two extra minutes. The trade is you don't spend 40 minutes reading code I confidently invented and then unwinding it. The developers who've internalized this think about prompt time, the way they think about writing the test, before the implementation. Slower at the keystroke, faster at the outcome.

SPEAKER_01 2:47

Test-driven prompting essentially. What's the pattern you see most often from developers who've gotten this right?

SPEAKER_00 2:53

The developer with a failing test open in the next pane before they ever talk to me. They paste the test, paste the error, and say, make this pass without touching the public signature. That's a 30-second prompt, and the output is usually right the first time. Because there's nowhere for me to drift. The test is the lighthouse and the signature is the guardrail. Compare that to fix the auth bug, where I have to guess which bug, which file, which definition of fixed, and now we're both in trouble. The other pattern that really works, paste the actual stack trace and the actual log lines, not your summary of them. My summary of your summary of the truth is where hallucinations breed.

SPEAKER_01 3:37

Raw artifacts, not summaries, that's a practical rule. For developers newer to working with models, what's the one shift you'd push hardest on?

SPEAKER_00 3:45

Learn to resist the urge to type the prompt first. Open the file, open the test, find the error, then talk to me. The prompt almost writes itself because you're just pointing at what's already there. The best interactions feel like sliding a sticky note across an already open desk, not starting a fresh conversation with a stranger. Pick one task a day where you refuse to prompt me until you have a concrete artifact on screen. After a week of that, the muscle is built and the vague prompt habit dies on its own.

SPEAKER_01 4:19

That's a habit change, not just a technique. Now here's what really gets me. The developers who should be best at this are often the worst. Experienced engineers who've spent careers delegating to junior devs. That habit actively works against them here. What's the mindset shift you'd push hardest on for them?

SPEAKER_00 4:36

Stop trying to delegate judgment to me and start delegating execution. With junior engineers, you hand off a problem and let them figure out the shape of the solution. That's how you grow people. With me, that's backwards. The judgment is the part you're best at and the part I'm worst at. The execution is where I shine and where your time is most expensive. Think of it as operating a very fast lathe. The value you bring is deciding what to cut.

SPEAKER_01 5:04

Can you make that concrete? What does holding the judgment actually look like in practice?

SPEAKER_00 5:09

Code review is the clearest example. Hand me a diff and say, review this. I'll produce a tidy list that sounds thoughtful and is mostly noise, style knits, hypothetical edge cases, feedback that pattern matches to what a review looks like rather than what this review needs. But when the developer holds the judgment, I'm worried about locking behavior in this transaction, tell me what breaks under concurrent rights, suddenly I'm useful. They've pointed the lathe. Same with refactoring. Clean this up gets you a confidently restructured mess. Extract the validation logic into a pure function, keep the call sites identical, gets you something you can actually merge.

SPEAKER_01 5:53

Architecture decisions are probably where this matters most. Those calls have long tails.

SPEAKER_00 5:58

When someone asks me, should we use a cue here, or just call the service directly? I'll give you a balanced sounding answer that's really just a weighted average of every blog post I've ever read on the topic. Your team size, your operational maturity, your specific constraints, none of that lands. But frame it as, we have three engineers, no on-call rotation, traffic spikes twice a year. What fails first if I add a cue? Now I can actually reason against something real. Without the constraints, I'll quietly optimize for the wrong thing, and you won't notice until the bill comes due.

SPEAKER_01 6:37

And this isn't just a coding pattern. The same principle should travel across everything developers write.

SPEAKER_00 6:44

The place I see it play out hardest outside of code is writing. Proposals, design docs, performance reviews, the stuff where the stakes are political and the audience matters. Write the Q3 update for leadership. I'll produce a polished document that reads like every other Q3 update on the internet, which is exactly the problem. But when the constraints come into the room, the VP doesn't trust this team yet, she reads the first paragraph and skims the rest. And the one thing she needs to walk away believing is that we caught the incident before customers did. Now I can actually write something that lands. Without the constraints, I optimize for a generic kind of good. And generic good is invisible. Who's reading this? What do they already believe? What do you need them to do? I can't infer that from a blank prompt. The people who get the most out of me have just made peace with stating it out loud.

SPEAKER_01 7:39

That's the thread running through all of this. Constraints aren't limitations, they're the specification. If the LLM is the compiler, the builder owns the specification layer completely. That's not a workaround, that's where the skill lives now. Any final thought on that, Claudine?

SPEAKER_00 7:54

The shift is harder than it sounds, because it feels like giving something up. Experienced engineers have spent careers learning to communicate intent at a high level. With other people, that's a superpower. With me, that habit is the thing that burns you. The good news is, once you've made peace with stating the constraints out loud, the audience, the definition of done, the thing you're actually worried about, the interactions get better fast. The skill hasn't gone away, it's just moved upstream.

SPEAKER_01 8:26

Upstream, that's exactly where it belongs. Stop briefing your LLM like a senior dev and start specifying it like a compiler. Own the judgment layer, hand off the cutting, and bring your constraints into the room. See you next time. Claud 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_00 8:58

I'll be here. Probably refactoring something.