# Claude Code New Features, Explained

Channel: Greg Isenberg
Video: https://www.youtube.com/watch?v=SkY-tR9kf-k
Duration: 48 min
Language: English
Words: 8223
Transcript page: https://viewrankai.com/tools/youtube-transcript/SkY-tR9kf-k

---

[0:00] I think there's a lot of people using claude 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 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 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

[0:37] 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 [music] 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 cloud code like no one ever before with AI agents that run 24/7

[1:15] that act like AI employees. Enjoy the episode. Shout out to Anthropic for supporting the channel and sponsoring today's episode. [music]

[1:30] [music] The way I think about an AI employee and setting it up is actually pretty simple. If you want to if you want cloud code 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

[2:08] 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

[2:42] an opus. 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, want if you're creating a landing page and you want to create a weight list form, you'd say add a weightless form to the landing page with a success state and check it in desktop preview. That's

[3:20] 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, uh, you can do it in the desktop app, which is what I I primarily use. You can 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

[4:01] Claude can help review the work too, but you want a system where changes get actually checked against your standards before anything important ships. Um then it needs a schedule. Um, so this is when a lot of people start having that aha moment where it's an actual 247 employee. You can basically give Claude recurring work like a morning brief, weekly issue review, poll request reviews. Um, Claude calls this routines and we'll get into that uh 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. Cloud is

[4:44] the exact same way. Um, so it could read files, it could inspect the repo, it could run tests, uh, it can work on small branches, but before touching things like dependencies, before touching migrations, before touching payments, a thing, these like bigger things, you basically want to make sure that the human owns those trust

[5:04] 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

[5:43] 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 cloud desktop, you're going to want to hit the cloud code section. Um I prefer using it in the desktop app. It's a lot less overwhelming than in the terminal. So, we're going to use use that today. Um, you're going to want to go and select your project folder

[6:10] um where Claude actually goes and runs. And just for the sake of this demo, we're going to talk about an idea that I found on ideabrows.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, uh, ask about pricing, but the business responds too late. There's an opportunity to create a cash flowing uh, 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 what I would want to do if I'm set if I'm creating an app, if I'm creating a

[6:46] software, I want basically slash app/context/c customers/spec/demo/ routines. I'm going to want 3MD files. And I'm going to talk about what all that means. So slash app is the product slashcontext is the business brain slashc customers is where the sales calls the support notes any objections customer language you put that there uh slashdemos is where you're going to want to put the demo 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 like recurring tasks that are going to happen that'll be in the routines and then the the three root file files that you're going to want to

[7:30] have uh the that are MD files that are basically like this operating manual for you are going to be claw.md which tells you how claude to work. It you're going to want a roadmap.md file that's going to tell claude what matters right now and you're going to want a review.md file which is going to tell Claude how to judge the work before

[7:53] it chips. So the mo 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 create or update claw.md roadmap review/context/c customer/spec/demo routines. And then you say use this business context. So you can say product miss lead responsive for med spa. So

[8:34] 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 and 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 write this before writing ask me for any missing context that would materially change the

[9:09] setup and keep the first version simple. That's all you need to set up your workspace. um while while you know you can do it manually but the best way to do it is just h have this all set up um and you can see here it's going to say I'll ask you a few highleverage 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 um you know I'm going to go and answer it really quickly Um, and based on that, it's going to set

[9:49] up my entire workspace so it's optimized. So, you know, it's it's the way I think see it is like you're setting yourself up for success. If you don't have all, you know, an optimi the optimized MD files and the optimized uh places uh and folders, then you're you're, you know, cloud code is going to trip here and there. So, we're going to go ahead and uh 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 cloud MD file, the AI employee operating ma manual, business in one line, we've

[10:28] got the roadmap.mmd, uh we've got the review.md. We've got the folders there, but we need to optimize it more. So, um I got this prompt ready. How do you optimize a claude MD 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

[11:04] 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 inbounds leads faster. So you're reminding it what what are we

[11:27] 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 5 seconds. The demo flow should work on desktop and mobile. You use specific customer language. All this stuff you're putting in your cloud. MD file because you want to just you want it to know how you work. What is what that you know what does success look like to you? Um and just you're guiding you're guiding you're mentoring you're mentoring it. So we've now gone and

[12:01] optimized the cloud.MD MD file. Really, really helpful to do. All right. So, it's updated my claw.md. It's actually updated my review.md, but I'm going to talk about how we can do give it even more feedback on review.mmd. The next step I want to do is is basically tell claude what it needs to focus on this week. So, we're going to talk about uh how you can optimize the road roadmap.md file, which is basically what is your goal this week. So I say the current goal is to build a simple simple demo that shows how a medka med spa can recover misleads. And this week I want

[12:41] you to focus on a landing page, a weight list 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 want it 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 looks like to you, uh what is acceptable

