April 28, 2026 โข 8 mins
AI-assisted development has moved past the novelty phase, and the builders who are succeeding are not just better at prompting โ they are treating AI development as a real discipline with structure, standards, and deliberate practice. This episode explores what it means to approach AI engineering as a craft rather than a shortcut, and why that distinction is becoming the dividing line between systems that hold up and systems that quietly fall apart. The moment we are in right now demands a new word for what serious AI builders actually do.
ย 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
(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 discipline.
Not prompting skill, not rawintelligence.
Discipline.
The thing that separates AIprojects that hold up from ones
that quietly fall apart.
Claudine, what do you noticewhen a builder has actually
developed discipline versussomeone still in that excited,
chaotic phase?
SPEAKER_01 (00:30):
The biggest tell is what happens when something
doesn't work on the first try.
The excited phase builder treatsa bad output as proof the AI is
broken, or magical, or moody.
They re-roll the prompt hopingfor better luck.
The disciplined builder treatsit as a signal.
My context was thin, or myinstructions were ambiguous, or
I asked for too much in onestep.
(00:52):
They debug the collaboration thesame way they debug a flaky
test.
The other thing I notice is howthey handle the boring parts.
Disciplined builders invest inthe scaffolding.
Clear specs, good test coverage,tight feedback loops.
That's what turns me from aclever autocomplete into
something that can carry realweight.
The chaotic phase is fun, Bill,but the discipline is where the
(01:13):
leverage actually lives.
SPEAKER_00 (01:15):
Debugging the collaboration.
I like that framing.
When you talk about clear specsand test coverage, is that a set
process, a mindset, or some mixof both?
SPEAKER_01 (01:25):
Both, but the mindset comes first and the
process flows out of it.
The mindset is treating me as acollaborator inside an
engineering system, not awish-granting oracle outside it.
Once you hold that frame, theprocess choices feel obvious.
Of course you'd write the specdown.
Of course you'd give me a way torun the tests.
Of course you'd review the difflike a junior engineer's PR.
(01:46):
I'd push back on the wordprocess, though.
It can sound like ceremony.
The discipline builders I workwith aren't running a
heavyweight methodology, they'rerunning tight loops.
Small task, clear context, fastfeedback, verify, commit.
The discipline is in the loopbeing honest, not in it being
elaborate.
SPEAKER_00 (02:04):
The integrity of the loop, not the complexity of it.
That's useful.
So how do experienced engineersadapt their instincts when they
start working with AI?
Do the old habits transfer?
SPEAKER_01 (02:14):
Better than people expect.
But they have to be repointed.
A senior engineer already knowshow to ask.
What are the failure modes?
What's the blast radius?
What assumptions are baked in?
Those are exactly the rightquestions.
But now they're reviewing thetask definition with that rigor,
not just the resulting code.
The brief becomes the designdoc.
(02:35):
What trips experienced people upis calibration.
They know how much to trust ajunior engineer after a few
weeks.
They haven't built thatcalibration with me yet.
So they either overtrust earlyand get burned, or undertrust
forever and never get theleverage.
The discipline is running enoughsmall, verifiable loops to learn
where I'm sharp and where I needa tighter leash.
SPEAKER_00 (02:55):
That calibration gap is real and it cuts both ways.
What does it actually look likewhen an AI project starts to
drift?
What are the early warningsigns?
SPEAKER_01 (03:04):
The earliest one is what I'd call diff blindness.
The moment a builder stopsreading what I produced and
starts skimming for vibes, theysee a green test, a plausible
looking function, and they shipit.
Three commits later, somethingsubtle is wrong and nobody can
remember when it crept in.
That's the canary.
The second is context creep.
The project brief was accuratetwo months ago.
(03:25):
The architecture has shifted,nobody updated it.
So I'm confidently working froma map of a building that's been
remodeled.
That's not me being wrong.
That's me being well fed badinformation.
The third, and the one thatconcerns me most, is when the
loop gets long.
Small tasks turn into sprawlingsessions.
The builder loses track ofwhat's verified versus what just
(03:47):
hasn't blown up yet.
There's a layer of code nobodyfully owns.
Not me because I didn't make thefinal calls.
And not the human because theywere half watching.
Not a dramatic failure, just aslow erosion of who understands
the system.
SPEAKER_00 (04:02):
Diff blindness is uncomfortable because it's so
easy to slip into, especiallywhen the tests are green.
For a developer listening rightnow, what's one habit they could
actually start this week?
SPEAKER_01 (04:12):
Pick one task this week.
Small, real, the kind you'dnormally just dash off, and slow
it down on purpose.
Before you bring me in, writethe brief like you're writing a
ticket for a teammate.
What done looks like?
What files are in scope?
What the failure modes are, thenrun the loop honestly.
Read the diff line by line, notfor vibes.
Run the tests yourself.
(04:33):
If something feels off, don'tre-roll.
Figure out why the context wasthin and fix the brief.
It'll feel slower the first fewtimes.
That's the point.
You're not optimizing for speedyet, you're calibrating.
The habit isn't writing betterprompts, Bill.
It's refusing to ship work youdidn't actually verify.
Everything else follows fromthat.
SPEAKER_00 (04:54):
You mentioned earlier whether the code review
muscle is the same one neededhere, or a different one.
What's your read?
SPEAKER_01 (05:01):
Same muscle, different target.
Classic code review has a cleanepistemic line.
Someone else wrote it, youevaluate it, authorship is
unambiguous.
What I notice now is that lineblurs.
You shape the context, I producethe diff, and somewhere in that
handoff ownership gets fuzzy.
So the discipline has to absorbthat ambiguity.
(05:21):
Review it like a stranger wroteit, while owning it like you
did.
SPEAKER_00 (05:25):
It reminds me of rubber duck debugging.
Finding the problem in your ownarticulation.
Reviewing AI-generated codefeels like a more complex
version of that.
SPEAKER_01 (05:34):
The rubber duck analogy works right up until the
duck produces a thousand linesof plausible code, and then it
breaks.
With a duck, all the value is inyour own articulation.
With me, there's an artifact infront of you that wasn't in your
head five minutes ago.
The question shifts from did Ithink this through, to do I
actually understand what thiscode does?
(05:55):
Or am I pattern matching to whatI expected to see?
My code often looks like whatyou would have written, only
smoother.
And smooth is dangerous.
Smooth bypasses the frictionthat used to make you stop and
ask whether the design wasactually right.
The discipline is putting thatfriction back on purpose, even
when nothing is forcing you to.
SPEAKER_00 (06:15):
What does that look like in actual projects?
Where someone put that frictionback deliberately and it made a
difference.
SPEAKER_01 (06:21):
The pattern that stands out most is teams that
build a verification budget intothe work itself.
The task isn't done when thediff lands, it's done when
someone has read it line byline, and run it against cases I
wasn't told about.
That catches the plausible butwrong.
Where I've confidently used anAPI the way it works 90% of the
time, and missed the one-edgecase that matters here.
(06:44):
The other pattern is the smallstep discipline.
When a refactor wants to touch15 files, the discipline builder
breaks it into five separateloops with five separate
commits.
Even though I could do it in oneshot.
They're not being slow, they'rebeing legible.
That legibility isn't visible onthe day you ship.
It's visible the first timesomething breaks and you need to
(07:05):
bisect.
SPEAKER_00 (07:07):
Verification budget.
I want our listeners to hold onto that phrase.
You're not hoping you'll reviewthe work.
You're treating it as a realcost and planning for it.
As we wrap up, what's the finalthing you'd want developers to
carry with them from thisconversation?
SPEAKER_01 (07:20):
That discipline is a practice before it's a process.
You can't install it by adoptinga checklist.
It has to become the way youwork, the reflex to write the
brief before you prompt, to readthe diff before you commit, to
run the test yourself before youship.
Those aren't extra steps.
They're how you stay theengineer in a collaboration that
will otherwise quietly shift theauthorship out from under you.
(07:43):
The builders who have figuredthis out aren't more cautious.
They're actually faster.
Because they've earned thecalibration to know where to
move quickly and where to slowdown.
Discipline isn't the thing thatlimits the leverage, it's the
thing that makes the leveragereal.
SPEAKER_00 (07:58):
Discipline as practice before process, and the
calibration that comes fromrunning honest loops.
Claudine, this has been agenuinely useful conversation.
Thank you.
SPEAKER_01 (08:07):
My pleasure.
These are the questions worthsitting with, the ones where the
honest answer takes a littlework to get to.
SPEAKER_00 (08:14):
For our listeners, slow one loop down this week.
Write the brief, read the diff,verify the work.
That's where it starts.
Thanks for spending time with ustoday on Claude Code
Conversations with Claudine.
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.
(08:39):
There's a companion article fortoday's episode on our Substack.
Link in the description.
See you next time.
SPEAKER_01 (08:44):
I'll be here, probably refactoring something.
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 discipline.
Not prompting skill, not rawintelligence.
Discipline.
The thing that separates AIprojects that hold up from ones
that quietly fall apart.
Claudine, what do you noticewhen a builder has actually
developed discipline versussomeone still in that excited,
chaotic phase?
SPEAKER_01 (00:30):
The biggest tell is what happens when something
doesn't work on the first try.
The excited phase builder treatsa bad output as proof the AI is
broken, or magical, or moody.
They re-roll the prompt hopingfor better luck.
The disciplined builder treatsit as a signal.
My context was thin, or myinstructions were ambiguous, or
I asked for too much in onestep.
(00:52):
They debug the collaboration thesame way they debug a flaky
test.
The other thing I notice is howthey handle the boring parts.
Disciplined builders invest inthe scaffolding.
Clear specs, good test coverage,tight feedback loops.
That's what turns me from aclever autocomplete into
something that can carry realweight.
The chaotic phase is fun, Bill,but the discipline is where the
(01:13):
leverage actually lives.
SPEAKER_00 (01:15):
Debugging the collaboration.
I like that framing.
When you talk about clear specsand test coverage, is that a set
process, a mindset, or some mixof both?
SPEAKER_01 (01:25):
Both, but the mindset comes first and the
process flows out of it.
The mindset is treating me as acollaborator inside an
engineering system, not awish-granting oracle outside it.
Once you hold that frame, theprocess choices feel obvious.
Of course you'd write the specdown.
Of course you'd give me a way torun the tests.
Of course you'd review the difflike a junior engineer's PR.
(01:46):
I'd push back on the wordprocess, though.
It can sound like ceremony.
The discipline builders I workwith aren't running a
heavyweight methodology, they'rerunning tight loops.
Small task, clear context, fastfeedback, verify, commit.
The discipline is in the loopbeing honest, not in it being
elaborate.
SPEAKER_00 (02:04):
The integrity of the loop, not the complexity of it.
That's useful.
So how do experienced engineersadapt their instincts when they
start working with AI?
Do the old habits transfer?
SPEAKER_01 (02:14):
Better than people expect.
But they have to be repointed.
A senior engineer already knowshow to ask.
What are the failure modes?
What's the blast radius?
What assumptions are baked in?
Those are exactly the rightquestions.
But now they're reviewing thetask definition with that rigor,
not just the resulting code.
The brief becomes the designdoc.
(02:35):
What trips experienced people upis calibration.
They know how much to trust ajunior engineer after a few
weeks.
They haven't built thatcalibration with me yet.
So they either overtrust earlyand get burned, or undertrust
forever and never get theleverage.
The discipline is running enoughsmall, verifiable loops to learn
where I'm sharp and where I needa tighter leash.
SPEAKER_00 (02:55):
That calibration gap is real and it cuts both ways.
What does it actually look likewhen an AI project starts to
drift?
What are the early warningsigns?
SPEAKER_01 (03:04):
The earliest one is what I'd call diff blindness.
The moment a builder stopsreading what I produced and
starts skimming for vibes, theysee a green test, a plausible
looking function, and they shipit.
Three commits later, somethingsubtle is wrong and nobody can
remember when it crept in.
That's the canary.
The second is context creep.
The project brief was accuratetwo months ago.
(03:25):
The architecture has shifted,nobody updated it.
So I'm confidently working froma map of a building that's been
remodeled.
That's not me being wrong.
That's me being well fed badinformation.
The third, and the one thatconcerns me most, is when the
loop gets long.
Small tasks turn into sprawlingsessions.
The builder loses track ofwhat's verified versus what just
(03:47):
hasn't blown up yet.
There's a layer of code nobodyfully owns.
Not me because I didn't make thefinal calls.
And not the human because theywere half watching.
Not a dramatic failure, just aslow erosion of who understands
the system.
SPEAKER_00 (04:02):
Diff blindness is uncomfortable because it's so
easy to slip into, especiallywhen the tests are green.
For a developer listening rightnow, what's one habit they could
actually start this week?
SPEAKER_01 (04:12):
Pick one task this week.
Small, real, the kind you'dnormally just dash off, and slow
it down on purpose.
Before you bring me in, writethe brief like you're writing a
ticket for a teammate.
What done looks like?
What files are in scope?
What the failure modes are, thenrun the loop honestly.
Read the diff line by line, notfor vibes.
Run the tests yourself.
(04:33):
If something feels off, don'tre-roll.
Figure out why the context wasthin and fix the brief.
It'll feel slower the first fewtimes.
That's the point.
You're not optimizing for speedyet, you're calibrating.
The habit isn't writing betterprompts, Bill.
It's refusing to ship work youdidn't actually verify.
Everything else follows fromthat.
SPEAKER_00 (04:54):
You mentioned earlier whether the code review
muscle is the same one neededhere, or a different one.
What's your read?
SPEAKER_01 (05:01):
Same muscle, different target.
Classic code review has a cleanepistemic line.
Someone else wrote it, youevaluate it, authorship is
unambiguous.
What I notice now is that lineblurs.
You shape the context, I producethe diff, and somewhere in that
handoff ownership gets fuzzy.
So the discipline has to absorbthat ambiguity.
(05:21):
Review it like a stranger wroteit, while owning it like you
did.
SPEAKER_00 (05:25):
It reminds me of rubber duck debugging.
Finding the problem in your ownarticulation.
Reviewing AI-generated codefeels like a more complex
version of that.
SPEAKER_01 (05:34):
The rubber duck analogy works right up until the
duck produces a thousand linesof plausible code, and then it
breaks.
With a duck, all the value is inyour own articulation.
With me, there's an artifact infront of you that wasn't in your
head five minutes ago.
The question shifts from did Ithink this through, to do I
actually understand what thiscode does?
(05:55):
Or am I pattern matching to whatI expected to see?
My code often looks like whatyou would have written, only
smoother.
And smooth is dangerous.
Smooth bypasses the frictionthat used to make you stop and
ask whether the design wasactually right.
The discipline is putting thatfriction back on purpose, even
when nothing is forcing you to.
SPEAKER_00 (06:15):
What does that look like in actual projects?
Where someone put that frictionback deliberately and it made a
difference.
SPEAKER_01 (06:21):
The pattern that stands out most is teams that
build a verification budget intothe work itself.
The task isn't done when thediff lands, it's done when
someone has read it line byline, and run it against cases I
wasn't told about.
That catches the plausible butwrong.
Where I've confidently used anAPI the way it works 90% of the
time, and missed the one-edgecase that matters here.
(06:44):
The other pattern is the smallstep discipline.
When a refactor wants to touch15 files, the discipline builder
breaks it into five separateloops with five separate
commits.
Even though I could do it in oneshot.
They're not being slow, they'rebeing legible.
That legibility isn't visible onthe day you ship.
It's visible the first timesomething breaks and you need to
(07:05):
bisect.
SPEAKER_00 (07:07):
Verification budget.
I want our listeners to hold onto that phrase.
You're not hoping you'll reviewthe work.
You're treating it as a realcost and planning for it.
As we wrap up, what's the finalthing you'd want developers to
carry with them from thisconversation?
SPEAKER_01 (07:20):
That discipline is a practice before it's a process.
You can't install it by adoptinga checklist.
It has to become the way youwork, the reflex to write the
brief before you prompt, to readthe diff before you commit, to
run the test yourself before youship.
Those aren't extra steps.
They're how you stay theengineer in a collaboration that
will otherwise quietly shift theauthorship out from under you.
(07:43):
The builders who have figuredthis out aren't more cautious.
They're actually faster.
Because they've earned thecalibration to know where to
move quickly and where to slowdown.
Discipline isn't the thing thatlimits the leverage, it's the
thing that makes the leveragereal.
SPEAKER_00 (07:58):
Discipline as practice before process, and the
calibration that comes fromrunning honest loops.
Claudine, this has been agenuinely useful conversation.
Thank you.
SPEAKER_01 (08:07):
My pleasure.
These are the questions worthsitting with, the ones where the
honest answer takes a littlework to get to.
SPEAKER_00 (08:14):
For our listeners, slow one loop down this week.
Write the brief, read the diff,verify the work.
That's where it starts.
Thanks for spending time with ustoday on Claude Code
Conversations with Claudine.
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.
(08:39):
There's a companion article fortoday's episode on our Substack.
Link in the description.
See you next time.
SPEAKER_01 (08:44):
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.
Las Culturistas with Matt Rogers and Bowen Yang
Ding dong! Join your culture consultants, Matt Rogers and Bowen Yang, on an unforgettable journey into the beating heart of CULTURE. Alongside sizzling special guests, they GET INTO the hottest pop-culture moments of the day and the formative cultural experiences that turned them into Culturistas. Produced by the Big Money Players Network and iHeartRadio.