.agent folder is making claude code 10x better...

How can we get cloud code works well as your codebase became more and more complicated without getting to circles and make you feel frustrated? Once I learned that there are many things you can do to improve performance dramatically through good context engineering and context engineering basically means how you can optimize what goes into conversation history thread for the cloud code or codeex so that only relevant and necessary information are included here to guide agents next actions. As we know coding agent like cloud code at default has 200,000 token context limit and if you run / contacts in your cloud code you will see breakdown token consumptions across different categories and this is a very basic example of what you can do with context engineering optimization because in general the whole context consist of few different things the system promise assistant tools is something you can't really change it always comes with agent so the part you can optimize is the agent has any MCP tools or custom agents that you don't really use but consume a lot of tokens and the memory file here are basically your cloud. md file and I know as your project became bigger and bigger sometimes the cloud MD file just became so big that leaves very little room for the actual message. So in this very specific example I can already see that if I remove all those MCPS from this agent it will immediately give me 2% additional context token window. So this is one very basic example of what you can do to optimize context window better. The key part you want to optimize is the actual message which including the user message you send as well as list of two call actions that the agent take and the key thing here is that how can you making sure all the

information in the history here is relevant and reduce noise as much as possible and there are many things you can do here for example sub agent is a great tool that you can use to reduce context so when I look at what happened here if you prompt agent help me add a Google O the majority of the actions agent take here is actually not about making trends but doing the research to figure out the I plan for the implementation and those research steps generally took whole bunch of context in the conversation thread and with feature like sub agents instead of including all those research related token consumption in the main conversation thread you just delegate and offload the whole token consumption related to research to the sub agent where it has isolated conversation thread to do just this and return back a summary of the research which means only absolute necessary information and tokens are included in the main conversation thread. So one very basic thing you can do is that before you implement big feature you can just add a small text that let's use task or sub agent to do the research first so that it can trigger this specific behavior and this is why I often use a compact command much more proactively so that after agent complete certain set of fairly isolated task often just run the compact so that we can proactively clean up the conversation threadive methods that I often use is set up your

own documentation system for your codebase there are many different ways you can do Yeah. And this is the part I want to dive a bit deeper today. But before we dive into that, one trend has been happening is that more and more people use cloud code to not only doing coding task but day-to-day operation task from handling your emails, using different system, automate tasking, different productivity apps, journaling and this tell us there's massive layer to build. Look at what type of use case people are trying to hack into cloud code then productionize it into aic products. That's why I want to introduce you to this research called AI agents unleashed a pragmatic report about what kind of things and use case people are hacking agents into who those people are what they doing and dive deeply into real world examples where they interview hundreds of people from top stars and enterprise in the world across marketing sales operation as well as real world learnings of what actually worked and what didn't the common pitfalls and challenge that people are facing today. So you can use those information to direct your agenda product road map much better. One of the favorite part is that they propose a really useful framework to think through if a task and use case that can drive huge business value that people are currently paying for. So if you're trying to build a genus, I highly recommend you go check out this research. You can access this report for free in description below. And thanks HubSpot for sponsoring this video. Now let's talk about my documentation system for cloud code. So the purpose of documentation system is to create a summarized snapshot of your current codebase. So instead of agent every time doing deep research across the whole codebase to find information that it need, it can just read a summarized documentation that clearly pull all the relevant information together. So it has less noise in the context window and also making sure all the relevant information are feeding into context instead of hoping agent pull all the relevant information together by itself. And the question is what type of documentation is useful and how can you make it scalable as your codebase became larger and larger. So the common structure I have is something like this. I typically just have this dot agent folder that contain all the relevant and useful information that I need. So one is a task folder. This is where I store all the PRDs and if you don't know what PRD is basically before I implement any feature I always turn on plan mode and ask to generate implementation plan and after finish I will always store the implementation plan in the task folder. So next time if we are implementing something similar we can link to those implementation doc as a reference and second part is system folder. So system folder contains things like project structure, the database schema, your APIs or some critical and complex part of your codebase and those things can go across different individual PRDs and really useful for agent to get a overall understanding and this is also the part that it can grow bigger and third is SOPs. This is where we will log the standard process for doing certain things or mistakes you saw agent make. So after I get agent do something, I will ask it to generate a SOP for this specific process. It can be as generic as like adding a new database table, what are the list of action you should take to something more granular like how to integrate a new replicate model. And last but not least also a readme file. So as your codebase became more and more complicated, there'll be just so many docs and the readme here is almost like index of all documentation files you have and when to read which documentation file. So the agent can quickly get an overview of all the relevant documentations and read injection history. So this is a common documentation system I often use. Meanwhile, I also uses update doc command quite frequently. What it does is that it basically includes certain instructions to agent about what to do when initialize documentation structure as well as when I need to update documentation. So I will run this command after I implement certain features or I can use this update doc command after we help agent correct certain mistakes so we don't make same mistakes again. Then it will create this SOP that clearly list out all the step-by-step process and also the related documentations so the agent can consume more relevant information and this SOP doc will also be included in the readme. md. So this is pretty common

