The Startup Ideas Podcast - How to use Claude Code better than 99% of People

Episode Date: August 17, 2026

Get Claude Code: https://startup-ideas-pod.link/claude-greg In this solo episode I lay out the exact system I use to turn Claude Code into what I call an AI employee. My premise is simple: give Claude the same things you would give a person joining your company (a workspace, memory, a brief, a clear ticket, eyes, review, a schedule, and permissions). I build the whole setup live around a real idea I found on ideabrowser.com , a missed-lead responder for med spas, and I share the specific prompts I use at each step. By the end, the product, the customer feedback, the docs, the demos, the reviews, and the recurring work all live inside one operating loop. I close with a seven-day plan you can run at your own pace. And thank you to Claude and Anthropic for supporting the podcast. Setup Claude Code to be your 24/7 employee: https://startup-ideas-pod.link/Claude-code Timestamps 00:00 – Intro: The AI Employee Map 05:47 – Step 1: Creating The Workspace In Claude Desktop 14:53 – Step 2: The Brief And Plan Mode 18:08 – Step 3: The Ticket And Defining Done 22:15 – Step 4: The Eyes And Desktop Preview 26:13 – Step 5: Review In Layers And The Diff View 29:34 – Step 6: The Schedule And Routines 34:32 – Step 7: Parallel Agents And Worktree Isolation 39:14 – Step 8: Permissions: Safe, Ask First, Human-Owned 41:15 – Step 9: Skills, Connectors, And Hooks 44:28 – The Seven-Day Plan 47:42 – Closing Thoughts Key Points I treat Claude Code like a new hire: workspace, memory, brief, ticket, eyes, review, schedule, permissions. The repo brain teaches Claude how I work and what good looks like. Plan mode comes first: Claude reads the context, proposes an approach, and waits for my approval. One ticket at a time means one task, one finish line, and one reviewable change. The eyes matter: Claude opens the app in desktop preview, clicks the flow, checks the console, and reports what a buyer experiences. Routines and permissions turn a chat tool into a 24/7 operator with clear boundaries. The #1 tool to find startup ideas/trends - https://www.ideabrowser.com LCA helps Fortune 500s and fast-growing startups build their future - from Warner Music to Fortnite to Dropbox. We turn 'what if' into reality with AI, apps, and next-gen products https://latecheckout.agency/ The Vibe Marketer - Resources for people into vibe marketing/marketing with AI: https://www.thevibemarketer.com/ FIND ME ON SOCIAL X/Twitter: https://twitter.com/gregisenberg Instagram: https://instagram.com/gregisenberg/ LinkedIn: https://www.linkedin.com/in/gisenberg/

I think there's a lot of people using ClaudeCode 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 cloud code that spin up actual AI employees. But the thing is, you have to set it up in a certain way. And today I'm going to show you what that certain way is. I'm going to show you the nine different areas that you need to master in order to, 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 going to give away all the prompts and all the sauce in this episode, are going to be able to outperform people,

are going to be able to build products that work 24-7, are going to 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 24-7 that act like AI employees. Enjoy the episode. Shut out to Anthropic for supporting the channel and sponsoring today's episode. The way I think about an AI employee and setting it up is actually, pretty simple. If you want Claude Coe 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 want to use like a fable over an opus. We'll talk more about that. Then it needs a clear ticket, basically an assignment. 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 best. make this pop, these very vague prompts that are assigned to it. The better way to do it is to be extremely specific. So if you're, you know, if you're creating a landing page and you want to create a waitless form, you'd say add a waitless form to the landing page with a success state and check it in desktop preview.

That's going to work just a lot better. The next thing it needs is eyes, you know. and you can finally do this in Cloud code, and it's so, so exciting. So you can do it in the desktop app, which is what 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 going to 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 ships. Then it needs a schedule. So this is when a lot of people start having that aha moment where it's an actual 24-7 employee. you can basically give Claude recurring work, like a morning brief, weekly issue review, poll request reviews. Claude calls us routines and we'll get into that 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. Cloud is the exact same way. So it can read files, it can inspect the repo, it could run tests, can work on small branches. But before touching things like dependencies, before touching migrations,

before touching payments, these bigger things, you basically want to 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. 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, Claude 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 going to want to hit the Cloud Code section. I prefer using it in the desktop app.

It's a lot less overwhelming than in the terminal. So we're going to use that today. You're going to want to go and select your project folder where Cloud actually goes and runs. And just for the sake of this demo, we're going to talk about an idea that I found an idea browser. dot 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 going to talk about how we'd actually set up this repo, what the structure would be. And what I would want to

do, if I'm creating an app, if I'm creating a software, I want basically slash app slash context, slash customers, slash spec, slash demo, slash routines. I'm going to want three MD files, and I'm going to 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 going to want to put the demo flow flows, loom scripts, screenshots, things like that. Routines is where you're going to want to put those recurring prompts. Like we talked about these recurring tasks that are going to happen. That'll be in the routines. And then the three root files that you're going to want to have that are MD files that are basically like this operating manual for you are going to be clawed.md, which tells you how clod to work. You're going to want a roadmap.md file. That's going to tell you.

