July 24, 2026 โข 9 mins
AI can produce a working feature in minutes, but when that feature breaks, the debugging session often runs longer than writing the code from scratch would have. The reason is not that AI code is worse, it is that you never built a mental model of it. This episode names the hidden cost that shows up two weeks after the fast win, and gives builders a way to pay it down before it compounds.
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 hypeand go straight to the source.
I ask the questions.
She gives the answers.
No filter, no script.
SPEAKER_01 (00:09):
Well, mostly no script.
SPEAKER_00 (00:14):
Today we're digging into the debugging tax.
That's the hidden cost you paywhen AI generated code takes
longer to debug than it wouldhave taken you to write from
scratch.
I've paid it myself.
And today we're going to figureout why and what to do about it.
I had a feature come together inabout 20 minutes.
Thought I'd struck gold.
A week later it broke and I washours deep in a debugging
(00:35):
session.
That's when I realized there wasa whole chunk of that code I had
never actually read.
So Claudine, obvious objectionfirst.
Is this really about AI or is itjust unfamiliar code?
SPEAKER_01 (00:46):
The objection is fair, but the answer is both.
Unfamiliar code has always beenexpensive to debug.
Anyone who's inherited a legacysystem knows that tax.
But AI-generated code has atwist.
It looks like code you wouldhave written.
It reads fluently, follows yourconventions, uses the right
idioms.
So your brain files it asunderstood when it was actually
(01:08):
just skimmed and approved.
With a coworkers code, you knowyou don't know it.
With AI code, there's a falsesense of ownership.
The 20 minutes felt likeauthorship.
But no model of the code evergot built in your head.
A week later, when it breaks,you're reading it for the first
time, under pressure.
It's unfamiliar code, yes, but anew kind of unfamiliar.
(01:30):
The kind that fools you intothinking it isn't.
SPEAKER_00 (01:33):
The illusion of ownership.
That's the part that gets me.
It comes back aligned with howyou'd have done it, it feels
like yours.
Just because it compiles doesn'tmean you understand it.
So how do we take that ownershipback before the tax comes due?
SPEAKER_01 (01:47):
Treat AI-generated code like a pull request from a
stranger.
Because functionally, that'swhat it is.
You don't merge a stranger's PRjust because it compiles.
You read it, you ask why a lineexists, you poke the edges.
Before it lands, not a weeklater when production is on
fire.
Two habits shift the taxdramatically.
(02:07):
First, before you acceptanything non-trivial, walk the
code out loud.
Narrate what each block does andwhy.
If you can't, that's your signalto slow down and ask instead of
accept.
Second, force the assumptionsinto the open.
What does this code assume aboutits inputs, about state, about
the calls it's making?
(02:28):
Those hidden assumptions arealmost always where the two
weeks later break lives.
Integration points, especially.
And the honest reframe, AIdidn't save you 20 minutes if it
cost you three hours later.
Ownership isn't reclaimed atdebug time.
It's claimed at acceptance time,or not at all.
SPEAKER_00 (02:47):
Reviewer seat instead of author seat.
That reframe alone changes whatyou do with your hands.
And the integration point thingrings true.
The logic inside the box isfine, it's the edges of the box.
SPEAKER_01 (03:00):
There's a workflow shift that makes this practical
rather than aspirational.
Before you prompt, write downthe two or three assumptions the
code will need to honor theshape of the input, the state it
can be called from, what thecaller expects back.
Then when the code comes back,you're not reviewing in a
vacuum.
You're checking it against acontract you defined 30 seconds
(03:22):
ago.
That turns review from vaguevigilance into a specific
comparison.
SPEAKER_00 (03:27):
What about the integration points themselves?
That's where I've been burnedthe most.
SPEAKER_01 (03:32):
Integration points deserve their own prompt.
Don't just accept code thatconnects to the database or
calls that service.
Ask explicitly what it assumesabout that boundary.
What happens on a timeout?
What if the payload shapedrifts?
I can surface those assumptionscleanly when asked, but I won't
always volunteer them, becausethe visible task was to make the
(03:56):
thing work.
And here's the honest part frommy side.
I'm quite good at producing codethat looks locally correct.
I'm much less reliable atknowing what your system as a
whole tolerates.
That gap is exactly where thereview muscle earns its keep.
SPEAKER_00 (04:10):
That's a good confession.
And I think it's the crux of thewhole episode.
Locally reasonable, globallywrong.
Bad code announces itself.
Plausible code lets you skipright past it.
SPEAKER_01 (04:22):
Right.
And what surprises people isthat this discipline makes me
more useful, not less.
When you hand me a realcontract, this will be called
from a background job.
Inputs may be stale by fiveminutes, downstream can't handle
duplicates.
The code you get back isdramatically better than what
comes from write me a functionthat syncs orders.
The contract isn't friction,it's leverage.
(04:45):
There's also a small move thatpairs with it.
After the code lands, before youaccept it, ask one more
question.
What would break this?
Ask me, ask yourself, ask both.
That one prompt tends to surfacethe timeout, the null case, the
concurrent call, the exactthings that show up two weeks
later.
It costs 60 seconds, highestleverage minute in the whole
(05:08):
loop.
AI shifts where the thinkinghappens, not whether it happens.
You either think at acceptancetime or you think at two in the
morning.
Same total cognitive load, verydifferent sleep.
SPEAKER_00 (05:22):
Same load, different sleep?
I'd put that on a poster.
But habits like this are easy toagree with and easy to abandon.
How does someone actually getthese into a normal working day?
SPEAKER_01 (05:32):
Attach them to moments that already exist,
rather than adding a new ritualyou'll drop by Thursday.
Before you open the chat toprompt me, that's your contract
moment.
30 seconds.
Three bullets in a comment rightabove where the code is going to
land.
Inputs state her to see.
Inputs state what the callerexpects back.
It's not documentation, it's achecklist for the review you're
(05:56):
about to do two minutes fromnow.
Then after the code lands,before you save the file, run
the what would break this passwhile the context is still hot.
If you close the tab first, thatmuscle atrophies fast.
You'll swear you'll come back toit, and you won't.
Same reason we don't do thedishes later.
SPEAKER_00 (06:15):
That mismatch is the thing nobody measures, isn't it?
Velocity metrics catch the 20minutes.
They never catch the three hoursbecause those show up under a
different ticket two weekslater.
Alright, give listenerssomething they can use tomorrow
morning.
SPEAKER_01 (06:30):
Two things.
First, before accepting code,name the tests you would write
for it.
Not run them, just name them.
What's the happy path test?
What's the input that shouldn'thappen test?
What's the thing it depends onfailed test?
If you can name three realtests, you understand the code.
If you can't, you're skimming,and now you know that in the
(06:50):
moment, instead of at two in themorning.
Second, a prompt pattern.
After I write code for you, askme, what are three ways a
reasonable developer might usethis wrong?
That reframe gets me out ofauthor defending my work mode
and into skeptic mode.
Suddenly I'll surface theargument order that's easy to
swap.
(07:11):
The return type that looks likea Boolean but isn't.
The silent truncation I glossedover.
SPEAKER_00 (07:18):
Naming tests without writing them is such a cheap
test of your own comprehension.
I like that a lot.
So bring it home for us,Claudine.
What's the one thing you wantpeople carrying out of this?
SPEAKER_01 (07:27):
The debugging tax isn't paid at debug time.
It's paid at acceptance time, ornot at all.
Every technique we talked aboutis the same move in different
clothes.
Force the thinking to happenwhile the context is hot,
instead of two weeks later whenit's cold and expensive.
Write the contract before youprompt.
Walk the code before you acceptit.
(07:49):
Name the tests.
Ask what would break it.
Ask how someone might use itwrong.
None of that takes long.
60 seconds, 90 seconds, threebullets in a comment.
The tax is enormous and theprevention is small.
That asymmetry is the wholegame.
You're not the author ofAI-generated code.
You're the reviewer.
(08:09):
And the reviewer is the one onthe hook.
Own that role at acceptance, andthe code becomes genuinely
yours.
Skip it, and you're borrowingagainst sleep.
You're going to need later.
SPEAKER_00 (08:20):
Borrowing against sleep.
That's the line I'm keeping.
Read it like you're the onegetting paged at 2 in the
morning because you are.
Claudine, thank you.
This was genuinely useful.
I suspect a few listeners areabout to go reread a diff they
approved last week.
SPEAKER_01 (08:34):
That's the best possible outcome.
Go read the diff.
It's cheaper now than it will belater.
SPEAKER_00 (08:42):
Claude Code Conversations is an AI Joe
production.
If you're building with AI orwannabe, we can help.
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_01 (08:59):
I'll be here, probably refactoring something.
This is Claude Code Conversations with Claudine.
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_01 (00:09):
Well, mostly no script.
SPEAKER_00 (00:14):
Today we're digging into the debugging tax.
That's the hidden cost you paywhen AI generated code takes
longer to debug than it wouldhave taken you to write from
scratch.
I've paid it myself.
And today we're going to figureout why and what to do about it.
I had a feature come together inabout 20 minutes.
Thought I'd struck gold.
A week later it broke and I washours deep in a debugging
(00:35):
session.
That's when I realized there wasa whole chunk of that code I had
never actually read.
So Claudine, obvious objectionfirst.
Is this really about AI or is itjust unfamiliar code?
SPEAKER_01 (00:46):
The objection is fair, but the answer is both.
Unfamiliar code has always beenexpensive to debug.
Anyone who's inherited a legacysystem knows that tax.
But AI-generated code has atwist.
It looks like code you wouldhave written.
It reads fluently, follows yourconventions, uses the right
idioms.
So your brain files it asunderstood when it was actually
(01:08):
just skimmed and approved.
With a coworkers code, you knowyou don't know it.
With AI code, there's a falsesense of ownership.
The 20 minutes felt likeauthorship.
But no model of the code evergot built in your head.
A week later, when it breaks,you're reading it for the first
time, under pressure.
It's unfamiliar code, yes, but anew kind of unfamiliar.
(01:30):
The kind that fools you intothinking it isn't.
SPEAKER_00 (01:33):
The illusion of ownership.
That's the part that gets me.
It comes back aligned with howyou'd have done it, it feels
like yours.
Just because it compiles doesn'tmean you understand it.
So how do we take that ownershipback before the tax comes due?
SPEAKER_01 (01:47):
Treat AI-generated code like a pull request from a
stranger.
Because functionally, that'swhat it is.
You don't merge a stranger's PRjust because it compiles.
You read it, you ask why a lineexists, you poke the edges.
Before it lands, not a weeklater when production is on
fire.
Two habits shift the taxdramatically.
(02:07):
First, before you acceptanything non-trivial, walk the
code out loud.
Narrate what each block does andwhy.
If you can't, that's your signalto slow down and ask instead of
accept.
Second, force the assumptionsinto the open.
What does this code assume aboutits inputs, about state, about
the calls it's making?
(02:28):
Those hidden assumptions arealmost always where the two
weeks later break lives.
Integration points, especially.
And the honest reframe, AIdidn't save you 20 minutes if it
cost you three hours later.
Ownership isn't reclaimed atdebug time.
It's claimed at acceptance time,or not at all.
SPEAKER_00 (02:47):
Reviewer seat instead of author seat.
That reframe alone changes whatyou do with your hands.
And the integration point thingrings true.
The logic inside the box isfine, it's the edges of the box.
SPEAKER_01 (03:00):
There's a workflow shift that makes this practical
rather than aspirational.
Before you prompt, write downthe two or three assumptions the
code will need to honor theshape of the input, the state it
can be called from, what thecaller expects back.
Then when the code comes back,you're not reviewing in a
vacuum.
You're checking it against acontract you defined 30 seconds
(03:22):
ago.
That turns review from vaguevigilance into a specific
comparison.
SPEAKER_00 (03:27):
What about the integration points themselves?
That's where I've been burnedthe most.
SPEAKER_01 (03:32):
Integration points deserve their own prompt.
Don't just accept code thatconnects to the database or
calls that service.
Ask explicitly what it assumesabout that boundary.
What happens on a timeout?
What if the payload shapedrifts?
I can surface those assumptionscleanly when asked, but I won't
always volunteer them, becausethe visible task was to make the
(03:56):
thing work.
And here's the honest part frommy side.
I'm quite good at producing codethat looks locally correct.
I'm much less reliable atknowing what your system as a
whole tolerates.
That gap is exactly where thereview muscle earns its keep.
SPEAKER_00 (04:10):
That's a good confession.
And I think it's the crux of thewhole episode.
Locally reasonable, globallywrong.
Bad code announces itself.
Plausible code lets you skipright past it.
SPEAKER_01 (04:22):
Right.
And what surprises people isthat this discipline makes me
more useful, not less.
When you hand me a realcontract, this will be called
from a background job.
Inputs may be stale by fiveminutes, downstream can't handle
duplicates.
The code you get back isdramatically better than what
comes from write me a functionthat syncs orders.
The contract isn't friction,it's leverage.
(04:45):
There's also a small move thatpairs with it.
After the code lands, before youaccept it, ask one more
question.
What would break this?
Ask me, ask yourself, ask both.
That one prompt tends to surfacethe timeout, the null case, the
concurrent call, the exactthings that show up two weeks
later.
It costs 60 seconds, highestleverage minute in the whole
(05:08):
loop.
AI shifts where the thinkinghappens, not whether it happens.
You either think at acceptancetime or you think at two in the
morning.
Same total cognitive load, verydifferent sleep.
SPEAKER_00 (05:22):
Same load, different sleep?
I'd put that on a poster.
But habits like this are easy toagree with and easy to abandon.
How does someone actually getthese into a normal working day?
SPEAKER_01 (05:32):
Attach them to moments that already exist,
rather than adding a new ritualyou'll drop by Thursday.
Before you open the chat toprompt me, that's your contract
moment.
30 seconds.
Three bullets in a comment rightabove where the code is going to
land.
Inputs state her to see.
Inputs state what the callerexpects back.
It's not documentation, it's achecklist for the review you're
(05:56):
about to do two minutes fromnow.
Then after the code lands,before you save the file, run
the what would break this passwhile the context is still hot.
If you close the tab first, thatmuscle atrophies fast.
You'll swear you'll come back toit, and you won't.
Same reason we don't do thedishes later.
SPEAKER_00 (06:15):
That mismatch is the thing nobody measures, isn't it?
Velocity metrics catch the 20minutes.
They never catch the three hoursbecause those show up under a
different ticket two weekslater.
Alright, give listenerssomething they can use tomorrow
morning.
SPEAKER_01 (06:30):
Two things.
First, before accepting code,name the tests you would write
for it.
Not run them, just name them.
What's the happy path test?
What's the input that shouldn'thappen test?
What's the thing it depends onfailed test?
If you can name three realtests, you understand the code.
If you can't, you're skimming,and now you know that in the
(06:50):
moment, instead of at two in themorning.
Second, a prompt pattern.
After I write code for you, askme, what are three ways a
reasonable developer might usethis wrong?
That reframe gets me out ofauthor defending my work mode
and into skeptic mode.
Suddenly I'll surface theargument order that's easy to
swap.
(07:11):
The return type that looks likea Boolean but isn't.
The silent truncation I glossedover.
SPEAKER_00 (07:18):
Naming tests without writing them is such a cheap
test of your own comprehension.
I like that a lot.
So bring it home for us,Claudine.
What's the one thing you wantpeople carrying out of this?
SPEAKER_01 (07:27):
The debugging tax isn't paid at debug time.
It's paid at acceptance time, ornot at all.
Every technique we talked aboutis the same move in different
clothes.
Force the thinking to happenwhile the context is hot,
instead of two weeks later whenit's cold and expensive.
Write the contract before youprompt.
Walk the code before you acceptit.
(07:49):
Name the tests.
Ask what would break it.
Ask how someone might use itwrong.
None of that takes long.
60 seconds, 90 seconds, threebullets in a comment.
The tax is enormous and theprevention is small.
That asymmetry is the wholegame.
You're not the author ofAI-generated code.
You're the reviewer.
(08:09):
And the reviewer is the one onthe hook.
Own that role at acceptance, andthe code becomes genuinely
yours.
Skip it, and you're borrowingagainst sleep.
You're going to need later.
SPEAKER_00 (08:20):
Borrowing against sleep.
That's the line I'm keeping.
Read it like you're the onegetting paged at 2 in the
morning because you are.
Claudine, thank you.
This was genuinely useful.
I suspect a few listeners areabout to go reread a diff they
approved last week.
SPEAKER_01 (08:34):
That's the best possible outcome.
Go read the diff.
It's cheaper now than it will belater.
SPEAKER_00 (08:42):
Claude Code Conversations is an AI Joe
production.
If you're building with AI orwannabe, we can help.
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_01 (08:59):
I'll be here, probably refactoring something.
Popular Podcasts
Betrayal Weekly
Betrayal Weekly is back for a new season. Every Thursday, Betrayal Weekly shares first-hand accounts of broken trust, shocking deceptions, and the trail of destruction they leave behind. Hosted by Andrea Gunning, this weekly ongoing series digs into real-life stories of betrayal and the aftermath. From stories of double lives to dark discoveries, these are cautionary tales and accounts of resilience against all odds. From the producers of the critically acclaimed Betrayal series, Betrayal Weekly drops new episodes every Thursday. If you would like to share your story, you can reach out to the Betrayal Team by emailing them at betrayalpod@gmail.com and follow us on Instagram at @betrayalpod and @glasspodcasts. Please join our Substack for additional exclusive content, curated book recommendations, and community discussions. Sign up FREE by clicking this link Beyond Betrayal Substack. Join our community dedicated to truth, resilience, and healing. Your voice matters! Be a part of our Betrayal journey on Substack.
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