I'm honestly blown away
by the huge disconnect between
people like I have here on the left where they say, I tried Cloud Code on your recommendation,
and I have a very different opinion than yours. It was horrible.
Then you've got people over here on the right that say Cloud Code made programming fun again. As you may know, I fall more on the right side.
And I've been thinking a lot, like, why
do I see such a divide between
people loving Cloud Code
and then people absolutely hating Cloud Code?
And I I got to thinking, like, maybe it's just the way I'm using it. So what I wanna do today is I wanna break down all the different things that I've learned.
I've tried to actually capture everything I could,
all the techniques that I use.
And I'm gonna go through them one by one. I won't make this incredibly long, and I'll try to put time stamps below so you can kinda jump between them. So the first tip that I wanna talk about is something brand new, but I have loved it.
Like, this is actually something that I didn't realize how much I missed,
and it could be one of the reasons why a lot of people still really prefer root code.
If you hit shift, tab, tab and let me pull over the terminal here. So shift, tab, tab, you can see over here on the bottom where it says plan mode on.
What you can do is you can actually
have a conversation with Claude,
And, basically, it will generate a plan of all the things it's gonna do, and then you could just kick it off and run it. It's magical.
Now I have someone in Discord to thank for this. This actually just released a few days ago. Definitely try it out. Shift tab tab is not an obvious,
like, thing that I would actually normally hit,
but it is there now in the latest latest version of Claude.
Now
the tip two that I would give you is talk to it like a teammate. There's a few different ways you can talk about talk to it. But you can you know, think about how you would talk to another engineer.
Ask it questions about the code.
What does this class do?
Which API
like, one of my favorite things is I I couldn't remember the name of an API.
And I was like, you know, I was like, start and all this stuff.
And I said, okay.
Uh, when onboarding starts,
what API am I calling? And in a few seconds, you know, it ended up having the answer for me, and it was correct.
You can also do things like change the login button. You don't even need to point to the component name.
Um, you don't even need to put to the file.
It does help it speed things up if you do point to the file, which I'll talk about in a minute
There's a button
that says create campaign. When it's clicked, I get a 500 server error from the API. Here is the log.
That is a that is one that I actually used yesterday
because I was getting a weird 500 error
for, uh, just a field that was missing. So then
it ended up fixing that for me, and I didn't have to go in and actually do anything too crazy there. You can also do, like, explain this thing to me. It it just works really, really, really well. Here's another project that I've been working on. I say, can you tell me what the API is for logging in
and the format?
And it
starts to answer that question for me. It does a great job on it. But I also recommend being more precise and surgical.
In this file, I need you to add a function that validates x y z before letting the user click sign up.
Here's an example of one that I did.
In this file, the calculated LTV last 90 is different from what shows on this file.
In this case, the number of customers is the same, but the LTV is different.
Work through the likely calls and a proposed plan to fix it. Very surgical. Like, I don't want it to actually
code anything. I actually wanted to go try to figure out what the problem is. I'll kick this off and I'll go work on something else. It ends up being a very minor change or
it may be a little bit more in the weeds. I can kind of take control of it if I need to there. Now this is one of the prompts that the formats that I like to use for long prompts. So a lot of times I'll be working on a new feature or I want something a little bit bigger.
You need to be even more precise.
So I'll use XML tags that I actually I know this is crazy, but I have like a million notepad on my Windows.
A billion notepads open.
And this is the format that I'll use. I'll use things like instructions,
requirements, testing.
Great tags to use.
Clog code seems to follow those really, really well. So I'll build something like this where I'll this is an exact example that I actually used.
So I will say build a serverless user authentication system using AWS Cognito, Lambda, and CDK,
and then I kind of fill in all the stuff. So I'll go through and tweak this. I actually will use AI
to help generate this originally, uh, initially, and then I just go in and kinda manually change it.
And this will help a ton
with the way that the Cloud Code will actually pick up this feature and run it. I've, uh, Cloud Anthropic itself actually talk about how well Cloud has been trained on following XML based tags, and you can actually reference them in other
parts of the prompt. For example, you can be make sure you refer back to this information area or make sure you do this particular thing. And I actually use that a lot in my production prompts as well. So this is a you know, this is an example of a prompt that I would build outside of Cloud. I wouldn't just type it in, and then I copy and paste it in, and we're good to go at that point.
Make sure you use a net to create a Cloud dot m d file. Talked about that a little bit, but also make sure you keep it up. So tell it to update it once in a while. This is something I've talked about in previous videos quite a bit, so make sure you just are aware of the slash init command. That's a very, very, very powerful one.
Now this is one that I know a lot of people don't know about. But let's say for some reason you end the day, you close out the conversation, cloud exit, you can simply hit claw dash dash continue to load up your previous conversation.
You're good to go. It's super helpful. There's also ways to go look at your clawed logs and grab the idea of a conversation,
and then you can load that in as well. But claud dash dash continue is the one I probably use the most. Because most of my conversations, my old ones, I don't really want to resume them very well. For the longest time, I was actually
exiting claud or opening up another terminal to actually interact with GitHub. And I still do this quite a bit,
but there's no reason to always do that. There are times that I just want to go ahead and commit.
So you can literally just type in commit into ClogCode,
and it'll actually go through. You could see here where I've actually been asked if I wanna git add that file
and basically eventually do a git commit dash m. I do actually love the commit message it has here. Another thing that I'll typically do, though, is if I
am if I wanna do the commit myself, I actually tell it to generate a commit message for me. I'll copy and paste it, and I use that.
I typically don't use it, but you can actually use the push as well. Um, so you can say,
uh, push branch or push to dev, and then you could actually get it to to to go ahead and do the push for you as well. Again, you do need to have git configured correctly to make this work, but it is a very useful thing if you just really wanna kinda have it do its thing in particular.
Now this is one I freaking love. So now we're starting to get into some stuff that I probably would think that you guys probably haven't tried yet.
So let's say that I'm in a,
uh, I'm in a terminal,
and I just have an idea for something I wanna go to lunch.
So I will say something like claw dash p. So this is basically it's just gonna sit there and do the work behind the scenes. I don't have to interact with it. I don't have to approve anything.
I'll say, I want you to make it so that I can attach a user avatar via an URL to my user record. I need an APN model update.
Very basic.
And this is what ends up happening. Like, I get back this once it's finished. All the work's done. I can then now go in and review it.
This is great. You can kinda think about this like a local
codex. You can just kinda kick off these tasks. And sometimes I'll kick off couple of them at a time in different parts of the code, and then I'll come back to it
and just see what it did. Now but you do end up losing the interactivity to it. So if it's something that, you know, you kinda wanna have a conversation with or be able to iterate on,
you do want to not do the Dashpeak. But it's so freaking awesome
if you just wanna get a start on it and treat it literally like codecs
or some sort of remote aid agent.
This is one I've started using a bit more. This is a new project I'm working on. But in general,
what I wanna say is like Claude custom slash commands.
You can actually create your own slash commands by going into your dot Claude folder, creating a folder called commands,
and then making a markdown file.
In this case, let's just say I wanna do an update docs one.
So I'll say evaluate the current project, evaluate the current documentation,
update cloud dot md with any new functionality, update other documentation as needed. And now you can see I do slash,
and I have that command in there. This this is a
brilliant,
like,
brilliant addition
that I've actually started to play around with a lot more in my main repo that I work on a daily basis. I think I have two three, actually, that I've created, all very, very useful.
This one is one that Anthropic kinda recommends where you can be like, please analyze and fix the GitHub issue. You can pass in a number for the GitHub issue, and it has the these commands here. Like, follow these steps. Use GitHub issue view to get the issue details, etcetera, etcetera, all the way down to push and create a PR to literally automate the entire thing
without ever interacting with it. It's super, super sweet.
This is one thing a workflow that I've used, and I use this with other AI too. But have
Claude
review work from Claude, and you can have one in Opus and one in Sonnet. Now I primarily use Sonnet just because I want as much
usage as possible.
But I will, a lot of times,
basically, go through and I'll have something done.
And then I'll be like, alright. This is a new file I created.
Go review this in another window. So I basically bring a new context. Look for issues.
You can make a prompt for this as well, by the way. You can do a prompt,
uh, a custom prompt if you have, like, special review guidelines,
and it gives me the reviews,
I will typically go through and have a conversation about this, get it to the point I want, and I give it back to the one that actually built it, and I have it iterate on it. It's very, very handy to start thinking about AI,
kind of iterating on things that AI has actually done for you. And Cloud Code is perfect, absolutely perfect at that. Yep. Use screenshots. Really use them. You can drag and paste or drag and copy them directly into the terminal. This is what it looks like for me when I do that. It works on WSL.
It also works really well in Linux.
So in my case, what I typically do is I'll just drag a file itself into the terminal. It really, really is handy, especially when you're doing design stuff or if there's a UI bug. Copy and paste it in there or just drag and and put it in there rather,
and then have tell it what's going on with it, and it helps it so so much. So definitely
use screenshots. Don't be afraid of them. I know a lot of people like the computer use and some of the other tools. This is one of the prompts that I've been using quite a bit. Again, I have what I do is I have,
um, these little text files I save on my desktop. My desktop is a mess, by the way. I need to organize that. But I
will do, like, a TDD type prompt, and notice that I'm using the XML format.
I'll do three different tag types, so test, implementation, and rules.
And then I'll say, we are doing test driven development. The implementation does not quite exist yet. Please implement my test, then implement the functionality to pass the test. Now you can actually go on and say, go ahead and commit and do a PR as well. I actually wanna review the code before that happens. So I do just usually stop it here. You can add any rules that you want in there. This is a very, very cool way because it actually
makes ClogCode pretty powerful. If if you have something kinda isolated enough
to where you can just have it iterate on to make the tests that it wrote pass, it's pretty pretty freaking powerful, to be honest with you. So definitely give this a try if you haven't already. You may even have a better prompt than what I have here, and I would love to hear that in the comments below.
Now this is one that I think a lot of people were most surprised about,
but it is so so helpful.
So I use a combination of ultra think,
but also a few other things in this prompt. This is the prompt that I save, and I just copy and paste it in, and I fill in what I wanna do. So I'll say, please ultra think through this. Start by exploring the code base and gathering the necessary context.
You should use sub agents where it makes sense. I want you to explore, plan, and implement the following.
So, basically, take a look at this example
here.
All of the stuff I just said, implement a new table for child profile. This should include name, birthday, and avatar name, avatar image. Child profile should reference a user as the owner. The users add them to their account. It's possible in the future that other users will have access to viewing child profiles
owned by a different user.
And it goes through
and starts to do work. So you can kinda see some of the thinking that it did here.
Then it builds a really great task list manager or a task list of things that it needs to go through and do. And this is spot on. And the implementation here was incredible.
And you can see that we've now triggered this thinking dot dot dot because we've told it to think harder. This is all done with Sonnet four. This is not Opus. I've heard people could say they get even better results
from Opus, but I have
again, I have most of my testing has done been done with Sonnet.
Now the last thing that I wanna do say is don't be afraid to throw away what it does.
This is something that
I feel a lot of people struggle with. And if I were was a betting person,
I think a lot of people spend a lot of time fighting AI
to try to get it to go back on the rails when it's already messed something up.
Git commit.
Git commit. Throw away things that mess up. Go back. Start over. Reword it. It is okay. Like, code is now pretty cheap to generate. So if it goes off the rails, go ahead and just wipe it away and start over.
So my hope is that I'll start to gather even more information over time to try to understand
why there is this, like, massive disconnect. And I see this. I'm talking
tons of messages,
uh, saying, I love Cloud Code or I hate Cloud Code.
And there may just be a nature that people are not CLI based users.
You know, it is a just a different experience.
And I can't fault anyone for wanting to go back to a group code. I love group code. I still use it on a daily basis.
But I also think CloudCode really
does
make programming very fun. I don't know another way to actually explain it other than I just have so much control
of how I actually wanna get things done.
And I can choose, like, I could choose to do a one shot and let it go. I can actually have it go really deep and build a task list. The control that I get on it is just absolutely
incredible.
So, anyway, I hope these tips have been helpful to all of you. If they have in some way, let me know in the comments below. If there's new ones that you actually know that I haven't included here, um, this is just my own personal,
uh, way of using CloudCode. I'm sure there are
ways that people use it that are beyond my,
uh, beyond my knowledge at this point, which would be amazing to learn for myself.
Anyway, I hope you guys all have a wonderful day. And until next time, everyone. Peace out.