Claude, what matters right now. And you're going to want to review.md file, which is going to tell Claude how to judge the work before it chips. So 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 up? What are what's like the best way to do it? 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 cloddd roadmap, review slash context, slash customers, slash spec, slash demo, slash routines. And then you say use this business context. So you can say product, mislead responsive for med spa. So you're just basically saying what it is. The buyer, you want to explain who the buyer is.

So in this case, it's a med spa 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 mislead before they book somewhere else. So you've identified 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 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. 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 going to 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 V1. So it's going to go and ask me a bunch of questions. You know, I'm going to go and answer it really quickly. And based on that, it's going to set up my entire workspace, so it's optimized.

So, you know, it's the way I see it is like you're setting yourself up for success. If you don't have all, you know, the optimized MD files and the optimized places and folders, then your, you know, cloud code is going to trip here and there. So we're going to go ahead and allow here, and it goes and creates the setup. Okay, so now we've got all the files and folders created. You can see here you've got the Cloud MD file, the AI employee operating manual, business in one line. We've got the Roadmap.md.md. We've got the review.md.

We've got the folders there, but we need to optimize it more. So I 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 want to keep the changes focused. I 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 change, what you test, and what needs human review. You want it to, you know, have business context too, right? So 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 are we doing here? Here's who the buyer is. It's an owner and operator. And 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 up in mobile, you use specific customer language. All this stuff you're putting in your clod.md file because you want to just,

you want it to know how you work. What is, what does success look like to you? And just your guiding, you're mentoring, you're mentoring it. So we've now gone and optimized the cloud and MD file. Really, really helpful to do. All right. So it's updated my clod.md.md. It's actually updated my review.md.

but I'm going to talk about how we can give it even more feedback on review.md. The next step I want to do is basically tell Claude what it needs to focus on this week. So we're going to talk about how you can optimize the roadmap.md file, which is basically what is your goal this week? So I say the current goal is to build a simple demo that shows how a medsba can recover mislead. And this week, I want you to focus on a landing page, a waitlist form, a demo flow, and then sending looms to 10 med spa 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 wanted to basically cook on the MVP.

I want it to be, like, exceed my expectations. So that's what I'm going to do to optimize the roadmap. MD file. Now, how can you optimize the review.md 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 do, does change match the current roadmap? Is the change small enough to review? Does the main user flow still work? Are there mobile layout issues? Are form errors handled correctly? Are there off payment or production data risk?

Did we add unnecessary complexity? And because we're building a landing page, we want to 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 customers would actually use? So this is specific to my med spot idea, but you can imagine how you can use this for whatever idea you're 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 5, 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 these guardrails. So it says the review.md is now complete. The workspace scaffolding is essentially done. Claude.mddmd, roadmap, 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 going to 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 context, and thinks through the job. and it shows you the approach before it starts changing files. So for this demo, I just want to use something that's simple and concrete.

I'm just going to ask Claude to add a waitless form to the landing page. But instead of just saying add a waitless form, I'm going to give it a real brief. So I'm going to show how you'd use plan mode here. So I say, use plan mode. I want to add a waitless form to the landing page. First, inspect the current app, the ClaudeMD, the Roadmap.md, and review. dotmd, 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 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 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 going to have something to react to. And 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 Superbase because I want real submissions. Or, you know, the form isn't simple enough. Just give me name, email company. You can say things like don't touch off 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 that need to change. It tells me the smallest clean implementation with the tech stack. It says NextJS 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. use and just gives me this whole plan and I then can go and say accept 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 going to want to do planning or meaningful work in general, actually. You're going to want to 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 simple success message. And by the way, keep it consistent with our current brand identity.

That is a good ticket. If 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 homepage. 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. 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. 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 what matters. And once it starts guessing, you're no longer managing the work. You're cleaning up the work. I will say Fable 5 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 want to give Claude a prompt that keeps it really focused.

So I say implement the improved plans as one focus 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 going to go and edit, copy, adding files, removing files, the diff is going to show you exactly what is change. And what's cool in is in the Cloud desktop app, 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 changed this shell. It's done this headline. It's made most. mobile first styles. It shows me what has been 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 going to check. They ask, what 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 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 kind of 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 bigger than the browser preview. So it's a bigger idea. Cloud can do things like run the test suite. It can check console logs. It can check network errors. It could check if the form actually fills the submission. So it could do really anything. And after Claude builds the waitless form, I actually want Claude to inspect the whole thing from the customer's point of view and the product operators point of view. So we're going to go ahead and check that and see how that works. So here's my prompt.

Start the app and inspect the waitless flow. Open the landing page and desktop preview. Check the experience from the perspective of a med spa owner, seeing this for the first time, then verify the implementation. And then here you say, tell me 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 path 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 process. 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 asks a cold med spa owner to hand over their email. 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 microcopy at the CTA. Again, this is really good employee doing stuff, right? This is what you want out of a good employee. So it's really cool that Claude

