00:00:00Everyone knows that you need a framework for working with coding agents, but not many people
00:00:04have one that's simple, really their own, and something they can evolve over time. Now, there
00:00:09are a lot of over-engineered frameworks out there on GitHub. All these multi-agent systems people
00:00:15are creating, I respect what people are working on, but a lot of times you just need something
00:00:19really simple that just gets the job done for you. Because I know that you have good ideas that you
00:00:24want to build, and you don't want to spend more time creating your agentic coding workflows than
00:00:29you do actually coding, and so that's what I have for you right now. This is my dead simple framework
00:00:35that I use every single time I'm starting a new project with my coding agent. Now, Brownfield
00:00:40Development, working on an existing code base, is slightly different. That's for another video. This,
00:00:45we're focusing on Greenfield Development. We want a simple framework to get our feet on the ground
00:00:50running as fast as possible, building anything new, and everything that I am covering here is universal.
00:00:56These principles will apply no matter the coding agent that you are using. So there are really two
00:01:00parts to this video, and I'm going to be doing a live build with you as I'm explaining everything
00:01:05here to make it super concrete. And so what I have right now with my code base is pretty much nothing
00:01:11besides my AI layer. So there's a few commands and skills that I brought over. This is what I use as a
00:01:16starting point for every single one of my projects. We're going to be creating something from scratch,
00:01:21and so we need to start with our initial planning, creating what is called a PRD. This is the initial
00:01:27scope of work that we have to create the minimum viable product for our application. And there's
00:01:32a lot that goes here, setting up our initial AI layer before we get into any of the actual coding.
00:01:37And then we take our PRD and we split it up into phases of work, and we're going to knock it out
00:01:43with PIV loops. And so I'll talk about what that means, we'll see an example of that, and then
00:01:47while I'm going through this entire implementation, I'll be covering the four golden rules that we want
00:01:52to follow all of the time. So these golden rules are going to fit in pretty naturally as I'm going
00:01:57through creating the PRD, our AI layer, and doing a PIV loop. For example, the context management.
00:02:03Context is your most precious resource when working with AI coding assistants. That's going to be a big
00:02:08theme throughout. Also creating commands and skills for everything and the system evolution mindset,
00:02:14because what we're going for here with our system is to create something that is reliable and
00:02:18repeatable. And so I'll be speaking to that as I go through everything. So just trying to hit on some
00:02:23of the core themes that you'll see throughout this. It's going to be a very value packed video. And so
00:02:28we'll start here with our initial planning, creating what I like to call the AI layer. So I'll explain
00:02:34what that is and we'll build it together right now. So your AI layer is all the assets in your code
00:02:39base that you created to be context for your coding agent. Like your PRD. What are we going to build?
00:02:45Your global rules. How are we going to build it? The commands. So we have reusable workflows for
00:02:50our coding agent. We'll focus on the prime one at first. And then also sub-agents. So we can delegate
00:02:55for research. And generally how I work with my AI layer, and I have this as a resource for you,
00:03:01is I have a more generic set of commands that I'll bring into any new project. And then the point of
00:03:07this is as my code base grows and I start to build it out, I will also evolve my commands to make them
00:03:13more powerful for the specific use case, just making them more specific to my code. And that's
00:03:18generally my recommendation for you. And so use this as a starting point if you want. I'll have
00:03:23a link to the GitHub repo in the description. The point of keeping this so simple is that you
00:03:27can take it for yourself and easily evolve it for your use case and how you like to work. That's why
00:03:33I recommend something like this over a more complex framework like Beemad or the GitHub spec kit.
00:03:38They're really, really powerful, but it's hard to really make it your own. I want you to be able to
00:03:42make this your own. So right now I'll show you what it looks like to create an entire PRD. Define the
00:03:48initial rules for our code base. We'll even customize our first command a little bit. And then
00:03:52I'll talk about sub-agents throughout. And I know we're doing a lot of planning before we write any
00:03:57of our actual code with the PIV loops, but it's important to do this. Doing the planning upfront
00:04:03might seem like we're taking things too slow, but if we create a really good plan, like we have good
00:04:07rules, a good PRD, it means that all of our development after is going to be a lot faster
00:04:13and more reliable. So let's start with our PRD. A lot of people call this a spec. Again, it's just
00:04:18the entire scope of work to build out the initial version of our application. And then after that
00:04:24point, when we have a good foundation, it moves more to brownfield development. That's the next
00:04:28video that I've got coming. So stay tuned for that. And so what I'll do here with my Clod code,
00:04:34I got a basically empty project here besides my AI layer is I will simply have a casual conversation
00:04:40at first. Just telling it about my idea, maybe some ideas I have for the tech stack and the
00:04:45architecture. You start really unstructured, which also just makes it easy to get started.
00:04:50And then you eventually get to the point where you use your conversation as context to create
00:04:55a structure to PRD. And I have a command that'll help us get the job done. I'll cover that once we
00:05:01get there, but first let's just start with our idea. And so what I want to build it just as a
00:05:06fun example for this video is something kind of like link tree, more like a self-hosted version
00:05:12where you can set up your own kind of landing page that has a bunch of links that you can organize.
00:05:16You have analytics like the click through rate on your different links. I want to build something
00:05:20like this. It's a good example for right now because it's not super trivial where you could
00:05:24just vibe code it really easily with some of the more cool features we can add in, but also it's
00:05:29not going to be overly complicated where we'll barely have anything by the end of this video.
00:05:33And so I'm going to use a speech to text tool to get the job done here. I highly recommend using
00:05:39something like Aqua voice. This is what I use. There are a lot of good free and open source options as
00:05:43well. Whisper flow, epicenter whispering, great tools that we have here, but I love using speech
00:05:48to text because I can promise you, I will never be able to type 226 words per minute. And so I'll
00:05:54use a tool like this just to give a big brain dump at first for what I want to build. And this is
00:05:59going to be really raw, but I'm going to go ahead and do a brain dump live for you right now and pay
00:06:03attention to what I asked Claude code to do for me, because this is just as important as the ideas that
00:06:09I'm sharing. I'll explain a little bit about that after as well. And by the way, you can do this
00:06:13entire thing with any AI coding assistant. So here we go. I want to build a link and bio page builder.
00:06:20So something kind of like link tree users can create an account. They can create their own
00:06:24landing page where they specify the links. They can change the order. I want them to be able to have
00:06:29analytics so they can view the click through rates on their links as well. And they can customize the
00:06:33theme. And then for the tech stack, I'm thinking probably like next JS, I'd like to use neon for
00:06:37my database and neon authentication. So definitely it's been up a sub agent to do some research for
00:06:43that. And then for the architecture, not super picky on that. Definitely want your recommendations
00:06:48for that. And just how we're going to handle the theming and the link building all of that. And so
00:06:55I want you to also spin off an agent to do a bunch of web research on just like best practices for
00:07:00creating these link tree type applications. And then what I want you to do after is come back to me
00:07:04with a bunch of questions so we can get on the same page with even the little details for what we are
00:07:10building here. All right, very good. So I'm going to go ahead and send that off and it'll just transcribe
00:07:14in a couple of seconds here. There we go. And boom, we are off to the races. And the most important
00:07:20thing that I did there is actually right at the end when I told it to ask me a bunch of questions
00:07:25after it does its research. So this is really important to drive home here. Your number one goal
00:07:32for any kind of planning with coding agents is to reduce the number of assumptions that your coding
00:07:37agent is making. Because in the end, when a coding agent makes a mistake in your code base, half the
00:07:42time it's not that the code is bad, it's that you just weren't aligned on what exactly you should be
00:07:48building. The common adage is that one line of bad code is just one line of bad code. One line of a
00:07:54bad plan is maybe a hundred lines of bad code. But then one bad line in a PRD, that could be a thousand
00:08:02bad lines of code because you have misalignment. And so I have been doing a lot of experimentation
00:08:08with ways to reduce assumptions over time. And having the coding agent actually just
00:08:13give me a flurry of questions has worked so incredibly well for me. Because especially
00:08:17Clod Code with its ask user question tool, where it can give multiple choice or write your own answer.
00:08:23We'll see that in a second. It's so powerful. They do a really good job thinking about all the edge
00:08:28cases and little details that maybe we aren't even thinking about. It's hard for us to just reason
00:08:33ourselves about what assumptions the coding agent might make. So it's very, very powerful. And then
00:08:38the other thing that I did, as you can see right here, is we have different sub-agents that are
00:08:42running for research. I love using sub-agents for any kind of planning, creating the PRD,
00:08:48or even for the planning process of the PIV loops that we'll talk about in a little bit. And so with
00:08:53Clod Code, I don't actually have to create my own sub-agents because we have the exploration and
00:08:59research sub-agents built right into the tool. For other coding agents, you might have to build
00:09:04your own, which is why I wanted to call it out here. But pretty much every single good coding
00:09:08agent these days supports the idea of sub-agents. And I love using them for research. And the reason
00:09:14for that is context isolation. Again, one of the key themes here is we want to really protect the
00:09:20context of our main coding agent. And the reason that research is such a good use case for sub-agents
00:09:26specifically is because when they explore, they're looking at everything. They're doing a bunch of
00:09:32code-based exploration or web research. They're loading in tens, even hundreds of thousands of
00:09:36tokens for their work. But really all we care about is their findings, the summary at the end
00:09:41that they return to our main context. And so we can keep our main context clean. I don't recommend
00:09:46using sub-agents for implementation because with implementation, we usually care about all of the
00:09:51context of the files that we've been editing and creating. Otherwise it leads to a lot of hallucinations
00:09:57in my experience. And that's also why Claude Code doesn't have any built-in agents for implementation.
00:10:01It's just for research. And that's exactly what we are seeing right here. And so I'm going to let
00:10:06everything complete and then I'll come back once it has the questions for us. All right, so all of our
00:10:12sub-agent research is done and we now have the initial set of questions to answer. And as I go
00:10:17through this, I think you'll really appreciate as much as I do because we are clarifying a ton
00:10:22of things. Every single question that we answer here is removing an assumption from the coding
00:10:26agent. And because it's multiple choice and usually one of the options it presents here is good, we can
00:10:31blitz through this really quickly. And so we can be pretty confident going into the implementation that
00:10:36we have all of the details locked down. And so for example, how should the public page URL structure
00:10:41work? I actually like option number one here and then boom onto the next one. How many pages should
00:10:46each user be able to create? Let's just do one page per user. I mean, some of these are just going to
00:10:50keep going with the defaults here, but there are a lot of instances where it really fundamentally
00:10:54misunderstands something and that's where I can type my own answer to really clarify. So I don't
00:10:59know if I'll run into an example right here, but what I'm going to do is I'm just going to go through
00:11:03and answer all of its questions, come back once I've done that. You don't really need to see me do every
00:11:07single question here because it might do up to like 20, 25 questions. Like it will take this pretty far.
00:11:14And so again, you have to be a bit patient with this, but every single question you answer could
00:11:19save you from having hundreds of lines of bad code. So actually here is a good example where I want to
00:11:24clarify something entirely different from what it suggested here. So it's saying this is the second
00:11:30batch of questions that Claude has asked me, by the way. Should the link editor have a live phone frame
00:11:35preview? So kind of like lovable or bolt on new, where you have the view of what you're creating and
00:11:39then you have the builder on the left side or should it be in line? And I kind of want to actually have
00:11:44both options here. So I can go to the chat about this. And so then it will ask me the other questions
00:11:49after, but now we get to have a little bit of a conversation for this thing specifically. And so
00:11:53I'll say right here, I want to have an inline editor, but I want the option to be able to see
00:11:58the preview as well. So essentially I want to have three buttons, one where I just see the editor, one
00:12:03where I see both of them, one where I just see the preview. So I send that in and then it'll come back
00:12:08and ask me more questions and I'll just continue the process. So here we are. Claude finished asking
00:12:13me a bunch of questions, probably more than I need, but you can really just tweak this to whatever you
00:12:18want to do. And now it's time to create our PRD because as you can see from the final spec summary,
00:12:23it really does have a clear understanding of exactly what we're going to build,
00:12:28even where I'm going to deploy it. I'm going to deploy this to Vercel after I build it.
00:12:31This is fantastic. Like I feel like it isn't really assuming much anymore. So now what I'm going to do
00:12:36is just run my create PRD command. I'll just put this in .claud/prd.md. You can really put this
00:12:43wherever you want. You can even call it whatever you want. And so I am using the command that I
00:12:47mentioned earlier because going back to our four golden rules, one of the big ones here
00:12:53is to commandify everything. If you do something more than twice, which I have definitely started
00:12:59more than a couple of projects, you should make it a command. And then otherwise known as skill
00:13:03because claud code did recently merge commands with skills, but I still like to have the distinction of
00:13:10commands are things that you invoke yourself like slash commit. And then skills, that's when an agent
00:13:15decides to read context, like understanding how to do something new. And so I'm creating a command
00:13:20here because I'm deciding, okay, at this point in the conversation, I want to run this command to
00:13:27output a structured PRD. So as a part of this command, I'm giving it the exact structure,
00:13:32all the different sections that I want in the PRD. So that way I'm making my whole process repeatable,
00:13:38right? A big part of this system that I'm showing you here is you can create something that works
00:13:42for you and then you can do it over and over and over again for new features and new code bases.
00:13:48And so I'm going to do a slash create PRD. I'm going to let it rip and I'll come back once we have
00:13:53our final PRD. All right, so our PRD is now created and it is very comprehensive, but that's good
00:14:00because it's not like we're going to send this into our coding agent to implement. Instead,
00:14:04we're going to build things in phases that are described by our PRD. So I'm not going to do a
00:14:09ton of validation on camera right now. Definitely not worth your time, but I do want to say that it
00:14:14is important to read through this and make sure that you really are aligned on everything. Otherwise
00:14:18it is going to lead to a lot of bad code in the future. And so the first thing I want to call out
00:14:22really quick here is we have our MVP scope and in this we can see all of our questions coming to life
00:14:29in our PRD. And that's important because the conversation we just had was really just unstructured
00:14:34context to feed into the PRD. The PRD is the only thing that's going to survive. So we need to make
00:14:40sure that the entire conversation that we have with our agent is really put in here. We have our
00:14:44out of scope, which is equally as important what we don't want to build right now. We have the entire
00:14:49directory structure. So it already understands generally what is going to go into our code base,
00:14:53which is good because we've already established our tech stack and architecture. And the important
00:14:58thing with this is that we have our phases of work. And so from this, when we use our prime command
00:15:04that we'll talk about in a little bit, we're able to establish like, okay, what have we already built
00:15:09in our code base? What do we have to build next based on the PRD? So this is going to be one of
00:15:13the important pieces of context at the start of every conversation as we build our MVP. And by the
00:15:19way, here's the section itself where I lay out the phases. Each one of these is going to be a granular
00:15:24implementation, one of our PIV loop. So we build the foundation and we build the link management.
00:15:29Then we do the theme and we're going to plan each one of these individually. So we're not trying to
00:15:33have the coding agent ever do too much at once. Okay. So we just created our PRD and that really
00:15:38is the biggest thing. So we're almost there getting into our first implementation. The next thing that
00:15:43we have to set up is our rules. And this is going to be pretty basic at first because our rules are
00:15:48definitely going to evolve the most as we are evolving our actual code base. And so I'm using
00:15:53clod code. I'm just referring to dot agents and agents.md because this is more of the universal
00:15:58standard for the naming for global rules. And so the important thing here is that the constraints
00:16:04and conventions that we always want our coding agent to follow, this goes in our global rule file.
00:16:10And so this is things like the commands to run our application, our testing strategy, our logging
00:16:16strategy. No matter what we're building, we always want our coding agent to see this. And so we want
00:16:20to create this right now, at least an initial version to get us started. And then the other
00:16:25component I have here is the reference folder. You can also use clod code skills for this by the way,
00:16:30but this is just more universal because a lot of times we have other contexts we want the agent to
00:16:35have in mind, but only when we're working on specific parts of our application, like a guide
00:16:40to building front end components if we're working on the front end. And the reason we don't want to
00:16:44just dump this all into our agents.md is this is loaded into the context of the coding agent
00:16:49every single conversation. And remember context is precious. So we want to keep this really concise
00:16:55and then just point it to each of these files. So we can tell the coding agent, if you are working
00:17:00on the front end, then you can read this file. Or if you're building new API endpoints, then you can
00:17:04read this file. So this is essentially progressive disclosure. We have different layers of contexts
00:17:09that the agent can discover over time to make sure it's only loading what it actually needs
00:17:14based on the current task at hand. And so for this one, I have yet another command. Again, commandify
00:17:20everything, just like I have a template I like for my PRDs. I have a template that I like for creating
00:17:25my global rules. And so first we are going to discover what we already have in the code base.
00:17:30Cause I created this to work for existing code bases and new ones. And so for this really all
00:17:35it's going to explore is the PRD. It's going to figure out what's our tech stack, what's our
00:17:38architecture, do some web research for testing and logging strategies, and then bring all that
00:17:43together with my guidance to create my global rules. And I have the exact structure here. And
00:17:50so it's going to be based off of this template that I have. So I'll show you this very quickly as well,
00:17:55because this is the template that I love using for all of my global rules. And you can see that
00:17:59everything here, we really do care about our agency no matter what. Like, okay, here's our tech stack,
00:18:04the commands to run and test things, our project structure. So it has essentially an index of our
00:18:08code base, our architecture, our code patterns, like things like naming conventions, testing
00:18:13and validation strategies. It's pretty basic overall, but we're going to create this first,
00:18:17and then I'll give you a couple of examples of reference documents like our secondary on-demand
00:18:22context. And so I'll go into Claude here and really just in the same conversation where I created my
00:18:27PRD, I'm just going to do create rules because I can really use all of this conversation as context
00:18:33to help. So it just right away, it knows, okay, here's our PRD. Here's our tech stack and things
00:18:38like that. All right. So our create rules command finished, and we now have our global rules. And so
00:18:43I have it pulled up already. Pretty standard here. We have our tech stack, the commands,
00:18:47like we're using Drizzle ORM for our database, for example, project structure, architecture,
00:18:52code patterns. For the sake of brevity, I'm not really customizing things here or applying my own
00:18:57thoughts to this very much, but depending on how technical you are, this is your time to make sure
00:19:03that the constraints and conventions, the code patterns is really aligned with how you want to
00:19:07create your code bases. So you can spend a lot of time with this if you want. I'm just not doing it
00:19:12because I'm focusing on the high-level ideas with you right here. And so I also had to do some web
00:19:16research on best practices for creating things like front-end components and API endpoints.
00:19:21And then based on that, I had to create some on-demand context as well. And again,
00:19:24these could be Clod code skills if you would like. And so if we go back to the global rules and we
00:19:29scroll down to the on-demand context section, here we go. When working on front-end components,
00:19:34read this file. When working on API routes, read this file. So the clod.md is the only thing loaded
00:19:40in upfront, but then it'll decide to bring this in when it needs. And in my experience, it's really
00:19:45good at referencing this, especially if our global rules is concise, like it should be. Like we don't
00:19:50even have 240 lines here. There's 233 lines for our global rules. And then we have our api.md and
00:19:58components.md. These are a lot bigger because when we are working on the task and it's very specific
00:20:03to this, then it's okay to bring in a lot more information to make sure we have good guidance
00:20:08for our coding agent. So again, going back to our diagram here, the rules, this is how we want to
00:20:14build things. The PRD is what exactly we're going to build. And so with both of these things in mind,
00:20:19the last thing that I want to talk about here is commands, specifically the prime command.
00:20:23Then we'll get into building the plan for our first phase and creating the code. So at this point,
00:20:29we have the initial AI layer. We have our PRD, our rules, and those generic commands that I brought in
00:20:34that you can feel free to use for yourself. And so we're going on to the implementation now. But
00:20:39here's the thing. At the start of every new conversation with an AI coding assistant,
00:20:44we need it to catch itself up to speed on the code base. What are we building? What comes next? That
00:20:50is where the prime command comes in. And so this is a command. We'll run /prime at the start of every
00:20:56new session. It is a guided process for it to explore our code base and get itself to the point
00:21:02where it has the mental model, where it's ready for the next feature implementation. And so we'll
00:21:06have it read documentation, explore the structure. It can use sub-agents to do all this as well.
00:21:11Checking the git log, because that's another thing that I'll talk about more in a bit as well,
00:21:15is using git log as our long-term memory. So it can see over time how our code base has been evolving,
00:21:21because that'll help it make decisions around what it's going to build next. And so after this command,
00:21:26it's going to output to us its understanding of the code base. So we can validate it knows
00:21:31what's up with our code base, and we can go on to building the next thing. And so not to cover the
00:21:36prime command in too much detail right here, but we do some operations with git to take advantage
00:21:40of the history. And then we're reading through the core files and identifying anything that we
00:21:45need to pay special attention to that are like main entry points to our application, for example. And
00:21:49then this output report is how we can validate its understanding. And we can evolve this over time to
00:21:55make it specific to our project. Just to give you one really small example here, for reading core
00:22:01documentation, I could say read the drizzle migrations so you understand the database schema,
00:22:08right? It even had the tab complete there. I knew exactly what I was going for. And so as you kind
00:22:12of build your own understanding of like what are the core things I want my coding agent to pay
00:22:16attention to in this code base, like maybe other documentation we have in the reference folder,
00:22:20for example, we can add that here. And so now what I'll do is I'll go into Clod, but I'm going to
00:22:25start a brand new conversation, because now we're going to get into our first PIV loop. And I'll
00:22:30explain the entire PIV loop in a little bit here, but watch this. I'm just going to run Prime. And
00:22:34that's going to be the beginning of my conversation before I do anything I want to explore. And so in
00:22:39this case, it's going to realize like, okay, this is a brand new project. Let me check the PRD. And
00:22:44it's going to recommend like, let's do phase one first. Let's create the foundation for our project.
00:22:49So our Prime completed. Here is the project overview link in bio page builder. The current state,
00:22:54it's an empty repository with just documentation. I did do a test build earlier, which is why it says
00:22:59this, but I cleared everything for right now. And then it pulled the first phase, the foundation
00:23:04from our PRD. And this is what it's recommending that we build. And that's exactly what I am going
00:23:10for here. I want it to pick out phases one at a time from the PRD. So we have granular
00:23:14implementations for our PIV loops, which speaking of the PIV loops, we are going to get into this now.
00:23:20And so PIV is short for plan, implement, validate. We take focused work, usually a phase from a PRD,
00:23:29and we run it through this entire process. So we create a structured plan. That's this part
00:23:34right here around what we're going to tackle. And this process is actually pretty similar to
00:23:38creating a PRD. Then we go into the implementation. And our goal here is to delegate all coding to the
00:23:44coding agent. And then we do the validation after. And so I'm going to cover really quickly what this
00:23:50process looks like. Then we're going to go through it in action. And so first of all, when we are in
00:23:55our planning, we have two layers of planning, we have the top level project planning. That is what
00:24:00we already did creating our PRD and our rules. And now we have the task specific planning. So like I
00:24:07just mentioned, these are pretty similar. Creating a structured plan is pretty similar to creating
00:24:13our structured PRD. The main difference is the structure plan is just very focused on
00:24:19an individual feature and all of the tasks that come with that. So now we're getting down to
00:24:24the code. We're not as high level, but we are still going to start with a very unstructured
00:24:30conversation. I like to call it vibe planning, or we're just going to explore general ideas.
00:24:35What's the architecture for what we're building specifically spinning off sub-agents for code-based
00:24:40analysis and documentation, and then just figuring out like, what are the specific tasks that we need
00:24:44to knock out for this feature? And so we have this conversation and I'll show you an example of this.
00:24:50And then we turn that into a structured document, just like with the PRD. So the goal here is to
00:24:56create a detailed plan of attack for the AI coding assistant based on our conversation. So the
00:25:02conversation is a part of our context, but here we have very specific sections that I want to create
00:25:09in the structure plan. The goal and success criteria of this feature, any documentation
00:25:13that we want to reference that maybe one of the sub-agents found, our task list, which can be as
00:25:18specific as even the individual files that we want to create an update. And then probably the most
00:25:23important part out of this entire plan is the validation strategy. This is kind of like test
00:25:27driven development where we want to be very specific with how we can validate the feature
00:25:33before we even write a single line of code. This forces both us and the coding agent to be very
00:25:38specific about the success criteria. And so we create our structured plan and we are very much
00:25:45a part of this, but then we delegate all of the coding to the agent itself. This is not vibe
00:25:51coding though. The only reason that I'm going to trust the agent but verify is because I am
00:25:56sandwiching the implementation with the planning and the validation that I am very much a part of
00:26:01the process for. And so we are going to have the coding agent check its own work with unit testing,
00:26:06integration testing, and end-to-end testing. We'll see that as well. But then I am going to run my
00:26:11own code review and manually test the application. I'll submit it up myself. I'll go through the
00:26:16application just like a user would make sure that everything is working good before I make that
00:26:20commit and send it off to production or staging or whatever. The important thing here is that in
00:26:26between the planning and the implementation, I am going to be resetting the context. This is one of
00:26:32the golden rules. Context is very precious. And so I have a long and detailed conversation figuring out
00:26:38this feature we're going to implement. And then the structure plan that I create right here, I want it
00:26:44to be all of the context the coding agent needs to get the job done so that I can have a fresh
00:26:50conversation where the plan is the only thing I send in because it has all the documentation to
00:26:55reference. It has the entire task list. So we know what we have to do. We know how to validate. So
00:27:00that way we can just cut things off and go into execution to keep things very focused, right? We
00:27:06want to not have a bunch of context bloating the conversation when we get into writing the actual
00:27:12code. All right. So with that, let's now get into our first PIV loop. And this is going to be a lot
00:27:16simpler than you would think because we really are going to reap the rewards from all of the planning
00:27:22that we did upfront. We are on the same page with our coding agent. We're confident, understands what
00:27:27we want to build. And so there's not even that much planning we're going to have to do for each of
00:27:31these phases, at least at first. And so going back here, we have finished the prime. We are on the same
00:27:36page of the coding agent. And I just gave it a really simple prompt here. Like, yeah, phase one
00:27:40looks good. Just confirm to me exactly everything that we're going to build. Now, usually for PIV
00:27:44loops after the first one, it's a bit more detailed. Like let's look at the code base to figure out how
00:27:49exactly we're going to build this. But right here, it's really simple. So this looks good. And now
00:27:53remember, command defy everything. I want to turn this conversation and this idea of phase one into
00:27:59a structured plan with a task list and validation. So I have another command for that. It is just
00:28:04called create or plan feature slash plan feature. There we go. So I'll send this in and now the plan
00:28:10feature, just like the create PRD, it has this idea of a structure plan built in. So I'll show you
00:28:17this command as well. So plan feature, open this up. So it accepts an optional argument where I can
00:28:23specify what I want to build. In this case, I just using the conversation history. So it already knew,
00:28:28but we go through a phased process here. So feature understanding diving into the code base, which is
00:28:33again, more applicable for future PIV loops, but it does a lot of research, pulling relevant
00:28:38documentation, making sure we have a rich set of contexts going into the execution. And then what
00:28:44you're looking at here, this is the template. So we want to describe the problem statement,
00:28:49any context or reference. We have our implementation plan with the task list right here. And then of
00:28:55course we have our testing strategy. We want to define the validation upfront. And after we create
00:29:00this plan, of course, we're going to validate it. We're going to make sure that we're very specific,
00:29:05the step-by-step here's exactly how we want you to validate the application. And I am actually using
00:29:11the Vercel agent browser CLI skill, which I made a video on that I'll link to right here. So we're
00:29:17going to build in full browser automation. The agent is going to spin up the backend in front and
00:29:21run the database migrations, go through and like build its own link tree and basically just make
00:29:26sure everything is working exactly how a user would use the application. So pretty exciting,
00:29:31but the validation is going to be very detailed here so that by the time control is passed back
00:29:36to us, we can be very confident in the implementation still doing validation ourselves, but it's going to
00:29:42be a lot less work. Okay. And our plan is created now. So let's go ahead and take a look. So I did a
00:29:47bit of validation off camera. I'll show you that in a little bit. Usually you will iterate a good amount
00:29:52because you want to make sure that it's understanding of phase one is aligned with what you have in the
00:29:56PRD, what you actually want to build, go through all of the sections. I encourage you to do so. So
00:30:01here's our implementation plan with the task list. It's very detailed, which is good. We want to be
00:30:05specific now that we are very focused on a single feature. We have our validation with the whole
00:30:10validation pyramid, as I like to call it. So type checking and linting and unit testing. And then
00:30:15we're very specific for the end to end testing, all the user journeys we want the agent to go through.
00:30:20So we can be confident in the implementation when it comes back to us. And that's something
00:30:24it didn't really do that well at first. And so I did have a follow-up prompt here just to give you
00:30:29a quick example of how we can iterate and refine the plan before we send it off to implementation.
00:30:34And then one other little golden nugget, I promise we'll get into implementation in a sec,
00:30:38but this is really important. Generally coding agents aren't the best at working with environment
00:30:43variables. They'll get tripped up. If you don't have the environment variables set before implementation,
00:30:48it'll just do a bunch of mock testing and say everything's validated when it isn't actually,
00:30:53it's really frustrating. And so usually what I like to do in parallel with the planning
00:30:57is that we'll create a .env.example and I'll have it look here. So it knows all the environment
00:31:03variables that I have set, and then I will set up my environment variables as well. So obviously
00:31:09I won't show this file because it has my secrets for the database URL and things like that. But
00:31:13because I already have that set up, now we can rip through the entire implementation and then not
00:31:19just write the code, but it can run the database migration, start up the backend and frontend,
00:31:23use the Vercel agent browser CLI to test everything. And it doesn't have to get interrupted for me to
00:31:29set my environment variables. And so I have the stage set up perfectly now and going into
00:31:34implementation and I'm pretty happy with this plan. So now remember context reset because context is
00:31:40precious. I am now in a brand new context window where I'll use my execute command and the one
00:31:45parameter is the plan that I'm pointing it to. This is all it needs for its context now. And so what
00:31:51I'll do is I'll pause and come back once it's gone through the entire thing. And really we are
00:31:56delegating all the coding to the agent now, reaping the rewards of all the effort we put into planning.
00:32:01Every single PIV loop at this point is going to be so fast now because of the work that we put into
00:32:06this. All right, our implementation is complete. We can see from the screenshots that it did full
00:32:11end-to-end testing. So you can be pretty confident in the implementation because the agent already
00:32:16took care of everything right here, but it's still important for us to do the human validations. We
00:32:21can really make sure that we are trusting but verifying. And so the code review, that gets
00:32:26pretty in the weeds. So I'm not going to do this right now, but if you're more technical, it's
00:32:30definitely important that you do so. But what I am going to do is test the application live with you.
00:32:35So the only thing I did off camera is I created an account already just to make sure that the basic
00:32:39authentication is working, but I haven't done anything here yet. And take a look at this. This
00:32:43is so cool. It already looks really, really nice. So I can set my display name. I can do a bio like
00:32:49a cool AI builder. All right, I can set my avatar URL. So I just uploaded a image to Imgur. So, okay,
00:32:55that's looking really nice as well. I can add some links like, okay, I'll do YouTube. And then that's
00:32:59https youtube.com/atcolemedine. All right, looking nice. Add another link. I'll do LinkedIn. I don't
00:33:08have my LinkedIn URL right now. So I'll just do like linkedin.com. Don't really care. All right,
00:33:11cool. And let me just add one more. I'll do X. All right, so let's just do x.com. Very cool. And I can
00:33:18drag these around to reorder them. It's automatically reflected here. I can view just the editor and then
00:33:24adjust the preview. The theme doesn't look the best right now. Like it's just white, but I think that
00:33:28comes in a later phase anyway, because right now we are just building the foundation. So a lot of
00:33:32this isn't perfect yet, but it's still looking extremely good for a starting point. And then I
00:33:37can click save. And, um, okay, yeah, let's load the API endpoints. This is running this local host.
00:33:42There we go. Changes saved successfully. So I can do a refresh and everything is still going to be
00:33:46there. All right. That's amazing. So this is looking really, really good. Now, what I want to talk about
00:33:51since we've gotten to a good foundation built is the commit message just really quickly here.
00:33:57And so I have another command called slash commit, and this one's really, really basic. You can make
00:34:01this more detailed if you want, but essentially you just want to provide instructions to the agent for
00:34:06how to create a get message, because we are going to use that as our long-term memory. So going back
00:34:11to the diagram here, this is one of those golden rules. Your commit history is your long-term
00:34:17memory. So if we are standardizing our message and that's why we're using a command slash commit to
00:34:22make this reusable, then our agent, when it's going through the prime, it can look at the get log to see
00:34:28a history of what we built recently, which will guide what comes next and maybe patterns that we
00:34:32want it to follow. And so that's the power of this commit message right here. So I'll do slash commit,
00:34:38which I could just run get commit myself. It's really, really easy, but this just makes it so
00:34:43it's always the same kind of message for consistency. So in this case, there's nothing to commit because
00:34:48I already ran this off camera as well, but that is important to take care of after every single
00:34:53implementation. Now, one other super important thing to cover after we have the foundation of our
00:34:58project laid out is you want to set up a framework for regression testing. We want to make sure
00:35:04that as we go through future PIV loops, so we go through this process over and over again for all
00:35:09the features we want to build, we need to make sure the old stuff doesn't break. And so this I'm going
00:35:14to cover more in a different video, all of the strategies that I have for implementing this sort
00:35:19of testing harness yourself, because essentially you go into the agent, you say like, okay, what we
00:35:25have now is great, but I could also go into Aqua voice here and say, I want you to list out all of
00:35:31the end to end testing that you did put this into a command for me. So I can run this later after I
00:35:36build other features so that we can make sure that everything that we built previously is still
00:35:41working, right? Something kind of like that. Again, I'm not going to get too in the weeds of this
00:35:46right now. It takes a while to set this up and kind of create a test harness, but this is how you make
00:35:50sure that your application is stable as you're continuing to build on top of it. And it does take
00:35:55a lot of work to create and maintain this cause you constantly have to update it. And so there are also
00:36:00solutions out there that take care of this for you. And they are very powerful. And one of these
00:36:05applications is QA tech. They have AI testing agents that evolve, they adapt with your codebase.
00:36:11So as you're adding more and more features, they add more and more test cases to make sure that
00:36:16everything, your application is working well as you're continuing to build it out. And so I'll show
00:36:22you an example of this really quickly. It's so easy to get started. So you go into QA tech, they got a
00:36:26free tier for you to get started and try this out. I'll create a project here, and then you just have
00:36:30to paste in a URL that you want to test. And so I took this application since I already made a commit
00:36:35and push it to GitHub. I deployed it in just like a minute to Vercel. So the easiest place to host
00:36:40your sites for free, especially when you build with Next.js. And so I'm going to go to my project here
00:36:45and just paste in this URL. And so it'll take a little bit to create your project and analyze
00:36:50your codebase. And what we can do is just say, I want a good test set up for my site. Help me create
00:36:55the first three to five test cases. And this is kind of like, you know, bolt out new or lovable,
00:36:59or you can just give a prompt for whatever you wanted to do to set up the test suite for your
00:37:04project. But this is what they recommend to get started. I'm going to go ahead and send this in.
00:37:08And it's so cool because it will dig through your website, like actually crawl through it, but you
00:37:12don't have to manage the infrastructure at all. So it analyzes your website and comes up with the test
00:37:16cases. And so I'll come back once it has done that. So mid execution, just want to show you really quick
00:37:21that it crawled my website in just a couple of minutes. And then one of the really important
00:37:25things is we need a way to log into our website. We want the automation to be able to do that. And
00:37:29so they have a way for us to enter in our username and password, and then they're going to store it in
00:37:34a secure way. So I just have a test account created here. I'm going to go ahead and save that. And then
00:37:38it'll use that to get into the website, really dig in and understand all of the user journeys that
00:37:43we want to test here. And there we go. Ed has generated a bunch of test cases for us, and we can
00:37:48even click into each one of these. And we can see the exact flow that it went through. And so now we
00:37:53have all these tests that are set up. And the AI testing agents in QA tech are going to evolve these
00:37:59test cases over time to make sure it continues to cover everything in our code base. As we build more
00:38:04and more features, it is super, super cool. And again, we can build our own kind of command system
00:38:09to do something like this. But I really appreciate having a platform that just takes care of all this
00:38:14for me. And there's agents under the hood that I can chat with to even just like work with the testing
00:38:19here and make sure that I am truly regression testing everything. And so then whenever there's
00:38:24anything that breaks, I can come in here and say, okay, there's a bug with the application right now,
00:38:28create a test that should be failing. Let me address the problem. And then the test should
00:38:33be passing. And so that takes us to the last golden rule that I have here, the system evolution mindset.
00:38:40So whenever we encounter a bug in our code base, it is important to not just address the bug,
00:38:46but think about what we can fix in our AI layer. So that doesn't happen again. Like maybe we need
00:38:51to be more specific about our style guide and our rules, or create a new on-demand context for that.
00:38:57Maybe we need to have more end to end testing that's laid out in our commands, our workflows,
00:39:02whatever it takes to make sure that we don't encounter this issue again. And then we can also
00:39:06do what I just showed in QA tech or our own command system, where we add a test to make sure that we
00:39:12don't encounter that issue again in the code base. And so the power of this, even though it takes
00:39:16time to do it, is that we make our coding agent more reliable and repeatable over time, evolving
00:39:21it along with our code base. And so we're doing three things in parallel. As we were building out
00:39:26our code base, we are evolving our test base, our code base, and our AI layer. And man, does that
00:39:32compound over time. And so going back to cloud code here, I'll just give you a really simple example of
00:39:37this. So one thing that I did do to iterate once off camera is I worked on the style for the site.
00:39:43Because if you go back to the start of the video, you'll see that I kind of forgot to talk about the
00:39:47style, exactly how I wanted the site to look. So cloud code just kind of made its own assumptions
00:39:51there. And it didn't look the best. And so I had to iterate on that. And so one thing that I can do
00:39:56here is, you know, at first I didn't like the style that you implemented for the front end. We
00:40:01definitely don't have enough in the AI layer with our rules and on-demand context for a style
00:40:06guideline. So I want you to do some meta reasoning here. Don't change anything, but help me think
00:40:10about right now, what could we change with our rules or on-demand context, something we could
00:40:15add or update so that we have more consistent styles that we're going to be building as we
00:40:20continue to, you know, build up the analytics and other things, other pages in this application.
00:40:25And so the important thing I'm doing here is telling it to not change anything yet,
00:40:29because usually I want to have a lot more control over changing the AI layer versus for the code
00:40:34base, I just want to delegate as much of that to the agent as possible. So I have it reason with me,
00:40:39but I usually like to make these small and very focused changes myself. And you can see here that
00:40:44it recommends creating a style.md in the reference folder. So a third piece of on-demand context for
00:40:50us. And so this, I guess would go along with the components.md. That's more like, here's how we
00:40:54should lay out things. And then the styles.md is here's how it works. Here's how we should work
00:40:58with Tailwind CSS and probably Shad CN, for example. So I'm not going to go through the full
00:41:03implementation of this and correcting everything, but just trying to give you a good example here of
00:41:06how, when we encounter anything where we have bugs in the code or just isn't quite aligned with us,
00:41:11like we have right here, it's always an opportunity for us to evolve the AI layer. And so we're more
00:41:16and more in tune with our coding agent for this specific project, as we continue to build it out.
00:41:20And that my friend is the most high leverage part of the entire process, really saving the best for
00:41:26the end. So that is everything. It really is a dead simple process for getting reliable and repeatable
00:41:32results with your coding agents when you are starting new projects, because now after the
00:41:35system evolution, we just take it back up to the top and we go through more PIV loops going through
00:41:40the exact same process to build out all the phases in our PRD, add any other features, whatever it
00:41:45takes to get to that minimum viable product. And then that'll take us into Brownfield development
00:41:49with one of the next videos that I'll put out on my channel. And so if this all sounds good to you
00:41:54and you want to dive even deeper with my full resource library of commands and rules, you want
00:41:59to see what system evolution really looks like and get deep into that. Definitely check out the
00:42:04agentic coding course that I have in the dynamics community. I'll have a link to this in the
00:42:08description and the pin to comment. And so that's everything that I got for you right now. So if you
00:42:13appreciated this video, you're looking forward to more things on agentic coding at Brownfield
00:42:17development video, I'd really appreciate a like and a subscribe. And with that, I will see you in
00:42:22the next video.