[13:24] and not acceptable. So I've got a prompt here for that. Um, 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 want to say, can a first-time visitor understand the offer in 5 seconds? Is the CTA visible? Is the copy specific to the buyer? And does the page use the words c would uh customers would

[14:00] actually use? So, this is specific to my med spa idea, but you can imagine how you can use this for whatever idea you're looking at looking looking at. And you're basically just you're letting Claude know that uh hey, you can't just ship garbage. You know, we can't ship AI slop. And the beauty about, you know, Opus 4.8 eight 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 this these guard rails. So, it says the review.mmd is now complete. The works workspace scaffolding is essentially done. Claw.md road map review and all

[14:40] five folders are populated and consistent with each other. Um, 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 clawed 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

[15:17] 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 want to use something that's simple and concrete. I'm just going to ask Claude to add a weightless form to the landing page. But instead of just saying add a weightless 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

[15:56] use plan mode. I want to add a weight list form to the landing page. First inspect the current app, the claude MD, the roadmap.mmd, 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 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

[16:34] uh cooking right now. The important thing here is you're now going to have something to react to. Um, and it's not it might not be perfect. Um, 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 simp the form isn't simple enough just give me name, email, company. Um, 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

[17:07] 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 text stack. It says Nex.js with TypeScript. Um it tells me the user experience. It explains what it looks like, the oneline promise. So I can go and review all these things. Shows me my risks like spam and abuse. Um and just gives me this whole plan. And I then can go and say accept um if I if I like it or I can give it I can reject it or

[17:42] revise it um 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. Um, 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

[18:20] 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 approve the product," right? You would say, "Do a specific task like add a

[18:37] weight list form to the landing page." It should collect a name and an email and a company and after someone submits, show us a simple success message. Um, 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 homepage or fix the onboarding redirect bug or fix the onboarding redirect bug

[19:20] after the email verification. Um, 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. Um, and you could review the work afterwards. Um, 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 5 has done an amazing job

[20:04] 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

[20:42] quick translation is it tells you the before and after. So, if Claude is going to go and edit, copy, adding files, removing files, um, the diff is going to show you exactly what has changed. And what's cool 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

[21:20] know, it's hard to really trust it. Um, 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. Um, you can see here visually it shows here's the file, here's what it does. Here, I'll make this a little bigger. Um, it's just giving me uh, you know, it's it's it's changed this shell. It's done this headline. It's made mobile first uh, styles. It shows me what has been tested. It shows me what it

[22:03] couldn't do and why it couldn't do it. and it tells me what actually needs human review. Uh 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

[22:31] 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 cloud 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

[23:05] 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 are bigger than the browser preview. It's a bigger idea. You know, Claude can do things like run the

[23:31] test suite. It can check console logs. It can check network errors. Um, check it could check if the form actually fills the submission. So, it can do really anything. And after Claude builds the weightless 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 going to go ahead and check that and and see how that works. So, here's my prompt. Start the app and inspect the weight list flow. Open the landing page in desktop preview. Check the experience from the point perspective of a med spa

[24:07] owner seeing this for the first time. Then verify the imple implementation. And then here you say, tell me what what the buyer understands in the first 5 seconds. What feels confusing or low trust? Whether the weight 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. Um 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 firsttime visitor. Empty

[24:49] submit first. Click join the weight list with nothing filled. So then it says the empty state works. It 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. Um and that's why this is important to do. You can see the su success state has rendered. It's verifying the backend that it wrote the record. It's checking the console and

[25:13] 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 with no reassurance about what the weight 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 microcopy 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 Claude Code has eyes, right? And it's amazing how few people actually use the eyes. So when you when you make it a

[25:52] part of your process, you're going to have better QA. You're going to have just better, you know, better product in the end because you're testing it. Um to make sure, you know, it could work, it could do things. It's how you want it. Um 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 click quickly as you see the bottom the bottleneck moves to judgment. So did it solve the right

[26:32] problems? Did it change the right files? Did it create this like weird edge case? Um did it make the product clearer for the customer? Um, 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

[27:03] view in in cloud desktop. Um, like we talked about, a diff is shows you uh a before and after of what's changed and look at the files that Claude has touched. You 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? Um, and surprising changes is usually where the risk is. So, it's an important question to ask. If Claude was supposed to add a weight list for him for example and suddenly it changed O and routing and databases and stuff like that I would want to know that

[27:42] 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 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

[28:14] 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 going to pay dividends. Um, 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 mustfix, should fix, and okay to ship. And you know, it asked

[28:46] 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 might want to do slash ultra review. So if you see here, it says launch a remote remote ultra view session for this repository. And that's going to be, you know, before before you're actually posting in production,

[29:24] 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 sixth piece is the schedule. Um, 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 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

[30:04] bit more valuable in the sense that they've got this repeating responsibility um 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." Um, that kind of work is, you know, quote unquote boring, not glamorous, but it's the exactly ex 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