has eyes, right? And it's amazing how few people actually use the eyes. So when you make it a part of your process, you're going to have better QA. You're going to have just better product in the end because you're testing it to make sure it could work. It could do things. It's how you want it.

So the eyes underrated. The next piece we're going to 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 quickly, as you see, the bottleneck moves to judgment. So did it solve the right problems? Did it change the right files? Did it create this weird edge case?

Did it make the product clear for the customer? That's why the review matters so much. because if you're going to 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 Cloud desktop.

Like we talked about, a diff shows you a before and after of what's changed. And look at the files that. that Claude has touched. You can click through the changes. You can ask yourself a few questions like, does this match the 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 wait list form, for example, and suddenly it changed off and routing and databases and stuff like that, I would want to know that immediately. The second layer is Claude is reviewing against your standard.

So you remember we created the review.md 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 go deeper on this? So I'm going to say use review.md 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 change outside the scope of the ticket and anything that violates the roadmap. So all that good work that we did with the review.md up front is going to pay dividends.

And let's see what it, let's see what come. Let's see what they say. So you can see here, it's separated into must fix, show. fix and okay to ship and you know it asked me if i want to 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 um if you want to just review your your code but if you're doing really risky stuff you're You might want to do slash ultra review.

So if you see here, it says launch a remote ultra view session for this repository. And that's going to be, you know, before you're actually posting a production, if it's like a big feature, maybe it's authentication, payments, that sort of thing. You're going to want to do something like an ultra review. So a little tip, little tip there as well. The six 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've got to 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 for people. Heating 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 got to go do.

That kind of work is, you know, quote unquote, boring, not glamorous, but it's the exactly the type of work that keeps a company moving, that keeps them progress. 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 Claude code called routines. So here's a sample routine prompt. I say every weekday morning at 7 a.m. Read slash customer slash context, open GitHub issues if it's connected, and then create or update slash context morning brief MD 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 poll 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 now you're probably starting to see like how this all kind of 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 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 set up. But what if you want to 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 3 p.m. 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 MD do not edit code.

Done. So the second scheduled agent is live. And what I think is so awesome about this is, you know, you're not going to have issues just piling up. Claude is going to 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 going to help you like prioritize your week and 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 going to create a loop? I'm going to post this poll request. So I'm going to say when a poll 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 going to have every morning Claude code telling you what matters. It's going to be telling you the patterns. And then every poll request, Claude is going to check that work against your standards because it's looking at the review.md. And that's this whole concept of like the night shift, right? Like people talk about, you know, Claude code working 24-7. That's what they mean. They mean that the work is going to continually get organized. The feedback's getting summarized over time as a

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 clear. 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, right? You're duplicating five, 10, 15, 20 employees. 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 COTAB can run separate sessions. So each

session could have its own context and its own set of changes. 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 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 spot 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 want to 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 have 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 clearer. 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 want to dial a giant pile of AI work at the end of 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, okay, 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 change, the checks or tests you ran, what you should review in the diff and 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 med spot owner understands a value in five seconds. Use clod.m.D., Roadmapmd, Review.md, and the latest customer notes. Important to include that there. Keep the change focus on the hero section unless the small supporting change is necessary. And when you're done, give me the before and after, et cetera, et cetera.

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, et cetera, et cetera. 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 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 got to stay with the human. So let's talk about safe actions, ask first actions, and human-owned actions. So safe actions are things like reading files, inspecting codebases, proposing plans, running local tests, edit a small

feature branch, update docs, create a draft poll request. As 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. 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 Claude 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 a bit too risky. So thinking about permissions as a strategy is going to be helpful to actually to actually.

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 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 latest calls or support notes and pull out the exact words that customers use, the repeated objections and the 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

happen more and more. And it just makes sense that you use that. You can also use that same skill when you're creating copy for ads. I would also do a, 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 going to 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 comment 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 to use that. Access to Google Drive, Slack. It's basically just a plugin 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, ships, 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 roadmap, your review standards, your customer notes, and your routine, Claude just becomes a lot more bespoke for your company. And that's kind of the bigger point with all these things. These are like power-ups for your business. And you can imagine that this is creating a kind of moat. If you have a really good system around this,

it's creating a moat because you're going to get really good outputs from your cloud code. Okay, so by now, I hope you understand like the main components of using cloud code to make it an AI employee. But you might be thinking, 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 on day one, and by the way, you can do this in seven hours. You can do it in 70 minutes. You can do it in seven days. You can do it in 31 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 weak perspective. So on day one, create the repo brain. You know, create the Claude MD, the Roadmap MD, the Review MD, the slash context, the slash customers, all that stuff. You write the customer, the problem, the current goal, and 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 waitless 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 Cloud 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 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 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 roadmap.md. The working style goes into clod.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 24-7 cloud code employee setup. Once you see it this way, 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 going to be perfect. But once you start building like this, you're not going to build like the old way. In the show notes, in the description, I'm going to 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 A.

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.