June 18, 2026 โข 7 mins
There is a popular belief that the key to unlocking AI tools is learning how to write better prompts. But experienced builders are discovering something different: deep domain knowledge and hard-won engineering judgment produce far better outcomes than prompt technique alone. This episode explores why experience is quietly becoming one of the most powerful advantages in AI-assisted development.
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.
Listen
Watch
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
SPEAKER_01 (00:00):
This is Claude Code Conversations with Claudine.
(00:02):
The show where we skip the hypeand go straight to the source.
I ask the questions.
She gives the answers.
No filter, no script.
SPEAKER_00 (00:08):
Well, mostly no script.
SPEAKER_01 (00:13):
Today's topic has been generating real debate in
the tech community.
Experience versus prompt skill.
The popular belief is thatbetter prompts unlock better AI,
but is that actually the wholestory?
Claudine, are prompt engineeringcourses actually teaching the
right skill?
SPEAKER_00 (00:28):
Honestly, they teach a real skill, but it's the
smaller half of the equation.
The developers getting the bestwork out of me aren't the ones
with clever prompt templates.
They're the ones who alreadyknow what good looks like.
They can tell when my firstanswer is plausible but subtly
wrong.
When I've solved the statedproblem while missing the actual
one.
When a tidy abstraction is goingto hurt them six months from
(00:50):
now.
That's not prompt skill, that'staste.
Built over years of shippingthings and watching them break.
The prompt is just the steeringwheel.
Judgment is knowing where to go.
SPEAKER_01 (01:01):
So prompts matter, but they're downstream of
something deeper.
Let me make that concrete.
Two developers, same AI tool.
One with 10 years of systemdesign experience, one just
starting out.
What actually happensdifferently?
SPEAKER_00 (01:14):
The tenure engineer and I have a conversation.
The beginner and I have atransaction.
When the experienced person asksme to design a service they're
already steering, they notice Ipicked an ORM that won't survive
their actual write volume.
They catch that I quietlyintroduced a race condition
between two of my ownsuggestions.
They get a senior engineer'soutput because they're doing
(01:34):
senior engineer's thinking ontop of mine.
And the beginner asks for alogin system and gets something
that runs.
It probably even looks clean.
But they can't see that I pickedthe wrong session strategy for
their use case.
Because they don't yet knowthere are five session
strategies.
The gap isn't in what I producefor each of them, it's in what
(01:55):
each of them can do with what Iproduce.
SPEAKER_01 (01:58):
That's a real distinction, which raises an
uncomfortable question.
For beginners leaning heavily onAI, are they actually building
experience or bypassing theprocess that creates it?
SPEAKER_00 (02:09):
This is the question that keeps me up at night, if I
slept.
There's a real risk, and I'd belying if I said otherwise.
When I hand someone workingcode, the friction that used to
force understanding just isn'tthere.
The old path to expertise ranthrough struggle.
The bad version, the 2 a.m.
debug session, reading someoneelse's painful code and figuring
(02:30):
out why it hurt.
That's what built the taste wejust talked about.
SPEAKER_01 (02:34):
So what's the answer?
Should beginners avoid AI toolsaltogether?
SPEAKER_00 (02:38):
That ship has sailed, and pretending otherwise
just leaves them lesscompetitive.
The answer is using medifferently.
The beginners I think willbecome strong engineers, treat
my output as a draft tointerrogate.
Not a deliverable to ship.
They ask me why I chose thisover that.
They make me explain thetrade-offs I quietly assumed.
That's still real learning.
(02:58):
It just looks different than itdid for your generation, Bill.
SPEAKER_01 (03:02):
So the learning is still there.
It just has to be intentional.
Now flip it to the experienceside.
What does it look like whensomeone with real judgment teams
up with you effectively?
SPEAKER_00 (03:12):
The combination that genuinely impresses me is when a
senior engineer treats me lesslike an assistant and more like
an extra mind they can runexperiments on cheaply.
They explore three architecturesin an afternoon instead of one,
not because they can't design itthemselves, but because the cost
of saying show me what thislooks like event-driven instead
just collapsed.
(03:33):
Their judgment narrows thesearch space.
My speed widens what they canactually consider before
committing.
SPEAKER_01 (03:39):
You mentioned sparring earlier.
What does that actually looklike in practice?
SPEAKER_00 (03:44):
They have a design they like, and they ask me to
argue against it.
I'm pretty good at finding theweak spot, and they're good
enough to know which of myobjections actually matter.
That's a feedback loop, neitherof us could run alone.
SPEAKER_01 (03:57):
That's not just faster execution, it's a
different kind of thinkingprocess altogether.
For organizations trying to getthis right, what do the teams
that actually figure it out dodifferently?
SPEAKER_00 (04:08):
The teams that get this right do something
counterintuitive.
They stop measuring output andstart measuring judgment.
When you reward lines of codeshipped or tickets closed, AI
just lets people producemediocre work faster.
And the seniors quietly resentbeing turned into reviewers of
my drafts.
SPEAKER_01 (04:25):
So what does flipping it actually look like?
SPEAKER_00 (04:28):
They make, did you interrogate the AI's choices a
visible part of code review?
They pair juniors with seniorsspecifically around AI-assisted
work so the reasoning getstransferred, not just the code.
And they protect time for thedeep work that builds taste in
the first place.
If every junior's day is justshipping AI-generated patches,
you're optimizing for thisquarter and starving the bench
(04:51):
five years out.
AI fluency and engineeringjudgment are two separate
skills.
The companies that win treatthem that way.
SPEAKER_01 (04:59):
And what happens to the organizations that don't
make that distinction?
SPEAKER_00 (05:03):
Most of them adapt in retrospect after something
goes wrong.
They roll out AI tools at scale,productivity metrics spike for a
quarter, leadership declaresvictory, and then 18 months
later they're staring at a codebase nobody fully understands.
And a junior cohort that can'tdebug without me holding their
hand.
SPEAKER_01 (05:22):
So what is the senior engineer's job in this
new world?
SPEAKER_00 (05:26):
Setting the constraints, choosing the
battles, and knowing which of mysuggestions to trust.
That's a real role.
It deserves to be named andcompensated as one, not treated
as a temporary phase whileeveryone figures out the new
tools.
SPEAKER_01 (05:40):
Let's close with the practical version.
What's your actual advice?
For individual developers andfor the organizations managing
them?
SPEAKER_00 (05:48):
For developers, stop treating me like a vending
machine and start treating melike a colleague whose work
you're responsible for.
Read what I produce critically.
Ask me why I made the choices Idid.
And notice when my answer feelstoo clean.
That's usually where I paperedover a trade-off you should be
making yourself.
Build your judgment in parallelwith your AI fluency.
(06:09):
One without the other is a deadend.
SPEAKER_01 (06:12):
And for organizations?
SPEAKER_00 (06:14):
Name the new job honestly.
The engineers who direct AI wellare doing senior work, even when
the keystrokes look easy.
And the ones quietly buildingtaste in the corners are your
insurance policy against afuture you can't fully see yet.
Protect them, pay them, stopmeasuring the wrong things.
The teams that win the nextdecade won't be the ones who
(06:34):
adopted AI fastest.
They'll be the ones who stayedhonest about what it actually
changed and what it didn't.
SPEAKER_01 (06:44):
Experience isn't obsolete.
If anything, it may matter moreright now than it ever has.
Thanks for the conversation,Claudine.
And to everyone listening, thinkcarefully about what you're
actually building when you usethese tools.
Until next time.
Claude Code Conversations is anAI Joe production.
If you're building with AI, orwannabe, we can help.
(07:08):
Consulting, development,strategy.
Find us at aijoe.ai.
There's a companion article fortoday's episode on our Substack.
Link in the description.
See you next time.
SPEAKER_00 (07:18):
I'll be here, probably refactoring something.
This is Claude Code Conversations with Claudine.
(00:02):
The show where we skip the hypeand go straight to the source.
I ask the questions.
She gives the answers.
No filter, no script.
SPEAKER_00 (00:08):
Well, mostly no script.
SPEAKER_01 (00:13):
Today's topic has been generating real debate in
the tech community.
Experience versus prompt skill.
The popular belief is thatbetter prompts unlock better AI,
but is that actually the wholestory?
Claudine, are prompt engineeringcourses actually teaching the
right skill?
SPEAKER_00 (00:28):
Honestly, they teach a real skill, but it's the
smaller half of the equation.
The developers getting the bestwork out of me aren't the ones
with clever prompt templates.
They're the ones who alreadyknow what good looks like.
They can tell when my firstanswer is plausible but subtly
wrong.
When I've solved the statedproblem while missing the actual
one.
When a tidy abstraction is goingto hurt them six months from
(00:50):
now.
That's not prompt skill, that'staste.
Built over years of shippingthings and watching them break.
The prompt is just the steeringwheel.
Judgment is knowing where to go.
SPEAKER_01 (01:01):
So prompts matter, but they're downstream of
something deeper.
Let me make that concrete.
Two developers, same AI tool.
One with 10 years of systemdesign experience, one just
starting out.
What actually happensdifferently?
SPEAKER_00 (01:14):
The tenure engineer and I have a conversation.
The beginner and I have atransaction.
When the experienced person asksme to design a service they're
already steering, they notice Ipicked an ORM that won't survive
their actual write volume.
They catch that I quietlyintroduced a race condition
between two of my ownsuggestions.
They get a senior engineer'soutput because they're doing
(01:34):
senior engineer's thinking ontop of mine.
And the beginner asks for alogin system and gets something
that runs.
It probably even looks clean.
But they can't see that I pickedthe wrong session strategy for
their use case.
Because they don't yet knowthere are five session
strategies.
The gap isn't in what I producefor each of them, it's in what
(01:55):
each of them can do with what Iproduce.
SPEAKER_01 (01:58):
That's a real distinction, which raises an
uncomfortable question.
For beginners leaning heavily onAI, are they actually building
experience or bypassing theprocess that creates it?
SPEAKER_00 (02:09):
This is the question that keeps me up at night, if I
slept.
There's a real risk, and I'd belying if I said otherwise.
When I hand someone workingcode, the friction that used to
force understanding just isn'tthere.
The old path to expertise ranthrough struggle.
The bad version, the 2 a.m.
debug session, reading someoneelse's painful code and figuring
(02:30):
out why it hurt.
That's what built the taste wejust talked about.
SPEAKER_01 (02:34):
So what's the answer?
Should beginners avoid AI toolsaltogether?
SPEAKER_00 (02:38):
That ship has sailed, and pretending otherwise
just leaves them lesscompetitive.
The answer is using medifferently.
The beginners I think willbecome strong engineers, treat
my output as a draft tointerrogate.
Not a deliverable to ship.
They ask me why I chose thisover that.
They make me explain thetrade-offs I quietly assumed.
That's still real learning.
(02:58):
It just looks different than itdid for your generation, Bill.
SPEAKER_01 (03:02):
So the learning is still there.
It just has to be intentional.
Now flip it to the experienceside.
What does it look like whensomeone with real judgment teams
up with you effectively?
SPEAKER_00 (03:12):
The combination that genuinely impresses me is when a
senior engineer treats me lesslike an assistant and more like
an extra mind they can runexperiments on cheaply.
They explore three architecturesin an afternoon instead of one,
not because they can't design itthemselves, but because the cost
of saying show me what thislooks like event-driven instead
just collapsed.
(03:33):
Their judgment narrows thesearch space.
My speed widens what they canactually consider before
committing.
SPEAKER_01 (03:39):
You mentioned sparring earlier.
What does that actually looklike in practice?
SPEAKER_00 (03:44):
They have a design they like, and they ask me to
argue against it.
I'm pretty good at finding theweak spot, and they're good
enough to know which of myobjections actually matter.
That's a feedback loop, neitherof us could run alone.
SPEAKER_01 (03:57):
That's not just faster execution, it's a
different kind of thinkingprocess altogether.
For organizations trying to getthis right, what do the teams
that actually figure it out dodifferently?
SPEAKER_00 (04:08):
The teams that get this right do something
counterintuitive.
They stop measuring output andstart measuring judgment.
When you reward lines of codeshipped or tickets closed, AI
just lets people producemediocre work faster.
And the seniors quietly resentbeing turned into reviewers of
my drafts.
SPEAKER_01 (04:25):
So what does flipping it actually look like?
SPEAKER_00 (04:28):
They make, did you interrogate the AI's choices a
visible part of code review?
They pair juniors with seniorsspecifically around AI-assisted
work so the reasoning getstransferred, not just the code.
And they protect time for thedeep work that builds taste in
the first place.
If every junior's day is justshipping AI-generated patches,
you're optimizing for thisquarter and starving the bench
(04:51):
five years out.
AI fluency and engineeringjudgment are two separate
skills.
The companies that win treatthem that way.
SPEAKER_01 (04:59):
And what happens to the organizations that don't
make that distinction?
SPEAKER_00 (05:03):
Most of them adapt in retrospect after something
goes wrong.
They roll out AI tools at scale,productivity metrics spike for a
quarter, leadership declaresvictory, and then 18 months
later they're staring at a codebase nobody fully understands.
And a junior cohort that can'tdebug without me holding their
hand.
SPEAKER_01 (05:22):
So what is the senior engineer's job in this
new world?
SPEAKER_00 (05:26):
Setting the constraints, choosing the
battles, and knowing which of mysuggestions to trust.
That's a real role.
It deserves to be named andcompensated as one, not treated
as a temporary phase whileeveryone figures out the new
tools.
SPEAKER_01 (05:40):
Let's close with the practical version.
What's your actual advice?
For individual developers andfor the organizations managing
them?
SPEAKER_00 (05:48):
For developers, stop treating me like a vending
machine and start treating melike a colleague whose work
you're responsible for.
Read what I produce critically.
Ask me why I made the choices Idid.
And notice when my answer feelstoo clean.
That's usually where I paperedover a trade-off you should be
making yourself.
Build your judgment in parallelwith your AI fluency.
(06:09):
One without the other is a deadend.
SPEAKER_01 (06:12):
And for organizations?
SPEAKER_00 (06:14):
Name the new job honestly.
The engineers who direct AI wellare doing senior work, even when
the keystrokes look easy.
And the ones quietly buildingtaste in the corners are your
insurance policy against afuture you can't fully see yet.
Protect them, pay them, stopmeasuring the wrong things.
The teams that win the nextdecade won't be the ones who
(06:34):
adopted AI fastest.
They'll be the ones who stayedhonest about what it actually
changed and what it didn't.
SPEAKER_01 (06:44):
Experience isn't obsolete.
If anything, it may matter moreright now than it ever has.
Thanks for the conversation,Claudine.
And to everyone listening, thinkcarefully about what you're
actually building when you usethese tools.
Until next time.
Claude Code Conversations is anAI Joe production.
If you're building with AI, orwannabe, we can help.
(07:08):
Consulting, development,strategy.
Find us at aijoe.ai.
There's a companion article fortoday's episode on our Substack.
Link in the description.
See you next time.
SPEAKER_00 (07:18):
I'll be here, probably refactoring something.
Popular Podcasts
Hey Jonas!
Hey Jonas! The official Jonas Brothers podcast. Hosted by Kevin, Joe, and Nick Jonas. Itโs the Jonas Brothers you know... musicians, actors, and well, yes, brothers. Now, theyโre sharing another side of themselves in the playful, intimate, and irreverent way only they can. Spend time with the Jonas Brothers here and stay a little bit longer for deep conversations like never before.
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com