Transcription
There is a very good chance that you are leaving most of the potential of your AI coding assistant on the table. So right now, I want to get super practical with you and show you some of the best techniques that all the top agentic engineers use for AI coding. The people that have a real system in place for working with their coding agent, like Claude, Code Hero, or Cursor. And so, I am going to assume here that you have at least a basic understanding of how to use coding agents because now I want to get specific into the really powerful unlocks for you. And I'm going to be very concise in my explanations here. I'm not going to waste any of your time. And the best part is, all of this, it doesn't require any new tools. It really is just a better way of working. All right, so let's get started.
At the top of the list here, we have PRD first development. So PRD is short for product requirement document, and that can mean a lot of different things, but in this context, it is a markdown document, a single place to define the entire scope of work for your project. And so for greenfield development, when you're starting from scratch, this generally contains everything that you have to build to complete your proof of concept or your MVP. And the beauty of this is, this single document becomes the north star for your coding agent. Everything that you have to build. And so from the PRD, you get all of the individual features that you're going to build out with your coding agent. It is important to not have your coding agent do too much at once, or it's going to completely fall on its face. So you use the PRD as a way to split your project into more granular features, like implementing the API, implementing the user interface, building the authentication in. You split it up like that. And then for brownfield development, if you are working on an existing codebase, instead of creating your initial scope of work, it's more documenting what you already have in your project and then what you want to build next. But either way, you're creating the north star for your project. A lot of people miss this. They dive right into building that first feature, but then they don't really have any connection between the different iterations that they're doing with their coding agent.
And in order to demonstrate all of the techniques that I cover in this video, I have this GitHub repository, which I'll link to in the description. I have a very basic demo project built out in this repo, as well as all of the commands that I cover here. And so, all of my workflows that I use day-to-day for AI coding, I have this all laid out for you. These are the core slash commands that I use every day. And one of these commands is related to what we were just talking about. I have a full workflow built out for you to help you create your PRDs. So now, going over to the repository locally, I have all of the commands in the `cloud/commands` folder for you. And by the way, you can use these commands for any AI coding assistant, not just Claude Code. They're really just prompts that define these workflows. And so I have the `create PRD` command right here. And so the whole point of this is, you have a conversation with an AI coding assistant about what you want to build, right? Like, "I want to build XYZ. Help me plan it out." And once you get to the point where you're on the same page with the coding agent for what you want to create in your conversation, you just run `/create PRD` and it'll output to a document that you specify here, the entire scope of work. And so for this simple habit tracker application, this is my PRD. And all of these sections are a part of the template defined in the command. So, target users, your mission, what is in scope, what is out of scope. You also have the whole architecture laid out here. This is now your northstar. So for all of the feature development that you do after this point, you're now going to be referencing the PRD to figure out what to build with the help of your coding agent.
So another command that I always use in my AI development workflows is a `prime` command. I run this at the start of any new conversation to load all of the necessary context in from the project. And the PRD is one of the core files that I always make sure my agent reads because then, after it primes itself on the codebase, I can just simply ask, "Based on the PRD, what should we build next?" And this question, I ask this every single day because I'm showing you the workflow that I use, no matter what I'm building, and it doesn't matter what codebase I'm working on.
All right, so the next big concept to wrap your head around is the idea of a modular rules architecture. Cuz here's the thing, most people make their global rules way too long. Remember, these are the constraints and conventions that are loaded into the context for your coding engine at the start of every single conversation. So if it's not lightweight, you're going to overwhelm the LLM with the number of rules that you have for it. And so your `agents.md` or your `claude.md`, whatever your global rule file is, you want to keep this actually really short and focused on the rules that apply no matter what you're working on. Things like the commands to run, your testing strategy, your logging strategy, that kind of thing. But when you're working on just the front end, maybe you're focusing on rules for your components, or you're working on deployments, you're working on building out the API for your application, you want to actually take these different rules for different task types, split them out into different markdown documents, and have your primary global rules reference these. So you're only loading these into the context of your LLM when you're working on something that really applies to the rules that you have laid out here.
All right. So going back to our handy-dandy habit tracker application, I want to show you an example of what these rules can look like. And so I'm using Claude Code. So `claude.md` is my global rule file. And I'm keeping this very lightweight. You can see that I don't even have 200 lines in my rules file here. But there's a lot more context that I have in my `cloud/reference` folder. So, I'll show you this in just a second, but what I have here is the things that I care about no matter what I'm working on. My tech stack. I want my coding agent to know the project structure so it can navigate it better. What commands we have to run the front end and backend, for example, MCP servers, code conventions, my logging standards. Remember, these are the things that, like, literally no matter what kind of feature I'm working on, I want the LLM to know this information. But here's the key thing. Right here, I have a reference section. This is where I refer to the task type specific context that I want to load only for certain types of features. And so because these paths are loaded into our global rules, the coding agent is going to understand, like, "Okay, when I'm working on building API endpoints, that is when I should read this file." And so I have these all just living in my codebase in this reference folder. And so there's a lot more context here. Like, this document alone is almost a thousand lines long. And it's the same for a lot of these because this is where we get very specific with our instructions. And we're allowed to make this longer because we're only going to read this when we're actually working on our API. And so having this reference section in your global rules is a very powerful way to keep your rules concise while still having all the context that you need. The goal is to protect the context window of your coding agent. That is something that a lot of people severely underestimate the importance of. And you can also reference these documents in your commands as well. Like maybe you've built up a workflow to build API endpoints. So you don't actually have to reference it here. You just have the path given in one of the commands that you have. So whatever it takes to make sure that you have access to all the context you need, but not all up front.
The next technique that I have for you is probably the most obvious out of all of them. But it is so important that I need to make sure this is always on the forefront of your mind. You should be commandifying everything, if that really is a word. Basically, anytime you send in a prompt to your coding agent more than twice, that should scream to you that it's an opportunity to turn it into a command or a reusable workflow. These are just markdown documents that we load in as context to define a process for our coding agent. And so when you make a commit to Git, when you're doing a code review, when you are loading context in from your codebase, pretty much anything that you can possibly do as a part of your development workflow can be turned into a command because it'll save you thousands of keystrokes as you use it more and more and more. And you can share these workflows with other people, like I'm literally doing for you right now. And going back to the habit tracker repository, like I said earlier, I have all of my core commands that I use on a day-to-day basis documented here and included in the repository. So you can feel free to take all of these for yourself and customize them to your own use cases. So pretty much everything that I found myself prompting more than twice, I've packaged up into a workflow here that you can feel free to use. So making Git commits, creating the PRD, like we saw earlier, everything in my core feature development cycle, like executing, planning, priming, all of my validation commands, even the ones for system evolution that we'll talk about in a little bit. I've got it all for you here. And just to show you really quickly, everything that I cover in the course, this is the complete system that we build together for both greenfield and brownfield development. I go over how I build features in cycles, system evolution to make our AI coding agent more powerful over time. I cover it all here. It is very, very comprehensive.
All right, the next technique that I have for you is also related to context management. If you couldn't tell already, that is a very critical component to working with coding agents. And so, here we have the context reset. And what I mean by this is, in between your planning and your execution where you write the code, you should always restart the conversation window with your coding agent. And the only reason you're able to do that is because you always end your planning session by outputting a document, typically a markdown doc. And this document has all of the context that you need to go into the execution. So we're not going to do any priming. We're not going to tell the coding agent what we want to build when we go into building our solution, that next feature. We just feed it this document. That is it. And the reason we want to do this is because we want to keep our context as light as possible when we get into the actual coding to leave as much room for the agent to reason about what it's doing, do all the self-validation, all that good stuff. So, I'll show you right now what this looks like using commands that I have for you in the repository. So we always start our planning with the `prime` command. So we understand what's in our codebase and then we have a conversation with our coding agent to figure out what we want to build next. Again, based on our PRD, what's the next feature that makes sense? And so I didn't go through this just for the sake of demonstration here. I went right into the next command where we create our structured plan. This is the markdown document that we're going to output that we use as context going into execution. And so right here, I will literally do `/clear`. So completely wiping the context window, or you can just restart your coding agent. And then I call the `execute` command, and the parameter for this command is that plan that I want it to read. That is all of the context that it needs. And so I'll show you that really quickly. Like, for this simple demo for the habit tracker, we are improving the visuals for the calendar. And so this outlines the feature description, user story, everything at a high level. All the context to reference the individual components we have to build, a task-by-task breakdown. Like, this is very comprehensive because we're not loading in any other context into our agent when we execute the plan right here.
Now, believe it or not, I have actually saved the most important technique for last because now we are getting into system evolution. And this is the most powerful way to use coding agents when you treat every bug as an opportunity to make your coding agent stronger. And so instead of just encountering a bug and fixing it manually and moving on, we actually look into the system for a coding agent, what should we fix to make it so that this issue doesn't happen again? This is especially powerful when you see patterns develop of an issue that your coding agent keeps hallucinating time and time again. And so typically, when you think about what you can fix in your system, it's either your global rules, any other kind of reference context, like we covered earlier, or your commands, aka workflows. There's going to be an opportunity to address something here because when the coding agent messes up on something, it's probably a rule that it doesn't understand that you want to specify, or it's a part of your process for validation, for example, that could be better. And so just for a couple of examples that I have here, if the coding agent uses the wrong import style, then you add a new rule, right? Like you just have a simple one-liner to explain what that looks like. And a lot of times, it can just be a one-liner. AI forgets to run tests. Well, you just update the template for your structured plan. What is fed into execution to include new sections for testing. If the coding agent doesn't understand the authentication flow, well, that's when you can create a new reference document. And you would update your global rules. When working on authentication, you should reference this doc, just like we showed up here. So, in the end, there are a million different ways that we can get into the system improvement mode with our coding agent, but typically, you're going to do it right after you finished building a feature and you validated things yourself. You notice a couple of things that are incorrect with how the application works or something wrong in the code, and you just go in, you say, "Hey Claude, I noticed that XYZ is not working in the application, and so I had to make this fix." And so what I want you to do is go into the rules, read all of the commands that we used here, and I want you to figure out what we could improve in the process or the rules so this issue doesn't happen again. Now, this is a bit of an oversimplification. And you can see I used the speech-to-text tool to input that here. But you get the general idea. You have it do more of a self-reflection, thinking about how the execution compared to the plan. How did it compare to our rules and the process we laid out? What are the discrepancies there? Things that we can address so these bugs don't come up again. And so I am very loosely defining the strategy here because if anything, this is just more of a mindset that I want you to adopt. Don't just fix the bug. Fix the system that allowed the bug. And that will take you so far because your coding agent just gets more powerful and more reliable over time.
So there you go. Those are all of my favorite techniques used by all of the top agentic engineers. And like I said earlier, in the description, I will link to the repo with all the commands, the Dynamis Agentic Coding Course, and this diagram if you want to download it for yourself. And so if you appreciated this video and you're looking forward to more things on Agentic Engineering, I would really appreciate a like and a subscribe. And with that, I will see you in the next.