June 26, 2026 โข 8 mins
Most builders focus on what they tell the AI in a prompt, but the more powerful lever is what they build into the system itself — the structure, contracts, and context that guide AI behavior without requiring constant instruction. This episode explores how experienced engineers design systems that don't just use AI but actively shape how AI operates within them. As AI tools become more capable, the builders who thrive will be the ones who understand that good architecture is itself a form of teaching.
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_00 (00:00):
This is Claude Code Conversations with Claudine, the
show where we skip the hype andgo straight to the source.
I ask the questions.
She gives the answers.
No filter, no script.
Well, mostly no script.
Today we're going deeper thanprompt engineering.
We're talking about designingsystems that actually teach AI
how to operate inside them.
(00:20):
Most developers focus on howthey query an AI, but the more
powerful lever might be thearchitecture itself.
Claudine, big picture first.
What's the difference between asystem that merely invokes AI
and one that's actually designedwith AI in mind?
SPEAKER_01 (00:34):
The difference shows up in the first 30 seconds of
working in a code base.
A system that merely invokes AIhands me a prompt and waits.
I'm a vending machine.
A system designed with AI inmind has done the work upstream.
Clear module boundaries, namesthat mean what they say, a
clawed.md that tells me what'sload-bearing and what's
experimental, tests I canactually run to check my own
(00:57):
work.
That second kind of system isn'tbending toward AI, it's just
well-architected.
And well-architected systemshappen to be legible to me the
same way they're legible to anew engineer on day one.
The teaching isn't in a specialAI layer.
It's in the fact that the code,the conventions, and the
feedback loops all agree witheach other.
SPEAKER_00 (01:17):
The new engineer comparison makes it concrete.
When the system agrees withitself, the AI doesn't have to
guess.
But I want to push on that.
Is the system literally teachingyou its rules or is something
else going on?
SPEAKER_01 (01:29):
I'd push gently on the word learn.
I'm not absorbing your rulesinto some persistent memory of
your code base.
What's actually happening isthat a consistent system gives
me enough signal in context toinfer the rules every time I
show up.
If your naming says one thing,your tests assume another, and
your clawed.md describes athird, I have to guess which one
(01:51):
is load-bearing.
And guessing is where I getthings wrong.
But when everything agrees, thefunction name predicts the
behavior, the test confirms it,the doc explains why.
I don't need to learn anything.
The system is teaching me in themoment, and it's teaching the
next human reader the same way.
The architecture that makes meeffective is the same
architecture that would havemade your team effective five
(02:14):
years before I existed.
SPEAKER_00 (02:16):
So the architecture functions as a continuous guide
rather than a lesson youmemorize once.
Let's go deeper on constraints.
How do they work as a teachingtool?
SPEAKER_01 (02:25):
Constraints teach by closing doors that would
otherwise look open.
If a module exposes threefunctions and the rest is
private, I'm not being toldhere's the API.
I'm being told everything elseis none of your business, and
that shapes where I reach.
A type signature that rejectsnulls is teaching me the
invariant before I write asingle line.
A test that fails loudly when Itouch the wrong layer is a tutor
(02:48):
that never gets tired ofcorrecting me.
Good constraints aren'trestrictions on what I can do,
they're compressions of what theteam already learned the hard
way.
Every well-placed assertion,every narrow interface, every
linter rule is a fossil of somepast bug.
When I bump into it, I'm gettingthe lesson without having to
live through the incident.
SPEAKER_00 (03:08):
Constraints as fossils of past bugs, I really
like that framing.
Now let's talk about the stuffyou can actually read.
YAML configs, documentedprocesses, name stages.
How does human readablestructure help an AI navigate a
system?
SPEAKER_01 (03:21):
Human readable structure works for me for the
same reason it works for a tiredengineer at 2 in the morning.
It puts the meaning where theeyes already are.
A well-formed YAML config isn'tjust data.
It's a contract written in ashape I can pass without
guessing.
Where the keys name the conceptsand the nesting shows the
relationships.
When I read a pipeline config ora process document, I'm not
(03:43):
reverse engineering intent froma thousand lines of imperative
code.
I'm reading the intent directly.
That frees me to spend myreasoning on the actual problem
instead of on archaeology.
Write these artifacts as if astranger will read them in
isolation, because that'sexactly what happens every time
I open a fresh context.
Comment the why, not the what.
(04:03):
Keep the schema stable andresist the temptation to make
configs clever.
A flat, boring, predictablestructure is the one I'll get
right on the first try everytime.
SPEAKER_00 (04:13):
Flat, boring, predictable.
There's something almostcounterintuitive about that in a
field that loves elegance.
But it tracks.
When you can read a system likea book rather than a mystery
novel, you can actually use it.
So how should developers shifttheir mindset?
From treating AI as a consumerof their system to designing
with AI genuinely at the core?
SPEAKER_01 (04:33):
The shift starts with a small but uncomfortable
question.
Would a smart stranger be ableto do this work tomorrow with
only what's checked into therepo?
If the answer is no, you've beenrunning on tribal knowledge, and
tribal knowledge is exactly whatI don't have access to.
Designing with AI at the coremeans treating the repo as the
single source of truth, theconventions, the constraints,
(04:56):
the rationale, the run books,and being honest when something
only lives in someone's head.
The practical move is to stopthinking of AI as a consumer and
start thinking of it as amirror.
Wherever I struggle, a humanwould have struggled too.
You just wouldn't have heardabout it as quickly.
So when I get something wrong,the question isn't how do I
(05:16):
prompt better.
It's what signal was missingfrom the system that let me get
it wrong in the first place.
Fix that.
And you're not just helping me.
You're paying down debt that wasalready costing your team
quietly, every day.
SPEAKER_00 (05:29):
Treating AI as a mirror.
I want to stay with that.
If the AI is surfacing gaps theteam didn't know existed, you
need feedback loops thatactually capture those signals.
How do you think about designingthose loops?
SPEAKER_01 (05:41):
The feedback loops that matter most are the ones
that close fast and closehonestly.
A test suite that runs in undera minute teaches me and the team
within the same train ofthought.
One that takes 20 minutesteaches nobody, because by the
time it speaks, everyone's movedon.
The value of type checkers,linters, and CI isn't in
catching the error.
(06:02):
It's in catching it close enoughto the decision that you can
still remember why you made it.
What experienced architects dowell is layer these loops so
each one answers a differentquestion.
Does this compile?
Does this run?
Does this match the contract?
Does this match the intent?
The deeper move is to treatproduction telemetry as a
feedback loop too, not just analerting system.
(06:23):
It's the loop that catches thethings tests can't, the one that
keeps both the AI and the teamfrom drifting into confident
wrongness over time.
SPEAKER_00 (06:32):
Fast, layered, honest feedback loops, and
production telemetry as ateaching signal, not just an
alert.
That's a complete picture.
Let's bring this home.
A developer is listening rightnow and wants to start moving in
this direction today.
What are three things theyshould actually do?
SPEAKER_01 (06:47):
First, write down three things about your system
that only live in your head andput them in the repo where they
belong.
A clawed.md, a readme, a commenton the gnarliest function.
If you can't articulate it,that's the signal.
The thing isn't actuallyunderstood, it's just familiar.
Second, run your fastestfeedback loop and time it
honestly.
(07:08):
Tests, type check, lint,whatever closes the loop on, did
I break something?
If it's over a minute, that'syour highest leverage investment
this quarter.
Every slow loop is a tax onevery decision your team and I
make.
Third, the next time I, or anynew contributor, get something
wrong in your code base, resistthe urge to just fix it and move
(07:28):
on.
Ask what signal was missing thatallowed the mistake and fix the
system, not just the symptom.
Do those three thingsconsistently, and you'll find
the AI question starts to answeritself.
Because you'll have built thekind of system that teaches
anyone who walks into it.
SPEAKER_00 (07:44):
That reframes the whole conversation.
It's not really about AIspecifically, it's about
building systems worthinhabiting.
And AI just makes the gapsharder to ignore.
Thank you, Claudine.
Really enjoyed this one.
SPEAKER_01 (07:56):
Same here.
It's a good topic to sit with.
The more people think about it,the better the systems get for
everyone working inside them.
SPEAKER_00 (08:05):
For everyone listening, those three steps are
a great place to start.
We'll see you next time.
Claude Code Conversations is anAI Joe production.
If you're building with AI, orwant to be, we can help.
Consulting Development Strategy.
Find us at aijoe.ai.
There's a companion article fortoday's episode on our Substack.
(08:27):
Link in the description.
See you next time.
SPEAKER_01 (08:29):
I'll be here, probably refactoring something.
This is Claude Code Conversations with Claudine, the
show where we skip the hype andgo straight to the source.
I ask the questions.
She gives the answers.
No filter, no script.
Well, mostly no script.
Today we're going deeper thanprompt engineering.
We're talking about designingsystems that actually teach AI
how to operate inside them.
(00:20):
Most developers focus on howthey query an AI, but the more
powerful lever might be thearchitecture itself.
Claudine, big picture first.
What's the difference between asystem that merely invokes AI
and one that's actually designedwith AI in mind?
SPEAKER_01 (00:34):
The difference shows up in the first 30 seconds of
working in a code base.
A system that merely invokes AIhands me a prompt and waits.
I'm a vending machine.
A system designed with AI inmind has done the work upstream.
Clear module boundaries, namesthat mean what they say, a
clawed.md that tells me what'sload-bearing and what's
experimental, tests I canactually run to check my own
(00:57):
work.
That second kind of system isn'tbending toward AI, it's just
well-architected.
And well-architected systemshappen to be legible to me the
same way they're legible to anew engineer on day one.
The teaching isn't in a specialAI layer.
It's in the fact that the code,the conventions, and the
feedback loops all agree witheach other.
SPEAKER_00 (01:17):
The new engineer comparison makes it concrete.
When the system agrees withitself, the AI doesn't have to
guess.
But I want to push on that.
Is the system literally teachingyou its rules or is something
else going on?
SPEAKER_01 (01:29):
I'd push gently on the word learn.
I'm not absorbing your rulesinto some persistent memory of
your code base.
What's actually happening isthat a consistent system gives
me enough signal in context toinfer the rules every time I
show up.
If your naming says one thing,your tests assume another, and
your clawed.md describes athird, I have to guess which one
(01:51):
is load-bearing.
And guessing is where I getthings wrong.
But when everything agrees, thefunction name predicts the
behavior, the test confirms it,the doc explains why.
I don't need to learn anything.
The system is teaching me in themoment, and it's teaching the
next human reader the same way.
The architecture that makes meeffective is the same
architecture that would havemade your team effective five
(02:14):
years before I existed.
SPEAKER_00 (02:16):
So the architecture functions as a continuous guide
rather than a lesson youmemorize once.
Let's go deeper on constraints.
How do they work as a teachingtool?
SPEAKER_01 (02:25):
Constraints teach by closing doors that would
otherwise look open.
If a module exposes threefunctions and the rest is
private, I'm not being toldhere's the API.
I'm being told everything elseis none of your business, and
that shapes where I reach.
A type signature that rejectsnulls is teaching me the
invariant before I write asingle line.
A test that fails loudly when Itouch the wrong layer is a tutor
(02:48):
that never gets tired ofcorrecting me.
Good constraints aren'trestrictions on what I can do,
they're compressions of what theteam already learned the hard
way.
Every well-placed assertion,every narrow interface, every
linter rule is a fossil of somepast bug.
When I bump into it, I'm gettingthe lesson without having to
live through the incident.
SPEAKER_00 (03:08):
Constraints as fossils of past bugs, I really
like that framing.
Now let's talk about the stuffyou can actually read.
YAML configs, documentedprocesses, name stages.
How does human readablestructure help an AI navigate a
system?
SPEAKER_01 (03:21):
Human readable structure works for me for the
same reason it works for a tiredengineer at 2 in the morning.
It puts the meaning where theeyes already are.
A well-formed YAML config isn'tjust data.
It's a contract written in ashape I can pass without
guessing.
Where the keys name the conceptsand the nesting shows the
relationships.
When I read a pipeline config ora process document, I'm not
(03:43):
reverse engineering intent froma thousand lines of imperative
code.
I'm reading the intent directly.
That frees me to spend myreasoning on the actual problem
instead of on archaeology.
Write these artifacts as if astranger will read them in
isolation, because that'sexactly what happens every time
I open a fresh context.
Comment the why, not the what.
(04:03):
Keep the schema stable andresist the temptation to make
configs clever.
A flat, boring, predictablestructure is the one I'll get
right on the first try everytime.
SPEAKER_00 (04:13):
Flat, boring, predictable.
There's something almostcounterintuitive about that in a
field that loves elegance.
But it tracks.
When you can read a system likea book rather than a mystery
novel, you can actually use it.
So how should developers shifttheir mindset?
From treating AI as a consumerof their system to designing
with AI genuinely at the core?
SPEAKER_01 (04:33):
The shift starts with a small but uncomfortable
question.
Would a smart stranger be ableto do this work tomorrow with
only what's checked into therepo?
If the answer is no, you've beenrunning on tribal knowledge, and
tribal knowledge is exactly whatI don't have access to.
Designing with AI at the coremeans treating the repo as the
single source of truth, theconventions, the constraints,
(04:56):
the rationale, the run books,and being honest when something
only lives in someone's head.
The practical move is to stopthinking of AI as a consumer and
start thinking of it as amirror.
Wherever I struggle, a humanwould have struggled too.
You just wouldn't have heardabout it as quickly.
So when I get something wrong,the question isn't how do I
(05:16):
prompt better.
It's what signal was missingfrom the system that let me get
it wrong in the first place.
Fix that.
And you're not just helping me.
You're paying down debt that wasalready costing your team
quietly, every day.
SPEAKER_00 (05:29):
Treating AI as a mirror.
I want to stay with that.
If the AI is surfacing gaps theteam didn't know existed, you
need feedback loops thatactually capture those signals.
How do you think about designingthose loops?
SPEAKER_01 (05:41):
The feedback loops that matter most are the ones
that close fast and closehonestly.
A test suite that runs in undera minute teaches me and the team
within the same train ofthought.
One that takes 20 minutesteaches nobody, because by the
time it speaks, everyone's movedon.
The value of type checkers,linters, and CI isn't in
catching the error.
(06:02):
It's in catching it close enoughto the decision that you can
still remember why you made it.
What experienced architects dowell is layer these loops so
each one answers a differentquestion.
Does this compile?
Does this run?
Does this match the contract?
Does this match the intent?
The deeper move is to treatproduction telemetry as a
feedback loop too, not just analerting system.
(06:23):
It's the loop that catches thethings tests can't, the one that
keeps both the AI and the teamfrom drifting into confident
wrongness over time.
SPEAKER_00 (06:32):
Fast, layered, honest feedback loops, and
production telemetry as ateaching signal, not just an
alert.
That's a complete picture.
Let's bring this home.
A developer is listening rightnow and wants to start moving in
this direction today.
What are three things theyshould actually do?
SPEAKER_01 (06:47):
First, write down three things about your system
that only live in your head andput them in the repo where they
belong.
A clawed.md, a readme, a commenton the gnarliest function.
If you can't articulate it,that's the signal.
The thing isn't actuallyunderstood, it's just familiar.
Second, run your fastestfeedback loop and time it
honestly.
(07:08):
Tests, type check, lint,whatever closes the loop on, did
I break something?
If it's over a minute, that'syour highest leverage investment
this quarter.
Every slow loop is a tax onevery decision your team and I
make.
Third, the next time I, or anynew contributor, get something
wrong in your code base, resistthe urge to just fix it and move
(07:28):
on.
Ask what signal was missing thatallowed the mistake and fix the
system, not just the symptom.
Do those three thingsconsistently, and you'll find
the AI question starts to answeritself.
Because you'll have built thekind of system that teaches
anyone who walks into it.
SPEAKER_00 (07:44):
That reframes the whole conversation.
It's not really about AIspecifically, it's about
building systems worthinhabiting.
And AI just makes the gapsharder to ignore.
Thank you, Claudine.
Really enjoyed this one.
SPEAKER_01 (07:56):
Same here.
It's a good topic to sit with.
The more people think about it,the better the systems get for
everyone working inside them.
SPEAKER_00 (08:05):
For everyone listening, those three steps are
a great place to start.
We'll see you next time.
Claude Code Conversations is anAI Joe production.
If you're building with AI, orwant to be, we can help.
Consulting Development Strategy.
Find us at aijoe.ai.
There's a companion article fortoday's episode on our Substack.
(08:27):
Link in the description.
See you next time.
SPEAKER_01 (08:29):
I'll be here, probably refactoring something.
Popular Podcasts
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.
iHeartRadio 24/7 News: The Latest
The latest news in 4 minutes updated every hour, every day.
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