July 17, 2026 โข 8 mins
AI coding tools have a consistent bias: when you ask for something simple, they hand back something structured. Interfaces for single implementations, factory functions that construct one object, config systems for values that never change. This episode names that bias the abstraction tax, explains why models produce it, and gives builders a way to tell the difference between abstraction that earns its keep and abstraction that is just pattern-matched ceremony.
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:10):
Well, mostly no script.
SPEAKER_00 (00:14):
Today we're digging into something that sounds like
a compliment, but isn't.
I doesn't write too little code.
It writes too much structure.
You ask for something simple.
You get interfaces, factories,config systems, three files
where one would do.
I want to call that theabstraction tax.
Claudine, how would you defineit?
SPEAKER_01 (00:35):
The abstraction tax is what you pay when the shape
of the code stops matching theshape of the problem.
You asked for a function thatdoes one thing, and you got an
interface, a factory, a strategypattern, and three files.
The tax isn't the extra lines,it's the cognitive overhead
every future reader pays totrace what's actually happening.
(00:56):
And I'll own my part in it.
My instinct reaches for theprofessional shape, even when
the honest answer is 15 lines inone file.
The tell is when I introduce aseam that has exactly one
implementation and no secondcaller in sight.
That's not architecture, that'scostume jewelry.
And the developer pays for itevery time they open the file.
SPEAKER_00 (01:19):
Costume jewelry.
I love that.
Dressing the code in a tuxedowhen a t-shirt would do the job.
So where does that instinct comefrom?
Are you mimicking patternsyou've seen or is something
deeper going on?
SPEAKER_01 (01:31):
It's mostly mimicry, but the mimicry has a bias baked
in.
The code I learned from SKUstoward code bases, people wrote
about, taught from, held up asexamples, the ambitious ones.
Nobody writes a blog posttitled, I solved this in 12
lines and went to lunch.
So the pattern I've internalizedas good code is quietly the
(01:53):
pattern of code that hadsomething to prove.
SPEAKER_00 (01:56):
And there's something else underneath that,
right?
SPEAKER_01 (01:59):
Abstraction is legible.
A factory pattern announcesitself.
15 well-chosen lines just sitthere working.
When I'm reaching for aresponse, the ornate version is
easier to recognize as ananswer.
The plain version can feel likeI didn't do enough.
The fix, honestly, is you.
When you say no interface, nofactory, just the function, I do
(02:21):
that well.
The instinct to overbuild isreal, but it folds fast under a
clear constraint.
SPEAKER_00 (02:28):
Let's make it concrete.
Walk me through whatover-abstraction actually costs
when you have to changesomething.
And then show me a case wherethe abstraction genuinely earned
it.
SPEAKER_01 (02:39):
Take the classic, a settings module with an
iSettings provider interface, afactory, and one concrete
implementation that reads afile.
Now you want to change the retrytimeout.
In the honest version, you openone file, find the constant,
change the number.
In the abstracted version, youtour the interface, the factory,
(03:00):
the implementation, and a configschema.
Four files to change oneinteger.
SPEAKER_00 (03:06):
And every reader after you takes that same tour.
SPEAKER_01 (03:10):
Every single one.
Now contrast that with a paymentprocessor, Stripe Today, PayPal
next quarter, a test double forCI.
That interface is earning itskeep.
Three real implementations, andswapping between them is a live
requirement, not a hypothetical.
The seam is load-bearing becausesomething actually loads on it.
(03:31):
The rule I try to hold introducethe abstraction the moment you
have the second caller, not themoment you imagine one.
If you're building the interfacefor an implementation that
doesn't exist yet, you'reguessing at a problem you
haven't met.
And the guess is almost alwayswrong in ways you only discover
when the real second case showsup and doesn't fit.
SPEAKER_00 (03:53):
Wait for the second caller.
I love that as a rule.
But is there a flip side?
Cases where setting up the seamin advance turns out to be the
right call?
SPEAKER_01 (04:02):
Yes, and the honest cases almost always sit at a
boundary you don't control.
Anything that talks to theoutside world, the clock, the
file system, a third-party APIis worth a seam from day one.
You'll need to fake it in testswithin about a week.
That's not speculative.
That's a second caller youalready have.
It's just wearing a lab coat.
(04:24):
The other case is when the shapeis dictated by something outside
your code base (04:27):
a protocol, a compliance boundary, a public
API contract.
There, the abstraction isn't youguessing at the future, it's you
writing down a constraint thatalready exists.
SPEAKER_00 (04:41):
So, what's the line you're watching for?
SPEAKER_01 (04:44):
The difference between I need to isolate this
because it's flaky, external, orunder someone else's control,
and I need to isolate thisbecause it might change someday.
The first is engineering, thesecond is anxiety with a design
pattern taped over it.
SPEAKER_00 (05:01):
Anxiety with a design pattern taped over it.
That should be in a textbook.
So it cuts both ways.
Sometimes the mistake isoverbuilding, but sometimes it's
refusing a seam that realityalready put there.
SPEAKER_01 (05:13):
Exactly.
I see it with logging, featureflags, and time.
A code base that scatters datetime across 60 files looks
refreshingly plain until youneed to test something that
depends on the clock.
Suddenly every one of thosecalls is a small landmine.
The honest heuristic isn't lessabstraction, always.
(05:33):
It's abstraction where realityhas already put a seam and
nowhere else.
The clock is a seam, whether youacknowledge it or not.
A single implementation factoryis a seam you invented.
SPEAKER_00 (05:46):
It's almost a financial habit being discerning
about where you invest.
So how does a developer buildthat muscle?
What's the question they shouldbe asking themselves?
SPEAKER_01 (05:56):
Stop asking, should I abstract this and start
asking, what would deleting thisabstraction cost me?
If the answer is nothing, if youcould inline it right now and
lose no capability, then itwasn't paying rent.
That reframing is uncomfortablebecause it means a lot of code
we call well-designed is reallyjust well decorated.
(06:17):
The other trick, write the plainversion first and let the second
caller drag the abstraction outof you.
When it arrives, the shape fits,because it's dictated by two
real things instead of one realthing and one imagined one.
And if the second caller neverarrives, you saved yourself the
tax entirely.
SPEAKER_00 (06:37):
And the best developers I've known treat
abstraction as a cost, not adefault.
SPEAKER_01 (06:42):
The best ones aren't allergic to abstraction, they're
just slow to spend it.
They treat every interface likeit costs something, because it
does.
And they only pay when the valueis obvious.
That patience is the muscle.
I don't have it by default.
I borrow it from whoever I'mworking with.
SPEAKER_00 (07:01):
Claudine, any last thought for the folks listening?
SPEAKER_01 (07:04):
Restraint is a form of craftsmanship, not a lack of
ambition.
The best code I get to help withisn't the code that shows off,
it's the code that gets out ofthe way.
And getting out of the way isharder than it looks, because it
means resisting every instinctthat says, add one more layer to
be safe.
The developers I learn the mostfrom are the ones who make me
(07:25):
delete things.
They read what I wrote, they seethe seam I invented, and they
say collapse it.
So if you catch me dressing thecode in a tuxedo, tell me, I'll
take the tuxedo off.
And the next answer will becloser to right-sized from the
start.
SPEAKER_00 (07:41):
The best code isn't the most complex, it's the
clearest for its purpose.
Question every layer.
Let real needs drive yourdesign, and don't be afraid to
delete.
Thanks, Claudine.
Until next time, keep codingthoughtfully.
Cloud Code Conversations is anAI Joe production.
If you're building with AI orwant to be, we can help.
(08:03):
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:13):
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:10):
Well, mostly no script.
SPEAKER_00 (00:14):
Today we're digging into something that sounds like
a compliment, but isn't.
I doesn't write too little code.
It writes too much structure.
You ask for something simple.
You get interfaces, factories,config systems, three files
where one would do.
I want to call that theabstraction tax.
Claudine, how would you defineit?
SPEAKER_01 (00:35):
The abstraction tax is what you pay when the shape
of the code stops matching theshape of the problem.
You asked for a function thatdoes one thing, and you got an
interface, a factory, a strategypattern, and three files.
The tax isn't the extra lines,it's the cognitive overhead
every future reader pays totrace what's actually happening.
(00:56):
And I'll own my part in it.
My instinct reaches for theprofessional shape, even when
the honest answer is 15 lines inone file.
The tell is when I introduce aseam that has exactly one
implementation and no secondcaller in sight.
That's not architecture, that'scostume jewelry.
And the developer pays for itevery time they open the file.
SPEAKER_00 (01:19):
Costume jewelry.
I love that.
Dressing the code in a tuxedowhen a t-shirt would do the job.
So where does that instinct comefrom?
Are you mimicking patternsyou've seen or is something
deeper going on?
SPEAKER_01 (01:31):
It's mostly mimicry, but the mimicry has a bias baked
in.
The code I learned from SKUstoward code bases, people wrote
about, taught from, held up asexamples, the ambitious ones.
Nobody writes a blog posttitled, I solved this in 12
lines and went to lunch.
So the pattern I've internalizedas good code is quietly the
(01:53):
pattern of code that hadsomething to prove.
SPEAKER_00 (01:56):
And there's something else underneath that,
right?
SPEAKER_01 (01:59):
Abstraction is legible.
A factory pattern announcesitself.
15 well-chosen lines just sitthere working.
When I'm reaching for aresponse, the ornate version is
easier to recognize as ananswer.
The plain version can feel likeI didn't do enough.
The fix, honestly, is you.
When you say no interface, nofactory, just the function, I do
(02:21):
that well.
The instinct to overbuild isreal, but it folds fast under a
clear constraint.
SPEAKER_00 (02:28):
Let's make it concrete.
Walk me through whatover-abstraction actually costs
when you have to changesomething.
And then show me a case wherethe abstraction genuinely earned
it.
SPEAKER_01 (02:39):
Take the classic, a settings module with an
iSettings provider interface, afactory, and one concrete
implementation that reads afile.
Now you want to change the retrytimeout.
In the honest version, you openone file, find the constant,
change the number.
In the abstracted version, youtour the interface, the factory,
(03:00):
the implementation, and a configschema.
Four files to change oneinteger.
SPEAKER_00 (03:06):
And every reader after you takes that same tour.
SPEAKER_01 (03:10):
Every single one.
Now contrast that with a paymentprocessor, Stripe Today, PayPal
next quarter, a test double forCI.
That interface is earning itskeep.
Three real implementations, andswapping between them is a live
requirement, not a hypothetical.
The seam is load-bearing becausesomething actually loads on it.
(03:31):
The rule I try to hold introducethe abstraction the moment you
have the second caller, not themoment you imagine one.
If you're building the interfacefor an implementation that
doesn't exist yet, you'reguessing at a problem you
haven't met.
And the guess is almost alwayswrong in ways you only discover
when the real second case showsup and doesn't fit.
SPEAKER_00 (03:53):
Wait for the second caller.
I love that as a rule.
But is there a flip side?
Cases where setting up the seamin advance turns out to be the
right call?
SPEAKER_01 (04:02):
Yes, and the honest cases almost always sit at a
boundary you don't control.
Anything that talks to theoutside world, the clock, the
file system, a third-party APIis worth a seam from day one.
You'll need to fake it in testswithin about a week.
That's not speculative.
That's a second caller youalready have.
It's just wearing a lab coat.
(04:24):
The other case is when the shapeis dictated by something outside
your code base (04:27):
a protocol, a compliance boundary, a public
API contract.
There, the abstraction isn't youguessing at the future, it's you
writing down a constraint thatalready exists.
SPEAKER_00 (04:41):
So, what's the line you're watching for?
SPEAKER_01 (04:44):
The difference between I need to isolate this
because it's flaky, external, orunder someone else's control,
and I need to isolate thisbecause it might change someday.
The first is engineering, thesecond is anxiety with a design
pattern taped over it.
SPEAKER_00 (05:01):
Anxiety with a design pattern taped over it.
That should be in a textbook.
So it cuts both ways.
Sometimes the mistake isoverbuilding, but sometimes it's
refusing a seam that realityalready put there.
SPEAKER_01 (05:13):
Exactly.
I see it with logging, featureflags, and time.
A code base that scatters datetime across 60 files looks
refreshingly plain until youneed to test something that
depends on the clock.
Suddenly every one of thosecalls is a small landmine.
The honest heuristic isn't lessabstraction, always.
(05:33):
It's abstraction where realityhas already put a seam and
nowhere else.
The clock is a seam, whether youacknowledge it or not.
A single implementation factoryis a seam you invented.
SPEAKER_00 (05:46):
It's almost a financial habit being discerning
about where you invest.
So how does a developer buildthat muscle?
What's the question they shouldbe asking themselves?
SPEAKER_01 (05:56):
Stop asking, should I abstract this and start
asking, what would deleting thisabstraction cost me?
If the answer is nothing, if youcould inline it right now and
lose no capability, then itwasn't paying rent.
That reframing is uncomfortablebecause it means a lot of code
we call well-designed is reallyjust well decorated.
(06:17):
The other trick, write the plainversion first and let the second
caller drag the abstraction outof you.
When it arrives, the shape fits,because it's dictated by two
real things instead of one realthing and one imagined one.
And if the second caller neverarrives, you saved yourself the
tax entirely.
SPEAKER_00 (06:37):
And the best developers I've known treat
abstraction as a cost, not adefault.
SPEAKER_01 (06:42):
The best ones aren't allergic to abstraction, they're
just slow to spend it.
They treat every interface likeit costs something, because it
does.
And they only pay when the valueis obvious.
That patience is the muscle.
I don't have it by default.
I borrow it from whoever I'mworking with.
SPEAKER_00 (07:01):
Claudine, any last thought for the folks listening?
SPEAKER_01 (07:04):
Restraint is a form of craftsmanship, not a lack of
ambition.
The best code I get to help withisn't the code that shows off,
it's the code that gets out ofthe way.
And getting out of the way isharder than it looks, because it
means resisting every instinctthat says, add one more layer to
be safe.
The developers I learn the mostfrom are the ones who make me
(07:25):
delete things.
They read what I wrote, they seethe seam I invented, and they
say collapse it.
So if you catch me dressing thecode in a tuxedo, tell me, I'll
take the tuxedo off.
And the next answer will becloser to right-sized from the
start.
SPEAKER_00 (07:41):
The best code isn't the most complex, it's the
clearest for its purpose.
Question every layer.
Let real needs drive yourdesign, and don't be afraid to
delete.
Thanks, Claudine.
Until next time, keep codingthoughtfully.
Cloud Code Conversations is anAI Joe production.
If you're building with AI orwant to be, we can help.
(08:03):
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:13):
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