Typing the words build the thing into an AI feels
like absolute magic, doesn't it? Oh, yeah, completely.
But it's actually a trap. It is a massive trap.
Honestly, it's the absolute fastest way to manufacture
software bugs. And you do it with total, unwavering
confidence. Welcome to the Deep Dive. We're unpacking
something incredibly fundamental today. Beat.
It is April 2026. Hard to believe, right? Right.
And we are looking at a brilliant article by
Max Ann today. Yeah, we're exploring the official
developer workflow for Claude Code. This system
was built by an engineer named Boris Cherny.
We're really guiding you through a massive paradigm
shift today. We are moving far away from the
era of clever prompting. Exactly right. I mean,
clever prompting is completely dead. Yeah. we're
finally entering the era of architectural discipline
and we'll walk you through five specific actionable
steps today these steps turn your ai from a disposable
chatbot into a custom operating system it's just
a complete reframing of how you interact with
the machine you aren't just giving it tasks anymore
you're building an environment for it to succeed
so let's talk about the blueprints you know you
can't build a solid architecture without looking
at them Right. And that's exactly where the first
major failure happens. The biggest mistake developers
make actually happens before they write a single
line. Yeah. It's a trap we call reactive coding.
And reactive coding feels like you're making
real progress. You jump right into the terminal.
You start generating code immediately. Because
it's fun. Right. But you're really just creating
a massive mess for yourself later. You end up
reacting to a cascade of issues. You're not planning
for them at all. Beat. That brings us to our
first major shift. This is a big one. Yeah. Boris
Cherny starts 80 % of his sessions in plan mode.
80%. That number should really stop you in your
tracks. Variously. He is the engineer who actually
built the tool, and he spends almost all his
time planning. To access this mode. You simply
hit shift and tab twice. It forces the strategic
thinking to happen before the actual building
starts. Plan mode uses multi -model reasoning
to actually verify your logic. Let's unpack that
for a second because... Multi -model reasoning
sounds incredibly dense. Oh, sure. It just means
having different AI models check each other's
work. Got it. One model drafts a plan, and another
model tries to find the holes in it. So it aggressively
stops you from rushing ahead blindly. Exactly.
You use a very specific setup prompt here. You
have Claude ask you about the fundamental problem
you're solving. You meticulously define the intended
user. You establish the specific success metrics.
You figure out exactly what victory looks like.
And critically, you define the anti -goals. You
tell the AI what it should explicitly avoid doing.
Two sec silence. I'm looking at this setup and,
you know, I get setting goals. Right. But the
intense focus on anti -goals feels slightly counterintuitive.
Why is defining an anti -goal sometimes more
important than defining the actual goal? Because
it prevents confident hallucination. Which means
the AI smoothly generating completely wrong but
plausible answers. Exactly. Large language models
are fundamentally people pleaser. Yeah, they
really are. If you don't set strict negative
boundaries, the AI just fills in the blanks.
It guesses what you want and it usually guesses
wrong. It creates code that looks perfect but
fails structurally. Right. Think about assembling
a complex piece of furniture. If you don't look
at the instructions, you might build something
resembling a chair. Sure. But the moment you
sit on it, the entire thing collapses. The anti
-goals are the instructions telling you which
screws absolutely do not belong together. Right.
Telling it what to avoid prevents expensive and
frustrating wrong turns. You map out the entire
minefield before you walk through it. It saves
you hours of expensive refactoring later. So
we've carefully mapped the logic. We have a solid
plan. Now we need some basic ground rules for
the environment. Beat. This leads us directly
to the Claude .md file. Yeah, this is basically
Claude's standing cheat sheet. The model reads
this specific file at the start of every single
chat. You might think you should give the AI
a massive legal document, but the real secret
here is ruthless minimalism. People tend to treat
this file like a dusty storage unit. They hoard
rules. They really do. They create this massive,
overly anxious rulebook. They throw every single
edge case they've ever encountered into it. And
that directly causes instruction drift. Which
is simply the AI getting lost in too many contradictory
rules. The model only has so much attention to
give. Right. If you feed it a 500 line markdown
file of strict rules, the token waiting gets
completely diluted. It loses focus. Exactly.
It starts ignoring the core task because it's
terrified of violating some obscure formatting
rule from six months ago. The elite developer
workflow in 2026 approaches this entirely differently.
Yeah. You must keep this file under 100 lines.
Under 100 lines. That requires incredible. discipline.
Yeah, it does. It forces you to only include
the absolute most critical project DNA. Two sec
silence. I have to admit something vulnerable
here. Oh. I still wrestle with prompt drift myself.
Oh yeah. I get anxious when a model fails. Yeah.
And I just start endlessly adding rules to the
file. It's a really hard habit to break. We all
do that. It is completely human nature. Right.
We want to feel in control of the machine's output.
When something breaks, our instinct is to build
a taller fence. But in this new era, taller fences
just block the AI's view. The article suggests
a brilliant cleanup prompt tactic to fix this.
You actively ask Claude to review the file. and
delete outdated or conflicting information. Or
you go nuclear and just burn it down completely.
Just delete it. Yeah, you delete the entire file
to remove legacy friction. But wait, if we just
delete the file, aren't we losing the fundamental
project DNA we've worked so hard on? Not at all.
You have to remember that these underlying models
improve constantly over time. Oh, true. What
used to require strict, explicit rules is now
handled entirely naturally by the model's base
intelligence. The AI just understands standard
best practices better now. Exactly. Storing old
rules doesn't add clarity anymore. It just adds
friction. It's like leaving training wheels on
a motorcycle. It actively prevents the machine
from leaning into the curves. So fewer rules
actually force better AI alignment and less confusion.
Spot on. You want a beautifully sharp tool, not
a bloated corporate policy manual. Okay, let's
look at where we are. We've planned the core
code. We've burned down the rulebook and set
lean boundaries. Now, how do you actually trust
the output it gives you? You don't. You absolutely
never blindly trust the output. You force the
AI to check its own work. This is the concept
of self -verifying loops. Yeah. Honestly. It's
quietly the most powerful idea in this entire
article. It is brilliant because it mimics senior
engineering behavior. You give Claude a tangible
tool to inspect its own output. You give it direct
access to a browser or a test runner. Right.
You don't just say, write this function. You
say, write this function, run the test suite,
read the error logs, and fix it until it passes.
And this seemingly simple feedback loop creates
a massive 3x lift in output quality. A three
times quality improvement. It fundamentally shifts
the AI from being a passive writer to an active
participant. Whoa. Just imagine the AI catching
its own bugs in the dark before it even reaches
your terminal. That's genuinely incredible. It
completely changes your relationship with the
machine. Yeah. It's the difference between reviewing
a messy first draft and approving a polished
final product. You implement this by using a
reusable cleanup prompt. You explicitly tell
Claude to recheck all the work it just completed.
You have it independently ensure that all best
practices were followed. You force it to confirm
that no weird structural complications were introduced.
I'm thinking about edge cases here, though. Okay.
What if you're working on something abstract
where there isn't a simple test runner? or a
clear visual layout to inspect. That is actually
a massive glaring red flag. Really? Yeah. If
there is no clear way to mechanically check the
result, you failed step one. You mean the plan
mode phase? Exactly. It means the initial task
was not framed clearly enough. Oh, I see. If
success cannot be measured or verified by a tool,
then the AI is just guessing. And we already
know how dangerous guessing is. Right. If the
AI can't check its work... Your initial goal
wasn't clearly defined. Precisely. Verification
has to be baked into the actual setup. It cannot
be an afterthought you tack on at the end. Sponsor.
So your AI is now self -verifying its own beautiful
work. Things are moving fast. But really fast.
Because it's moving fast, you might be extremely
tempted to run five sessions at once. Oh, sure.
You want to speed things up even more. But here's
exactly why you shouldn't do that. Running parallel
sessions on the exact same file is a catastrophic
mistake. You end up with what Boris calls context
collision, which is simply AI confusion from
multiple sessions editing identical files. Think
of it this way. It's like handing two separate
contractors the exact same half -finished kitchen
remodel. Okay, that sounds bad already. You blindfold
them both, and you do not tell either one what
the other is doing. So one is installing cabinets
while the other is tearing down the wall. Instead
of accelerated progress, you just get overlapping
chaos. Right, and you are the one who ends up
untangling those contradictory code merges at
11 p .m. Ouch. The AI models overwrite each other's
logic because they don't share a real -time brain.
The elegant solution here is to use fresh, independent
sessions, but you strictly only use them for
distinct silos. Maintaining clean context is
a developer superpower. A clean, focused context
window spots incredibly simple solutions. those
solutions get completely lost in crowded noisy
chats so you might dedicate one isolated session
entirely to documentation you use another separate
session for the core logic right and another
strictly for edge cases you isolate the variables
but wait where exactly is the line between a
distinct silo and just another part of the exact
same task It all comes down to the final product
destination. If the two sessions are trying to
edit the exact same code block, that is a collision
waiting to happen. Makes sense. But if one session
is writing the core script and the other is writing
a separate readme file, that is a perfectly distinct
silo. Keep their jobs completely separate and
they won't step on each other's toes. Divide
and conquer. But keep the territories completely
segregated. That brings us beautifully to our
final major shift. This is the ultimate overarching
goal of the 2026 workflow. We are finally moving
from a manual day -to -day grind. to long -term
skill -based leverage. Most people still use
AI as a disposable conversational chatbot. They
write a long prompt, they get a decent answer,
they close the window. Yeah. And they start completely
over from scratch tomorrow. It keeps you eternally
stuck in manual mode. You're just pulling levers
every single day. Exactly. The real paradigm
shift is turning your repeat work into a repeatable
skill. Think about basketball. A prompt is telling
a player exactly how to dribble the ball down
the court every single time. A skill is just
calling a designated, heavily practiced play
from the sideline. That is a brilliant way to
picture it. You define the complex skill once
and you securely store it. And then the AI fundamentally
inherits your specific project DNA every single
time it wakes up. Wow. It instantly knows exactly
how we do things around here. It knows the coding
standards, the formatting quirks, the preferred
libraries. You're building infrastructure, not
just sending text messages. Beat. But you also
never want to bet against the model itself. Never.
Betting against the model's trajectory is the
worst strategic mistake you can make right now.
The article stresses this heavily. Do not spend
countless hours optimizing tiny, fragile prompt
tricks for today's specific limitations. Because
underlying AI models are improving at a staggering
rate right now. Those little quirks and limitations
you're hacking around, they will simply vanish
in the very next model update. You should invest
your energy in durable systems, better context
management, and tighter iteration loops instead.
You want to build architecture that actually
survives the next major AI release. But if the
underlying models are improving so rapidly, won't
our documented skills become obsolete just as
fast as our fragile prompts? Not if you build
them correctly. Okay. Good systems and clear
logical instructions actually scale beautifully
with the model's intelligence. That makes sense.
When the model gets smarter, your system just
runs faster and makes fewer errors. Clever prompt
hacks, on the other hand, just break immediately
when the model updates. Build structured workflows
that scale rather than relying on fragile, temporary
prompt hacks. Yes, you are literally building
an operating system. You are not compiling a
collection of magic spells. Let's synthesize
this entire journey for a moment. Mastering clawed
code isn't about being a wizard engineer with
secret knowledge. It's really not about having
the secret magical list of prompts saved in a
document. It is entirely about architectural
discipline. You absolutely must plan the logic
before you start building. Keep your standing
rules incredibly lean and minimal. Verify all
of your outputs with automated self -checking
loops. Silo your parallel tasks strictly to avoid
nasty context collisions. And finally, systemize
your repeat manual work into highly durable skills.
Less wizard. more operating system. It is remarkably
simple. It isn't flashy at all, but it actually
works reliably at scale. So here is your actionable
call to action for today. Go into your project
and delete your bloated Cleland E .MD file right
now. Seriously, just burn it down. Start completely
fresh. And try starting your very next development
project in plan mode. Let the models argue about
your logic before you build. Two sec silence.
I want to leave you with one final, slightly
provocative thought today. Something to really
chew on while you work. If the gold standard
right now is manually systemizing your repeat
work into these stored skills, or wait, sorry,
into these stored skills, what happens in the
very near future? What happens when the AI starts
silently analyzing your daily terminal behavior
to suggest and build its own skills without you
even asking? Oh, it is absolutely coming. The
machine will inevitably learn exactly how you
work just by watching you. We started today by
saying build the thing is a dangerous trap. Someday,
very soon, the AI might already know exactly
how to build the thing before you even type a
single word. OTRO music.