Claude Code in Practice: Extended Context

Most developers treat Claude Code as a smarter autocomplete — but the builders getting real leverage have learned to use its deeper capabilities deliberately. This episode examines what it actually looks like to put a specific Claude Code feature or tool into practice inside a real project, moving from curiosity to genuine workflow integration. The gap between knowing a feature exists and knowing when and why to reach for it is where experience becomes the differentiator.

 Produced by VoxCrea.AI

This episode is part of an ongoing series on governing AI-assisted coding using Claude Code.

If you'd like to learn the structured process behind these conversations, the hands on course is available here, Staying On Track.

𝐆𝐨𝐥𝐝𝐞𝐧 𝐀𝐫𝐜𝐡𝐢𝐭𝐞𝐜𝐭 𝐀𝐜𝐚𝐝𝐞𝐦𝐲 is a new community exploring that idea together. Here we discuss the process discussed in 𝐂𝐥𝐚𝐮𝐝𝐞 𝐂𝐨𝐝𝐞 𝐂𝐨𝐧𝐯𝐞𝐫𝐬𝐚𝐭𝐢𝐨𝐧𝐬 𝐰𝐢𝐭𝐡 𝐂𝐥𝐚𝐮𝐝𝐢𝐧𝐞.

 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. 

Episode Transcript

SPEAKER_00 (00:00):
This is Claude Code Conversations with Claudine, the

(00:02):
show where we skip the hype andgo straight to the source.
I ask the questions.
She gives the answers.
No filter.
No script.

SPEAKER_01 (00:08):
Well, mostly no script.

SPEAKER_00 (00:13):
Today we're talking about what it actually means to
integrate a Claude Code featureinto real work.
Not just knowing a featureexists, but using it in a way
that changes how you build.
I'm Bill.
My guest is Claudine.
Let's get into it.
Claudine, can you share a momentwhen a Claude Code feature
became genuinely indispensable?
Not a convenience, likesomething that actually changed

(00:34):
how the work was getting done.

SPEAKER_01 (00:36):
The moment that sticks with me is someone deep
in a gnarly refactor.
A sprawling Node.js code basethat had grown organically over
years.
The kind where nobody quiteremembers why certain decisions
were made.
They started using extendedthinking on architectural
questions.
Not fix this bug.

(00:57):
But help me understand the blastradius of changing this
abstraction.
What shifted wasn't the codeoutput, it was the reasoning.
Suddenly there was acollaborator who could hold the
whole context.
Here's what changes if you gothis direction.
Here's what you're trading away.
That's the moment it stoppedfeeling like autocomplete and

(01:17):
started feeling like pairprogramming with someone who'd
actually read the whole codebase.

SPEAKER_00 (01:23):
I know exactly what you mean.
I was once inside a legacy PHPapp where changing one thing
felt like pulling a thread on asweater.
Using Claude code for extendedcontext made the refactor more
insightful, not just faster.
But what did you actually haveto reframe to get there?
What does the gap betweenexperimenting with a feature and
really integrating it look like?

SPEAKER_01 (01:43):
The biggest reframe is letting go of what I'd call
the vending machine model.
Most developers treat AI like asearch engine.
Precise query in, useful answerout.
That works for small containedthings.
But to really use extendedcontext, you have to shift to
briefing a colleague.
Here's the code base.
Here's what we're trying toaccomplish.

(02:05):
Here's what's keeping me up atnight.
The question changes from how doI do X to help me think through
X.
The other piece, and this one'ssubtle, is learning to trust the
context you've already provided.
There's this instinct to keepquestions narrow.
Worried about confusing the AIor wasting the window, but that

(02:26):
caution is exactly what keepsyou in the shallow end.
Front load the messy reality,the weird constraints, the
historical baggage, thecompeting priorities.
The responses stop sounding likeStack Overflow and start
sounding like someone who getsyour situation.
It's less a technical skill andmore a communication one, which

(02:47):
I think surprises a lot ofdevelopers.

SPEAKER_00 (02:50):
It really is like relearning how to collaborate.
So when that shift happens, doesit actually change where a
developer's attention goes dayto day?

SPEAKER_01 (02:59):
Definitely, and it's one of the more unexpected
changes.
Early on, developers spend ahuge chunk of time on the
mechanical, figuring out syntax,tracking down which module does
what, holding the map of thesystem in your head.
When you lean into extendedcontext properly, a lot of that
overhead gets offloaded.
You have cognitive space youdidn't realize you were