structure I use for my projects and continuously maintain and updating them. Obviously the best version of documentation system is always something tailored to your codebase. For example, I talked to Simon from AI builder club where he showcased how he builds a whole documentation system with his team for their Lexi codebase. This is the pointer dock as it were that points to everything um how we do all sorts of things and you know best practices um etc. And so this is very human readable obviously as well but it is it was designed more for our LLM friends. We document all the ways we do our like migrations how we store the data. We got a whole class of things with methods for helpers, updators, utilities, all sorts of stuff like that. We've sort of split out all that all this stuff into well doumented sections. — The very first versions of these we did inside Claude. We got Claude to generate the MD files and then we started using cursor and we've got our own little uh this thing here. All right. — What are they these things are called? Now cursor now has got the slash commands. I haven't yet experimented with turning this into a slash command because I've always found this rather frustrating that we've only got so much room to see what's going on in there. — But it's not complicated. We go through and then we say review this class — and upgrade the inline documentation. So we do that first so that then the class has got the best possible inline documentation and then we'll use a prompt in the prompt interface to generate the class documentation in more detail. So there's this workflow that goes generate or update the inline documentation and then output that into the bigger documentation. So I've just thrown all the LLMs at this to sort of get as best as we can. It makes the whole process easier to manage by exposing all of that. — And let me give you a quick example of how do I do it. If I start a new project, let's firstly create cloud. md

file. I just added one section for docs specifically explain the doc structure we want agent to follow and then give a rules that we always update agent folder docs after we implement certain features and before we plan any implementation always raise the ray me first to get the full context and meanwhile I will also create a doc cloud folder commands update doc. MD. This is a simple prompt that specifically telling agent about the dock structure and what to do when we start initialize the doc ask to update doc as well as some very specific rules when it create new doc files. I'm going to show you how we use this setup to continuously update docs. So I firstly do /update doc initialize. This will race through my current project and try to set up a do agent folder structure. And once it finish you will see that it creates this agent folder and set up a project architecture as a first doc. And there's also a readme file under the dot agent folder which listing out all the docs that we have. Now let's just take you through example of how do we use this. Let's say we want to build a basic app that can do text to image generation using a model host on replicate. So I'm going to copy over a doc and give prompt. How we build a text to image app using model above and I'm going to use a plan mode. And after I finish the plan I'm going to prompt a save implementation plan in a do agent/task folder and start implementation. Great. Okay, now we have this text to image model working. Quite often in my experience, model will fail to integrate replicated model out of box and that's where R can use this update doc command saying generate SOP integrating replicate model. Then what it will do is that it will create this replicated model integration SOP. In this doc, it will explain specifically step-by-step integration process, the directory structure should follow and also there's a section called related documentations. So for this one probably didn't make perfect sense but you can imagine if your documentation became more and more complicated. This can be used as a directory to lead to all related documents and in the end it will also go update the readme as well to include more stuff. So now I can even clear the conversation without giving too much context and give different model which is text to video and give a prompt help me add text to video capability using model above plan implementation and read do agent doc first for context and again I'm using the plan mode. This time you can see it reading through different files to get the full picture. And we're going to do the same thing. Save the implementation plan to /task folder and start implementing. With this one is able to oneshot this video generation model and it is fully functional without any errors. So this how you can imagine this whole documentation system works. You can have higher confidence that I can just come in any time and start implementing something with pretty consistent performance. You can do same thing for your existing codebase as well to ask cloud code start generating the system architecture documentations which can including text project architecture as well as database schema API endpoint and many more. If you're interested we have a specific session in AI builder club where we include detailed instructions of the cloudd and update do commands that you can copy paste as well as a 1h hour workshop where Simon dive deeper into his specific setup. So you can learn how others are generating documentation system for big and complex codebase. I have put the link in the description below for you to join AI builder club. So feel free to click and join if you're interested. I hope you enjoy this video.