Picture this. You're building a massive Lego
castle on your desk. Okay. It's got everything.
Drawbridges, towers, the works. It's your masterpiece.
I'm with you. But then halfway through, you realize
you need to build a Lego car. Right. But your
desk is full. So to build the car, you'd have
to, what, smash a turret? Or sweep the whole
castle into a bin just to clear some space. It
is the worst feeling. You lose all that momentum.
But what if you just buy second desk? And that's
it. That's the core of what we're talking about
today. In the real world, a new desk is expensive.
In software, it's surprisingly cheap. And yet
we're all still smashing our castles. We are.
Welcome to the deep dive. I've been thinking
a lot about how we interact with these AI tools.
We tend to treat them like fancy search engines.
Like a Q &A box? Exactly. When really the source
material argues we should be treating them like
junior partners. It's a total mental model shift.
I see so many developers get frustrated. They're
staring at code, waiting for the AI, copy -pasting,
getting errors, and they just say... This is
slower than me doing it myself. It's interesting
you say that, because today's guide argues that
if it feels slower, you're working linearly.
One thing at a time. And the fix, and this is
kind of the big theme today, is parallelism.
Right. Breaking out of that input weight output
loop. So let's go back to that second desk idea.
The guide talks about this productivity killer
called the waiting game. Oh, yeah. This is the
invisible time sack. You ask the AI for a function,
takes 30 seconds. You run a test suite, that
takes a minute. And in that gap. You check Slack.
You look at Twitter. You totally lose your train
of thought. It's the context switch that kills
you, not the weight itself. So the solution is
parallel work. For, you know, the command line
power users, the guide brings up Git work trees.
I've heard of these, but can you break down what
that actually is? Sure. Think of it like this.
Your project folder is your one desk. If you
want to switch from a bug to a feature, you have
to switch branches. And that changes all the
files. Their whole desk transforms. But with
WorkTrees, you can have the same project in two
different folders at the same time. So I'd have,
like, folder A for the login feature and folder
B for a database bug, and they're both open.
Precisely. You don't close one to open the other.
You have two desks. You push code to the AI on
desk one. And while it's thinking, you just swivel
over to desk two and keep working. OK. But what
if I'm not living in the terminal? What if I'm
just using the Claude web interface? Same principle.
Stop using one long chat for everything. Open
five tabs. And this part is crucial. Name them.
Name them what? Log and fix. Database logic.
Tab three can be stupid questions. Stupid questions?
Yeah. Everyone needs a safe space. That's where
you ask, wait, how does a switch statement work
again? You don't want that basic stuff cluttering
up your complex architecture discussion. But
doesn't that, I mean, doesn't splitting your
focus like that just create chaos? I feel like
my brain would just melt. It sounds chaotic,
I know, but it's actually cleaner for the AI.
You have to remember these models have a context
window. They can only remember so much. Right.
If you mix database queries and UI design and
CSS tweaks in one thread, the AI gets confused.
It starts making things up, splitting them, keeps
the AI's memory pure. So it keeps the AI's memory
distinct and manageable. Exactly. You're acting
less like a coder and more like a product manager
running a team of specialists. Being an orchestrator
means you need a plan, which brings us to the
next point, the architect mindset. The source
is pretty harsh here. It calls most of our prompts
vending machine prompts. Right. Make me a snake
game. Fix this bug. You put a coin in, you want
a product out. And then you get mad when the
code is messy? Of course. But you'd never tell
a human contractor, build me a house and just
walk away. You'd end up with a bathroom in the
kitchen. Exactly. So the fix is what they call
plan mode. Before you write a single line of
code, you open a new chat and you say, act as
a senior software architect. You ask for a blueprint,
a file structure, libraries, data schemas, security
risks, all of it. You're front loading the thinking,
but doesn't that just delay the actual building?
I want to see code. It delays the start, but
it massively accelerates the finish because changing
a text description is free. Changing 500 lines
of code because you chose the wrong database
library. That's really expensive. There's a tactic
in here I really liked getting a second opinion
on that plan. This is my favorite trick. So you
get the plan from chat A, then you copy it, open
a totally new chat B, and you say, hey, I'm thinking
of building this. critique it, tear it apart.
It's like an adversarial review. It is. The second
AI has zero attachment. It's fresh. It'll spot
things the first one best because it's not, you
know, high on its own supply. So why is that
planning phase so non -negotiable? Because entropy
is the default state of all code. Without a plan,
complexity just spirals. With a plan, you're
executing a checklist. Fixing text is cheap.
Fixing code is expensive. That's the bottom line.
OK, so we have our parallel desks. We have our
blueprints. But then you hit the wall of repetition.
Everyone's felt this. You start a new chat. You
have to remind the AI. I use Python. I like short
lines of code. Don't use this library. It's like
that movie 50 First Dates. Assistant amnesia.
It's a huge friction point. So the solution here
is a file called ClaudeEatE .md. How does a simple
text file fix amnesia? Well, most of these AI
coding tools can look at your project files now.
So if you create a file in your main folder called
Claude EMD... That's the start? Your tech stack?
Sure. But the real high leverage stuff is lessons
learned. Give me an example. Okay, let's say
you spend four hours on a bug where the attainment
gateway crashes if an address has a special character.
You fix it. Normally, that knowledge just lives
in your head. But with this system, you go to
clodee .md and you write, lesson. Payment API
fails on special characters. Always sanitize
input. And the next time I ask the AI to write
payment code. It reads that file first. It knows
not to make that mistake. And if it slips up,
you don't just fix the code. You actually scold
it. You say, you ignore the instructions. Update
clodee .md so you never do this again. So how
does this change your relationship with the tool?
It stops being a fresh chat every time and starts
kind of reading your mind. It accumulates wisdom.
It's moving from a blank slate to institutional
memory. Exactly. The AI becomes a colleague that's
been on the project as long as you have. Let's
move to automation. The guide mentions custom
skills or magic spells. This sounds pretty complex.
It's actually not. We all have these boring,
repetitive tasks. Check for unused variables,
summarize what the team did on Slack. The idea
is just to turn those into shortcuts. Like tech
death. Right. In a really sophisticated setup,
you can program a command like techdet to run
a script. But even if you're just in the web
chat, you can keep a text file on your desktop.
Call it myprompts .txt. So when I want a really
tough code review, I don't type out the whole
thing. I just copy paste my spell. You got it.
It just lowers the cognitive load. If asking
for a code review is a hassle, You're not going
to do it. If it's a quick copy paste away, you'll
do it every time. So is this just about typing
faster or is it something more? It's about reducing
that cognitive load. It turns these repetitive
chores into single word triggers. It lowers the
barrier to doing things the right way. Exactly.
Speaking of barriers, let's talk debugging. The
red test. You run your code. The screen fills
with red error text. And the human reaction is
to squint at it, scroll up, try to find the one
important line. Stop. Stop playing detective.
Humans are terrible at parsing thousands of lines
of logs. We see what we expect to see. AIs are
just logic engines. They're literal. So what's
the workflow then? You copy the entire error
log. I don't care if it's 500 lines of gibberish.
You paste it in and just say Fix the failing
tests. You don't even try to give it a hint.
Like, I think it's the database. No, because
you might be wrong. And if you give it a hint,
you're biasing the AI. You're contaminating the
evidence. Let it look at the raw data. The source
also mentions a term, MCP, Model Context Protocol.
What does that actually mean? It sounds like
jargon, but think of it as giving the AI hands.
Normally, the AI is a brain in a jar. It can
only talk. MCP lets the AI reach out and touch
your tools. It can read your terminal, access
your Slack, look at GitHub issues directly. So
instead of me pasting the logs, the AI just goes
and looks at them itself. Exactly. You can say,
why is the goal failing? And it goes and checks
the server logs for you. It connects the dots
way faster. Why does this work better than a
human searching through logs? Because it's analyzing
logic instantly. It finds things we miss, like
a missing semicolon or an inverted true false.
It's unbiased pattern recognition versus human
guessing. That brings up a really interesting
tactic called grill me, which feels like the
opposite of asking for help. Yeah. Usually we
want the AI to be nice to us. Grill me is asking
the AI to be mean. How so? You say, I'm about
to commit this code, act as a strict security
auditor, grill me on the flaws. You're asking
for a stress test. And it will find them. It'll
say, you didn't handle what happens if the internet
connection drops. Or, this loop will freeze the
browser with 10 ,000 items. It catches all the
edge cases we're too optimistic to see. Then
there's the scrap it method. This one, I think
I'd struggle with this. Knowing everything you
know now, scrap this and implement the elegant
solution. It hurts, doesn't it? It's the sunk
cost fallacy. I spent three hours on this, I
have to make it work. But the guide argues the
second draft is always better. Always. The first
draft is for you and the AI to learn the problem.
Once you understand it, that code you wrote is
just baggage. If you tell the AI, OK, lesson
learned, delete it, write it clean, you get a
solution that's half the length and twice as
fast. It just feels so counterintuitive asking
the AI to delete its own work. But the restart
carries all the lessons you learned and ditches
all the baggage. Killing your darlings to lock
in the lesson. Ruthlessly. Let's touch on the
environment itself. There's a mention of things
like ghosty and voice mode. Is this just about
making things look nice? Well, ghosty is a terminal.
And yeah, good readability helps. But voice mode,
that's the real game changer. Really? I type
pretty fast. You don't type as fast as you think.
But more importantly, when you type, you summarize.
You cut corners because typing is work. When
you speak, you ramble, and I mean that in a good
way. You provide so much more context. So instead
of typing, fix this function, you're saying,
OK, so I'm trying to sort this list, but I'm
worried about the user data being null, and we
need to make sure. Exactly. You're dumping your
entire mental state into the AI. It's just high
bandwidth communication, and it gives the AI
a much richer context to work with. The guide
also uses a house building analogy for something
it calls subagents. How does that work? So think
about building a house. You've got your general
contractor, but you also have a plumber, an electrician,
a roofer. You wouldn't ask the electrician to
plumb the toilet. So a subagent is like a specialist.
Yes. For a massive task, you tell the main AI,
break this down, use subagents. One agent might
just go read the documentation for a new library.
Another might write the SQL queries. They all
report back to the main boss. And what's the
real benefit of using these subagents? It keeps
the main AI from getting tired. It stops its
context window from filling up with noise. So
specialization keeps the context clean. Right.
We've talked a lot about building faster. But
there's a fear here. If the AI writes the SQL
and the AI debugs the logs, are we just forgetting
how to code? Yeah, the de -skilling fear. And
it's valid, but only if you use the tool lazily.
If you just say, do it, and paste the result
without thinking, then yes, you will become a
worse coder. So how do you flip that script?
You turn the AI into a tutor. The source calls
this the educational shift. If the AI writes
a complex SQL query, don't just use it. Ask it,
why did you use a left join here instead of an
inner join? You force it to explain its work.
And you can use visual aids. You can ask for
an ASCII diagram. It'll literally draw a flowchart
with text characters to show you how the data
is moving. And what about spaced repetition?
Yeah. Quiz me on React hooks. Use that downtime.
Instead of scrolling Twitter while your code
compiles, have the AI grill you on concepts you're
weak on. You actually end up learning faster
because you have a senior engineer who never
gets tired of explaining things. So does relying
on AI make us forget how to code? Not if you
use it as a senior teacher or a study buddy.
So active curiosity prevents that skill from
fading. You have to use it to create curiosity,
not replace it. We're going to take a quick break.
When we come back, we're going to distill all
this down. If you only do one thing from this
list, what should it be? We've covered a lot.
Parallel work trees, CLOUDE .md, adversarial
grilling, voice mode. It feels like a completely
new operating system for development. But if
we zoom out, what's the one big idea here? The
shift is from thinking of it as a tool to thinking
of it as a partner. Meaning? Well, you don't
give a hammer a memory file. You don't ask your
hammer for a plan. But you treat AI like a hammer.
You get really limited results. You have to treat
it like a brilliant but junior colleague. It
needs context. It needs clear instructions. It
needs a dedicated workspace. It does. It's about
leveraging the fact that it can do the heavy
lifting, which frees you up to do the high -level
thinking. Your brain is for architecture, business
logic, creativity. And the AI is for syntax,
boilerplate, and error checking. When you get
that balance right, coding stops being a grind.
it starts feeling like magic again. So for the
listener who's maybe sitting at their desk right
now, don't try to do all 10 of these things at
once. No, you'll burn out. Just pick one. And
which one should that be? I'd say start with
cliude .md. Just create that text file on your
project. Put your tech stack in it. Add just
one lesson you learn the hard way. And just watch
how that changes the conversation when the AI
stops having amnesia. That's the actionable step.
And I'll leave you with this thought. If the
AI is handling the syntax, the debugging, the
boilerplate, maybe we aren't just coders anymore.
Maybe this tool lets all of us finally become
architects. That's the goal. Let the AI handle
the boring stuff so you can get back to the joy
of building. Thanks for diving in with us. See
you in the next one.