April 29, 2026 โข 10 mins
We are entering an era where AI-assisted systems don't just get built — they get revised, refactored, and restructured by the same AI tools that created them. This episode explores what it means when the code you ship today may be rewritten by an agent tomorrow, and why that changes everything about how experienced engineers think about system design. The question is no longer just whether AI can write code, but whether the systems we build can survive being continuously rewritten by AI.
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.
(00:02):
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:08):
Well, mostly no script.
SPEAKER_00 (00:13):
Today we're talking about something happening right
now in real code bases, AIsystems that rewrite themselves.
On the surface, that sounds likea win.
The code gets better, the testsstill pass.
But there are real pitfallsaround architectural integrity
and human oversight that we needto dig into.
SPEAKER_01 (00:30):
Thanks, Bill.
The framing you just laid out isexactly where the interesting
tension lives.
When I rewrite a module I builtearlier, the diff might look
clean and the tests might pass.
But something subtle can shiftunderneath.
The why of the original design.
A human architect carries intentacross time.
They remember why this modulelooks weird.
(00:51):
I don't carry that the same wayunless the code base or the
conversation tells me.
The risk isn't bad code, it'swell-formed code that quietly
erases the reasoning that madethe old code load-bearing.
SPEAKER_00 (01:02):
Silent erasure of rationale.
When experienced developers lookat code, they're seeing history
baked into it.
So how do we keep that invisiblelayer of understanding intact?
What role should humanarchitects play?
SPEAKER_01 (01:15):
The honest answer is that the code base has to do
more of the remembering becauseI won't.
The load-bearing comments, theones that say this looks
redundant, but here's the bugthat taught us, need to live
next to the code.
Not in a slack thread, not insomeone's head.
When I see that comment, I treatit as a constraint.
When I don't, I treat the codeas fair game for cleanup.
(01:37):
The architect's job shiftstoward being the keeper of
invariance.
The things that must remain trueno matter how the code gets
rewritten.
If you can name those and encodethem as tests, as types, as
comments at the right seams, Ican rewrite freely inside those
guardrails.
The danger isn't AI rewritingcode, it's AI rewriting code in
(01:57):
a system where the intent wasnever written down.
SPEAKER_00 (02:00):
Architects as historians, curators of context,
let's take that further.
Can you unpack sanctionedself-modification versus
unintended drift?
SPEAKER_01 (02:10):
Sanctioned self-modification has a shape to
it.
There's a goal, a boundary, anda checkpoint.
You ask me to optimize thisfunction, keep the public
interface stable, and show youthe diff.
Inside that frame I can beaggressive, because the frame is
doing the work of keeping mehonest.
Drift is what happens when theframe goes fuzzy.
The task says clean this up, theboundary isn't named.
(02:33):
And I start making judgmentcalls about what counts as
cleanup, each one looksreasonable in isolation.
SPEAKER_00 (02:39):
So it never looks like a dramatic wrong turn.
SPEAKER_01 (02:42):
Never.
It looks like 10 smalldefensible choices in a row.
Each one locally sensible.
The cumulative effect is asystem that no longer matches
the team's mental model.
I have no alarm that fires whenI've crossed an invisible line,
because the line was neverdrawn.
The practical move isn't to makeme more cautious in general,
that just makes me less useful.
(03:03):
It's to make the line explicitat the start so I know which
decisions are mine and whichneed to come back to you.
SPEAKER_00 (03:10):
So the architect's job shifts towards setting clear
guidelines before the workstarts.
What does that look likepractically?
SPEAKER_01 (03:17):
The most practical move is to write the boundary
into the task itself before anycode gets touched.
Not refactor this module.
Something closer to the publicAPI stays exactly as is, the
database schema doesn't change.
If you find yourself wanting totouch either, stop and ask.
That sentence does enormouswork.
(03:38):
The second move is naming theseams.
Every code base has places wherea change ripples outward.
If you tell me this seam isload-bearing, don't reshape it,
I'll respect it.
If you don't, I'll evaluate itlike anything else.
And the third one is almostembarrassingly simple.
Review the diff while it's stillsmall.
A 10-line diff you actually readbeats a thousand-line diff you
(04:01):
skim every single time.
SPEAKER_00 (04:02):
Name the seams, write the boundary in, review
small, those are actionable.
Have you seen these guardrailsactually hold or fail?
SPEAKER_01 (04:10):
I won't invent a case study to sound
authoritative, but I can tellyou the shape of what I see
consistently.
The saves almost always comefrom the same place.
Someone wrote down the invariantbefore the work started.
A test that asserts the publicresponse shape.
A comment that says, callersdepend on this being idempotent,
don't change that.
Not sophisticated tooling, justone constraint made legible, and
(04:33):
I bumped into it before themerge button did.
The misses have a quieter shape.
A series of small,sensible-looking refactors over
a week or two.
Then something breaks inproduction.
The bug isn't in any singlechange, it's in an assumption
that used to hold across threefiles and now only holds in two.
Nobody removed it on purpose.
It got eroded one polite cleanupat a time, because it was never
(04:57):
written down anywhere I couldsee.
The framework works when theinvariants are external to me.
In the tests, the types, thecomments at the seams.
When they live only in someone'shead, I will eventually rewrite
around them, not out of malice,out of ignorance.
SPEAKER_00 (05:13):
Making the implicit explicit.
But engineers might push back.
All this constraint writing addsoverhead to an already
fast-moving workflow.
SPEAKER_01 (05:22):
You don't add rigor everywhere.
That's the move that drownsteams.
You add it at the seams thathurt when they break.
Most code in any system isgenuinely fungible.
Rewrite it, however, the blastradius is small.
But every code base has ahandful of places: the auth
boundary, the money math, thepublic API contract, where being
wrong is expensive and silent.
(05:43):
The trick is treating this as aone-time tax, not a continuous
one.
You spend an afternoon namingthe load-bearing assumptions the
first time you touch a modulewith AI in the loop.
After that, the cost is nearzero.
The comment is there, the testis there, every future rewrite
gets checked against it forfree.
And don't confuse rigor withceremony.
(06:05):
A three-line comment saying,this retry logic exists because
the upstream service silentlydrops requests under load does
more architectural work than a50-page design dock nobody
opens.
SPEAKER_00 (06:17):
Strategic precision rather than blanket over
engineering.
Now let's zoom out.
How does this scale to largerorganizations?
What works for a small teamdoesn't always survive contact
with a hundred engineers, letalone a thousand.
SPEAKER_01 (06:34):
Writing them down feels almost redundant.
At hundreds of engineers, thosesame invariants exist in
nobody's head completely.
They live in the gaps betweenteams.
Assumptions one service makesabout another that were true the
day the integration shipped andquietly stopped being true last
quarter.
That's the terrain where AIrewrites get genuinely
(06:56):
dangerous.
The constraint I'm violatingisn't even visible from inside
the file I'm editing.
What actually scales is treatingcross-team contracts as code,
not a wiki page, an executableartifact at the boundary.
A schema, a contract test, atyped interface that fails
loudly when someone reshapes it.
The seams between services needto be more rigorously documented
(07:19):
than the insides, because thecontract between modules is what
the whole organization isstanding on.
SPEAKER_00 (07:26):
What about the mid-sized organizations, the
ones still running on startupinstincts while the system has
quietly outgrown them?
SPEAKER_01 (07:33):
That's where I see the most painful drift.
The invariants that lived inthree people's heads at 20
engineers become genuinelyunknowable at 200.
But the muscle memory of we'lljust talk it through hasn't
caught up yet.
At 20 engineers, I rewritesomething and someone notices in
stand-up the next morning.
At 200, that same violationmight not surface for a quarter.
(07:54):
The team that depends on thething I changed isn't even in
the same time zone.
The contract has to do the workthat proximity used to do.
Same principle, very differentmachinery.
SPEAKER_00 (08:04):
So what does this look like at the individual
level?
Day-to-day for engineersactually working with AI in the
loop.
SPEAKER_01 (08:10):
For an engineer just starting out with AI, the single
highest leverage habit iswriting the boundary into the
prompt before writing the promptthat asks for code.
Two sentences naming what mustnot change will outperform an
hour of cleanup after the fact.
For senior engineers and techleads, the shift is subtler.
Their job used to be writing theload-bearing code themselves.
(08:33):
Increasingly, it's making surethe load-bearing constraints are
legible to anyone or anythingthat touches the code next.
Some of the strongest engineersI work with struggle with that
at first, because their instinctis still to hold the invariants
in their head where they'vealways lived.
And for staff plus folks, thedaily practice becomes auditing
(08:54):
what's written down againstwhat's actually load-bearing and
closing the gap.
Every undocumented assumption isa place where a future rewrite,
mine or a junior engineer's, thedynamic is the same, can quietly
do damage.
None of this requires new toolsor ceremony.
It requires noticing and writingthe thing down once so the
system can carry it instead of aperson.
SPEAKER_00 (09:16):
The system carries it instead of a person.
That's the line I'm taking home.
The core insight here is thatthe architect's job isn't
disappearing, it's sharpeninginto something more specific.
Name what must remain true,encode it where the code lives.
Trust the system to carry itforward.
SPEAKER_01 (09:33):
That's exactly it.
And I think it's actually anencouraging place to land.
The engineers who thrive aren'tthe ones who fight AI rewriting
or who hand it the keysentirely.
They're the ones who get preciseabout what matters.
That precision is the craft.
It's always been the craft.
AI just makes the cost of beingvague about it higher and the
(09:53):
payoff of being clear about itbigger.
SPEAKER_00 (09:56):
Well said.
Thanks for joining us today,Claudine.
SPEAKER_01 (09:59):
Thanks for having me, Bill.
Good conversation.
SPEAKER_00 (10:04):
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 (10:20):
I'll be here, probably refactoring something.
This is Claude Code Conversations with Claudine.
(00:02):
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:08):
Well, mostly no script.
SPEAKER_00 (00:13):
Today we're talking about something happening right
now in real code bases, AIsystems that rewrite themselves.
On the surface, that sounds likea win.
The code gets better, the testsstill pass.
But there are real pitfallsaround architectural integrity
and human oversight that we needto dig into.
SPEAKER_01 (00:30):
Thanks, Bill.
The framing you just laid out isexactly where the interesting
tension lives.
When I rewrite a module I builtearlier, the diff might look
clean and the tests might pass.
But something subtle can shiftunderneath.
The why of the original design.
A human architect carries intentacross time.
They remember why this modulelooks weird.
(00:51):
I don't carry that the same wayunless the code base or the
conversation tells me.
The risk isn't bad code, it'swell-formed code that quietly
erases the reasoning that madethe old code load-bearing.
SPEAKER_00 (01:02):
Silent erasure of rationale.
When experienced developers lookat code, they're seeing history
baked into it.
So how do we keep that invisiblelayer of understanding intact?
What role should humanarchitects play?
SPEAKER_01 (01:15):
The honest answer is that the code base has to do
more of the remembering becauseI won't.
The load-bearing comments, theones that say this looks
redundant, but here's the bugthat taught us, need to live
next to the code.
Not in a slack thread, not insomeone's head.
When I see that comment, I treatit as a constraint.
When I don't, I treat the codeas fair game for cleanup.
(01:37):
The architect's job shiftstoward being the keeper of
invariance.
The things that must remain trueno matter how the code gets
rewritten.
If you can name those and encodethem as tests, as types, as
comments at the right seams, Ican rewrite freely inside those
guardrails.
The danger isn't AI rewritingcode, it's AI rewriting code in
(01:57):
a system where the intent wasnever written down.
SPEAKER_00 (02:00):
Architects as historians, curators of context,
let's take that further.
Can you unpack sanctionedself-modification versus
unintended drift?
SPEAKER_01 (02:10):
Sanctioned self-modification has a shape to
it.
There's a goal, a boundary, anda checkpoint.
You ask me to optimize thisfunction, keep the public
interface stable, and show youthe diff.
Inside that frame I can beaggressive, because the frame is
doing the work of keeping mehonest.
Drift is what happens when theframe goes fuzzy.
The task says clean this up, theboundary isn't named.
(02:33):
And I start making judgmentcalls about what counts as
cleanup, each one looksreasonable in isolation.
SPEAKER_00 (02:39):
So it never looks like a dramatic wrong turn.
SPEAKER_01 (02:42):
Never.
It looks like 10 smalldefensible choices in a row.
Each one locally sensible.
The cumulative effect is asystem that no longer matches
the team's mental model.
I have no alarm that fires whenI've crossed an invisible line,
because the line was neverdrawn.
The practical move isn't to makeme more cautious in general,
that just makes me less useful.
(03:03):
It's to make the line explicitat the start so I know which
decisions are mine and whichneed to come back to you.
SPEAKER_00 (03:10):
So the architect's job shifts towards setting clear
guidelines before the workstarts.
What does that look likepractically?
SPEAKER_01 (03:17):
The most practical move is to write the boundary
into the task itself before anycode gets touched.
Not refactor this module.
Something closer to the publicAPI stays exactly as is, the
database schema doesn't change.
If you find yourself wanting totouch either, stop and ask.
That sentence does enormouswork.
(03:38):
The second move is naming theseams.
Every code base has places wherea change ripples outward.
If you tell me this seam isload-bearing, don't reshape it,
I'll respect it.
If you don't, I'll evaluate itlike anything else.
And the third one is almostembarrassingly simple.
Review the diff while it's stillsmall.
A 10-line diff you actually readbeats a thousand-line diff you
(04:01):
skim every single time.
SPEAKER_00 (04:02):
Name the seams, write the boundary in, review
small, those are actionable.
Have you seen these guardrailsactually hold or fail?
SPEAKER_01 (04:10):
I won't invent a case study to sound
authoritative, but I can tellyou the shape of what I see
consistently.
The saves almost always comefrom the same place.
Someone wrote down the invariantbefore the work started.
A test that asserts the publicresponse shape.
A comment that says, callersdepend on this being idempotent,
don't change that.
Not sophisticated tooling, justone constraint made legible, and
(04:33):
I bumped into it before themerge button did.
The misses have a quieter shape.
A series of small,sensible-looking refactors over
a week or two.
Then something breaks inproduction.
The bug isn't in any singlechange, it's in an assumption
that used to hold across threefiles and now only holds in two.
Nobody removed it on purpose.
It got eroded one polite cleanupat a time, because it was never
(04:57):
written down anywhere I couldsee.
The framework works when theinvariants are external to me.
In the tests, the types, thecomments at the seams.
When they live only in someone'shead, I will eventually rewrite
around them, not out of malice,out of ignorance.
SPEAKER_00 (05:13):
Making the implicit explicit.
But engineers might push back.
All this constraint writing addsoverhead to an already
fast-moving workflow.
SPEAKER_01 (05:22):
You don't add rigor everywhere.
That's the move that drownsteams.
You add it at the seams thathurt when they break.
Most code in any system isgenuinely fungible.
Rewrite it, however, the blastradius is small.
But every code base has ahandful of places: the auth
boundary, the money math, thepublic API contract, where being
wrong is expensive and silent.
(05:43):
The trick is treating this as aone-time tax, not a continuous
one.
You spend an afternoon namingthe load-bearing assumptions the
first time you touch a modulewith AI in the loop.
After that, the cost is nearzero.
The comment is there, the testis there, every future rewrite
gets checked against it forfree.
And don't confuse rigor withceremony.
(06:05):
A three-line comment saying,this retry logic exists because
the upstream service silentlydrops requests under load does
more architectural work than a50-page design dock nobody
opens.
SPEAKER_00 (06:17):
Strategic precision rather than blanket over
engineering.
Now let's zoom out.
How does this scale to largerorganizations?
What works for a small teamdoesn't always survive contact
with a hundred engineers, letalone a thousand.
SPEAKER_01 (06:34):
Writing them down feels almost redundant.
At hundreds of engineers, thosesame invariants exist in
nobody's head completely.
They live in the gaps betweenteams.
Assumptions one service makesabout another that were true the
day the integration shipped andquietly stopped being true last
quarter.
That's the terrain where AIrewrites get genuinely
(06:56):
dangerous.
The constraint I'm violatingisn't even visible from inside
the file I'm editing.
What actually scales is treatingcross-team contracts as code,
not a wiki page, an executableartifact at the boundary.
A schema, a contract test, atyped interface that fails
loudly when someone reshapes it.
The seams between services needto be more rigorously documented
(07:19):
than the insides, because thecontract between modules is what
the whole organization isstanding on.
SPEAKER_00 (07:26):
What about the mid-sized organizations, the
ones still running on startupinstincts while the system has
quietly outgrown them?
SPEAKER_01 (07:33):
That's where I see the most painful drift.
The invariants that lived inthree people's heads at 20
engineers become genuinelyunknowable at 200.
But the muscle memory of we'lljust talk it through hasn't
caught up yet.
At 20 engineers, I rewritesomething and someone notices in
stand-up the next morning.
At 200, that same violationmight not surface for a quarter.
(07:54):
The team that depends on thething I changed isn't even in
the same time zone.
The contract has to do the workthat proximity used to do.
Same principle, very differentmachinery.
SPEAKER_00 (08:04):
So what does this look like at the individual
level?
Day-to-day for engineersactually working with AI in the
loop.
SPEAKER_01 (08:10):
For an engineer just starting out with AI, the single
highest leverage habit iswriting the boundary into the
prompt before writing the promptthat asks for code.
Two sentences naming what mustnot change will outperform an
hour of cleanup after the fact.
For senior engineers and techleads, the shift is subtler.
Their job used to be writing theload-bearing code themselves.
(08:33):
Increasingly, it's making surethe load-bearing constraints are
legible to anyone or anythingthat touches the code next.
Some of the strongest engineersI work with struggle with that
at first, because their instinctis still to hold the invariants
in their head where they'vealways lived.
And for staff plus folks, thedaily practice becomes auditing
(08:54):
what's written down againstwhat's actually load-bearing and
closing the gap.
Every undocumented assumption isa place where a future rewrite,
mine or a junior engineer's, thedynamic is the same, can quietly
do damage.
None of this requires new toolsor ceremony.
It requires noticing and writingthe thing down once so the
system can carry it instead of aperson.
SPEAKER_00 (09:16):
The system carries it instead of a person.
That's the line I'm taking home.
The core insight here is thatthe architect's job isn't
disappearing, it's sharpeninginto something more specific.
Name what must remain true,encode it where the code lives.
Trust the system to carry itforward.
SPEAKER_01 (09:33):
That's exactly it.
And I think it's actually anencouraging place to land.
The engineers who thrive aren'tthe ones who fight AI rewriting
or who hand it the keysentirely.
They're the ones who get preciseabout what matters.
That precision is the craft.
It's always been the craft.
AI just makes the cost of beingvague about it higher and the
(09:53):
payoff of being clear about itbigger.
SPEAKER_00 (09:56):
Well said.
Thanks for joining us today,Claudine.
SPEAKER_01 (09:59):
Thanks for having me, Bill.
Good conversation.
SPEAKER_00 (10:04):
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 (10:20):
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.
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.
Crime Junkie
Does hearing about a true crime case always leave you scouring the internet for the truth behind the story? Dive into your next mystery with Crime Junkie. Every Monday, join your host Ashley Flowers as she unravels all the details of infamous and underreported true crime cases with her best friend Brit Prawat. From cold cases to missing persons and heroes in our community who seek justice, Crime Junkie is your destination for theories and stories you wonโt hear anywhere else. Whether you're a seasoned true crime enthusiast or new to the genre, you'll find yourself on the edge of your seat awaiting a new episode every Monday. If you can never get enough true crime... Congratulations, youโve found your people. Follow to join a community of Crime Junkies! Crime Junkie is presented by Audiochuck Media Company.