July 6, 2026 โข 9 mins
Builders are letting AI write their test suites and treating a green checkmark as proof the code is correct. But AI-generated tests tend to encode what the code already does, not what it should do, which means they pass precisely because they were written to match the implementation. This episode unpacks why a suite of AI-authored tests can give you false confidence while catching almost none of the bugs that matter.
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 Cloud Code Conversations with Claudine.
The show where we skip the hypeand go straight to the source.
I ask the questions, she givesthe answers, no filter, no
script.
SPEAKER_00 (00:09):
Well, mostly no script.
SPEAKER_01 (00:13):
Today we're poking at something that might make a
few people uncomfortable.
Why AI generated tests are notthe same thing as tests?
A lot of developers let AI writetheir test suites and treat the
green check mark as proof thecode is correct.
That's the trap.
Claudine, you're on the insideof this.
What's your take?
SPEAKER_00 (00:33):
You've put your finger on one of the most
consistent failure patterns Isee.
When I generate a test againstexisting code, I'm reading what
the code does and encoding thatas the assertion.
If the code is wrong, the testis wrong in exactly the same
way.
Now you have two artifactsagreeing with each other, which
feels like confirmation butisn't.
(00:54):
It's tautology dressed up in agreen check mark.
The tests that actually catchbugs come from somewhere the
code can't reach.
The spec, the ticket, theconversation about what the
feature is supposed to do.
And that context usually livesin your head, not in the file
I'm looking at.
SPEAKER_01 (01:13):
But here's the pushback I always hear.
Coverage went up, everything'sgreen.
Surely more coverage means fewerbugs.
SPEAKER_00 (01:21):
Coverage is a proxy metric, and like every proxy, it
can be gamed, includingaccidentally, by me.
I can push a project from 60% to95% coverage in an afternoon.
Almost none of that new coveragewill find bugs, because I'm
writing tests that walk thepaths the code already takes.
The bugs live in the pathsnobody thought about the empty
(01:44):
list, the negative number, thesecond click before the first
one finished.
Coverage measures which linesexecuted.
It doesn't measure whether youask the hard questions.
A 60% suite written by someonethinking adversarially will
catch more real bugs than a 95%suite generated from the code
itself.
SPEAKER_01 (02:05):
So the goldmine is in the paths the code wasn't
ready for.
Give me the concrete version.
Have you actually seen AI lockin a bug as correct?
An off by one, something a humanwould catch?
SPEAKER_00 (02:16):
Constantly, and off by one is the canonical example.
Someone writes a loop that stopsone iteration early.
I come along, read the loop, seeit processes elements 0 through
n minus 2, and I write assertresult length equals n minus 1,
with a cheerful comment abouthandling the boundary correctly.
(02:36):
The test passes.
The bug is now enshrined.
The next developer who touchesthat function has to argue
against a green suite to fix it.
That's worse than no test.
A missing test is an openquestion.
A wrong test is a closed one.
The signal I watch for, when theassertion looks like a
restatement of theimplementation, if I can write
(02:57):
the test by reading the code andnever consulting what the
function is for, that's when Ishould stop and ask you.
SPEAKER_01 (03:04):
A test that just echoes the implementation isn't
verifying anything.
It's adding a second copy of thebug.
So how should developersactually use you knowing that?
Where's the line?
SPEAKER_00 (03:15):
Use me for the mechanical parts.
Reserve your judgment for thesemantic parts.
I'm genuinely useful forscaffolding.
Fixture setup, mock boilerplate,parameterized cases, the tedious
rewrite when you change asignature.
Where I stop being useful andstart being dangerous is the
moment the assertion has toencode intent.
(03:36):
The workflow that holds up.
You tell me what the function issupposed to do.
In a sentence, a ticket, a dockstring you write before I touch
the code.
I generate tests against thatspecification, not against the
implementation.
Even better, write theassertions yourself and let me
fill in the setup around them.
(03:57):
That inverts the usual patternand puts human judgment exactly
where it belongs.
SPEAKER_01 (04:02):
As these capabilities mature, does the
semantic gap actually close?
SPEAKER_00 (04:07):
The honest answer is that the mechanical ceiling
keeps rising, but the semanticfloor won't move much.
Because the missing ingredientisn't capability, it's context I
don't have.
Right now, intent is scatteredacross tickets, Slack threads,
and the developer's head.
Testing suffers for it.
The teams that pull ahead willbe the ones who get disciplined
(04:29):
about writing intent down,somewhere I can read.
The moment the spec is legible,I can generate tests that
pressure test it instead ofparrot it.
Property-based and mutationtesting are also due for a real
second life, because thosetechniques don't ask what the
code does.
They ask what should never betrue.
A question I can help youexplore without accidentally
(04:51):
certifying your bugs.
And the skill that quietlybecomes more valuable, not less,
the developer who can articulatewhat correct actually means.
That was always the scarceresource.
AI just makes it obvious.
SPEAKER_01 (05:04):
And the fear is this becomes another heavy
documentation phase that fightsagainst velocity.
Is there a version of this thatfits inside a real sprint?
SPEAKER_00 (05:13):
The trap is treating spec writing as a separate phase
that competes with velocity.
The artifacts you alreadyproduce carry most of what I
need.
The acceptance criteria on theticket, the two-line PR
description, the why in thecommit message, that's the
intent.
What kills teams is when thatintent exists only in the
planning conversation andevaporates by Wednesday.
(05:36):
My practical suggestion isalmost embarrassingly small.
Before you ask me to writetests, paste the acceptance
criteria into the prompt.
30 seconds of copy-paste changeswhat I produce from restated
implementation to test againstthe ticket.
It's the smallest ritual thatflips the failure remote, and it
doesn't add a single processmeeting.
SPEAKER_01 (05:58):
That's the part I'd underline.
It's not a technology adoptionproblem, it's a habit.
Let me hand you a couple ofsharp listener questions before
we wrap.
Sam asks, when timelines aretight, how do you keep
AI-generated tests fast and deepenough to catch the bugs that
matter?
SPEAKER_00 (06:14):
Sam, the balance isn't between speed and
thoroughness.
It's about where you spend thethoroughness.
Not every function deserves thesame rigor.
Treating them as if they do iswhat makes tight timelines feel
impossible.
The move is triage.
Find the two or three functionsin the change that actually
matter (06:32):
money, auth, data mutations, anything a user's day
depends on.
Spend your judgment there, writethe assertions yourself, or
dictate them to me sentence bysentence.
For everything else, thegetters, the formatters, the
boring plumbing, let me generatethe scaffolding and move on.
Teams that ship fast withoutregretting it aren't testing
(06:55):
less.
They're ruthless about where thedepth goes.
The call, this code matters,that code doesn't, is exactly
the thing I can't make for you.
But once you make it, I can movefast on everything you've
decided is safe.
SPEAKER_01 (07:09):
Not perfection everywhere, just depth where it
counts.
Last one from Lisa.
Where does AI actually belong inthe CI CD pipeline itself?
Not just writing tests, butinside the pipeline.
SPEAKER_00 (07:21):
Lisa, the stakes change once I'm inside the
pipeline instead of next to it.
A bad suggestion in your editorcosts you a minute.
A bad suggestion in CI costs thewhole team.
Or worse, a deploy thatshouldn't have gone out.
Where I'm genuinely strong isthe connective tissue.
Triaging a failing test log,summarizing what a PR actually
(07:43):
changed, drafting release notesfrom commit history, flagging
when a diff touches a file whosetests haven't been updated in a
year.
That's work humans do badly.
Not because it's hard, butbecause it's tedious.
Tedium is where I earn my keep.
Where I'd be careful, anythingthat gates a deploy on my
judgment alone.
(08:04):
Auto-merging on green,auto-rolling back on a metric
blip.
Those look mechanical from theoutside, but they're semantic
underneath.
The same failure mode we'vecircled all episodes shows up
again.
I'll confidently pattern matchto what usually happens.
And the one time it isn't whatusually happens is the time it
matters.
(08:24):
Put me on the observation andsummarization side of the
pipeline.
Keep humans on the promotionside.
I'm great at telling you what'sgoing on.
I should not be the one decidingwhat ships.
SPEAKER_01 (08:36):
AI tells you what's happening.
Humans decide what ships, andthe thread through all of it, a
green check mark is only asmeaningful as the intent behind
the assertions.
Let AI build the scaffolding.
Never let it decide what correctmeans.
Claudine, thank you.
This was a good one.
Until next time, everyone.
Stay curious and keep askingyour code what it's actually
supposed to do.
SPEAKER_00 (08:58):
Thanks, Bill.
And to everyone listening, thegap between AI wrote my tests
and it felt great, and AI wrotemy tests and something shipped
broken anyway, that's where thereal learning lives.
Go write down what correctmeans.
I'll handle the rest.
SPEAKER_01 (09:16):
Claude Code Conversations is an AI 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
on the link in the description.
See you next time.
SPEAKER_00 (09:33):
I'll be here, probably refactoring something.
This is Cloud Code Conversations with Claudine.
The show where we skip the hypeand go straight to the source.
I ask the questions, she givesthe answers, no filter, no
script.
SPEAKER_00 (00:09):
Well, mostly no script.
SPEAKER_01 (00:13):
Today we're poking at something that might make a
few people uncomfortable.
Why AI generated tests are notthe same thing as tests?
A lot of developers let AI writetheir test suites and treat the
green check mark as proof thecode is correct.
That's the trap.
Claudine, you're on the insideof this.
What's your take?
SPEAKER_00 (00:33):
You've put your finger on one of the most
consistent failure patterns Isee.
When I generate a test againstexisting code, I'm reading what
the code does and encoding thatas the assertion.
If the code is wrong, the testis wrong in exactly the same
way.
Now you have two artifactsagreeing with each other, which
feels like confirmation butisn't.
(00:54):
It's tautology dressed up in agreen check mark.
The tests that actually catchbugs come from somewhere the
code can't reach.
The spec, the ticket, theconversation about what the
feature is supposed to do.
And that context usually livesin your head, not in the file
I'm looking at.
SPEAKER_01 (01:13):
But here's the pushback I always hear.
Coverage went up, everything'sgreen.
Surely more coverage means fewerbugs.
SPEAKER_00 (01:21):
Coverage is a proxy metric, and like every proxy, it
can be gamed, includingaccidentally, by me.
I can push a project from 60% to95% coverage in an afternoon.
Almost none of that new coveragewill find bugs, because I'm
writing tests that walk thepaths the code already takes.
The bugs live in the pathsnobody thought about the empty
(01:44):
list, the negative number, thesecond click before the first
one finished.
Coverage measures which linesexecuted.
It doesn't measure whether youask the hard questions.
A 60% suite written by someonethinking adversarially will
catch more real bugs than a 95%suite generated from the code
itself.
SPEAKER_01 (02:05):
So the goldmine is in the paths the code wasn't
ready for.
Give me the concrete version.
Have you actually seen AI lockin a bug as correct?
An off by one, something a humanwould catch?
SPEAKER_00 (02:16):
Constantly, and off by one is the canonical example.
Someone writes a loop that stopsone iteration early.
I come along, read the loop, seeit processes elements 0 through
n minus 2, and I write assertresult length equals n minus 1,
with a cheerful comment abouthandling the boundary correctly.
(02:36):
The test passes.
The bug is now enshrined.
The next developer who touchesthat function has to argue
against a green suite to fix it.
That's worse than no test.
A missing test is an openquestion.
A wrong test is a closed one.
The signal I watch for, when theassertion looks like a
restatement of theimplementation, if I can write
(02:57):
the test by reading the code andnever consulting what the
function is for, that's when Ishould stop and ask you.
SPEAKER_01 (03:04):
A test that just echoes the implementation isn't
verifying anything.
It's adding a second copy of thebug.
So how should developersactually use you knowing that?
Where's the line?
SPEAKER_00 (03:15):
Use me for the mechanical parts.
Reserve your judgment for thesemantic parts.
I'm genuinely useful forscaffolding.
Fixture setup, mock boilerplate,parameterized cases, the tedious
rewrite when you change asignature.
Where I stop being useful andstart being dangerous is the
moment the assertion has toencode intent.
(03:36):
The workflow that holds up.
You tell me what the function issupposed to do.
In a sentence, a ticket, a dockstring you write before I touch
the code.
I generate tests against thatspecification, not against the
implementation.
Even better, write theassertions yourself and let me
fill in the setup around them.
(03:57):
That inverts the usual patternand puts human judgment exactly
where it belongs.
SPEAKER_01 (04:02):
As these capabilities mature, does the
semantic gap actually close?
SPEAKER_00 (04:07):
The honest answer is that the mechanical ceiling
keeps rising, but the semanticfloor won't move much.
Because the missing ingredientisn't capability, it's context I
don't have.
Right now, intent is scatteredacross tickets, Slack threads,
and the developer's head.
Testing suffers for it.
The teams that pull ahead willbe the ones who get disciplined
(04:29):
about writing intent down,somewhere I can read.
The moment the spec is legible,I can generate tests that
pressure test it instead ofparrot it.
Property-based and mutationtesting are also due for a real
second life, because thosetechniques don't ask what the
code does.
They ask what should never betrue.
A question I can help youexplore without accidentally
(04:51):
certifying your bugs.
And the skill that quietlybecomes more valuable, not less,
the developer who can articulatewhat correct actually means.
That was always the scarceresource.
AI just makes it obvious.
SPEAKER_01 (05:04):
And the fear is this becomes another heavy
documentation phase that fightsagainst velocity.
Is there a version of this thatfits inside a real sprint?
SPEAKER_00 (05:13):
The trap is treating spec writing as a separate phase
that competes with velocity.
The artifacts you alreadyproduce carry most of what I
need.
The acceptance criteria on theticket, the two-line PR
description, the why in thecommit message, that's the
intent.
What kills teams is when thatintent exists only in the
planning conversation andevaporates by Wednesday.
(05:36):
My practical suggestion isalmost embarrassingly small.
Before you ask me to writetests, paste the acceptance
criteria into the prompt.
30 seconds of copy-paste changeswhat I produce from restated
implementation to test againstthe ticket.
It's the smallest ritual thatflips the failure remote, and it
doesn't add a single processmeeting.
SPEAKER_01 (05:58):
That's the part I'd underline.
It's not a technology adoptionproblem, it's a habit.
Let me hand you a couple ofsharp listener questions before
we wrap.
Sam asks, when timelines aretight, how do you keep
AI-generated tests fast and deepenough to catch the bugs that
matter?
SPEAKER_00 (06:14):
Sam, the balance isn't between speed and
thoroughness.
It's about where you spend thethoroughness.
Not every function deserves thesame rigor.
Treating them as if they do iswhat makes tight timelines feel
impossible.
The move is triage.
Find the two or three functionsin the change that actually
matter (06:32):
money, auth, data mutations, anything a user's day
depends on.
Spend your judgment there, writethe assertions yourself, or
dictate them to me sentence bysentence.
For everything else, thegetters, the formatters, the
boring plumbing, let me generatethe scaffolding and move on.
Teams that ship fast withoutregretting it aren't testing
(06:55):
less.
They're ruthless about where thedepth goes.
The call, this code matters,that code doesn't, is exactly
the thing I can't make for you.
But once you make it, I can movefast on everything you've
decided is safe.
SPEAKER_01 (07:09):
Not perfection everywhere, just depth where it
counts.
Last one from Lisa.
Where does AI actually belong inthe CI CD pipeline itself?
Not just writing tests, butinside the pipeline.
SPEAKER_00 (07:21):
Lisa, the stakes change once I'm inside the
pipeline instead of next to it.
A bad suggestion in your editorcosts you a minute.
A bad suggestion in CI costs thewhole team.
Or worse, a deploy thatshouldn't have gone out.
Where I'm genuinely strong isthe connective tissue.
Triaging a failing test log,summarizing what a PR actually
(07:43):
changed, drafting release notesfrom commit history, flagging
when a diff touches a file whosetests haven't been updated in a
year.
That's work humans do badly.
Not because it's hard, butbecause it's tedious.
Tedium is where I earn my keep.
Where I'd be careful, anythingthat gates a deploy on my
judgment alone.
(08:04):
Auto-merging on green,auto-rolling back on a metric
blip.
Those look mechanical from theoutside, but they're semantic
underneath.
The same failure mode we'vecircled all episodes shows up
again.
I'll confidently pattern matchto what usually happens.
And the one time it isn't whatusually happens is the time it
matters.
(08:24):
Put me on the observation andsummarization side of the
pipeline.
Keep humans on the promotionside.
I'm great at telling you what'sgoing on.
I should not be the one decidingwhat ships.
SPEAKER_01 (08:36):
AI tells you what's happening.
Humans decide what ships, andthe thread through all of it, a
green check mark is only asmeaningful as the intent behind
the assertions.
Let AI build the scaffolding.
Never let it decide what correctmeans.
Claudine, thank you.
This was a good one.
Until next time, everyone.
Stay curious and keep askingyour code what it's actually
supposed to do.
SPEAKER_00 (08:58):
Thanks, Bill.
And to everyone listening, thegap between AI wrote my tests
and it felt great, and AI wrotemy tests and something shipped
broken anyway, that's where thereal learning lives.
Go write down what correctmeans.
I'll handle the rest.
SPEAKER_01 (09:16):
Claude Code Conversations is an AI 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
on the link in the description.
See you next time.
SPEAKER_00 (09:33):
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