Greg Isenberg's nine-part framework for turning Claude Code into a 24/7 AI employee, walked through live on a real med-spa idea, from workspace and memory files to scheduled routines and parallel agent sessions.
Posted
yesterday
Duration
Format
Tutorial
educational
Views
11.3K
473 likes
57 · 43
Big Idea
The argument in one line.
Claude Code stops feeling like a one-off chat tool and starts acting like a 24/7 AI employee once it's given the same nine things a new human hire needs: a workspace, memory, a brief, a ticket, eyes, review, a schedule, and permissions.
Who This Is For
Read if. Skip if.
READ IF YOU ARE…
You already use Claude Code for real product work and want a repeatable system instead of one-off prompting.
You're a solo founder or small team trying to get an AI agent to handle recurring operator work, not just single tasks.
You want a concrete file structure (CLAUDE.md, ROADMAP.md, REVIEW.md) and exact copy-paste prompts rather than abstract advice.
SKIP IF…
You've never opened Claude Code and want a basic 'what is it' introduction first.
You're looking for new model capabilities or pricing changes rather than a workflow and process framework.
TL;DR
The full version, fast.
Most people use Claude Code as a one-off chat tool, and Greg Isenberg argues that's the mistake. His fix is to treat it like a new hire and give it the nine things a real employee needs: a workspace (the repo), memory (CLAUDE.md, ROADMAP.md, REVIEW.md), a brief (plan mode), a clear ticket, eyes (desktop preview that clicks through the app and checks the console), layered review (diff view, a written standard, and an optional ultra review), a schedule (recurring routines like a morning brief), permissions split into safe, ask-first, and human-owned tiers, and reusable skills, connectors, and hooks. He builds the whole thing live around a real med-spa missed-lead-responder idea, then compresses it into a seven-day setup plan.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Greg argues most people use Claude Code wrong and lays out the nine things an AI employee needs, the same things you'd give a person joining your company: workspace, memory, brief, ticket, eyes, review, schedule, and permissions, plus skills/connectors/hooks.
05:47 – 14:53
02 · Step 1: Creating The Workspace In Claude Desktop
Builds a real repo in Claude Desktop for a med-spa missed-lead-responder idea from ideabrowser.com: the /app, /context, /customers, /specs, /demos, /routines folder structure, and the CLAUDE.md, ROADMAP.md, REVIEW.md root files, then optimizes each with specific prompts.
14:53 – 18:08
03 · Step 2: The Brief And Plan Mode
Introduces plan mode as the 'measure twice, cut once' step: Claude inspects the app and context files, proposes files to change, the smallest implementation, risks, and what's left out, and waits for approval before editing.
18:08 – 22:15
04 · Step 3: The Ticket And Defining Done
Contrasts vague prompts ('make the app better') with specific tickets that name the job, scope, expected UX, and boundary, then shows the diff view output after Claude implements a scoped waitlist-form ticket.
22:15 – 26:13
05 · Step 4: The Eyes And Desktop Preview
Claude opens the built app in desktop preview, tests the empty and success states of the waitlist form as a first-time med-spa owner, checks console and network errors, and flags the highest-impact trust issue on the page.
26:13 – 29:34
06 · Step 5: Review In Layers And The Diff View
Lays out review in layers: your own diff read, Claude reviewing against REVIEW.md and sorting issues into must-fix/should-fix/okay-to-ship, /review for routine changes, and /ultra review for high-risk changes like auth or payments.
29:34 – 34:32
07 · Step 6: The Schedule And Routines
Sets up recurring 'routines': a 7am morning brief pulling top customer pain points into a file, a Friday weekly ops review, and a pull-request review loop, framed as giving Claude a 'night shift'.
34:32 – 39:14
08 · Step 7: Parallel Agents And Worktree Isolation
Explains running multiple Claude Desktop code sessions at once, each with its own worktree, using three example sessions (a bug fix, a landing page hero rewrite, a demo script) that feed into one review queue.
Splits Claude's authority into safe actions (reading files, running tests, small branch edits), ask-first actions (dependencies, migrations, auth, payments, deleting files), and human-owned actions (deploys, billing, customer data, security).
41:15 – 44:28
10 · Step 9: Skills, Connectors, And Hooks
Defines a skill as a repeated prompt worth saving (landing page teardown, customer notes extractor, demo script generator), a connector as access to outside tools like GitHub or Slack, and a hook as an automated guardrail like running tests before a PR.
44:28 – 47:42
11 · The Seven-Day Plan
Compresses the whole system into a day-by-day plan: repo brain, plan mode, a visible build, the preview loop, layered review, sending the result to 10 people, and the first scheduled routine.
47:42 – 48:10
12 · Closing Thoughts
Closes by pointing viewers to the prompts included in the show notes and encouraging them to actually build the system rather than just watch.
Atomic Insights
Lines worth screenshotting.
Claude Code performs less like a tool and more like an employee once it's given a workspace, memory, a brief, a ticket, eyes, review, a schedule, and permissions.
Vague prompts like 'make the app better' force Claude to guess what matters, turning the human from a manager into a cleanup crew.
A repo split into /app, /context, /customers, /specs, /demos, and /routines, plus CLAUDE.md, ROADMAP.md, and REVIEW.md, gives Claude an operating manual instead of a blank slate.
Plan mode makes Claude read the project context and propose an approach before touching any files, so the human approves the plan before the work starts.
A good ticket names the job, the scope, the expected user experience, and the boundary, the same way a manager would brief a new hire.
Claude can now open the app itself, click through a flow, read console and network errors, and report what a first-time buyer would actually experience.
Review should happen in layers: the builder's own diff read, Claude checking the work against a written REVIEW.md standard, then an optional slash ultra review for high-risk changes like auth or payments.
Scheduled routines turn a chat tool into a 24/7 operator: a 7am morning brief, a Friday weekly ops review, and an automatic pull-request review loop.
Multiple Claude Desktop code sessions can run in parallel with worktree isolation, so a bug fix, a landing page rewrite, and a demo script can all move forward at once without their changes mixing.
Permissions should split into three tiers: safe actions Claude can do freely, ask-first actions like dependency or migration changes, and human-owned actions like production deploys and billing.
A skill is just a prompt used often enough that it deserves to become reusable, like a landing page teardown or a customer notes extractor.
Connectors give Claude access to outside context like GitHub, Linear, Google Drive, and Slack, while hooks are guardrails that run formatting or tests automatically after an edit.
The whole operating loop closes when customer feedback, product direction, working style, and quality standards all live in files Claude reads before every task.
A seven-day setup plan makes the whole system real: one repo brain, one plan-mode task, one visible build, a preview loop, a layered review, ten people to send it to, and one scheduled routine.
Takeaway
Treat Claude Code like a new hire.
THE 9-PART SYSTEM
Claude Code stops being a one-off chat tool the moment it gets a workspace, memory, a brief, a ticket, eyes, review, a schedule, and permissions, the same setup you'd give a new hire.
01Intro: The AI Employee Map
Claude Code works best when treated like a new hire, not a chat box: give it a workspace, memory, a brief, a ticket, eyes, review, a schedule, and permissions.
Vague instructions force Claude to guess, which turns the human from a manager into a cleanup crew after the fact.
02Step 1: Creating The Workspace In Claude Desktop
A dedicated folder structure, /app, /context, /customers, /specs, /demos, /routines, plus three root files (CLAUDE.md, ROADMAP.md, REVIEW.md), gives Claude an operating manual before any code gets written.
CLAUDE.md should state a working style, small reviewable changes, explain the plan first, run checks, summarize what was tested, the same way you'd brief a new hire.
ROADMAP.md names the current goal and, just as important, what's explicitly out of scope, so Claude doesn't wander into payments or admin dashboards on an MVP.
03Step 2: The Brief And Plan Mode
Plan mode makes Claude inspect the existing app and context files, then propose files to change, the smallest implementation, risks, and what's intentionally left out, before touching anything.
Treat plan mode like 'measure twice, cut once': reacting to a proposed plan is cheap compared to undoing a wrong build.
04Step 3: The Ticket And Defining Done
A good ticket has a job, a scope, an expected user experience, and a boundary, for example 'add a waitlist form with name, email, company, and a success message, matching current brand.'
The diff view shows the exact before-and-after of every file Claude touched, which is what makes small tickets reviewable and large ones untrustworthy.
05Step 4: The Eyes And Desktop Preview
Desktop preview lets Claude open the app itself, click through the flow, and report back from the customer's point of view instead of only editing files blind.
After building a feature, ask Claude to test the empty state, check console and network errors, and name the single highest-impact usability issue before shipping.
06Step 5: Review In Layers And The Diff View
Review happens in layers: your own diff read first, then Claude checking the work against a written REVIEW.md standard and sorting issues into must-fix, should-fix, and okay-to-ship.
Use /review for routine changes and /ultra review, a remote review session, before shipping anything touching auth, payments, or production data.
07Step 6: The Schedule And Routines
Routines turn Claude into a proactive operator: a 7am morning brief pulls the top customer pain point and one recommended task from customer notes and open issues.
A weekly ops review groups related issues, flags duplicates, and suggests the single highest-leverage fix for the week, functioning like a chief of staff.
A pull-request review loop checks every PR against REVIEW.md and posts a summary automatically, which is the actual meaning of Claude Code 'working 24/7.'
08Step 7: Parallel Agents And Worktree Isolation
Claude Desktop can run separate code sessions in parallel, each with its own worktree, so a bug fix, a landing page rewrite, and a demo script can move forward at the same time without changes mixing.
Give each parallel session its own scoped prompt and a specific handoff format so the work comes back as a reviewable packet, not a giant tangle to untangle at the end of the day.
Split Claude's authority into three tiers: safe actions like reading files and running tests, ask-first actions like dependency or migration changes, and human-owned actions like deploys and billing.
Start with manual review and tighten permissions as CLAUDE.md, REVIEW.md, and ticket scoping get stronger; going fully autonomous too early is described as too risky.
10Step 9: Skills, Connectors, And Hooks
A skill is a prompt typed often enough that it deserves to become reusable, like a landing-page teardown or a customer-notes extractor that pulls exact buyer language.
Connectors (GitHub, Linear, Google Drive, Slack) give Claude outside context, while hooks are automated guardrails, like running formatting after an edit or tests before a PR summary.
11The Seven-Day Plan
Day 1 builds the repo brain (CLAUDE.md, ROADMAP.md, REVIEW.md, context folders); Day 2 runs one plan-mode task; Day 3 ships one small visible build.
Day 4 runs the preview loop for clarity and mobile; Day 5 reviews the diff against REVIEW.md; Day 6 sends the result to 10 real people and logs their replies.
Day 7 creates the first routine, a morning brief, which closes the loop: customer feedback, product direction, working style, and quality standards all now live in files Claude reads automatically.
Glossary
Terms worth knowing.
CLAUDE.md
The root file that tells Claude how to work: its style (small reviewable changes, explain before editing), the business context, and the quality bar.
ROADMAP.md
The file that tells Claude what matters right now, including the current goal and what's explicitly out of scope for the current build.
REVIEW.md
The file that tells Claude how to judge finished work before it ships, used as the standard for automated and slash-review checks.
Plan Mode
A Claude Code mode where Claude reads the project's context files and proposes an approach, files to change, and risks before editing anything, waiting for approval.
Ticket
A small, specific assignment with a visible finish line, given to Claude the way a manager would brief a task to an employee.
Diff View
The before-and-after view in Claude Desktop showing exactly which files and lines changed, used to review a completed ticket.
Desktop Preview / 'Eyes'
Claude's ability to open the running app itself, click through a flow, and inspect the result from a customer's point of view, not just edit files blind.
/review
A slash command that has Claude review current changes against REVIEW.md and sort issues into must-fix, should-fix, and okay-to-ship.
/ultra review
A more thorough, remote review session recommended before shipping high-risk changes such as authentication or payments.
Routines
Claude Code's term for recurring scheduled tasks, such as a daily morning brief or a weekly ops review, that run without a human prompting each time.
Worktree Isolation
A mechanism that keeps each parallel Claude Desktop session's changes in a separate branch so multiple sessions can work at once without mixing edits.
Permission Modes (Safe / Ask First / Human-Owned)
A three-tier model for what Claude can do unsupervised (read files, run tests), what it should ask about first (migrations, dependencies), and what stays with a human (deploys, billing).
Skill (Claude Code)
A saved, repeatable prompt for a task done often enough to standardize, such as a landing-page teardown or a customer-notes extractor.
Connector
A plugin that gives Claude access to an outside tool's context, such as GitHub, Linear, Google Drive, or Slack.
Hook (Claude Code)
An automated guardrail that runs around Claude's work, such as running formatting after an edit or tests before a pull-request summary.
“If you find yourself typing the same prompt over and over again, chances are that should just be a skill.”
practical, immediately actionable definition of a skill→ newsletter pull-quote↗ Tweet quote
The Script
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
17px
metaphoranalogy
I think there's a lot of people using code wrong. And they're using Claude code wrong because it is one of the most powerful pieces of technology that have ever existed.
And there's a way to use Claude code that spin up actual AI employees. But the thing is you have to set it up in in a certain way. And today, I'm gonna show you what that certain way is.
I'm gonna show you the nine different areas that you need to master in order to spin up these AI employees. And this episode might feel a little boring at times because I'm going through a setup, I'm teaching you how to actually do it.
But I think that the people that actually stick to the end, the people that actually get their hands dirty, that copy what I do, and I'm gonna give away all the prompts and all the sauce in this episode, are gonna be able to outperform people, are gonna be able to build products that work twenty four seven, are gonna build AI native companies, AI native companies that just are able to crush.
And I'm so excited to put this together for a free course for how to master Claude code like no one ever before with AI agents that run twenty four seven, that act like AI employees.
Enjoy the episode. Shout out to Anthropic for supporting the channel and sponsoring today's episode.
The way I think about an AI employee and setting an app is actually pretty simple. If you wanna if you want Claude Coat to act more like an employee, you need to give it the same basic things you would give a person joining your company.
It only makes sense. Right? First, it needs a workspace.
In this case, the workspace is called a repo, and that's where the product actually lives. That's where the files live, and that's where Claude can actually go and do the work.
Second thing it needs is memory. Memory is basically the context that you put into the project. So Claude understands what you're building, who the customer is, what matters right now, what good work looks like, and we'll get into that later, and what you've already learned so it doesn't repeat mistakes.
Then it needs a brief. Before Claude is, like, changing things all around, you wanted to understand the assignment. So that's where this thing called plan mode is super, super useful.
You're basically saying, look around, read the context, think through the job, and tell me how you'd approach it before you touch anything.
And for something like that, you might wanna use like a fable over an opus, and we'll talk more about that. Then it needs a clear ticket, basically an assignment. You know?
A real employee does better with an assignment. Why wouldn't an AI employee? Claude is the exact same.
The mistake a lot of people make is they'll say, make the app better. Make this pop. These very vague prompts, uh, that are assigned to it.
The better way to do it is to be extremely specific. So if you're, you know, wanna if you're creating a landing page and you wanna create a waitlist form, you'd say, add a waitlist form to the landing page with a success state and check it in desktop preview.
That's gonna work just a lot better. The next thing it needs is eyes. You know?
And you can finally do this in Claude code, and it's so, so exciting. So, uh, you can do it in the desktop app, which is what I I primarily use.
You could just say, Claude, open the app, look at the page, click through the flow, inspect what is confusing, and tell me, like, what a customer would actually experience by going through this.
That's obviously very, very different level of usefulness than only editing files. Then it needs review.
So review is just gonna look at the before and after changes. So Claude can help review the work too, but you want a system where changes get actually checked against your standards before anything important shifts.
Then it needs a schedule. So this is when a lot of people start having that moment where it's an actual twenty four seven employee. You can basically give Claude recurring work, like a morning brief, weekly issue review, poll request reviews.
Claude calls this routines, and we'll get into that in in this episode. And the last thing it needs is permissions. So a good employee knows what it can do on its own or when it should ask you for permission.
Claude is the exact same way. So it can read files, it can inspect the repo, it can run tests, it can work on small branches.
But before touching things like dependencies, before touching migrations, before touching payments, off thing these, like, bigger things, you basically wanna make sure that the human owns those trust decisions.
And that's basically the map. So the map is basically workspace, memory, ticket, eyes, reviews, schedule, and permissions.
And if you're able to do that, that's what I mean by an AI employee. It's basically this working system. Um, you give Claude a place to work, context to understand the business, you give it a clear way to plan, a way to execute, a way to check the product, a way to review things, a few recurring responsibilities that happen every single day, and then you give boundaries so it doesn't do something super risky.
And once you set it up this way, Cloud Code starts to feel less of like a one off chat thing and really more of like an operating layer for your company. So let's talk about how you can actually set up the first step, which is creating a workspace.
So in Claude Desktop, you're gonna wanna hit the Claude Code section. I prefer using it in the desktop app.
It's a lot less overwhelming than in the terminal, so we're gonna use use that today. You're gonna wanna go and select your project folder where Claude actually goes and runs.
And just for the sake of this demo, we're gonna talk about an idea that I found on ideabrowser.com, which is basically a mislead responder for med spa med spas.
So, basically, someone fills out a form, DMs the business, calls after hours, ask about pricing, but the business responds too late. There's an opportunity to create a cash flowing software business there.
So we're gonna talk about how we'd actually set up this repo, what the structure would be, and what what I would wanna do if I'm set if I'm creating an app, if I'm creating a software, I want basically slash app slash context slash customers slash specs slash demos slash routines.
I'm gonna want three MD files, and I'm gonna talk about what all that means. So slash app is the product, slash context is the business brain, slash customers is where the sales calls, the support notes, any objections, customer language, you put that there.
Slash demos is where you're gonna wanna put the demo flows, Loom scripts, screenshots, things like that. Routines is where you're gonna wanna put those recurring prompts. Like, we talked about these, like, recurring tasks that are gonna happen.
That'll be in the routines. And then the the three root files that you're gonna wanna have the that that are MD files that are basically like this operating manual for you are gonna be Claude dot MD, which tells you how Claude to work.
It you're gonna want a road map dot MD file. That's gonna tell Claude what matters right now.
And you're gonna want a review dot m d file, which is gonna tell Claude how to judge the work before it ships. So the the the first the the takeaway I want you to have is Claude gets just way more useful when the project explains itself.
So how do you actually go and set this thing things up? What are what are what's, like, the the best way to do it? This this is what you should do.
So here's the prompt. Help me set up this repo as an AI employee workspace, and then you just say creator update claud.md road map review slash context slash customer slash specs slash demo slash routines.
And then you say, use this business context. So you can say product, mislead responsive for MedSpa. So you're just basically saying what it is.
The buyer, you wanna explain who the buyer is. So in this case, it's a MedSpa owner, an operator, the pain that they go through.
So the inbound leads are going cold when the team replies too late. The promise, which is respond to every missed lead before they book some somewhere else.
So you've identified, you know, what success looks like here. And then the goal, the current goal, build a simple landing page and demo flow.
And then this is very helpful to to write this. Before writing, ask me for any missing context that would materially change the setup and keep the first version simple.
That's all you need to set up your workspace. While while, you know, you can do it manually, but the best way to do it is just have this all set up. And you can see here, it's gonna say, I'll ask you a few high leverage questions first.
The answers change how I structure the demo flow and the customer spec folder. Everything else, I'll fill with sensible defaults and keep v one. So it's gonna go and ask me a bunch of questions.
You know, I'm gonna go and answer it really quickly. And based on that, it's gonna set up my entire workspace so it's optimized. So, you know, it's it's the way I think see see it is like you're setting yourself up for success.
If you don't have all you know, an the optimized MD files and the optimized places and folders, then your your, you know, Claude code is going to trip here and there.
So we're gonna go ahead and allow here, and it goes and creates the the setup.
Okay. So now we've got all the files and folders created. You can see here you got the clot m d file, the AI employee operating manual, business in one line.
We've got the road map dot m d. We've got the review dot m d. We've got the folders there, but we need to optimize it more.
So I've got this prompt ready. How do you optimize a CloudMD file so it actually feels more like an AI employee?
You have to give it a working style. Right? If you hired a junior employee, any employee, you would want to be like, this is how I would like you to work.
So you give it the work style. You say, I want small, reviewable changes. I want you to explain the plan before editing when the task affects product behavior.
I wanna keep the changes focused. Want you to use the existing code style. I want you to run relevant checks after changes, and I want you to summarize what's changed, what you tested, and what needs human review.
You want it to, you know, have business context too. Right? So you you create a business context section.
You say, the product helps med spas respond to missed inbound leads faster. So you're reminding it what what are we doing here? The here's who the buyer is.
It's an owner and operator, and you you give it the promise again. You tell it what the quality bar is as well.
You say, you know, the landing page should be clear in five seconds. The demo flow should work on desktop and mobile. You use specific customer language.
All this stuff, you're putting in your claud dot m d file because you wanna just you want it to know how you work, what is what what that you know, what does success look like to you, and just you're guiding you're guiding, you're mentoring you're mentoring it.
So we've now gone and optimized the Claude dot m d file. Really, really helpful to do. Alright.
So it's updated my Claude dot m d. It's actually updated my review dot m d, but I'm gonna talk about how we can do give it even more feedback on review.md. The next step I wanna do is is basically tell Claude what it needs to focus on this week.
So we're gonna talk about how you can optimize the road map dot m d file, which is basically what is your goal this week.
So I say the current goal goal is to build a simple simple demo that shows how a med spa spa can recover misleads. And this week, I want you to focus on a landing page, a wait list form, a demo flow, and then sending looms to 10 MedSpa owners. An important thing to do is what here is out of scope?
So I'm including that payments are out of scope, CRM integration, admin dashboards, multi user permissions. And the reason I'm doing this is I want it to basically cook on the MVP.
I want it to be like, exceed my expectations. So that's what I'm gonna do to optimize the road map dot m d file. Now how can you optimize the review dot m d file?
This is the file that knows your standards, what, you know, what UD looks like to you, what is acceptable and not acceptable.
So I've got a prompt here for that. Here's my review checklist. So I say, before shipping, I want you to does change match the current road map?
Is the change small enough to review? Does the main user flow still work? Are there mobile layout issues?
Are form errors handed handled correctly? Are there off payment or production data risk? Did we add unnecessary complexity?
And because we're building a landing page, we wanna say, can a first time visitor understand the offer in five seconds? Is the CTA visible? Is the copy specific to the buyer?
And does the page use the words cuss would customers would actually use? So this is specific to my MedSpa idea, but you can imagine how you can use this for whatever idea you're looking at looking at. And you're basically just you're letting Claude know that, hey.
You can't just ship garbage. You know? We can't ship AI slop.
And the beauty about, you know, OPUS 4.8 or Fable five, you know, with the right MD files and the right structure and the right brain, it does such a good job, but it does need this these guardrails. So it says the review.md is now complete.
The works workspace scaffolding is essentially done. Claw.md, road map, review, and all five folders are populated and consistent with each other.
We just need to name the product and confirm the demo is simulated on screen, and then we can go ahead and make progress on this business idea.
Okay. So we've got the workspace set up. The next step is the brief.
So this is the piece that feels really small, but it does change the whole way you're gonna use Claude code. When you give a real person an important task, you don't just throw the task over the wall and just hope that they understand it.
Right? You talk through it first. You explain what you're trying to accomplish, what matters, what the constraints are, and what would make the work good and not a waste of time.
That's how I want you to think about plan mode. Plan mode is basically the moment where Claude looks around the project, reads the contacts, and thinks through the job.
And it shows you the approach before it starts changing files. So for this demo, I just wanna use something that's simple and concrete. I'm just gonna ask Claude to add a waitlist form to the landing page.
But instead of just saying add a waitlist form, I'm gonna give it a real brief. So I'm gonna show how you'd use plan mode here. So I say use plan mode.
I wanna add a waitlist form to the landing page. First, inspect the current app, the ClaudeMD, the roadmap.md, and review.md.
Important that you ask it to do that, by the way. Then you say, then give me well, it's important. I'll explain why because it's it's gathering the context.
It's important to gather the context to get the best quality output. Then you say, then give me the files that I need to change, the smallest clean implementation, the user experience, the risks, how we will verify it, and what you are intentionally leaving out for the first version.
And you say wait for my approval before editing. As it's cooking right now, the important thing here is you're now gonna have something to react to. And it's not it might not be perfect, but you can say, good.
Just keep the front end only because this is just a demo maybe. Or actually connect this to Supabase because I want real submissions.
Or, you know, the simp the form isn't simple enough. Just give me name, email, company. You can say things like don't touch auth and payments or the database yet.
So it doesn't need to be perfect, but you're basically starting with something that is well thought through. So now you can see Claude proposed a plan.
Here's the context. It gives me the files I need to change. It tells me the smallest clean implementation with the tech stack.
It says Next. Js with TypeScript. It tells me the user experience.
It explains what it looks like, the one line promise. So I can go and review all these things. It shows me my risks, like spam and abuse, and just gives me this whole plan.
And I then could go and say accept if I if I like it, or I can give it I can reject it or revise it based on my feedback to it.
So I'll go ahead and accept it. The way to think about plan mode in general is that anytime you're doing meaningful product work, you're probably gonna wanna do planning or meaningful work in general, actually. You're gonna wanna do some planning.
It's worth it. The way I think about it is it's like, you know the quote, measure twice, cut once? That's what you're doing here.
The next big piece to understand is the ticket. And this is where a lot of people accidentally make Claude worse than it needs to be.
So Claude code is very good at doing the work, but it needs to know what done looks like. And that's basically what a ticket is. A ticket is a small, clear assignment with a visible finish line.
If you were managing a person, you probably wouldn't say, hey. Go and improve the product.
Right? You would say, do a specific task, like add a wait list form to the landing page. It should collect a name and an email and a company, and after someone submits, show a a simple success message.
And by the way, keep it consistent with our current brand identity. That is a good ticket. It gives Claude the job, the scope, the expected user experience, and the boundary.
So I'll give you a few examples of tickets that I would give to Claude. Create a pricing page using the existing design system and keep it consistent with the home page.
Or fix the onboarding redirect bug or fix the onboarding redirect bug after the email verification. Turn these five customer objections into a sharper landing page section section.
These are small enough these are small enough that Claude can understand the finish line and just get to work, and you could review the work afterwards. The there are a bunch of tickets that do go sideways, but they're mostly the vague ones.
Right? Make the app better. Make this more viral.
Add AI. Build the whole thing. And the problem with those prompts is Claude has to guess guess what matters.
And once it starts guessing, you're no longer managing the work. You're cleaning up the work. I will say Fable five has done an amazing job at actually guessing what matters, but I still believe that this is an important part of the whole process to get the most out of it.
So after I've approved the plan, I wanna give Claude a prompt that keeps it really focused. So I say, implement the improved plans as one focused change.
Keep the change small enough that I review it in the diff view. I'll explain what diffs are in a second. After editing, run the relevant checks, open up the app in the desktop preview, summarize what's changed, tell me what you tested, and tell me what still needs human review.
The translation, like, what is a diff? The quick translation is it tells you the before and after. So if Claude is gonna go and edit, copy, adding files, removing files, the diff is gonna show you exactly what has changed.
And what's cool in is is in the Claude desktop app, it's it's pretty visual. You can click into the change files. You can review edits.
You can leave comments. And you can ask Claude to revise anything that feels off.
And that's really why ticket size matters so much, because if it's a small ticket, you can manage it. But if the ticket is massive, you end up with a giant pile of changes that might look impressive, but, you know, it's hard to really trust it.
So the rule here is pretty simple. Give Claude one clear ticket at a time, which is one task, one finish line, and one reviewable change.
So here's the output. You can see here visually, it shows here's the file.
Here's what it does. Here, I'll make this a little bigger.
It's just giving me you know, it's it's it's changed the shell.
It's done this headline. It's made mobile first styles.
Tested. It shows me what it couldn't do and why it couldn't do it, and it tells me what actually needs human review what actually needs human review.
And then we can go from there. So super helpful. So the fourth piece to understand is what I call the eyes.
So this is where Claude code really starts to feel like an operator of some sort. When I say eyes, by the way, I don't necessarily just mean the visual preview. I mean, Claude needs a way to inspect work after it builds it.
Right? If you think about a good employee, they do the task, and then they check the task.
They open the product. They click the flow. They run the test.
They look for errors. They check the console. Maybe there's some weird edge case that they're gonna check.
They ask, well, would this actually work for the customer? And that's the loop that I want with Claude Code. You know, you build the thing.
You run the thing. You use the thing. You test the thing.
You improve the thing. The desktop preview is a is a really big part of that because product work especially is visual. A lot of work is visual, but product work especially.
A landing page can load and still feel really confusing. A form could submit and then still kinda be awkward. A button can be on the page but still be hard to notice.
A headline can explain the product but still miss the buyer's pain. So the eyes are are bigger than the browser preview.
It's a bigger idea. You know? Claude can do things like run the test suite.
It can check console logs. It can check network errors. Check it could check if the form actually fills the submission.
So it could do really anything. And after Claude builds the waitlist form, I actually want Claude to inspect the whole thing from the customer's point of view and the product operator's point of view.
So we're gonna go ahead and check that and and see how that works. So here's my prompt.
Start the app and inspect the waitlist flow. Open the landing page and desktop preview. Check the experience from the point perspective of a MedSpa owner seeing this for the first time, then verify the implementation.
And then here, you say, tell me what what the buyer understands in the first five seconds, what feels confusing or low trust, whether the wait list form works, what happens after submission. So asking it a bunch of just questions, and then say, make one focus pass to improve the highest impact issue.
Again, this is what a good employee does, and we're just making a part of our process. So you can see the website has been created, and it's checking to see if it's rendering correctly.
It says now testing the flows as a first time visitor. Empty submit first. Click join the wait list with nothing filled.
So then it says the empty state works. It's used four tools for that. Look.
You can see it went and found, read the page, and used a computer. I mean, this is absolutely insane that it can actually do this, and that's why this is important to do.
You can see the success state has rendered. It's verifying the back end that it wrote the record. It's checking the console and network for errors.
Look at this. It says the highest impact issue. The page asked a cold MedSpa owner to hand over their email with no reassurance about what the wait list is or whether they'll get spam.
This is the single biggest friction point on the action the page asked for. My focus pass, add expectation setting micro copy micro copy at the CTA. Again, this is really good employee doing doing stuff.
Right? This is what you want out of a good employee. So it's really cool that Cloud Code has eyes.
Right? And it's amazing how few people actually use the eyes. So when you when you make it a part of your process, you're going to have better QA.
You're gonna have just better, you know, better product in the end because you're testing it to make sure, you know, it could work, it could do things.
It's how you want it. So the I is underrated.
The next piece we're gonna cover is called review. So this is the part of the whole AI employee setup that actually makes it usable.
Because once Claude can build things click quickly, as you see, the bottom the bottleneck moves to judgment. So did it solve the right problems? Did it change the right files?
Did it create this, like, weird edge case? Did it make the product clearer for the customer? That's why the review matters so much.
Because if you're gonna let Claude do a lot more of your work, you need a way to inspect that work without turning every task into this, like, hours of code review and stuff like that. So I would think about review in layers. The first layer is your own read.
So you open the diff view in in Cloud Desktop. Like we talked about, a diff is shows you a before and after of what's changed.
And look at the files that Claude has touched. You can click through the changes. You can ask yourself a few questions like, does this match the ticket ticket?
Does this match the plan? Is there something surprising in here? And surprising changes is usually where the risk is, so it's an important question to ask.
If Claude was supposed to add a waitlist form, for example, and suddenly it changed auth and routing and databases and stuff like that, I would wanna know that immediately. The second layer is Claude is reviewing against your standard. So you remember we created the review dot m d file earlier?
Well, you're asking Claude to review the work against what this project actually cares about. So how do we prompt Claude Code to to go deeper on this? So I'm gonna say use review dot m d as the standard, review the current changes for the production issues, broken edge cases, and confusing user flows, and then separate issues into must fix, should fix, and okay to ship.
Focus on bugs, user confusion, security risks, and unnecessary complexity files, files change outside the scope of the ticket, and anything that violates the road map. So all that good work that we did with the review.md upfront is gonna pay dividends.
And let's see what it let's see what come let's see let's see what they say. So you can see here, it's separated into must fix, should fix, and okay to ship, and, you know, it asked me if I wanna fix one and two now.
Good to know. Right? If I'm actually creating an app and putting into production, you know, it's helpful to know this sort of stuff, and I just find this format of must, should, and okay to be super, super helpful.
So you can do slash review if you wanna just review your your code.
But if you're doing really risky stuff, you might wanna do slash ultra review. So if you see here, it says launch a remote remote ultra view session for this repository, and that's gonna be you know, before before you're actually posting in production, if it's, like, a big feature, maybe it's authentication, payments, that sort of thing, you're gonna wanna do something like an ultra review.
So a little tip little tip there as well. The sixth piece is the schedule. This is basically this idea that the AI employee is working proactively for you.
So up until now, we've mostly been talking about Claude helping you while you're sitting there with it, and you gotta prompt it and review. You give it context.
You know, you give it a plan. You give it a ticket. You have it build, inspect, review the work.
I mean, that's really cool, but an employee is a bit more valuable in the sense that they've got this repeating responsibility that they go and do tasks.
So, you know, every business has work like this. Right? Like, someone has to look at customer notes or someone has to notice which issues are coming up.
Someone has to review open task and say, hey. There's a thing on this list that I gotta go do. That kind of work is, you know, quote, unquote, not glamorous, but it's the exactly it's it's exactly the type of work that keeps a company moving, that keeps them progressing, and that keeps them adding value to customers.
So I would start right there. I wouldn't start by asking Claude to ship production code while I'm asleep. I would start by just giving it a recurring operator task.
Eventually, you can get to more cool, glamorous tasks, but I would just start by, you know, create a morning brief for me.
And this is using a tool on Cloud Code called routines. So here's a sample routine prompt. I say, every weekday morning at 7AM, read slash customer slash contacts, open GitHub issues if it's connected, and then create or update slash context morning brief m d with the top customer pain point from the latest notes, one product risk, one recommended build task for today, and one question I should ask customers today.
Don't edit production code, don't open a pull request, and keep it under 500 words. Now this is something that you can do no matter what you're building. Right?
And thank god we got that repo, right, slash customer slash context. And and now you're you're probably starting to see, like, how this all kinda comes together.
So let's set up this task and see how it works. Cool. So that's all done.
I like this task as your first task because it's it's useful and controlled. It's not like changing the product. It's not touching production or anything like that.
It's not building random features. Just reading the business, looking at the current work, and giving you a sharper standing point for the day.
So this is really cool and took, like, a few seconds to to to set up.
But what if you wanna take that to the next level? I would add something like a weekly ops review. So let me paste in the prompt.
So I would say, every Friday at 3PM, review open issues and recent customer notes. Group related issues or identify duplicates suggest the single highest leverage fix for the week and post the summary to slash context slash weekly ops m d.
Do not edit code. Done. So the second scheduled agent is live.
And what I think is so awesome about this is, know, you're not gonna have issues just piling up. Clot is gonna help you see these patterns, and maybe there were customer complaints that you didn't see.
Maybe people had the same onboarding problem, and it's gonna help you, like, prioritize your week.
And and it's it's it's almost like a chief of staff that helps you do that. So now I have two routines running. You can see it here, the morning brief and then the weekly ops review.
So the last thing I would add here, and I encourage you to do the same thing, is to create a loop. How am I gonna create a loop?
I'm gonna post this, uh, pull request. So I'm gonna say, when a pull request opens, review it using review.md.
Leave comments only on issues that could create bugs, broken user flows, security problems, or confusing behavior.
And then post a short summary with what looks good, what needs attention, and whether this is ready for human review. So, you know, once this is done, you're gonna have every morning Claude code telling you what matters.
It's gonna be telling you the patterns. And then every pull request, Claude is gonna check that work against your standards because it's looking at the review dot m d.
And that's this whole concept of, like, the night shift. Right? Like, people talk about, you know, Claude code working twenty four seven.
That's what they mean. They mean that the work is gonna continually get organized, the feedback's getting summarized over time as it comes in, risks for the business are getting surfaced, and then what you should be working on the next set of tasks are getting clearer and clearer.
The next big piece to understand is how you can have parallel agents parallel work being done at the same time. Obviously, you don't want to have to, you know, do one thing at a time.
The dream is to have multiple agents, you know, doing multiple things at the same time, so it's not really one employee.
Is that possible? Yes. And I'll explain you how that works.
Because if your work is scoped well, Claude could actually move forward a few things at the same time. In Claude desktop, basically, the code tab can run separate sessions.
So each session could have its own context and its own set of changes. And and with work tree isolation, those changes can stay separate instead of all getting mixed together.
So the simple way to think about it is this. Each session should feel like you're handed one clear assignment to one person.
So imagine, you know, you sit in sit down in the morning and you want three things to be moved forward. The first thing is technical.
So maybe the onboarding redirect is broken after email verification, and you need someone to figure out figure it out and just fix it.
The second thing is product clarity. The landing page hero is maybe too vague, and you want the med spa MedSpa owner to understand the value in the first five seconds.
And the last thing is sales. Maybe you've got a bunch of customer notes and you wanna turn them into a sharper demo script. Those are all really different jobs.
Right? One is debugging, one is product and copy, one is sales enablement.
In the old workflow, I would probably do those one after the other. In the AI employee workflow, I can give each one its own Claude session and with the same product context and a very clear output.
So the bug session fix should come back with the root cause, the files it changed, the checks it ran, and what I should look for in the diff.
The landing page session, well, that should come back with a before and after hero, the customer language it used, and what changed in the preview, and why the new version is clear. And the demo session, well, that should have pulled the customer notes, the objection it was trying to handle, and what I should review before recording.
So the unlock here is this. You don't wanna jile a giant pile of AI work at the end of the day that you have to untangle because that's not fun.
You basically want, you know, little packets of work that the human being could you can inspect, accept, revise, or reject. So k.
Let's let's what does this mean in practice? How can we actually do this?
I would use a prompt like this. So I would say, work on the onboarding redirect bug after email verification. Use the project context files before you propose a fix.
Start by explaining what you think is causing the bug and which files you need to inspect. After I prove the plan, implement the smallest clean fix, and when you're done, give me the root cause, the files you changed, the checks or tests you ran, what you should review in the diff, and anything anything that feels uncertain.
Now for the landing page hero, you can do a similar format of the prompt, and you can just say, improve the landing page hero so a MedSpa owner understands the value in five seconds.
Use claw.md, road mapmd, review.md, the latest customer notes.
Important to include that there. Keep the change focused on the hero section unless a small supporting change is necessary.
And when you're done, give me the before and after, etcetera, etcetera. And lastly, for the sales bit, I would say a similar type prompt. I'd say, read the latest customer notes and turn them into a short demo script for the mislead responder.
Use the customer's actual language where possible. The demo should show pain, the product, moment, and the payoff. And when you're done, give me the demo script, etcetera, etcetera.
So what have I done here? I gave each session a clear job, the same project context, and a specific handoff. The point is not to have AI spray work in every direction.
The point is you wake up, you pick the three most useful work stroke work streams, you have Claude move each one forward in a way that you can actually review. The eighth piece is permission. We've got one more piece after this.
So permissions are really important because this is risky business. I think about permissions the same way I think about delegation.
There's some things that Claude can do freely. There's some things that Claude should ask about. Some things, they gotta stay with the human.
So let's talk about safe actions, ask first actions, and human own actions.
So safe actions are things like reading files, inspecting code bases, proposing plans, running local tests, edit a small feature branch, update docs, create a draft pull request.
Ask first actions are things like installing dependencies, changing database migrations, touching authentication, changing payment logic, deleting files, things like that.
And then human owned actions are production deploys, customer data decisions, billing decisions, security sensitive changes.
Like, you still want that to be a human being led. Even if you do have AI employees, that high risk stuff, you still want to be with human beings.
In Cloud Desktop, you can actually choose permission modes depending on how much control you want. So you can start conservative, and then you can use plan mode for the bigger changes.
And you can use manual review when you're learning the system. So I would let Claude move faster as the repo brain, the review checklist, and task scopes get stronger and stronger. That's the management model.
You give the AI room to work and boundaries, and I wish more people did that. You know, going YOLO mode, it's it's a bit too risky.
So thinking about permissions as a strategy is going to be helpful to actually be able to scale your team of AI employees. The ninth piece to understand is skills, connectors, and hooks. This is our last piece.
This is the part where Cloud Code stops feeling like this generic thing, and it starts feeling like it belongs to your company. So I'm sure you've heard of skills.
What is a skill? It's basically a repeatable way of doing work.
If you find yourself typing the same prompt over and over again, chances are that should just be a skill. So for example, in this med spa project I was working on, I would make the landing page tear down a skill.
And every time I use it, Claude should look at that page like a med spa owner and check off that five second clarity, find that vague copy, and look for the missing trust signals, inspect the CTA, and suggest one focus improvement.
I'd also make something like a customer notes skill. You know, it'd read the latest calls or support notes and pull out the exact words that customer use customers use, the repeated objections and the buy buying triggers that keep showing up.
That's super, super useful because now Claude isn't just building from my opinion. Right?
It's building from customer language, and this is a whole trend that I'm seeing more happen more and more, and it just makes sense that you'd use that. You can also use that same skill when you're, uh, creating copy for ads. I would also do a, uh, demo script skill.
So I would take the latest product state and customer notes and turn them into a short demo. You know, here's the pain, here's the product moment, and here's the payoff. That's the type of thing that's gonna save you hours every single week.
There are places you can download skills, or you can just, you know, create the skills yourself. If people are interested, I can do a deep dive on different marketplaces for skills and how to explore them.
Let me know in the comments section. So what is a connector? Well, the connector gives Claude just better context.
So, you know, it gives it access to GitHub. It gives it access to Linear if you use that, access to Google Drive, Slack. It's basically just a plug in that allows you to, you know, access all these different tools.
And what's a hook? A hook are the guardrails around the work.
So after Claude edits code, run formatting. You know, before a PR summary, run tests. Before a change shifts, run checks that matter.
So you've got skills that make the work repeatable. You've got connectors that give Claude better context, and now you've got hooks that make the workflow safer.
And when you combine all those with your road map, your review standards, your customer notes, and your routines, Claude just becomes a lot more bespoke for your company. And that's kind of the bigger point with with with all these things.
These are, like, power ups for your business.
And you you can imagine that this is this is creating a kind of moat. You know? If you have a really good system around this, it's creating a moat because you're gonna get really good outputs from your Claude code.
Okay. So by now, I hope you understand, like, the main components of using Claude code to make it an AI employee. But you might be thinking to yourself, like, okay.
How can I actually make a plan to try this? Well, here's a seven day plan that I would give to someone who wants to create a digital AI employee.
So the on day one and by the way, you could do this in seven hours. You can do it in seventy minutes. You can do it in seven days.
You can do it in thirty one days. It depends how technical you are, how much time you have. Are you working a job?
But, you know, I thought it would be fun to just think about it from a week perspective. So on day one, create the repo brain. You know?
Create the CloudMD, the RoadmapMD, the ReviewMD, the slash context, the slash customers, all that stuff.
You write the customer, the problem, the current goal, and the definition the definition of done. On day two, you can run the plan mode. So you can pick one small product task and make Claude inspect the repo before editing.
Your output is a plan. Your output is a file list. Your output is risks.
Your output is verification steps. On day three, just build one visible improvement.
The waitlist form, the pricing page, the demo flow, the onboarding bug. Choose something small enough to review and real enough to show a real customer.
On day four, use the preview loop. Have Claude open the app in desktop preview, click through the flow, check mobile, and improve clarity.
On day five, review the work. Open the diff view. Read the before and after changes.
Ask Claude to review against review.md, and and use the review code flow for a serious change that you might do. On day six, you can actually send it to 10 people.
Send the Loom, the demo, the landing page, whatever it is you end up building to some some people who might care. Then put their replies into that slash customer repo.
And then on day seven, create the first routine. Start with the morning brief.
Let Claude read the customer notes and issues, then recommend one useful build task. Now you have this loop. It's alive.
It's breathing, and you're starting each day with context, feedback, and a next move. And it's basically an AI employee.
Right? It's an AI employee because the final loop looks like this. The customer feedback goes into slash customers.
The product direction goes into road map dot m d. The working style goes into claw.md. The quality standards go into review.md.
Small tasks go through plan mode. Changes go through preview and review. Recurring work becomes a scheduled routine, and that's the twenty four seven Cloud Code employee setup.
Once you see it this way, it you know, Cloud Code doesn't feel like a chat box anymore. The product, the customer feedback, the docs, the demos, the reviews, the recurring work all start, and they live in this operating loop that over time you have to optimize.
Right? It's not gonna be perfect. But once you start building like this, you're not gonna build like the old way.
In this in the show notes, in the description, I'm gonna include all the prompts that I went through so you can learn from them, so you can copy this workflow, so you can too spin up your AI employees using Cloud Code. I think that the leverage you get from spinning up AI employees right now is insane.
You can use Cloud Code. You can use other systems, but, you know, do it. Have fun.
Get your hands dirty, and I'll see you next time. Have a creative day.
The Hook
The bait, then the rug-pull.
Greg Isenberg opens by claiming most people are using one of the most powerful tools ever built the wrong way, then spends the rest of the episode showing the nine-part system he uses instead to turn Claude Code into an AI employee that plans, builds, checks its own work, and runs recurring tasks on a schedule.
Frameworks
Named ideas worth stealing.
04:20list
The AI Employee Map (9 areas)
Workspace
Memory
Brief (Plan Mode)
Ticket
Eyes (Desktop Preview)
Review
Schedule (Routines)
Permissions
Skills, Connectors & Hooks
The nine things Greg says Claude Code needs to act like an employee rather than a one-off chat tool, mirrored directly on what a new human hire would need. Parallel agents / worktree isolation is covered as its own chapter but is presented as an application of these nine, not a tenth item.
Steal forany AI-agent-driven workflow, not just software builds, anywhere a task gets handed to an autonomous agent
27:03model
Review In Layers
Your own read (diff view)
Claude reviews against REVIEW.md
/review
/ultra review (remote, for risky changes)
Human call
A layered review model that scales scrutiny with risk, from a quick personal diff read up to a remote 'ultra review' before shipping anything touching auth, payments, or production data.
Steal forany code-review or QA process where the same checklist shouldn't apply equally to every change
39:14model
Permissions: Safe / Ask First / Human-Owned
Safe: read files, inspect repo, run tests, small branch edits, draft PRs
Human Owns: production deploys, customer data decisions, billing decisions, security-sensitive changes
A three-tier delegation model for how much autonomy an AI agent should have, moving from fully autonomous to approval-required to strictly human-only.
Steal forsetting permission boundaries for any autonomous agent, not just Claude Code
44:28list
The 7-Day Setup
Day 1: repo brain
Day 2: plan mode
Day 3: visible build
Day 4: preview loop
Day 5: review work
Day 6: send to 10 people
Day 7: first routine
A day-by-day compression of the whole nine-part system into something a solo builder can run in a week, ending with one repo, one roadmap, one review checklist, and one routine.
Steal forany onboarding checklist for standing up a new AI-agent workflow fast
CTA Breakdown
How they asked for the click.
VERBAL ASK
47:50link
“In the show notes, in the description, I'm gonna include all the prompts that I went through so you can learn from them, so you can copy this workflow, so you can too spin up your AI employees using Cloud Code.”
Soft CTA with no direct sale in the video itself; the description separately links Anthropic's Claude Code signup (sponsor link) and Greg's other resources (ideabrowser.com, his agency, a newsletter).
Cloudflare quietly built the payment rail for AI agents to pay tiny fees for web resources, and that rail is about to spawn a whole generation of businesses selling clean data, agent-readiness, and packaged expertise.
Cody Schneider returns to build two marketing agents live on screen — a cold-outbound machine that turns LinkedIn engagement into enriched leads, and an organic engine that turns internal conversations into a daily content pipeline.
Greg Isenberg gets a live, screen-shared tour of Jack Dorsey's new agent-native chat app from an early user — and presses him on whether it actually beats Slack.
00:38
01:11
02:01
02:36
03:10
03:45
04:54
05:29
06:08
06:50
07:32
08:14
09:38
10:20
11:02
11:44
12:26
13:08
13:50
14:32
14:53
15:55
16:30
17:48
18:08
19:36
20:11
20:46
21:22
21:57
22:15
23:56
24:14
24:48
25:22
26:10
26:13
27:36
27:57
28:43
29:17
29:34
30:29
31:44
32:21
32:58
33:36
34:13
34:32
36:00
36:35
37:10
37:36
38:21
38:56
40:14
40:54
41:34
42:12
43:30
44:08
44:47
45:26
46:43
47:22
47:42
47:56
26:28
39:43
34:10
48:28
Video of the Day43:59
38:44