Transcription
Well, hello there. So, back in January, the creator of Cloud Code, Boris Chenry, he actually posted about his entire workflow. And I actually had a chance to meet with him and ask him a bunch of questions. And I personally found his personal workflow very enlightening. And I've been trying to replicate a lot of his workflows directly into mine. So today, I thought it'd be fun to go over this chain of thread posts that he made, and also kind of show you physically what it actually looks like in practice.
Now, I have a few local projects. They're nothing really in terms of complexity as my projects for work, but I thought it would actually work pretty well to kind of showcase some of these and kind of like interact with some of them right here. So, as usual, I created a little slide deck, so let's get right into it.
So, this is Boris Chenry. For each of these, I'm just going to read it out really quick, show you each of the tips. "Hi, I'm Boris and I created Cloud Code. Lots of people have asked how I use Cloud Code, so I wanted to show off my setup a bit. My setup might be surprisingly vanilla. Cloud Code works great out of the box, so I personally don't customize it much. There is no one correct way to use Cloud Code. We intentionally build it in a way that you can use it, customize it, and hack it however you like. Each person on Cloud Code team uses it very differently, so here goes."
I really like how he set up here that Cloud Code can be customized. I personally have been customizing the hell out of it, and at some point, I'll probably share my own personal setup as well, but I really like how it starts out here. So, let's get to the first tip.
The first tip is around running clouds in parallel. "I run five clouds in parallel in my terminal. I numbered my tabs one through five and use system notifications to know when a cloud needs input." So, look at this. I will open up my terminal. All right, so it looks like what he does is he creates a cloud like this. And then he has one that is just for like, just a terminal for bash. So it looks like this is a setup. And then he has multiple tabs like this. And then he probably replicates this cloud tab system for all of them, right?
Now, I actually work very similarly like this. I'll have one instance here, one instance there. I'm using like hotkeys. For iTerms, it's Command 2, Command 3, Command 4 to switch between. And then you could switch in between the tabs by doing Command Left Bracket or Right Bracket. Now, one additional tip here that I like to do to keep things like in my mental context is to like rename it. So, this could be like local one, or maybe the project that I'm working on, local. This is push to prod app, for example. And then here, maybe instead of this, I work on my anime Pomodoro app, for example. And because I did that, I will name this local anime.
Now, you could imagine that you would have like SSH or some kind of on-demand stuff as well. And this is exactly what I do at work. So that's tip number one. It also looks like he uses light mode. I am not going to switch my dark mode to light mode.
Okay. Tip number two is five to 10 web clouds. "I also run five to 10 clouds on clod.ai/code in parallel with my local clouds. As I code in my terminal, I will often hand off local sessions to web and I will manually kick off sessions in Chrome. And sometimes I will teleport back and forth. I also start a few sessions for my phone from the Cloud iOS app every morning and throughout the day and check in on them later."
So, this is clod.ai, and I actually haven't done the teleport feature, but let's try the teleport. I don't know if it will work, but for my push to prod app, let's work on some of the printify integrations. Give me a plan. So it looks like it's whatever sessions are on here, it just maintains here, but let me see if I can do a slash teleport. I'm just going to try. Can you, can you push to the web? I shall teleport. I'm just going to try this. Okay, this is taking a long time. I'm just going to cancel this and create to-dos for print to buy integrations.
Okay, so it looks like it's creating a background task. Look at this right here. So you just hit and like this, and then, um, it creates a session, and then you can basically open the session like so, and it's going right here. That's really cool. I actually haven't been using this, but I can imagine doing this, especially when I'm like ready to go off for the day or something like that. And it's synced to your phone. If you look at this, it's synced. So, so you can start new sessions here. So I actually didn't know about this, but this is actually mind-blowing to me. That's awesome. I'm going to start using this all the time.
Okay. Next tip. Tip number three is Opus with thinking always. "I use Opus 4.5 with thinking for everything. It's the best coding model I've ever used. And even though it's bigger and slower than Sonnet, since you have to steer it less and it's better at tool use, it's almost always faster than using a smaller model in the end."
Now, he posted this before Opus 4.6 came out. So I wonder what he's thinking about it now, because Opus is like known to be a lot slower. So, one thing you can do is you can switch though, like this. Oh, so using slash model. And I actually also just default to 4.6. They got rid of ultra think, which used to have this little like animation thing, but, and if you have like just multiple like sessions of Cloud Code going, then it doesn't matter if it's that slow in my opinion, right?
Tip number four is share your cloud.md. "One cloud.md for the whole team checked into the Git. Update multiple times a week. Our team shares a single cloud.md for the Cloud Code repo. We check it into Git and the whole team contributes multiple times a week. Anytime we see Cloud do it, do something incorrectly, we add it to the cloud.md. So Cloud knows not to do it next. Our team maintains their own cloud.mds. It is each team's job to keep theirs up to date."
Now, I actually asked Boris what his personal cloud.md is. And he said, there's basically like two lines and it just points to, um, using the cloud.md. And so, so the whole idea is that they're doing compound engineering and then context engineering right within the codebase. I have a video coming up around this on agentic engineering, but, but yeah, it's very simple. I also am doing this now where, for example, like this Pomodoro app, I have the cloud.md directly here. And it's kind of like things about my codebase for iOS, the navigation flow, the design patterns, and things like that. A lot of this stuff you can just create using slash init. But yeah, like this is like very straightforward stuff.
All right. Tip number five is add Claude in code reviews. "So during code review, I will often tag add Claude on my coworkers' PRs and add something to cloud.md as part of the PR. We use Claude code GitHub action slash install GitHub action for this. It's our version of at Dan shippers compound engineering."
Now, so I actually kind of set this up. So you can see that like right there, Claude's there in this workflow. Um, let me try, try making a quick PR, write me a quick PR on some of these to-dos and push it as a separate branch. So the whole idea is that you should theoretically, once this pushes, do an at, and then do a review. Now, obviously, this is like not a good example that I'm doing because it's just to-dos. But theoretically, the whole idea is you develop a system so that it automatically uses Claude to review your diffs or do other actions.
Tip number six is plan mode first. "Most sessions start in plan mode, shift tab twice. If my goal is to write a pull request, I use plan mode and go back and forth with Claude until I like his plan. From there, I switch it into auto-accept edits mode and Claude can usually one-shot it. A good plan is really important."
So, I, I also do plan mode all the time as well. So, for example, here, I want to create a new live activity for my anime Pomodoro app, where it keeps tracks of the timer in my like live activity and also dynamic island. All right. There's something definitely wrong with this UI here, but it's going. So I really like plan mode, because it's a way to really analyze and deep dive into your codebase before you actually make any changes. Someone asked me recently, why do you even have multiple cloud instances? What are you doing? A lot of times, if I'm not using Git work trees, or like some way to do multiple coding executions, I'm actually doing a lot of deep dives using plan mode for like different parts of the codebase. So maybe I have like some kind of performance optimization project I want to do on media viewer, maybe I want to do look into app init or app start, whatever I'm trying to investigate. I actually use plan mode. And also for like investigating SEVs or investigating like random bugs, I'll also start with plan mode to start investigating. And plan mode is essentially a way for you to create prompts, like gigantic prompts, like really good prompts. And I talked about context engineering and things like that. But plan mode is where you do the orchestration to be able to bring all the context that you need into that Cloud instance so that the agent can execute correctly.
All right, tip number seven, slash commands for everything. "I use slash commands for every inner loop workflow that I do many times a day. This saves me from repeated prompting and makes it so Cloud can use these workflows too. Commands are checked into the Git and live in .cloud/commands. For example, Cloud and I use a slash commit-push-PR slash command every day. The command uses inline bash to precompute Git status to make the command run quickly and avoid back and forth with the model."
Okay, so if you ever wonder how you want to make a slash command, it's very, very easy to do. So let's just go here and say I want to create a commit-push-PR skill. And this skill needs to format my code and then add everything that I just did in the session and then commit the code with a good commit message. I always want to push it as a PR rather than directly as main so that I can review the code online, something like that. And these days, actually, slash commands and skills are basically the same. So Cloud will usually create the same thing now.
You know, the thing about making these videos is that it just takes a long time because Cloud takes a long time to run. I probably should have ran this on Sonnet, but it's okay. Opus is fine. But you can see here that it's exploring the skills first so that it's not remaking the same thing. And I love the fact that Cloud Code and Codex, they ask questions rather than just assuming. And I think this is like a big change between like, I don't know. I haven't used Cursor in a bit. Maybe I should give it a try. But I remember it just like kind of did stuff without it. Always just made assumptions, which and it always turned out like not great.
All right. It decided to name it slash ship, which is fine to me as well. But yeah, that's how you create skills. It's very easy. You remember all you need to do to make skills or slash commands or sub-agents or install MCPs, it's just leverage Cloud Code to ask you to do it.
All right, tip number eight from Boris is custom sub-agents. "I use a few sub-agents regularly. Code Simplifier simplifies the code after Cloud is done working. Verify app has detailed instructions for testing Cloud Code end-to-end and so on. Similar to slash commands, I think sub-agents is automating the most common workflows that I do for most PRs."
Now, one thing about sub-agents I want to say is that it's really to protect the context. Sub-agents are really useful if you want to do like side effects or if you want to just have the result of that like Cloud instance running. You don't really care how it got there, but you just want the output. That's really good for sub-agents. There's a new thing. This that just came out with Opus 4.6 called Agent Swarm or Agent Teams. And I'll probably do a video on this, but it's the idea of sub-agents that have actually different roles and they share context with each other. And there's like a master orchestrator. I think in my other video, I show what a sub-agent is, but I should have some sub-agents here. Agents, you can see here. I actually have I created the same ones that Boris made because I thought it was very interesting. Yeah, so I could just say right here in another instance, "Can you run my code architecture sub-agent to verify the integrity of my build or integrity of my app?"
I don't know about you guys, but I run out of RAM all the time at work. I think one, my codebase is extremely large. And then I also have like five or so Cloud instances running all the time. Um, I had to give up running Android Studio completely or like I just had my terminal up. I don't even have Chrome up sometimes when I'm running out of memory. So yeah. So you can see that it's running two agents here. Let's do Control O to expand it and just see what it's doing. Yeah. Code architecture is reviewing. I don't know. All of this stuff is so cool to me.
Okay, so while that's all going, let's go back. All right, post tool use hooks. I don't know why it's hard to say, but we use a post tool use hook to format Cloud Code's. Cloud usually generates well-formatted code out of the box, and the hook handles the last 10 to avoid formatting errors in CI later. This one, there's not much to show. You can create one just saying post tool use, and it's very similar to like pre-commit hooks. It's nothing new here.
All right, slash permissions and not dangerously skip. Number 10, "I don't use dangerously skip permissions. Instead, I use slash permissions to pre-allow common bash commands that I know are safe in my environment. To avoid unnecessary permission problems, most of these are checked into .cloud/settings.json and shared with this team." This is what I talk about like in compound engineering where this you need to like start putting things like this into the codebase and share with the team. A team needs to be like AI native first, and everyone has to kind of start agreeing on some of these these like ways that we need to work, and that's how you really move quickly. But yeah, so quickly showing you guys, you can do slash permissions here, and then yeah, slash permissions. There's a bunch of things here. And I would just say you can update this manually, right? "Can you update my permissions list so that all bash scripts are okay to run?" For example, you could do that. Like I keep saying this, but don't manage your Cloud Code instance manually, you know, just have Cloud Code do it. And then after you do this, you can always push all of this directly into the codebase. You see it's trying to change the settings right now.
All right, while that's going, tip number 11, MCP for all tools. "Slack, entry, Cloud uses your tools, not your codebase. 11, Cloud Code uses all my tools for me. It often searches and posts to Slack via the MCP server, run BigQuery questions to answer analytic questions using a BigQuery CLI, grabs error logs from Sentry and Slack. MCP configurations is checked into our MCP.json and shared with teams."
Now, I always say be careful with MCPs because they're. They're known to blow up your like context window. Only leverage it when you need it for a very specific things. If you see what these are, these are very like outside of the norm of regular coding and even like Slack, right? Like this is, so we have this integration similar to our internal communication channel. And I use this as a, with a combination of our like PR reviewing thing, where I'll just pull all of my context from the PRs, read the diffs that I wrote this week. And then I'll have it summarize that. And then like send status reports to like specific threads that I want. So using Cloud Code to manage your work besides just coding is like a whole like big thing.
Now, there's not much to show here, but for MCPs, you should always just kind of be careful because I think like MCP is also another place where prompt injection is going to start happening. Same thing with downloading plugins and stuff like that. I think just be careful when you're doing these and just always have Cloud Code review the MCP before you install it.
Okay, for number 12, long running tasks. "For very long running tasks, I will either prompt Cloud to verify its work with the background agent when it's done. Use agent stop hook to do that more deterministically or use Ralph Wiggin plugin. I will also use either permission mode equals don't ask or dangerously skip and sandbox to avoid permission prompts for the sessions. So Cloud isn't blocked on me."
So now I don't really use dangerously skip too often or even Ralph Wiggin. Tried Ralph again. Ralph is this right? So this is the Ralph Wiggin loop, basically. You just have a task, you have the agent, you have the file system, and then it just keeps looping until it's finished. I don't really like this because I feel like there's it's too, I don't know, there's just so much uh work that needs to happen for you to have like a spec that's like so perfect that you can just have something like Ralph build the whole thing. But honestly, for side projects and things like that, I might just spec the whole thing out and I don't really care too much. And it's it's okay to let it run uh overnight or whatever. And it's okay. And the whole idea is like you do it a few times, maybe and then get a different result every single time. And then you kind of test out if it's good. And then you could throw it away and then start engineering. I think there are times when it's actually pretty good. I think the hype around it has died quite a bit. But yeah, like if you want to use it, I'm not going to show how to use it here. But you just install the plugin that I showed you earlier and then just start installing it.
But to do dangerously skip permissions, it's very easy to do that. So, for example, when you're here, let's exit here. When you do a Cloud, you can do just a Cloud dangerously skip permissions like that. And then now when you ask Cloud to run something, it won't ask you any permissions. Basically, it's okay.
13, a final tip, probably the most important thing to get good, great results out of Cloud Code, "give Cloud a way to verify his work. If Cloud has that feedback loop, it will three to two to three X the quality of final results. Cloud tests every change I land in cloud.ai/code using the Chrome extensions. It opens the browser, tests the UI, and iterates until it works."
So let's give this a try. "Can you run an end-to-end integration test navigating the website from the homepage to the detail page? When you click on a poster, make sure the title is the same." Okay, so it just launched the website. I'm gonna try to show it. Okay, there you go. Check that out. Okay, so it navigated to the main website. All right, so now it went into the detail page and it's clicking on stuff. You can see that it's like taking screenshots and stuff. It's very cool. And this is kind of this agentic validation thing that I'm talking about in one of my other videos. And look, it passes. It like tells you what it did. Very, very cool. And this is like a different form of end-to-end, right? It's not, I didn't like write an end-to-end test per se, right? It just kind of knew how to do it and navigate. You can do really a lot of interesting things here.
So that's Boris Chenly's workflow. I hope you guys enjoy this. I think one of the really interesting things is that if you think about what your work might have looked like six months ago, and then you compare it to like Boris's workflow, it's probably like night and day, right? We were still manually coding at that point, but now we have like multiple Cloud Code instances just going at all times, multiple Cloud Code instances. And you're just like playing StarCraft over here, you know, basically saying, hey, file this PR over here. And then you go to the next one and then you go down and go, oh, update my like backlog task or fix this bug and you switch over. Now, I know probably this is content, right? Context switching wise, mentally, it's probably the bottleneck at this point. And these little quick prompts that I'm doing is obviously not ideal, but you should really challenge yourself to try to like take some of the learnings here. Try it yourself. Like one thing I'm gonna do this week is definitely figure out how to do the teleport things more often. Obviously, I can't do it for my work because we don't have slash teleport yet, but for my personal products, I could just see myself doing this. And I wanna build like an entire agentic validation on GitHub, so that I can just do Cloud Code sessions on my phone and actually code. You know, I did a video around kind of trying to do this with Happy, but in that workflow, it's very hard to test the flow. But with GitHub Actions, if it can actually navigate the web and send me like a GIF of like what it did, then it makes me feel a lot more safe. And I just know that it's validated itself using screenshots and stuff like that.
But yeah, I hope you guys enjoyed this video on Boris Chenry's Cloud Code setup and go and check out my other Cloud Code videos and my engineering videos. And until I see you guys on the next one, bye.