You know, there is a universal friction we all
experience when we sit down to build. Oh, absolutely.
You get completely in the zone. The ideas are
flowing perfectly. But instead of actually building,
you're forced to context switch. Yeah, the worst.
You jump over to a terminal window. Then you
flip to a browser tab to read some documentation.
Right. Then you tab over to a separate chat box.
Two secs silence. It completely fractures your
flow state. We've spent decades adapting our
brains to how computers organize information.
Which is pretty unnatural, honestly. It is. So
what if your entire digital workspace lived inside
one intelligent window? That is the holy grail,
isn't it? Yeah. We leak so much cognitive energy
just shuttling context between different apps.
Our brains really aren't wired for that kind
of constant switching. Welcome to the Deep Dive.
Today we're... We're exploring the new Claude
Code desktop app. Yeah, and we are basing this
on the architect's manual. But we aren't just
going to read you a feature list today. We're
exploring a fundamental shift in how builders
operate. We're looking at how this app moves
away from being a simple chat box. It acts more
like a unified workshop. Yes. We're going to
break down the philosophy behind plan mode. We'll
look at the future of work through automated
routines. And we'll honestly examine where the
illusion breaks down. It's a massive behavioral
shift. Yeah. I'm really eager to unpack the psychology
here, how this tool actually changes our daily
workflows. Let's start with the physical architecture
of this new space. To understand how the AI operates
differently here, we have to look at the layout.
The manual highlights three specific tabs at
the top, chat .co -work and code. Clicking that
code tab opens a dark focused workspace. It immediately
sets a different tone. It feels like a serious
developer environment. It certainly doesn't feel
like a conversational chatbot anymore. You're
presented with this brilliant three -pane layout.
So on the far left, you have mission control.
That's where your project lists and active sessions
live. Then the middle column is your active session
that holds your chat thread and your input box.
And the right side is this flexible zone for
extra panes. That right pane is where the magic
happens. You can open a preview pane to see your
app running or... a plan view to see architecture
or diff view to see exact code changes. The layout
relies heavily on drag and drop. It's about reducing
cognitive load. If you're reviewing a massive
code refactor, you don't want to squint at a
tiny box. Exactly. You just grab that diff view
and drag it to take up the whole screen. Yeah.
Or maybe you're tweaking user interface colors.
You can drag the live preview right next to the
chat. It completely eliminates that endless alt
-tabbing we're all so used to doing. The analogy
in the original manual didn't quite capture the
mechanism for me. Oh, really? Yeah. Working with
old AI web chats felt like working at a tiny
cluttered desk. Right. But this new layout, it
feels more like stacking Leo blocks of data on
a massive multi -room factory floor. Oh, I like
that. Because with the old web chats, the AI
overheard every single conversation. It would
hallucinate code from a marketing site you asked
about three days ago. Yeah, that cross -contamination
is incredibly frustrating. So this new layout
uses a project -first model. The AI is placed
in a soundproof room. It only has access to the
specific blueprints you slide under the door.
Work is strictly separated by folders. And that
folder boundary is enforced mechanically. It
uses something called Git work trees underneath
the hood. Let's define that jargon really quickly.
Sure. A Git work tree is basically a way to work
on different parts of code at once. That's spot
on. Agent A can be completely rewriting your
payment module. At the exact same moment, Agent
B is writing unit tests for your user login.
Wow. Yeah, they don't step on each other's toes
at all. So the workspace is organized, but an
empty room doesn't write software. Why is this
isolated folder -based context such a massive
game changer compared to the old chat threads?
Because language models are highly susceptible
to noise, when you isolate the context to a single
folder, the AI's attention mechanism becomes
hyper -focused. It doesn't have to guess which
version of a file you care about. So clean folders
mean the AI never pulls context from the wrong
project. It's a hard, impenetrable boundary.
So the physical space is set, but how do we actually
breathe life into it? The first decision a user
makes actually dictates the AI's entire operating
boundary. Right. And you have to set the foundation
properly. This requires a fresh installation
of the desktop app. And, crucially, it requires
a Claude Pro subscription. The manual mentions
the free tier is mostly just for testing the
visual layout. Yeah, because the AI is reading
your entire project folder, the context window
fills up immediately. You'll hit the free limits
in minutes. You really need the pro plan for
this workflow. Let's pause and talk about the
economics of that. The pro plan is roughly $20
a month. According to the source, that gives
you about 44 ,000 tokens per 5 -hour Watto. That
translates to anywhere from 10 to 40 prompts.
But I have to push back a bit here. That scarcity
fundamentally changes the relationship, doesn't
it? 44 ,000 tokens can run out fast on heavy
code bases. Users really need to be strategic.
Oh, it absolutely does. You can't just spam the
AI with lazy half -baked thoughts anymore. You
have to treat every single prompt like an expensive
managerial directive. Which means choosing your
operating environment carefully. When you boot
up a session, you get three choices. Local, Remote,
or SSH. Right. Let's explore the implications
of those choices. Local is your speed layer.
It runs directly on your local machine and reads
your file system natively. It skips the delays
of pushing and pulling from a cloud repository.
It's incredibly fast for rapid iteration. The
manual notes Windows users need Git installed
for that while Macs have it natively. What about
the remote environment? Remote operates completely
differently. It runs safely on Anthropic's cloud
infrastructure. The brilliant part is that it
survives even if you close your laptop. Oh, wow.
Yeah. It's much safer for delicate client projects
because changes are stored in a dedicated branch
with a full history. And SSH is the third option.
SSH just allows the session to tunnel into a
remote server that you control. It's great for
folks managing their own bare metal hardware.
So we have our environment. Next is the model
selection. We have Claude Sonnet 4 .6 and Claude
Opus 4 .7. Think of Sonnet as your highly caffeinated
junior developer. It's fast, it's great for daily
tasks, simple UI changes, and quick bug fixes.
And Opus. Opus is your lead architect. You bring
in Opus for deep reasoning, complex database
migrations, or massive architectural shifts.
There's also an effort selector. You can choose
low, medium, high, or auto. They simplified that
nicely. Low effort means the agent moves quickly
and doesn't overthink small tweaks. High effort
forces the model into a deeper chain of thought
process before it touches a single line of code.
But the real leverage seems to be hidden. There's
a subtle menu inside the input box that a lot
of people overlook. Oh, the context menu. It
is the nerve center of the whole application.
You click that little icon and a massive set
of tools opens up. You can inject specific reference
files. You can pull live GitHub issues directly
into the AI's working memory. And you have connectors.
You can seamlessly link the session to your Gmail,
your Slack channels, or your Notion workspaces.
Right. You also access your skills from that
menu and the transcript mode where you can toggle
between verbose, normal, or summary. It's an
incredible amount of power right at the cursor.
So for someone starting a brand new project this
afternoon, how should they choose between local
and remote environments? I always recommend starting
local. You want that tight, immediate feedback
loop when you're initially prototyping. Once
the foundational architecture is stable, you
shift the session to remote. That protects the
code base with a continuous cloud history. Local
for speed and testing, remote for safe, continuous
cloud history. Exactly right. So we've established
that tokens are precious. We can't afford sloppy
meandering mistakes to sex islands. Jumping straight
into coding is usually what causes those expensive
errors. There is a specific feature designed
to purposely slow the AI down. Plan mode. I genuinely
believe it's the most profoundly undervalued
feature in the entire ecosystem. To understand
plan mode, we first have to look at the permission
states. The default state is ask permissions.
Right. It's incredibly safe. but painfully slow.
The AI pauses to ask your permission before every
single file edit. Then you have the opposite
end of the spectrum. Auto accept edits. The agent
runs wild. It writes files, edits code, and executes
terminal commands freely. It only pauses for
highly destructive actions, like deleting a directory.
And sitting outside of both of those is plan
mode. Plan mode forces the AI to put its hands
behind its back. It drafts a highly detailed
comprehensive roadmap and pure markdown. You
get structured headings, you get code blocks,
but it absolutely refuses to write project code
immediately. The manual provides a brilliant
example of this constraint in action. You tell
the agent you want to build an on -chain token
watch list application, but before it writes
anything, you command it to ask you five highly
targeted questions about scope, auth, and the
tech stack. I love that workflow. You force the
AI to interrogate you. It asks about your target
audience. It asks about your preferred database
structure. And the incredible part is, the AI
actually stops and waits for your answers. It
does. It sits there patiently. Once you answer,
it generates a meticulous step -by -step build
plan. It outlines the precise file structure,
the API endpoints, and the UI components. It
forces alignment before a single token is wasted
on bad code. I'll make a vulnerable admission
right here. beat. I still wrestle with prompt
drift myself. Oh yeah. Yeah. I get so impatient
when I try to skip the planning phase. I see
that blinking cursor and I just want the dopamine
hit of watching code generate on the screen.
We are all guilty of that. We've been conditioned
by standard chatbots to expect instant gratification.
But skipping plan mode on a fresh build is a
devastating trap. You inevitably spend three
times as many tokens untangling a spaghetti code
mess three hours later. You review the draft
in the dedicated plan pane. You spot the missing
logic. You correct it. Only then do you switch
the permissions to accept edits. It's the ultimate
preventative measure. But to be fair, you shouldn't
use it for everything. Right. The manual notes
that plan mode is gold for new builds, but it's
massive overkill for fixing a simple CSS alignment
issue or a tiny bug. If you just need a button
move five pixels to the left, use auto accept
edits. Feed the agent the exact file name and
the exact line number. Don't overcomplicate small
chores. That does make me wonder about the psychological
friction. Does forcing yourself into plan mode
kill the momentum of rapid prototyping? It definitely
feels slower in the first 15 minutes, but it
is exponentially faster by hour three. The AI
catches fatal architectural flaws before they're
ever coded into existence. Plan mode actually
saves hours by preventing massive code rewrites
later. Measure twice, cut once. It's timeless
advice. Sponsor. So the workspace is set. The
architectural plan is rock solid. But the execution
phase is where this tool breaks out of being
just a fancy text editor. This brings us to the
new automation capabilities, routines, and skills.
Routines are where we start seeing the future
of software development. Anthropic rolled these
out on April 14, 2026 as a research preview.
Let's unpack what a routine actually is. At its
core, a routine is a cloud -based configuration
that runs automatically. It bundles together
a specific prompt, a target repository, and the
necessary API connectors. And crucially, it runs
completely autonomously on Anthropic's cloud.
Which means your laptop can be closed and stored
in your backpack. Exactly. It operates entirely
independently of your local hardware. The manual
details three specific ways to trigger these
routines. Let's walk through them. The first
is schedule triggers. These use standard Krone
expressions. You can configure a routine to run
every night at midnight or every Monday morning.
Anthropic currently caps the frequency at once
per hour to manage compute loads. The second
trigger is what really caught my eye. API triggers.
Every single routine is assigned its own unique
HTTP endpoint. Right. You just had a simple POST
request with an authentication token and the
AI session boots up in the cloud. Wow. Imagine
wiring that API trigger directly up to your deploy
hooks. You could literally have the AI review
your code while you sleep. It's mind blowing.
You literally wake up to a fully vetted perfectly
documented pull request. It's essentially a tireless
junior engineer working the graveyard shift.
Yeah. And that perfectly segues into the third
trigger type, GitHub triggers. The AI listens
to the repository's heartbeat. Yes. It natively
subscribes to specific repository events. If
someone opens a new pull request or cuts a new
release, the routine automatically springs into
action. Wow. You just have to authorize the Cloud
GitHub app first. The source material gives a
brilliantly practical example of a schedule trigger,
the 7 a .m. daily morning brief. It's such a
clever quality of life hack. Every weekday morning
at exactly 7 a .m., the routine quietly spins
up. It uses the Gmail connector to read your
inbox. It scans for urgent deadlines or missed
payments. Then it reads your Google Calendar
for the day. Without you touching a single key.
Right. It synthesizes all that chaotic information
into a clean, structured markdown document. Finally,
it uses the Flac connector to drop that brief
directly into your private channel before you
even wake up. That's a beautiful example of cross
-platform orchestration. But we also need to
examine skills, which operate a bit differently.
Skills are what transform clogged code from a
coding assistant into a customizable work platform.
A skill is essentially a deeply ingrained reusable
set of instructions loaded on demand. The manual
suggests creating a product -led Prad skill.
When you invoke it, the AI instantly assumes
the persona of a rigorous product manager. It
automatically asks seven specific questions about
user pain points, demographics, and technical
constraints. So instead of copying and pasting
that massive prompt from a notes app every single
time you have an idea, you just type a slash
command. Every new project gets the exact same
rigorous treatment. You can load these skills
via a zip file or by pasting a terminal command.
or even using skills .sh. Yeah, it gives your
tool stack immense flexibility. You just have
to be careful not to install dozens of them at
once, or they start competing for the model's
attention. This raises an interesting operational
question. How do these native skills actually
differ from just keeping a Notion document full
of your favorite copy -paste prompts? A Notion
document is just dead text. A skill is a living,
active tool. When you invoke a skill, it natively
configures the agent's internal parameters and
runs its built -in slash commands automatically
within the session's memory. Skills are native
reusable AI tools that automatically run their
built -in slash commands. They literally become
extensions of the agent's brain. It sounds like
a deeply seductive, perfect system, but to actually
master it, we have to look past the marketing.
We have to understand the underlying mental model,
and we have to be brutally honest about where
the illusion currently breaks down. The underlying
mental model is the skeleton key to this whole
app. It breaks down into three very simple components,
context, agents, outputs. Let's explore those.
Context is simply the folder. Right, but it's
not just storage. The folder is the AI's short
-term memory. It holds your code base, sure.
But it should also hold reference PDFs, brand
guidelines, and old architecture docs. The richer
the soil in that folder, the better the AI's
output. The manual calls out a very specific
widespread mistake people make regarding context.
Staring at a completely empty folder and typing
a massive 500 -word prompt, the agent has absolutely
zero grounding. You have to invert that behavior.
Fill the folder with dense context first. Right.
Then write a very short, highly focused prompt.
Let the agent connect the dots. The second pillar
is agents. And an agent is not just the underlying
language model. That's a crucial distinction.
An agent is Claude Opus, combined with your specific
permission settings, your active skills, and
your enabled connectors. You can run the exact
same underlying model with different rule sets,
and you will get wildly different behaviors.
And the final pillar is outputs. Code is the
obvious answer here. But the output can be anything
now. It can be a fully formatted markdown brief.
It can be a visual Canva design. It can be a
complex calendar invite. The AI seamlessly moves
across mediums without ever leaving that single
window. You really start treating the interface
like a small, highly capable team. But let's
look at the rough edges. The manual is surprisingly
candid about what still feels clunky or broken.
The most glaring omission is the lack of a proper
file viewer. There is no native file tree panel
inside the application yet. Which is maddening
if you're a visual thinker. You can't just click
folders to see how the project is structured.
You have to ask the AI to print out the directory
structure. So for now, you end up keeping standard
VS Code open on a second monitor just to maintain
your spatial awareness of the project. I have
to thoughtfully challenge this all -in -one workspace
claim then. Oh. If a builder still needs VS Code
open to see their files, and they still need
Chrome DevTools open to debug their CSS, then
this isn't truly a single window workspace. It's
just a prettier terminal. I see why it feels
that way. But I think you're looking at the wrong
layer of abstraction. Clod code isn't trying
to replace your IDE's file explorer. It's trying
to replace your hands on the keyboard. Think
of it like a manager's control room. You don't
need to hold the wrench if you're directing the
mechanic. That's a fascinating reframe. The preview
console is another area that feels a bit hollow.
It is very lightweight. You only get basic session
logs. If you hit a complex front -end bug, the
internal preview won't give you the deep inspection
tools you need. You still have to open the local
server in a real browser. And the cloud sandboxes
have their own friction. They feel sluggish on
that initial boot. It can take a solid minute
or two to spin up a fresh GitHub branch sandbox
in the cloud. That's why local is so crucial
for the fast, messy iteration phase. So, knowing
all these intricate mechanics, the folder rules,
the token limits, the missing file trees... How
should users handle the situation when the AI
inevitably generates a terrible output, rather
than just blaming the model's intelligence? You
have to audit the environment you built for it.
Did you fail to provide a key reference document
in the folder? Are your permission rules too
restrictive? The model itself is incredibly capable.
The failure is almost always in the managerial
setup. Don't blame the model. Fix your folder
context or adjust the permission rules. You are
the orchestrator now. You have to manage the
workspace. Let's pull all these threads together.
We've covered a tremendous amount of ground.
For someone listening right now, what is the
ultimate takeaway? The builders who are moving
incredibly fast right now are combining three
specific things. Plan mode. Custom skills. and
cloud routines. That specific formula is what
separates the fast builders from the slow ones.
Moving from a chat box mentality to treating
the app like a small managed team that ships
work for you. It's a complete paradigm shift.
It requires patience to learn, but the compounding
returns on your time are massive. So here's our
call to action for you. Pick one tiny low stakes
project today. Open the app, create a strictly
isolated folder, boot up a session in plan mode,
and write your first architectural prompt. Just
get one small win. The initial friction disappears
very quickly. Two secs silence. But before we
wrap up, I want to leave you with a lingering
thought. We started this deep dive talking about
the universal frustration of context switching,
the deep desire for one intelligent window that
understands our intent. We've just explored how
Claude code now handles the initial project planning.
It writes the PRDs. It executes the raw code.
It even summarizes its own results on Slack for
you while you sleep. beat. If the AI is handling
the planning, the execution, and the reporting,
well what exactly is the human's core role in
the software loop of 2027? That is a real question
we're all going to have to answer. Out to your
own music.