Transcription
Half of my job isn't actually coding at all. In fact, a ton of my work is actually writing about the code. Status updates, PR descriptions, documentations, handoff docs. There's just a ton of writing that engineers need to do. And you know, no one really wants to do it at the end of the day, but it's just one of those very necessary things that needs to happen for the job to get done. So yeah, I'll be the first one to admit that I hate doing all of this stuff. So I automated it. And today in this video, I'll show you the exact workflows that I use and how you can build your own custom workflows to automate the boring parts.
So by now most engineers are already using AI for these tasks. You open chat. You pay some context and you explain your project from scratch and then you get some kind of generic response. Afterwards, you'll spend about 10 minutes fixing it up, you know, prompting it back and forth, reiving it context that you've already given it for. You know, this may work, but it's not automation. It's really just moving the work around from one place to another. Sure, it probably does end up saving you some time, but you're still doing the same things over and over and over again. Whether that's reexplaining your architecture for the 10th time or reexplaining some decision that was made and why something has changed. Every time real work gets done in the real world, every PR that gets submitted, basically every week [music] that you have made progress in your work, this is new domain context that chatpt just does not [music] have.
And you know, chat does have memory features, right? Which is very cool, but it's pretty shallow in my opinion. And when it comes to this kind of continual contextual maintenance, it's just simply not integrated to your work for you to really leverage it properly. Basically, at the end of the day, the memory stuff, it knows kind of like what you're prompting and what you're curing, but it doesn't know about your day-to-day work very well. And often times, it can get confused and you don't really have control when you need to retrieve that information. you can't organize that context in a way that is actually helpful in real time and consistently.
And I was running into this same thing. I wanted essentially something a lot better. And I actually found the solution. It actually started about 6 months ago. I switched over to Cloud Code 100%. Originally, it was just to level up my actual coding. And yeah, it's amazing. It's probably the best coding agent out there. But the surprising thing for me was that there was a ton of other things that claude code could actually do that is just not related to coding at all. It started out simple with like a PR description. I had realized that when I was getting ready to submit my PR, Clocko had the full context already. So I just asked it to write me a description and it just did it perfectly because it had the full context in that working session. And then the next thing I tried was during an on call investigation, I asked Claude to run a deep dive on the latest like release branch, [music] you know, look at every single div or I mean PR. Sorry for those of you that don't work at Meta, but yeah, basically looking at the commit log and give me best theories on what broke based on the SEV description. and it was able to give me such insightful theories that I was able to pinpoint some issues, test them out, and find a se resolution very quickly. The crazy thing in all of this is that the prompt wasn't getting like better. I wasn't getting better at prompting all of a sudden. But the big difference was the context and where the work itself was happening, right? Instead of just getting better at prompting, I was essentially building a system that remembers and gets better over time. basically as part of my daily work. [music]
And I remember very distinctly the next time I went to like our internal chatbt to start preparing a status update and I was just pasting the same context and I was like looking at different threads for like the explanation of the architecture that I I had done for this project and I just had this feeling that I've just done this over and over this exact same thing the same explanation the same copy paste and you know same output that I had to clean up anyways and this is the moment that I all hit me. You know, like cloud code can remember my things a lot better, right? I had experimented this with cloud code and clock has this internal like memory system, you know, it uses like MD files to really have great local context. And because it runs locally, I could basically build any kind of rack system that I want.
So, here's how I've been actually setting it up. Now, it's essentially like two steps to get started. It's nothing fancy and the goal isn't really to fully automate everything. There's still a lot of in the human loop decision that needs to be made. But at a high level, what you're trying to do is build a second brain. And this second brain will get better and better and more useful the more you use it and the more you organize your work domain knowledge into this second brain. And to get started, all you really need is cloud code. After that working session, you should just ask Claude code to create a knowledge base of your project [music] and store it locally. And then after every working session, you tell Claude one thing. Update what we just did to my project. And because Cloud knows the projects that you're working on, it'll be able to just update the context very easily. Honestly, this takes about 30 seconds. But over time, this compounding like domain knowledge that you build up into cloud code becomes so valuable. [music] You know, weeks later, Claude doesn't need any explanation on some project that you worked on. It already has a history of the project. If you did it correctly, it should have all the context behind the decisions that you made, how the codebase is shaped, relevant code pointers to the project, gatekeeping, config files, whatever information you need to bring up quickly, you can build this local context. So, cloud code has like starting points to do deeper investigation. So, the next time I needed that status update, I didn't have to explain any of it. I just add cloud to give me the latest status report because I also created a to-do list in cloud code for my projects and I just review it and I just ship it after it gives me the results.
So this second brain concept in my opinion is a huge unlock for people who are very interested in getting the best out of their AI workflow. Honestly, this kind of agentic system in my opinion is the future. And I actually believe that our code base will grow to have these small domain like MD files or some form of like vectorized memory that the AI can use very quickly. So it doesn't have to parse the entire codebase every single time. It's essentially just a small compaction of context that is readily available at all times for clot code to use. That's the second brain concept. It's a huge unlock. you should definitely go after it.
Now the step two of this whole thing is building custom workflows. Now once you have this like second brain and this real like context that you have, you can do so many interesting automations off of it and it just gets really fun. Cloud code has something called skills. And a skill is basically a saved workflow, a set of steps and all of this is actually written by Claude itself. And it it's actually just a giant prompt in the markdown file, but it's written in a way that Claude knows how to execute those steps every single time consistently. So here's like a really simple example. Every time I ship something, I need to write the same kind of post to let people know that I had shipped something, what changed, how to test it, what to watch out for, how to give feedback. It's a basically the same structure every single time. And to build this skill so that you don't have to ever manually write this again, you just actually do these steps manually with Claude just once, step by step. And then all you say is turn what we did into a skill. And Claude will make that skill for you. And now whenever you need to post something as long as that you've been working on this second brain for after every like work session you can just trigger this skill and instantly cla context look up recent changes you know go actually to the divs if cla needs to and it will write it in the style that you wanted to without reexplaining reingjecting doing anything about like dragging and dropping. you just prompt it and you just have the content that you need to post.
So when I've been playing around and really experimenting with skills, the reason why I keep harping on this second brain context is that I realized that context is king. You know, context is best serve fresh and condensed, right? Everyone talks about prompt engineering and how like you need to optimize your prompting for it to have the perfect wording. And I think that's kind of the wrong optimization. Of course, there's some elements of that that is true and it needs to be fine-tuned. But I don't think automation has to do with the prompt. Automation to be really great is actually the context. The context has to be great. The data that is fed into the automation needs to be great. Right? So like think about onboarding a junior engineer. It's a very interesting parallel, but the way you onboard them, you just have to onboard them once usually if they're really good. You just explain a bunch of stuff. You give them a bunch of context and then you kind of don't have to reexplain the same entire thing every single time, right? The and the same idea is here. You can build a context once and just build it as you go. Let it compound over time. And also, you know, you should let cloud code manage your context on your behalf. And once you do that, the prompting itself barely matters.
So, yeah, now that you know this system, let me share a few more examples of workflows that I've converted into skills to get you started. And hopefully this gets your gear spinning on how you can take this kind of like workflow for yourself. Because honestly, at the end of the day, everyone has custom workflows. Everyone works at different companies, so skills that I'm using is really useful for me, but it may not be useful for you. But [music] the point of this video is to teach a man how to fish, right? Not to give the fish. So, yeah.
So, here's a few examples. PR splitting. Now, at Meta, we have a huge culture on atomic commits. Every commit needs to be like landable on its own, and we don't really do feature branches. everything gets rebased and landed onto the main branch. So depending on how you code and for me the way I usually code is I would build the entire thing chicken scratch once and then I'll rebuild the entire thing again and I build the entire feature just the way I like it and then I'll split the whole diff into bite-sizable chunks. And this process used to take me a ton of time because it, you know, it's just a lot of work to split diffs. But with cloud code, I just trained it as a skill. I have a pretty like straightforward system and like logical way of breaking up a diff, right? I do the interfaces first and then the integrations, any helper methods and then the integration and some tests, right? And then that's kind of a highle ordering, right? Start with the leaf nodes and then work your way into the integration. I trained cloud code to do this. And now all I say is look at my diff, split this PR into logical chunks. It'll run through my skills and it knows my preferences and it will just do it perfectly almost every time. Of course, I need to go and fix things here and there, but I have a diff review skill as well where it goes with me line by line and I have a conversation with cloud code through all of this. And also I briefly mentioned this but seven investigation is a big part of our job. I have a skill that goes to the release branch, looks at the all the diffs that may be related and then gives me the best theories. You know, this kind of like biscting, it's pretty repeatable, and cloud code can do it very easily. You know, you may need some MCPs to like look at GitHub or whatever third party service that you're using for managing your code. [music] But the point is, you should be able to do all of these. This one skill has saved me hours of time in investigation. Like during on call, I just have multiple clock sessions and I'm just asking questions to it based on tasks that I receive.
So these are just a few examples and I hope you take this and you really think about like what it could mean for you and how you can make things better, right? Take this and make your own custom skills. So let me know in the comments what kind of skills you built after this video. And don't forget that you really need to have this like context, the second brain, right, to continually update your knowledge and your domain, you know? So, I hope you guys really enjoyed this video. For all of the skills and stuff that I have, I will create the show notes for you in my new newsletter called Push to Pro. The link will be in the descriptions. But yeah, all of the skill templates that I described in this video will be there, so check it out. And also check out my other videos on software engineering right here.