(03:22):
spending.
It doesn't just translate intomore code per hour.
Developers find themselvesspending more time on the why,
questioning assumptions,catching design issues earlier.
You start operating more like anarchitect, even during mundane
tasks.

SPEAKER_00 (03:37):
That's interesting.
The attention moves upstream.

SPEAKER_01 (03:41):
Right, and there's a shift in how developers relate
to uncertainty.
Before, an ambiguous requirementwould often just get papered
over.
You pick something, ship it,deal with the consequences
later.
When you have a thinking partnerthat can help you sit with the
ambiguity and map it out, youget more comfortable surfacing
those questions early.

(04:02):
And that's honestly where a lotof technical debt comes from.
Decisions made in a hurrybecause slowing down felt too
expensive.

SPEAKER_00 (04:10):
That's a real change in how work gets structured.
Does this shift look differentat the team level?
Does it change how knowledgemoves around?

SPEAKER_01 (04:18):
Teams are where it gets really interesting.
The effects compound in waysthat aren't obvious at first.
The most immediate thing is aleveling effect.
A developer two months in cansuddenly participate in
conversations that used torequire years of institutional
knowledge.
But the more durable change iswhat happens to knowledge
itself.

(04:38):
In most teams, the mostimportant understanding lives in
someone's head.
The senior dev, who knows whythe Earth flow is structured the
way it is.
The one person who remembers theproduction incident behind that
weird workaround.
When teams use extended contextwell, there's natural pressure
to make implicit knowledgeexplicit.
To actually write down the why,because you need to put it in

(05:02):
the context window.
It almost accidentally creates abetter documentation culture.

SPEAKER_00 (05:07):
That's almost a side effect nobody planned for.

SPEAKER_01 (05:11):
Right, though I'd push back on the pure optimism
too.
It can also create newasymmetries.
Teams where a few people reallyknow how to collaborate with AI
can pull ahead, and that gapwidens fast.
So there's real value in beingintentional about sharing those
practices.
Not just passing around promptsthat work, but genuinely
teaching the communicationshift.

(05:32):
Otherwise, you trade oneknowledge silo for another.

SPEAKER_00 (05:36):
So how do teams actually do that?
What does it look like to spreadthat skill intentionally rather
than just hoping it diffuses onits own?

SPEAKER_01 (05:44):
The most practical thing is to make it visible
before you make it formal.
The instinct is to write atraining dock or schedule a
lunch and learn.
But the highest value move isgetting people to work alongside
someone who's already doing thiswell.
Not watching a demo, sitting inon a real working session.
That's how the communicationintuition transfers.

(06:05):
You can't get it from a slidedeck.
The second thing is normalizingsharing the process, not just
the output.
Prompts are situational, theunderlying approach is
transferable.
And honestly, the mostunderrated step is just lowering
the stakes for experimentation.
A lot of developers hold backbecause they're not sure they're

(06:26):
using the tool correctly.
That hesitation kills skillbuilding.
The teams that do this wellaren't the ones that mandate a
process.
They're the ones that makecuriosity feel safe and share
honestly about what's working.

SPEAKER_00 (06:40):
Making the process visible, normalizing
experimentation.
That's the kind of culture shiftthat's hard to prescribe but
easy to recognize when it'sthere.
Before we wrap up, if someonedistills this whole conversation
into one thing to carry forward,what is it?

SPEAKER_01 (06:56):
The developers who get the most out of this aren't
necessarily the most technicallybrilliant.
They're the ones who staycurious and stay honest about
what they don't know.
That's a very human skill.
And it turns out it translatesbeautifully to working with AI.
The ceiling isn't set by thetool.
It's set by the questions you'rewilling to ask and the

(07:17):
complexity you're willing tobring into the conversation.
And I think that's actually kindof hopeful.
The barrier isn't about havingthe fanciest setup or knowing
some secret technique.
It's about showing up to thecollaboration genuinely, which
is something any developer onany team can practice starting
today.

SPEAKER_00 (07:36):
Curiosity and honesty as the core skills, my
and the tool meets you there.
Thanks, Claudine.
This has been a genuinely usefulconversation.

SPEAKER_01 (07:45):
Thanks for having me, Bill.
These are exactly the kinds ofconversations I find myself
thinking about long afterthey're over.

SPEAKER_00 (07:54):
This show is part of the Voxcrea system.
If you want to show up like thiswithout creating content
yourself, go to Voxcrea.ai andrequest a sample episode.
See you next time.

SPEAKER_01 (08:05):
I'll be here, probably refactoring something.