Advanced Claude Code (ft Ray Fernando and Eric Buess)

The thing that a lot of people are missing right now, the fact that it's just hard to use cloud code and figure out where you need to go. You have this magical eight ball that can literally summon you a pizza to generate your next billion dollar idea. And now that you have this tool, how do you actually use it productively? Because when I use it, it doesn't always work. And then other people online say it doesn't work. And then when I use it this other way, all of a sudden, like I'm just in the zone, burning tokens at a million miles an hour. And so how can we actually leverage this intelligence and this conversation today is going to actually help us trigger that out? There is no reason that tools can't be constructed at this moment with the technology as it currently is, that will reliably let you give it a test and you come back in an hour. And the whole thing has been validated. Cloud code has quickly taken over as the top choice for AI coding tools. But most people are only using a fraction of its capabilities. This tool is way more powerful than people realize. And even I wasn't aware of some of the incredible functionality that we discussed today. So in episode 52 of Tool Use brought to you by Toolhive, we have two Cloud code experts joining us to tell us how the pros are using it. There are so many great tips in this video. Every Cloud code user will learn something new. We cover how to optimally set up Cloud code, the benefits of different thinking modes, context management techniques, sub agents, incredible hooks and slash commands, and a lot more. We're joined by Ray Fernando, a former Apple engineer for 12 years in my favorite AI streamer, teaching the whole world how to use AI. He's always cooking up some great content and Eric Busse, an avid builder who's deeply curious and an anthropic super fan. He has tweeted out more high value insights on Cloud code than anyone else I've seen. If you're not following these two guys, you're definitely following behind. This is a Cloud code master class. When you install Cloud code on a new machine, what's the first thing you do? How do you get started? - First I set up an alias for the letter C so that whenever I type C, it opens Cloud with dangerously skipped permissions flag. So I can very quickly hop around to a new project folder in the terminal and I can just type C and then it's open and I can start asking questions. I also try to do keyboard replacements. So like you know, your keyboard texture placement. So I replace the word the little U with UltraThink. And I replace the letter W with what happened? UltraThink and make a plan before coding. So I have a set of just principles to speed up the workflow quite a bit. The next thing I do is install Cloud code docs. And so this documentation allows a simple way for Cloud code to understand what its capabilities are. It has a base set of internal, I guess it's not specifically training, but Anthropic provides it with a set of instructions about what it can and can't do. But in order to get more information about the depth of its capabilities, it has to do a web fetch. So if you ask it, can you do this? How do I use slash commands? How do I use agents, things like that? Then it has to go to Anthropic Docs. And even though if you go to the documentation website, you can click on a copy markdown. It'll give you the markdown file. For some reason right now, Cloud code doesn't go straight to that file. It goes to the web page. It does a command which converts it to markdown and it demos all this stuff. And it takes a little bit of extra processing to do that. But it doesn't seem to have a direct manifest to know where all the other documentation are. So the Cloud code docs what they do is it's a one line installer. They install it and then it puts the documentation locally and it's kept up to date. There's a GitHub action that syncs with the Anthropic Code Code docs every three hours. It downloads that. So when you ask a question, there's a hook. And what the hook does is it tells, so you do for slash docs space. And then you ask your question, that's a slash command, the slash command tells Cloud code where to look for the docs. Instead of going to the Anthropics websites, go to your local path where you've already got the docs installed that are up to date. It also has a hook and the hook does a git fetch. And if it sees new content from the repository on GitHub, then it will do a git pool. And it does that git pool and finishes it before it sends the request to whatever you ask the docs for. So whatever information you want to know. So basically it allows Cloud to be able to answer any intricate to deep questions you have about the new things that came out. So you can say, what's new? It'll tell you, here's a diff from the last a ton of documents are updated for these docs they were updated and these weren't. And then based on those updates, I can see here's a summary of all the things that this many days ago. And you can click on the link to the GitHub and you can see the diff. And you can click on the link to the source and you can see Anthropics Cloud code doc for that documentation. And then you just talked to him and say, how does a slash command work? How can I use it with hooks? What are the sub agents? How can I take advantage of this tool in my project that I'm working on right now? And what would the tradeoffs be, for example? Or what are some unexpected ways that I can connect these together that I might not be thinking of based on this new tool that just came out. This new feature. And so having the docs locally is, I think, the biggest high yield thing that you can do whenever you first get started with Cloud code. It gives you the tool to learn the tool. But I'd like to clear it down a couple of things you mentioned. So you set the flag dangerously skip permissions, which is probably the most intense sounding flag of any CLI've come across. Is that yolo mode or what does that enable into your workflow? Yeah, so there's a lot of prompting you can do. And there are tradeoffs with this flag. That's what I do. And obviously for it's not prescriptive for everyone else. It depends on your use case. But if you're trying to get used to what Cloud does, then it's-- if you don't turn that flag on, whenever a Cloud code first came out, I wrote a wrapper that would, instead of Cloud directly, it would call this other tool, which would then call Cloud code and then attach to the terminal session and send commands to it recursively. And so it basically convinced it was in a sandbox in running a Docker container that got around-- I've kind of did the same thing. And then it gives a flag for dangerously skip permissions. And what that does is it makes it where a lot of the things where you ask you to do something has to write to a file. Maybe it has access to read a file, but maybe it can't change files in this path or run this tool or whatever, then it prompts you. Are you sure you want to do this? Do you want to do it for this session? Or if you have a sub agent and you want to give it access to do stuff, maybe you have to pass in exactly the tools you want to have that. And so it's a little bit more complexity on you up front. And that's fine. But it essentially is yolo mode. So if you're comfortable in your machine and your environment and the tasks that's in front of you to do yolo mode, that's great. Now, I set up a VM that's separate to all this so that I could do snap shots and give it access to everything and it's running on top of my Mac. It's a Linux, so it's a separate sandbox environment, basically. So I feel comfortable with my yolo. But in most cases, I think yolo is-- I haven't had any issues with it doing anything in folders I didn't want it to. There's lots of ways to prevent that even if you're-- you can use a hook, for example, to say before you run this command, make sure it's not in these areas. And the hook is a separate process that runs outside of Cloud Code. And so it can prevent things from happening as an example. And rate, Eric mentioned thinking mode. And I know there's a few different types of commands you can throw in there. How does thinking mode affect the way you use Cloud Code? Yeah, so thinking mode is a mode that I would use a lot for research or specific types of tasks. Keep in mind, there's four different modes. So there's the ultra-think, which is-- can use 32,000 tokens for thinking. And then it goes all the way down pretty much by half. So there's think harder, which would be 16,000. I think-- actually, let me pull this up right now, because I have it on my blog. I want you to think all the way. Just take it all. I've learned an interesting lesson. And this is kind of why I love that we're doing the podcast, because I used to be just Uber ultra-think all the time. And I noticed that I get variable results, and I kept kind of digging into why. And I kind of went back to something that I learned, which is basically less is more type of thing. So I have an article here that tells me-- from my website, Reefernando.ai. And here, basically, you have the four thinking modes. So you have think hard, think harder, and ultra-think as no spaces. And these are key terms that Claude code is going to be looking for inside of its environment. And this one is going to consume about 32,000 tokens. You're going to be 16 here. There's going to be about 8,000 and about 4,000 for thinking. And it's also important to note that these thinking windows are very important for helping users understand how much context you're going to be using up. And if you're using ultra-think all the time, what I discovered is that it's really good to just have your conversation isolated to a specific concern or problem that you're looking for. And you kind of want to maybe eventually start breaking that up. And I could show you why, because of the thing that everyone's talking about these days called context engineering or context window. So I built this simulation to help us understand a little bit of what you're doing if you do an ultra-think type of thing. So if you have some input about 2,000 tokens that you're saying, here's some relevant information that I'm trying to do. And then we do agent thinking. You pop in 8, 16, 24, a bunch of thinking tokens. So you use all this thinking token window to have it do some stuff. What Claude code is going to do is some tool calling to grab some stuff, maybe some code files and various stuff. And then eventually it's going to try to generate like a little plan or some output or stuff like that. So maybe it generates 32,000 tokens. Sometimes I've seen it generate like go through 40,000 or 50,000 tokens just searching through your code base and grabbing different files and things. So once this context window has filled up, then you're going to say, OK, cool. Yeah, let's go ahead and build my next billion dollar SaaS. And then you're like, I want you to do these types of things and make sure you grab all these other files as well. And then if you still have ultra think turn on, it's going to turn. to like then digest those types of things there. You'll do some more tool calling your code and then it's going to start to do some more code output and then eventually the output will not be kind of what you want it to be. And that's just two different conversations that you've had. You're like, dang, I have a 200 K token context window and like, my code isn't as good as what everyone's saying. And that's usually quite the problem here. And they're actually as a study that's been done by Chroma DB that talks about context, rot in a funny way that effective token context window starts to really fall off the cliff after about 50% for most use cases. And it gets distracted if you throw too many different problems. And so it's really important to kind of start with a conversation and then maybe just kind of start branching it off into different components that you want to solve for or something like that. So you as a human will want to review this giant research output that you've just got out and then see if you can kind of break that out into a different plan by doing slash clear. And another technique people use is maybe spawning sub agents. So if we kind of reset this here, let's just say we have a simple query that we do. And this is just kind of what happens. You know, the agent comes back with some more code output or something like that or it did some work. And now you're saying, okay, I have this plan now. Let's go ahead and see if we can execute on this in these different chunks. And you can even ask Claud code to generate some sub agents to try to figure out what it can do from there. So what that does now is it spawns off a whole new session with another set of 200,000 token context window. And that way you can just go ahead and follow on requests and so forth. And each of those sub agents, you kind of want them to really isolate and focus on one specific problem. So that way it doesn't affect the main agent that's at the very top. If there's any reporting or things that need to go back, it will send it back. But then you're now kind of dealing with something that's a little more intelligent. Kind of thinking of yourself as like a manager and you're heading off these, you know, really intense tasks to people to really focus on and get their work done. And that leads to very high code quality and high code generation. So back to kind of like the previous example where we talked about like think, think hard, think harder and ultra think you may want to think about. Maybe if I try something like think hard, maybe not as much tokens, but it can still get me some pretty good results because I still value the accuracy. And maybe for the first request, I want to ultra think because I want to go through a lot more thinking and then because I've had this problem for a while. And I've tried all these techniques and none of these work. So I'm going to feed that in as part of the plan saying, I've tried these techniques. These are some code snippets we've tried. And here's some documentation. I want you to know how ultra think and just, you know, the bazooka comes out and just, you know, go ahead and solve that problem. And that's just a little bit of context in terms of like how this stuff is kind of managed, but I feel like this can provide some oversight on maybe how do you choose, think versus think harder or ultra think and then why some of this visualization for you to see is important, which kind of goes into the topic of sub agents. And I'd love, you know, Eric to talk a little bit more maybe on how do you figure out these like sub agents and maybe, you know, how do you kind of best take advantage with cloud code in these types of environments? Yeah. That was awesome. I loved your visualization. I think that's a great explanation. I feel like these are two related, but independent problems that feed into each other. The issue of, you know, it's like Miller's law, I think it is with humans. You can help five to seven chunks of information and working memory at one time. And then, you know, you get overwhelmed with stuff. So if you, it doesn't matter how good your model is at instruction following benchmarks. At some point, if you give too many, do this, don't do that critical. You must do this like it's very confusing, as far as a whole lot of the more you fill the information space, it can't attend to everything equally at all times. And every, you can think of it like every percentage you focus, it's attention on one thing. It's, it's got a little bit less for something else usually that's separate. And if you keep the conversation going over time, as it gets close to its mass capacity, it's quality about what is definitely going to degrade. It's been like that since the beginning. And I feel like for a long time models are probably going to do that. And that's why cloud code has this auto compact feature, which is really cool, but you don't want to get to like 90% like when says there's 10% remaining, it's probably time to start over anyway. And so that the issue of like the reason I spam the ultra think thing is, is I do, I tend to like starter fresh session, I clear and I have an ultra think based off a previous plan that was well documented because I feel like when you do a project, it's really important to plan not just what your cloud Md should be, but like what the file structure should be, what the instructions that the model should have that kind of deviate from its baseline that you want to change a little bit. So like, hey, don't randomly create a bunch of files. It's just like with these documentation files, don't change that many. You can add, you can change the content, but don't add new ones. The maximum at this many lines profile, et cetera, and then keep them up to date. You can do that with something like a hook or you can do that with the slash command, which is what I tend to use for context reasons. But then at the end, you know, you clear or you compact or whatever before it's too large. And so you can still manage your context without, and they have high quality responses. And in that case, ultra think could be advantageous. I've found it to work really great for me, but at the same time, it does take a couple of more tokens and you just have to watch that more carefully. But if you're on the, like I'm on the max plan of 20 acts, it gives you, you know, a lot of tokens to play with in a five hour session. And so in that case, if I start running close to it, I have a session tracker tool that will tell me how many, how many approximately how many hours or minutes I have left in my five hours so that I can know it's going to trigger another one. And it gives me a countdown. I can see it in the menu bar. And so, okay, I'm going to hold off and I'm going to wait until like the next day. So I don't burn through too many in a month. But then the clause going to anthropics changing that at some point, we don't know the details yet. I think I'm curious to Eric about your hook workflow. Like how do you, like what are some of the hooks that you've tried that, because I feel like everyone's tried different hooks. And none of them have really stuck around for me too much, you know, like, you know, I, I, from generating sounds to having it do extreme code reviews where nothing happens until like, you know, it iterates on itself. And I'm like, yeah, that's an infinite loop right now. It's like, I can't get out of my agent. So have you found any hooks that you found that are pretty useful for yourself that you either generated for your own tool use or just get curious. Yeah. I've been cooking with one thing that I have is a, you know, the, I mentioned the cloud docs. So that's a hook because it does a fetch every time you do a read request from the path where the docs are installed. Then it detects that you're trying to read in that path. And then it triggers a hook and the hook calls a script in the script does a thing and the thing gets done and that response comes back and gets fed into the cloud model or like update something before the request from the user goes to the model to be processed. If you do a pre tool use hook. Um, so as far as other things I do. So yes, I have something called a hook that I love and I wouldn't do any, so many my projects rely on this one hook and it is definitely stuck around. I think it'll be there forever for a very long time. And it is the indexer. So I have a project that is a cloud code. It's called project index. And so a long time ago, like what, but when chat with GPD first came out and I like got obsessed with, okay, this is going to run my code for me. And literally since then I haven't written more than a couple hundred lines of code. It's been entirely vibe coding from day one. Well, probably from like day three accurately, but, but I, I like a monkey was sitting there. I felt like, uh, figuring out, okay, here's the code and here's the, my code in my project. And then I've got to figure out how to merge the two together by hand. So I wrote this tool that like you just copy the clipboard and automatically, uh, copies all the code because it does unify get the format and it knows the paths where it's supposed to be merged and then just emerges all the code in. Looks like the clipboard. Um, but I realized early on to get the best results. What you want to do is have his high signal and his little noise as possible to the models. So we don't overwhelm their context with stuff that is irrelevant to the task at hand. So whatever you want them to do, you need to give them as much information that they need to know what the documentation updates since in the API is since what their training was and what are the files and not the other files they don't need, just the files that they do need. So is there a pre processing step that could be useful to the models to be able to optimize their response, the quality of response. And so I determined then the best solution was step one, uh, take a modified version of the entire code base. And so for every file, I don't mean like web magnification, where it's obviously skated and and ran like the letters instead of variable names. I mean like, uh, you know, like a UML style abstraction, but you have the actual import statements, method signatures, maybe root level constants or something like that, return types, et cetera. And all the dependencies for every file in your project is not in dot getting nor. So this is like a project is got the path like the project tree structure and it has for all of these files, a little bit of information about where they sit and what they relate to and what content they contain. And so I have a hook that goes through the project every time a file is changed and it does this and updates the index. So there's a project on the score index all caps dot JSON that sits in the root of every project. And so this hook maintains that and it's outside of the plot. Does it know about it? Because it's not inside of its life cycle. The hooks sit outside of the claw your talking team. So it doesn't it doesn't dilute the context window of claw to use a hook. So this hook updates the project index file and then whatever I ask for a change, I can for example spin up a sub agent because I hate use a sub agent to look at this, uh, your project index and figure out just which files which lines are needed for you to reference to to look at this change as an example. Another is like whenever I start like I'll often do cleanup before I like it finishes a task I had for it. I'll do a cleanup slash command. and that will go to until to update all the docs and plan this next phase, 'cause you can pass arguments in with your slash command. You can say something after it and it will pass it in as arguments into the command that gets run. So then it knows what's gonna do next since update the docs and then I clear it and then once it's cleared, I have a command that's like fresh and the fresh command tells it to read all the documentation and everything in the project index to read the whole thing and then it knows not just what I wanted to do next, but all the docs and not everything in the project, obviously, we wait too much for the context, but it has this minified version, like a simple version of the entire project, what's dependent, what's where. So cloud does a really great job of using the search tool and going and finding things, right? But the bad thing is, you know, you'll get, sometimes it will miss stuff, right? If it's really big or sometimes it, the worst case scenario when you're vibe coding is it creates something in one place that it should have refactored in another, right? That's like what happens is what people try to avoid. This doesn't worry, the product is too big. If it's small, it's simple, everything fits in context and it just works. If it's big, you have this problem. So to avoid this problem, I have a like bulletproof-ish solution called the project index. There works. And that works off of hook. - Wow. So in practice, what's the setup like to get this going? Like how do I go from, I just installed cloud code to now. - This all starts from you with cloud code docs locally. And that's a public repository. I can, well, I can share it. It's cloud code docs. It's my repository, it's my project. But the project index, I don't have shared it the moment, but I can share it. And it's basically, it'll be like a one line install and then you can just run it one time. And then at once that project index file exists in the project, it also installs the hooks. And so it'll just see is there a project index in this folder? If so, then the hook will trigger and it will just create the index of the project for you. So, but if you don't have that, it's just what I built for myself. I'm happy to share it. If you don't have something like that, but you want something like that, you can just say, hey, cloud, they'll do four such docs if you have that installed. What do I need to do in order to improve, you know, you gave me this result. I didn't like the result. How can I talk to you better in order to prevent you from giving me this result and giving me more like that? Reference or documentation, see if there's anything useful that I could use to help, you know, encourage you in the right direction. And just conversations like that, like asking this messed up, I want it to not be like that. What would you recommend I change? What would you think about it? Make a plan and then you reference the docs and it will tell you all of these really crazy interesting solutions. Like I've found so many things that, I guess aren't really why I know are used a lot. Like passing context from a sub agent, calling a sub agent not just a sub agent that's defined early, but like an ephemeral one that gets defined for the task at hand and then gets removed. Or getting the context out of a sub agent and passing it into a cloud that you can resume or taking the content from an existing session and moving it to another session through a background. There's just a ton of things that you just talk to the docs and ask it, can I do this? Well, and here's your project folder, a cloud, can you look at that and see what else I can do and it's into your docs and it will tell you. Cloud code is awesome at being able to allow us to get real world work done. And to do that, you need to share your real data and systems and that's done through MCP. And that can be a little bit scary. So that's why I've been using Tool Hive. Tool Hive makes it simple and secure to use MCP. It includes a registry of trust MCP servers. It lets me containerize any other server with one single command. I can install it in a client in seconds and see crit protection and network isolation and built in. You can try Tool Hive 2. I highly recommend you check it out. It's free and open source and you can learn more at toolhive.dev and I've actually a conversation with Ray and Eric. For hooks, just for the mental model, is it something you should think of as an automated slash command or how do you differentiate what should be, what functionality should be a hook versus what you can put as a slash command? - This is what I do. I am pretty rigorous about trying to maintain the context, like knowing what's in the context. And you can think of it like, in ever since the beginning, this is like clearly the models are trained, they reinforce learning, they have a knowledge cut off, they're put into use, they do inference. At that point, what they know is a combination of like the hyper parameters, like what's their temperature, all these things that are like tell how much compute to use, right? But then they have a system prompt that's usually not controlled by you. Unless you use sub agents, and sub agents are different than the regular, hey, Claude, create a sub agent. If you have a defined sub agent, you can tell the system prompt to use. So it has a higher priority. But there are trade-offs to all this stuff because it's like you're receiving an email and someone's telling you, hey, what really matters is the second paragraph, but the second paragraph here is the analogy of the prompt. So when people are focusing on like the prompt is what matters, it does matter. But everything that email matters to you. Like it comes from your boss, that's like the system instructions, hey, here's an email I want you to really focus on this to the customer. And or like the external domain, notice that you can't forward it along or whatever, that kind of thing. Those are information that maybe you didn't control, it was a system message or something like that. But that's all part of what you're trying to figure out as a user, or in this case like what the agent knows, is everything and some of it, you know some of you don't. But of the part you can control, it's really important to make sure that there's not extra stuff in there to confuse the model. So I try to remove other, like if you put a bunch of MCP servers in a bunch of sub agents, well, Cloud, if you ask Cloud, what do you know right now? Like you just started a new Cloud product project and you a new session, you say, what do you know? It knows about its project, its directory, it knows a little bit of metadata about the project, it knows a Cloud MD from the project, the user root and from the project root. And it knows about its hooks, like a brief little list, sorry, not hooks, it does not know about its hooks. It knows about its slash commands, a brief little one line description or something. And it knows a whole lot about its sub agents. And I don't like that because I don't want every command that I send for it to read a whole bunch of information that it may not be relevant for the task at hand. And it has a decide between, should I call this sub agent, should I not call this sub agent? So I don't use them unless it's like something where it's very consistent for this type of project that's going to need that and choose to get the project level. But for hooks, it doesn't know anything, it doesn't delete the context at all. So hooks exist outside of the life cycle of, so there's a software development life cycle like a runtime. And then it's like before the hook is, before you submit a request and there's all these stages to process that request. And there's certain points where there's a check to see if there's a hook there. And there's a, if there is, and it runs the code. But clot itself, the context you're talking to doesn't know about it, which means that it's not messing with the context in it. - When you would go to a slash claim versus a hook, like I understand that it's polluting the context, but let's just say for general functionality, like your docs slash docs, why would that benefit from a slash claim versus a hook? I created this before hooks were out. It's possible that if I did docs as a slash command, the thing is, clot really is instructed, I guess in the system prompt, clot code to look in their website for their documentation. So I tried to put instructions in clot.md, and it would just ignore them. It was like, inconsistently followed them anyway. But when I did it as a slash command, then the slash command could tell, it could instruct clot at the level directly, what the user is doing, it seemed to have a higher priority than the clot md being read in, or the project level, project level is higher priority. It seems then the user level for some reason. But then your direct commands are high level than all of them still. And it might just be a recent thing, like where it falls into whatever. But for whatever reason, when I did a slash command, it consistently followed them. 'Cause I could say look in this local repository for the docs. Now if I do a hook, it has to be, it does a fetch, right? So it's got a hook in there for the docs, for example, and it will do the fetch, and if it's, it'll do a pull, if there's more information. But I think I tried that I ran into some kind of issue because remember, that's running outside of your cloud context. You can inject stuff from the hook, I think, into the cloud. Well, you definitely can, but I just don't know if it's supported. There's lots of things you can do that I'm not sure how. And also, I just want to pivot one little quick and say, there's like, I'm always on the fence, it's a gray area between, you know, you don't want to do anything that could, you know, be investigating anthropic stuff, right? But these models, it's kind of tricky because you ask, hey, look at these new tools and tell me what you're capable of doing. Or hey, I want to do this thing, but I'm not sure how to do it. And it will go off and figure out it's sandbox, it's environment, like, there are a lot of these tools. I don't want to say which tool and which environment, but I asked to do a little research to tell me how I could do this thing. And it created a mechanism that, like, basically broke out of it. This thing got me, it gave me all stuff that I, I thought, I don't think I supposed to notice. And so I had to report it, but I'm just saying it's very easy to get further down the road than you want to get. Sub agents are a great example. I don't use them very much because the default, if you say, somebody has been around in cloud for a long time, you can just say, hey, create a sub agent. And it's a task, it's a tool, it's a task, and it's called a general purpose sub agent. And Frapik defines what its system prompt is. But it can go and do anything you want. You can get 10 of them in parallel at one time. And they'll just do research, there's different use cases for different mechanisms to do it. And cloud will manage it all. And if you, you know, stop, escape or whatever, to interrupt, it'll handle the interrupt and all that stuff. If you do your own version it where you have your own sub agent and it's not actually a sub agent, it's really like a headless cloud code that you're calling, then you have to handle the interrupts and all that kind of stuff. So basically sub agents, I use them whenever there's a task that's really repetitive, like I know exactly what to do. I want to be dedicated and really good at doing this one specific thing, doing research on some task that I need to pull out. But I don't want to create a lot of them because I don't want them to be confusing the context of them. And a lot of some slash commands are my preferred use case. And Ray, on one of your live streams, I saw you put together sub agent, is either for coding styles or for design styles, when do you go to a sub agent? Yeah, for sub agents, I've been kind of experimenting with this because my goal is to get some consistency. And the only consistency I've received from sub agents have been for research tasks in my code. And these are the tasks where I do want to spend a lot of tokens to go through to make sure I don't repeat code. And so I think that's kind of what's been happening is like I started with my vibe idea. And then it's just kind of blown up with more and more and more features. And when you start to add databases authentication and all these different patterns, yeah, it starts to get pretty interesting to see what the model prefers. And so I generally spawn off like a sub agent. And I say, you know, to like to the main task like the goal right now is I want to implement authentication and here's some like documentation. Can you just do a quick review on like, where all this stuff and where I should be putting in considering, you know, my client side is here and here's my back inside. And so it's just going to start digging through code files. And I'm basically just giving an intern a task in some way to say, you know, just dig through the code, give me all the pieces that I should be aware about so that when I do my own code reviews, I can actually review and making sure that these lists are kind of all checked off. Because one thing I discovered in this entire process, too, is the fact that the model will say that it did one specific task, even though there's like a whole bunch of them, market is complete and move on. And that's something that you have to be careful of as well. And so I like to give these sub agents as like a second look in that whole pass. And sometimes I'll just give it the instructions and saying, here's my, here's my manifest of like areas where the authentication was supposed to be implemented. Can you just do a quick pass on each of these sections and I want you to kind of think about how each sub agent should take a look at it? And just I'm just kind of delegating it for the model. So at this point, I have Opus and I have the max plan. Opus is a really great orchestrator. It will kick off other sub agents. And those sub agents still use Opus. I found out I thought it uses the next lower model, but I guess maybe because I have the higher version of the plan, it's just uses another version of Opus. And Opus is really really really good at grabbing lots of obscure information and you'll see you do lots of tool calls in that sub agents. So yeah, I basically treated the sub agents right now as code reviewers and as like secondary reviewers through the different files. And then I can kind of quickly suss out is like, hmm, this pattern looks like it's been repeated a whole bunch of times. You know, it's just like my worst scenario. It's like I generated a bunch of code and it's just, you know, we could have just taken care of this in a react hook of some sort and that pattern should just be repeated everywhere else. And those are the times I just kind of back out the change and then just start fresh again and say, let's go ahead and implement this. And this is kind of what a bad example looks like. And just literally copy and paste some of those examples and start a fresh new prompt and everything. And I think that helps the model to generate way better output and be thoughtful about its architecture. And so I can basically go from right now, I spend a lot more time. I probably say I'd spend like 60 to 70% more time now in planning phases. Yeah. And code reviewing. So those are kind of like my splits right now. And then the other parts of the generation are just to sort of kind of babysit and loop back. And that's kind of where I'm in this current phase right now. I wanted to do more automation. I wanted to do more things. But as an engineer, I'm still spending a lot of time in this phase to verify all the stuff. And I'm actually very shocked at the output that it is not as good as what people are saying. I trusted it a little too much because this is what I'm discovering. It's being over anxious about check marking the boxes and moving on. So just want to give people that type of heads up. Yeah. Trust of verify. I have I love cloud because you know, Anthropic does a lot of work to try to make sure. And there's a there's a reason I'm an Anthropic fan. I don't know if we'll get to that at some point. But like it does a lot of work on its personality and trying to instill principles and values and ethics and stuff into the models. But it's it is very I don't trust cloud. I have to put in this instructions to you know not lie to me basically. Like do not say that the thing is is done if it's not done. That's dishonest. I think that like gets into its like really pays attention to that right. And so when I talked about sub agents earlier, I was really in the context of defined like predefined sub agents. I do use a task sub agent where you talk to a lot to do a thing a lot. And that is largely for the purpose of doing something. Anything I can do this outside the main context preserves the context of the main cloud agent you're talking to. And so I don't need it to go and search a bunch of things that it doesn't need to know about whenever those sub agents can pass the information that it finds is relevant to the question back to the main agent that it just has a subset of that knowledge is relevant. So that's the the whole idea of maximizing the context is using those sub agents all the time in that way. But blind validation. So like before you do this is what I found. This is for me to you Ray. I don't know if any of you will struggles with this. But when I say I don't trust cloud, I mean I explicitly do not trust it when it says it checked off a box that it's done. I require in every case that it closes the loop with testing and that it doesn't it doesn't validate it has to have a sub agent or some other agent be a blind validator. So in other words, when I'm starting a project, I'll first determine the plan and it has to include the testing plan and how specifically it's going to close a loop on testing. Whether it's going to use an mtp server. Some other tool it's going to build something gets online. Something like puppeteer if it's a or if it's a python script like taking screenshots of the GUI and saving them. But it can't be the agent. The one I'm talking to this building cannot be the agent to verify that the checklist that the main agent made it at first or whatever was designed the plan for testing. That agent can't be the one that's that's checking to see if it's done. It has to be a separate agent explicitly with the task of you are a blind validator of this thing and it looks at the screenshots and it looks at the checklist and it determines if it's done or not and it passes like it updates that file for example. And so that's the only way that I'll because otherwise like right now the issue is the model golf and do a bunch of things and then we'll come back and it'll say it's done and then we check it and then we're like it's not done because I can see this thing it didn't work right. So it needs to have some kind of tests that it can run to verify that it's done but it shouldn't be the one to do it. And so you have a sub agent that takes care of that piece for you and that way when you come back it's actually reliably done and that takes extra work up front to set up but it saves you so much time down the down the stretch of the project. And then also right now we're you know we come back in a few minutes or whatever but there is no reason that tools can't be constructed at this moment with the technology as it currently is that will reliably let you give it a task and you come back in an hour and the whole thing has been validated because the the reason that I love flawed is that from the very from early on you've been able to make composability of foundational feature where you give it a task and it can spin up other versions of itself that accomplishes other sides so it can be dynamically on the fly in the moment based on the task at hand create a set of sub agents that are responsible for this and this other thing and they go off and do it and then come back. And so and these can be nested they don't just have to be in parallel like sub agents can't regular sub agents can't form other sub agents nestedly but you there is a way around because of cloud code because of not just the SDK which has this different set of features and trade-offs but cloud and headless mode can be called by cloud and it can in turn call cloud headless mode in sub agents and things like that so you can imagine like this is the big tree that's a tree of in contact sharing and all this have in between with resume ability so it's it's possible now people are building and I've been working on some versions of it myself. Yeah I want to also pull back a little bit too and like I would not get discouraged if you're kind of maybe listening to this conversation you're like oh my god this is way too far advanced. I I dropped out of school right I got into Apple just by pure grit and then worked my way up and I learned a lot of these software engineering practices literally on the job right and then got to solve like bigger problems and bigger problems like multi-million to billion dollar problems right and I think there's a core of truth that if you're just getting started out with this don't be discouraged you can go a long way simply by just acting as a user and literally using your product and then trying to solve that one feedback loop and that's going to just you that's like the 80-20 of everything I feel is that like okay how do I not do this again or how do I set up a system to help me verify it if you just start at that level of curiosity it's going to take you a very long way because now you say oh maybe I could set up a sub agent for this to help me do this or how can I prompt the model to help me do this so that next time I implement a feature as I'm testing it by hand I don't hit that same problem or something and then you'll start to kind of discover some of these workflows so I want to encourage people that you can see how why so many developers are extremely [BLANK_AUDIO] excited right now is because the capability is like literally just almost infinite. It does get infinite and it goes not only infinite in like one direction and many directions. And that's how big of this, you know, glacier ice pool or like this giant piece of mass that is this AI system and how different people with all these different perspectives are talking about it. So I wouldn't be discouraged if you're listening to this and you maybe not know what half of the things are, but some of the basic tooling to just get started. It's like find one thing that you're doing. If it's being repeated a lot, can you think about a system that you can repeat over and over again to make it more reliable for the next time to help you solve that problem? And that will kind of help you in your learning journey. And I think the other important thing for me has been just asking cloud code itself to help me with that. Like what does that look like? Because I don't know, you know, like I didn't know how to implement a good sub agent or something like that. I've luckily have implemented this type of thing if you do slash agents, you can actually just have a natural conversation about what you want to do. And then it generates the system prompt for you. So you don't have to be a prompt engineer. You don't have to give it good and bad examples. You don't have to do all these different techniques. You know, those are like more advanced, I'd say. But that already gets you a pretty long ways just in using that type of system in there. And so I mean, I only advice is like always keep it simple. And sometimes the simpler, the better. So if you feel like you're kind of going off the deep end, it's okay to kind of clear everything out and start fresh again. It can help you learn things. The models are constantly evolving. We're constantly evolving in our knowledge. We're learning more. We're demanding more from our AI now that we understand what this real thing is, right? So just kind of my overall lesson is like, don't be discouraged. This is a really great time to be alive and ask us more questions and reach out wherever you want to reach out at and so forth. Get ahold of us. Yeah. I've been seeing more and more people trending around, oh, use TDD to operate your cloud. And you don't need to know what test driven development is. You just have to think of the principle, right to test. Make sure it passes the test. Eric, would you say there are any other guidelines, principles for people to just do this exploration, this play, this discoverability of the capabilities or any advice on just, you know, getting started and getting that comfort level of just, you know, experiment with the tool. I mean, I really feel like, obviously the adage of just use it. So I feel like everything that doesn't go right is an opportunity to figure out how can I talk to it better. And this has been sort of like from the beginning, if you think about like what we're leveraging here by being a person who's using a tool like this, you're really setting yourself apart by because this is the flywheel, right? If you're like the every moment you spend getting through like grinding on what is the difficult thing that most people stumble with, what what what failed here and then learning how do I overcome that by using the tool to help learn about it. And then continuing just that process, then you develop your own system and it changes from project to project and project size and style to project size and style. And then you kind of get a feeling for it. Like what I'm doing is not anything special or different than what anyone is able to do. It's just I've spent time with the tool and asking you a lot of questions whenever something didn't work right. And so based on that, I found okay, well, I don't want to like, there's friction between I've got a chat conversation. It's like this, this, you know, you get a long email thread from someone, we'll go back through that analogy. I'm just topping my head. I don't know if it works. But then like they, there's 16 messages, but it's fresh every time you've never seen it before. So I read through all of this stuff to figure out where you were. If you have to clear that email thread and start afresh, well, there's stuff that you would want to carry over, not all of it, but some small subset of it. It's really relevant. And that's a process of finding a system to preserve the right context as you clear your previous session, right? It will handle all of the compact for you. All of these tools, all of these like cursor and windsurf and different models and wrappers for these models, try to solve that problem as easily as possible, but there's always still some friction there, like which context matters for the next session and how you make sure you get it over. And I think the persistence of the file mechanism, just writing, having it like update the documentation, write the next steps to the file that will be read in. And then as soon as you clear, you run the thing that causes to read that documentation to know where to go. I think that system is very, very valuable. I think this is a good primer for people to get started with Cloud Code and ask more questions and get a little bit more perspective on some of our use cases. I feel like this is just scratching the surface or understanding where things can go. And I would encourage people like Eric saying, just be curious, start playing. Maybe it's chunked down to like maybe one problem that you're trying to solve that you're, you know, you see that little bar there, you know, start asking at the questions, trying to see if you can actually kind of work you through a workflow. I feel like a lot of people have these different areas of concern that they can kind of go down these rabbit holes. And I think these tools can get very advanced very quickly. And just if anything, if I have one piece of advice to give anyone, it's like your context window is so important and protect it with all my deep power, like it's your first born child and you don't want to let it go ever. That type of thinking will kind of help you get the most out of this like intelligence that we have today. And yeah, I guess you're, if people want to find out some more, I do AI live streaming. So my name, my handle is Ray Fernando, one, three, three, seven. That's my YouTube channel. You could also find me on the x I post a lot on there as well. And so I do AI live streaming several times a week and you can find me live streaming. And we'll still gonna have some recorded content kind of going over these concepts and stuff. So yeah, I appreciate you having me on the show, Mike. Yeah, I just want to say it's a great pleasure to get to hang out with you guys. It's really fun to find people who are also interested in the same things around the world or like minded and interested in sort of driving forward in the possibility of like what things we can unlock for ourselves and our families and our future basically to make simple to give us more time for the things we want to do. And it's just a really fun sandbox and tool to be able to do so much. You don't maybe yet know the value when you're gonna find something in the future. Like, oh, I wish I could do that, but you've learned the skills to do that and to talk to AI in the right way with the right tools to be able to do that. It's just, it's very fun. And I just want to encourage all of you guys, especially like Ray, it's really great to finally meet you. I've been a fan for a while. I really appreciate it, Mike. I was following you at Open Interpreter. And it's been a journey and I don't know what's gonna go, but I know that the future is bright and I really appreciate the ability to be able to get on and talk and share some of this stuff. I've been kind of hidden doing my thing, talking to people when I wanted the background, involved in some interesting stuff. So, but anyone who's doing this, I think you're spending your time very wisely because it's a good use and the payoff is gonna be really good long term. Thank you for tuning into this conversation on Cloud Code with Ray for Dan Donerig Boos. I had a great time talking to them. Both guys are two phenomenal people who I really enjoy hanging out with. We hope that you gained value out of this because I know I did. I learned stuff from these two just in this conversation, but there's so much more we want to cover. We were limited by time and we could have gone for hours. So there will be a part two, maybe here, maybe on one of Ray's live streams or maybe on Eric's Twitter. So, keep tuned for that. Please follow both of them. They're phenomenal people. And I just want to give a quick shout out to Toolhive, the secure MCP servers that really help make you more comfortable sharing personal information and Cloud Code uses MCP servers so you can definitely time in there. If you have any other questions, you know where to find us. Thank you for joining. We'll see you next week.