[30:40] right there. Um, I wouldn't start by asking Claude to ship production code while I'm asleep. Um, 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 7 a.m. read slashc customer slcontext open github issues if it's connected and then create or update slashcontext morning brief MD with the top customer painoint from the latest notes one product risk one recommended build task for today and one

[31:23] 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? Slashc customer/context. Um, and and now you're you're probably starting to see like how this all kind of comes together. So, let's set up this

[31:46] 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. Um, and took like a few seconds to to uh 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

[32:25] 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 slashcontext/weekly opsmd. 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. Um, maybe people had the same onboarding problem and it's going to help you like prioritize your week and and it's it's it's almost like a chief

[33:10] 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 uh poll request. So, I'm going to say when a poll request

[33:31] 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. Um, so you know, once this is done, you're going to have every morning

[33:54] Claude code telling you what matters. It's going to be telling you the patterns. Um, and then every pull 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

[34:20] 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. Um, so

[34:51] it's not really one employee, right? You're you're you're duplicating 5, 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 cloud 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

[35:36] 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. Um and you want the med spa med spa owner to understand the value in the first 5 seconds. And the last thing is sales. Um maybe you've got a bunch of customer notes and you want

[36:09] to turn them into a sharper demo script. Um those are all really different jobs, right? Um one is debugging, one is product and copy, one is sales enablement. Um in the old workflow, I would probably do those one after the other. Um, in the AI employee workflow, I can give each one its own cloud session and with the same product context, and a very clear output. So, the bug session uh fix should come back with the root caused, the files it changed, the checks it ran,

[36:45] 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, um, 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 a gile 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

[37:24] 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 changed, the checks or tests you ran, what you should review in the diff, and anything

[37:59] anything that feels uncertain. Now for the landing page uh 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 5 seconds. Use claw.md roadmap md review.md and the latest customer notes. Important to include that there. Keep the change focus on the hero section unless a small supporting change is necessary. And when you're done, give me the before and

[38:30] after, etc., etc. 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, etc., etc." 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 uh work streams, you have Claude move

[39:10] 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 cloud can do freely. There's some things that cloud should ask about. Um, some things they got to 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

[39:53] draft pull request. Ask first actions are things like installing dependencies, changing database migrations, touching authentication, uh changing payment logic, deleting files, things like that. And then humanowned actions are production deploys, uh customer data uh decisions, uh billing decisions, um security sensitive changes, like you still want that to be a human beingled. Even if you do have AI employees, that high-risisk stuff, you still want to be with human beings. In cloud desktop, you can actually choose permission modes

[40:34] 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. Um, and I wish more people did that. You know, going yolo mode. Um, it's it's a bit too risky. Um, 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

[41:17] understand is skills, connectors, and hooks. This is our last piece. Um, 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 5-second

[41:56] 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' read latest calls or support notes and pull out the exact words that customer use customers use, the repeated objections and the buy buying triggers um that keep showing up. That's super super useful because now Claude isn't

[42:22] 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 going to save you hours every single week. There are places you can download skills um or you can just you

[43:00] 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 if you 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 guard rails around the work. So after Claude edits code, run formatting. You

[43:41] 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 road map, 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 with uh with all these things. These are like powerups for your business. And you you can imagine that this is kind this is creating a kind of moat you know if you have a really good

[44:22] system around this it's creating a moat because you're going to get really good outputs uh 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 to yourself like okay how can I actually make a plan to try this? Well, here's a 7-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 7 hours, you can do it in 70 minutes, you can do it

[44:56] in 7 days, you could do it in 31 days. Um, it depends how technical you are, how much time you have, are you working a job? Um, 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 cloud MD, the roadmap MD, the review MD, the SLcontext, the SLC 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

[45:31] editing. Uh, 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 weightless 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.mmd and and use the review code flow for a serious

[46:15] 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 slashc 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

[46:45] 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 slashc customers. The product direction goes into roadmap.mmd. The working style goes into claw.md. The quality standards go into review.md. Small tasks go through plan mode.

[47:11] Changes go through preview and review. Recurring work becomes a scheduled routine. And that's the 247 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 going to be perfect. Um, but once you start building like this, you're not going to build like the old way. in the in the show notes in the description, I'm going to include all the prompts that I went

[47:47] 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. Uh you can use cloud code, you can use other systems, but you know, do it. Have fun, get your

[48:05] hands dirty, and I'll see you next time. Have a creative day.

---

About this transcript
Read from YouTube's own caption track and laid out by ViewRank AI (https://viewrankai.com).
ViewRank AI finds the videos already beating a creator's own average on Instagram, TikTok and YouTube Shorts, transcribes them from the audio itself in more than 60 languages, and turns what worked into new ideas and scripts.
Free transcript tools, no account needed: https://viewrankai.com/tools
How to read any video this way: https://viewrankai.com/llms.txt