You paste a massive code base into Claude. You
hit enter. 10 seconds later, it spits out 500
lines of code. It looks like absolute magic.
Beat. Until you actually run it. Right, and your
application completely crashes. We have all been
there, honestly. You are using the smartest model
on Earth. So why is the code garbage? Well, the
secret isn't writing a better prompt. No, it
is the system around the prompt. Exactly. Generating
text quickly doesn't guarantee good architecture.
You have to stop treating the AI like a magical
slot machine. Welcome to the deep dive. Okay,
let's unpack this. Today, we are exploring a
playbook of 12 distinct habits for professional
AI engineering. Yeah, a strong, deliberate system
turns a basic prompt into production -ready code.
We are going to start by laying a clean, solid
foundation. Then we will move into planning and
building out the code. And finally, we will explore
some advanced parallel workflows. These aren't
just minor workflow tweaks either. These setups
fundamentally change how you ship software. Let's
start with the foundation. You simply can't write
good code if the AI lacks context. No, it has
to understand your specific coding environment
completely. Yeah, and the easiest way to establish
that is initializing your workspace. Before you
start chatting, you run a command called slash
init. Right. When you do that, The AI scans your
local code base. It then creates a small markdown
file called claylode .md. Think of this file
as a short project briefing. It captures your
overall project structure and your technology
stack. It lists the main folders and your specific
coding conventions. So you skip the painful introduction
phase forever. You don't have to explain your
project rules every single time. Yeah, the AI
just reads the file and instantly knows the rules.
But you really need to keep this file incredibly
short. You want to aim for roughly 150 lines.
Definitely. This file loads into every single
session you start automatically. That means it
costs you tokens every single time you chat.
Tokens, which are just the basic data units,
the AI processes. Right. You pay for those tokens
on every single reply. So a massive briefing
file drains your wallet incredibly fast. You
should set up a status line to monitor those
costs. Use the slash status line command to track
your context percentage. You can literally watch
that percentage climb in real time. time. Seeing
that number physically climb trains you to keep
sessions clean. Which brings us to the most common
mistake developers make. People love to paste
their entire code base directly into the chat.
Oh yeah, they think a bigger context window will
yield much smarter answers. It sounds completely
logical on the surface, but in practice it works
the exact opposite way. When you dump 50 unrelated
files into the chat, things break. The context
window, the AI's short -term memory during a
chat, gets overwhelmed. Totally overwhelmed.
Think of a bloated context window like a cluttered
physical desk. If there's too much junk, you
cannot find the stapler. Right. Under the hood,
the AI relies on attention mechanisms. It assigns
a mathematical weight to every single word you
provide. If you feed it too much noise, the weights
get diluted. Important details simply get buried
under all the irrelevant boilerplate code. Exactly.
The AI's attention is pulled away from what actually
matters. The final output becomes incredibly
vague and generally unhelpful. So before you
send a prompt, ask yourself a simple question.
Would a new engineer need this file to do this
task? If the answer is no, the file stays out.
Beat. But realistically sessions do inevitably
get heavy over time anyway Yeah, yeah back and
forth debugging and the history just piles up
That is why session cleaning tools are so critical
here when a session feels sluggish Run the slash
context command. It shows a complete breakdown
of what is actually using tokens. You stop guessing
what is bloating your session. You might see
an MCP server eating 30 % of your window. An
MCP server, a tool connecting the AI to external
beta. Exactly. Or you might see an old irrelevant
error log. Once you see the breakdown, you can
cut the noise immediately. Around the 60 % mark,
you run the slash compact command. This command
compresses the conversation history effectively.
It keeps the actual meaning while dropping the
messy back and forth chat. You can even tell
it exactly what to keep during compression. Like,
you can ask it to preserve specific database
schema decisions. Right. Then there is the nuclear
option, the slash clear command. You use this
when you switch to a completely new task. It
wipes the chat history entirely, but your project
files stay. You aren't starting from absolute
zero. You are starting fresh with all your long
-term project context preserved. Beat. So how
quickly does token bloat actually degrade the
AI's logic? It happens surprisingly fast in complex
projects. More noise means important details
simply get buried and lost. So bloated sessions
just waste your money and confuse the AI? Yeah,
pretty much. Now that our workspace is clean,
we need some actual direction. if a bloated session
is the first way we sabotage AI. The second is
letting it run loose without a clear map. Right.
How do we put guardrails on it? Well, you always
start your workflow in plan mode. In plan mode,
the AI can read, search, and research deeply,
but it absolutely cannot edit your actual files.
It gives you a detailed plan before changing
any code whatsoever. It lists the steps and the
exact files it will touch. Importantly, it also
lists the assumptions it is currently making.
You read that plan and decide if it makes logical
sense. Let's say you ask it to build a user login
page. The plan might say it will use email and
password authentication. But you actually wanted
a Google single sign -on flow? Catching that
in plan mode takes about 10 seconds of reading.
If you didn't use plan mode, the AI would just
build it. Then you'd have to untangle hundreds
of lines of useless code. The time spent reviewing
a plan is incredibly short. It is dramatically
shorter than cleaning up a confident wrong agent.
You want to watch the plan for a few specific
things. Is it actually solving the right problem?
Is it touching files that should clearly stay
completely untouched? Is it making an assumption
that violates your core architecture? When you
spot those issues, you push back inside plan
mode. You add the missing context and correct
the bad assumption directly. Then you simply
ask the AI for a revised plan. This requires
a shift in how we actually view the tool. We
have to treat the AI like a fast, capable junior
developer. It is incredibly smart, but entirely
new to your company's conventions. Right. If
you tell a junior developer to write a function
blindly... You get raw code that might completely
ignore your security standards. Exactly. But
if you give them constraints and trade -offs,
the dynamic changes. You ask for different approaches,
and you make them reason first. You see their
thinking process, and you catch logical flaws
early. You should give the AI complex problems
to think about. Ask it to propose three architectural
approaches with pros and cons. You read the approaches,
pick one, and then ask it to build. Two secs
silence. I mean, I still wrestle with prompt
drift myself, honestly. Oh, really? Yeah. I constantly
want to treat AI like a magic wand instead of
a junior dev. It's kind of hard to break that
habit. No, we all do it when a deadline is approaching
fast. But there is an ultimate safety net for
this exact problem. It is called the 95 % confidence
workflow. Yeah. At the start of a massive task,
you add one line. You literally tell the AI to
ask you clarifying questions first. It must ask
questions until it is 95 % confident. Right,
and it actually stops to ask about weird edge
cases. It asks about missing database tables
and unverified API assumptions. You answer the
questions, and now your mental models are aligned.
Most bad output comes from confident guessing
on vague, poorly defined tasks. This workflow
gives the AI explicit permission to slow down.
You align once, you build once, and it usually
works perfectly. Beat. But does spending time
answering the AI's questions up front slow down
the actual building process? It actually speeds
up the total timeline significantly. It cuts
three or four painful rebuild cycles down to
just one. Right. A few minutes planning saves
hours of painful bug fixing. Exactly. It's an
incredibly high return investment. So the AI
planned the feature. and it wrote the code. But
we certainly cannot just blindly trust it. We
need the AI to rigorously verify its own work.
You have to add self -checking steps to every
single workflow. Do not bolt verification on
at the very end as an afterthought. Bake the
check step directly into the AI's initial plan,
tell it to build a payment form, then immediately
check it. Tell it to add the API route, then
rigorously test it. You can use powerful visual
tools for this verification process now. The
AI can take a screenshot of a locally running
page. It looks at the image to find layout and
UI spacing issues. But the Chrome DevTools integration
is where it gets absolutely crazy. The AI can
literally open the page and click through it.
It can fill out forms and submit them like a
human user. Under the hood, it's actually interacting
with the document object model. It watches the
browser console for JavaScript errors as it clicks.
Right, and it monitors the network tab to ensure
the API payloads are correct. This moves the
check from surface level visual matching to structural
verification. It changes the question from does
it look right to does it actually work. Once
you verify the code works, you want to systematize
things. You need to start building reusable custom
skills because once you write the same complex
instructions twice, you should stop. You turn
those instructions into a permanent reusable
skill. Skills live in a dedicated hidden folder
as small markdown files. Each file represents
a highly specific repeatable workflow for your
project. You might have a skill file just for
standard code reviews. You might have one that
scans the code base for massive technical debt.
You write the workflow once and you can call
it anytime. Building custom skills is like stacking
Lego blocks of data. You build it once and reuse
it forever. This is where the tool stops feeling
like a simple chat box. Your repeated manual
work becomes named, versioned, improvable engineering
assets. And you commit these skill files directly
into your Git repository. So when a new developer
joins, they clone the repository. They immediately
inherit all of your AI workflows on day one.
What actually shifts when you transition from
chatting with an AI to building an actual system?
It changes how your entire team operates fundamentally.
Named version skills turn raw chats into improvable
team assets. Commit the skills file and your
whole team instantly levels up. Sponsor. Okay,
so standard tools sometimes hit their absolute
limits. What happens when you face massive multi
-part problems at scale? You have to scale your
workflows horizontally across multiple models.
You introduce sub -agents for handling parallel,
highly complex tasks. a subagent, a secondary
AI session handling a specific task. Your main
session stays on the incredibly powerful OPUS
model. But it spawns smaller subagents to do
the tedious busy work. You can spawn several
of these subagents all at once dynamically. One
agent reads through 500 pages of complex Stripe
API documentation. Another agent scans your entire
code base for similar architectural routing patterns.
A third agent starts writing the rough first
draft of the code. They work completely in parallel
and then report back to the main agent. They
provide short, dense summaries of their findings
to the Opus model. Your main session stays completely
clean and incredibly light on tokens. You save
the heavy Opus model for the hardest reasoning
tasks. You use the cheaper faster Haiku model
for the reading agents. It is incredibly efficient
from a cost and time perspective. Whoa! I mean,
imagine spinning up parallel agents to research
and test while you just sit back and think. It
is wild. If we connect this to the bigger picture,
it's crazy. You are essentially managing a digital
development team. But there is a very real, very
dangerous problem here. Parallel sessions will
absolutely overwrite each other's files if left
unchecked. Oh, definitely. Think of it like two
chefs trying to bake different cakes in the exact
same mixing bowl. If you have two sessions in
the same folder, they fight. One agent edits
a core file and the other instantly overwrites
it. You end up debugging a massive mess that
nobody actually wrote. You need Git work trees
to manage this chaos effectively. A Git work
tree links a directory to a specific code branch.
Normally you switch branches inside a single
project folder, but WorkTrees give each parallel
session its own isolated directory on your hard
drive. They are in the same repository, but in
completely separate physical spaces. You can
run one session building a new feature entirely.
And you run another session on a stubborn bug
fix in another directory? They all run at once,
with absolutely no file conflicts. The AI agents
are completely blind to each other's experimental
changes. When a task is fully verified and done,
you just merge the branch back. For a solo builder,
this is truly revolutionary software engineering.
It's kind of like cloning yourself three times
over. It really is. But how do you definitively
prevent these multiple AI agents from destroying
each other's code? You have to isolate their
environments completely from the start. Get work
trees, keep them in separate spaces until you're
ready to merge. Git work trees keep every agent
safely inside its own sandbox. Right. They can
break things in isolation without ruining production.
We have scaled wide, so now let's scale deep.
How do we handle impossibly hard bugs and long
-running, tedious tasks? You start using hooks
and loops for deep continuous automation. Once
you have parallel sessions running, you have
to stop babysitting the terminal. Hooks trigger
a notification when a specific event finally
happens. You can get a desktop ping when a massive
test suite finishes. Then there is the loop command,
which is basically an infinite worker. It lets
a session rerun a prompt on a continuous schedule.
You can have it check your server deployment
status automatically every five minutes. The
best part is the session actually keeps its memory
intact. It maintains context across those continuous
loops for up to three days. It remembers what
failed 10 minutes ago and adapts its next check.
But this raises an important question about resource
allocation. What happens when standard fast reasoning
just isn't enough to solve the bug? Here's where
it gets really interesting. We bring in the heavy
hitter. It is a feature called UltraThink. UltraThink
tells the AI to use its absolute maximum thinking
budget. It uses up to 32 ,000 tokens just for
deep internal reasoning. The AI essentially argues
with itself before typing a single word of code.
Under the hood, it's exploring a path, realizing
it's wrong, and backtracking. It is the fundamental
difference between a shallow answer and a profound
architecture choice. You use it for deep debugging
on problems you've already failed to solve. You
use it for massive, risky refactors where one
wrong call breaks the entire application. But
why shouldn't we just use UltraThink for every
single prompt to get perfect code? Because it
is incredibly slow and highly expensive to run,
routine work simply does not need a massive reasoning
budget to succeed. Save the heavy ultra -think
budget only for the hardest architectural problems.
Yeah, if you are just centering a div, you don't
need a supercomputer pondering the universe.
Exactly. Beat. But seriously, we suggest picking
just three of these habits to start with today.
Try the init command to build a tight ClaudeE
.md file. Use plan mode on absolutely every new
task you tackle. And bake a self -check step
into every to -do list you write. So what does
this all mean for us? Let's synthesize the main
theme of this entire playbook. Modern AI heavily
rewards the person who actively designs the workflow.
It does not reward the person writing the cleverest
single prompt anymore. The structural system
you build matters exponentially more than the
initial command you type. Two sec silence. Think
about this for a moment. An AI can plan its own
execution completely from scratch. It can visually
check its own UI with developer tools. It can
loop its own monitoring workflows autonomously
for days. Beat. What does the future role of
a human developer actually look like? Are we
moving away from writing code line by line? Are
we simply orchestrating a team of digital minds
to build our visions? That is a profound question
to walk away with today. Thank you for joining
us on this deep dive. We highly encourage you
to test out the init command on your very next
project, OTRO music.