My Complete Agentic Coding Workflow to Build Anything
A 42-minute live build of a link-in-bio app that walks through one simple greenfield workflow for coding agents: a PRD, a small AI layer of rules and commands, and repeatable plan, implement, validate loops.
Posted
8 months ago
Duration
Format
Tutorial
educational
Views
76K
1.6K likes
57 · 43
Big Idea
The argument in one line.
Reliable agentic coding comes from removing the agent's assumptions before any code is written, then building in small plan, implement, validate loops and fixing the AI layer every time something goes wrong.
Who This Is For
Read if. Skip if.
READ IF YOU ARE…
You use Claude Code, Codex, Cursor or a similar coding agent and your new projects drift because the agent keeps guessing what you meant.
You've looked at heavy spec frameworks like BMAD or GitHub Spec Kit and want something small enough to own and change yourself.
You're starting a new app from an empty folder and want a repeatable order of operations from idea to first working feature.
You keep pasting the same instructions into every session and want to turn them into commands, rules and on-demand reference files.
Your agent says everything passed but the app is still broken, and you want a validation step you can actually trust.
SKIP IF…
You're adding features to a large existing codebase; this video covers greenfield only and the brownfield workflow is promised for a separate video.
You want a code review walkthrough or deep customization of the rules file; both are mentioned and deliberately skipped on camera.
You're looking for a full regression testing setup; the video points at the problem and shows a hosted testing tool rather than building a harness.
TL;DR
The full version, fast.
Most agent mistakes come from misalignment, not bad code, so the workflow spends its effort up front. You brain-dump the idea, have the agent research with subagents and then ask you every clarifying question it can think of, and turn that conversation into a structured PRD split into phases. A lean AGENTS.md or CLAUDE.md holds always-on rules, with bigger reference docs loaded only when relevant. Each phase then runs as a PIV loop: prime the agent, plan with a written validation strategy, reset context, execute from the plan alone, then verify with automated and manual tests. Every bug becomes a fix to the rules, commands or tests so it never repeats.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Positions the workflow against heavy multi-agent frameworks, scopes it to greenfield work, and previews the two parts: PRD planning and PIV loops, plus four golden rules.
02:28 – 04:14
02 · Creating the AI layer
Defines the AI layer (PRD, global rules, commands, subagents) and argues for a small generic starter kit you evolve per project over complex frameworks like BMAD or Spec Kit.
04:14 – 08:38
03 · PRD creation
Brain-dumps the link-in-bio idea by voice, asks for subagent research on the stack and best practices, and ends the prompt by asking the agent to come back with questions.
08:38 – 15:42
04 · Subagents, questions and the structured PRD
Explains subagents for context isolation, answers 20-plus multiple choice questions to remove assumptions, then runs a create-PRD command and reviews scope, out of scope and phases.
15:42 – 20:50
05 · Global rules and on-demand context
Generates a 233-line AGENTS.md style rules file with a create-rules command, plus larger API and component reference docs the agent loads only when relevant.
20:50 – 23:18
06 · The prime command
A start-of-session command that reads docs, explores structure and checks the git log, then reports back so you can confirm the agent's mental model before work begins.
23:18 – 31:40
07 · The PIV loop
Plan, implement, validate: vibe planning turned into a structured plan with goals, references, task list and a validation strategy, then a context reset before execution. Also covers setting environment variables ahead of time.
31:40 – 34:53
08 · Live implementation and validation
Executes phase one from the plan in a fresh session, checks the agent's browser test screenshots, manually tests the editor, and explains the commit command as long-term memory.
34:53 – 38:40
09 · Keeping the codebase reliable
Introduces regression testing so later phases do not break earlier ones, then demos QA Tech generating test cases against the deployed app (sponsored segment).
38:40 – 42:23
10 · Evolve your coding agent over time
The system evolution mindset: every bug or style miss prompts a change to rules, reference docs, commands or tests. Demonstrated by asking the agent to reason about a missing style guide.
Atomic Insights
Lines worth screenshotting.
One bad line of code is one bad line, one bad line in a plan is about 100, and one bad line in a PRD can be 1,000.
The single most useful planning prompt is asking the agent to come back with a batch of questions before it builds anything.
Half of the mistakes a coding agent makes come from misalignment on what to build, not from writing bad code.
Use subagents for research, not implementation, because research burns huge context but only the summary matters to the main agent.
Implementation subagents tend to hallucinate because the work depends on the full context of every file being edited.
The planning conversation is disposable context; only the PRD survives, so everything you agreed on has to be written into it.
An out-of-scope section in a PRD matters as much as the scope, because it tells the agent what not to build yet.
Keep the global rules file short, around 230 lines, and point it to larger reference docs the agent loads only for the task at hand.
If you do something with your agent more than twice, turn it into a command so the process is the same every time.
Start every new session with a prime command that reads the docs, scans the structure and checks the git log before any work begins.
Standardized commit messages turn git history into the agent's long-term memory of what was built and what comes next.
Write the validation strategy before the code, the way test-driven development defines success before the first line exists.
Reset the context window between planning and execution so the written plan is the only thing the coding agent sees.
Set real environment variables before implementation, or the agent will quietly mock its tests and report false success.
Every bug is a prompt to fix the AI layer, not just the code, so the same class of mistake never happens again.
Takeaway
Kill the agent's assumptions before any code exists.
PLAN, THEN LOOP
A coding agent builds well when a PRD and lean rules remove its guesswork, each feature runs as a plan, implement, validate loop, and every mistake upgrades the system.
02Creating the AI layer
Treat everything you write for the agent as one AI layer: the PRD says what to build, rules say how, commands hold workflows, subagents do research.
Start from a small generic set of commands and rules you understand, then make them more specific to each codebase as it grows.
03PRD creation
Begin a new project with an unstructured voice brain-dump of the idea, stack preferences and open questions instead of a polished spec.
End the planning prompt by telling the agent to research first and then ask you every question it has, because misalignment causes most bad code.
04Subagents, questions and the structured PRD
Send research to subagents so the tens of thousands of tokens they read stay out of your main context and only their findings come back.
Keep implementation in the main agent, since writing code depends on the full context of every file being created and edited.
Answer clarifying questions one by one and type your own answer when none fit; each one removes an assumption that could cost hundreds of lines.
Convert the conversation into a structured PRD with scope, out of scope, directory structure and numbered phases, because the chat itself will not survive.
05Global rules and on-demand context
Keep the always-loaded rules file short with the stack, run commands, structure and conventions, and put long front-end or API guides in reference files.
Tell the rules file when to read each reference doc so the agent loads detailed guidance only for the task at hand.
Generate the rules from a template right after the PRD so they inherit the tech stack and architecture you just settled.
06The prime command
Open every new session with a prime command that reads the PRD and core docs, explores the structure and checks the git log.
Make the prime command report its understanding back, so you can catch a wrong mental model before it touches any code.
07The PIV loop
Build one PRD phase at a time so the agent never has to do too much in a single pass.
Write a structured plan per feature with goals, success criteria, references, a file-level task list and a step-by-step validation strategy.
Define validation before coding, including end-to-end user journeys the agent runs in a real browser, so done is never ambiguous.
Set real environment variables and a .env.example before implementation, or the agent will mock its tests and report false success.
08Live implementation and validation
Reset the context window after planning and hand the executing agent only the plan file, so no exploratory chatter bloats the build.
Let the agent run its own unit, integration and browser tests, then still review the code and click through the app yourself.
Use a commit command so every message follows the same format, turning git history into memory the prime command can read later.
09Keeping the codebase reliable
After the first working phase, capture the end-to-end checks you already ran as a reusable regression suite so new features cannot quietly break old ones.
When a bug appears, first write a test that fails because of it, fix the code, and confirm the test now passes.
10Evolve your coding agent over time
Treat every bug or style miss as a gap in the AI layer and add the missing rule, reference doc, command step or test.
Ask the agent to reason about what to change in the rules without changing anything, then make those small AI layer edits yourself.
Evolve the code, the tests and the AI layer together, so each loop through the PRD runs faster and more predictably than the last.
Glossary
Terms worth knowing.
Greenfield development
Building a new project from an empty codebase, as opposed to brownfield work where you add features to existing code with its own history and constraints.
PRD
Product requirements document. A written scope of work for the first version of a product, covering features, what is out of scope, tech stack, structure and the phases the build will follow.
AI layer
All the files in a codebase written as context for a coding agent: the PRD, global rules, reusable commands, on-demand reference docs and any subagent definitions.
PIV loop
Plan, implement, validate. A cycle where one focused piece of work gets a structured plan, is coded by the agent from that plan, and is then checked by both the agent's tests and a human.
Subagent
A separate agent instance the main agent spins up for a task like web research or code exploration. It works in its own context window and returns only a summary.
Context isolation
Keeping noisy work such as research out of the main agent's context window so the main conversation stays focused and does not fill up with tokens it no longer needs.
Global rules file
A file like AGENTS.md or CLAUDE.md that the coding agent loads at the start of every conversation, holding the tech stack, commands, structure and conventions it should always follow.
Progressive disclosure
Giving an agent layers of context it can discover as needed, such as a short rules file that points to detailed front-end or API guides read only when that work comes up.
Prime command
A reusable command run at the start of a session that has the agent read key docs, explore the codebase and check git history, then report its understanding back to you.
Regression testing
Re-running checks on features that already worked to make sure new changes have not broken them.
Vibe planning
A loose, unstructured conversation with the agent about architecture and tasks for a feature, used as raw material before writing a structured plan.
“One line of bad code is just one line of bad code. One line of a bad plan is maybe 100 lines of bad code. But then one bad line in a PRD, that could be 1000 bad lines of code.”
self-contained escalation with numbers, no setup needed→ TikTok hook↗ Tweet quote
07:31
“Your number one goal for any kind of planning with coding agents is to reduce the number of assumptions that your coding agent is making.”
single clear rule, quotable as a thesis→ newsletter pull-quote↗ Tweet quote
02:04
“Context is your most precious resource when working with AI coding assistants.”
“This is not vibe coding though. The only reason that I'm going to trust the agent but verify is because I am sandwiching the implementation with the planning and the validation.”
answers the vibe coding objection in one breath→ TikTok hook↗ Tweet quote
30:40
“If you don't have the environment variable set before implementation, it'll just do a bunch of mock testing and say everything's validated when it isn't actually.”
six-word rule that reframes a familiar habit→ newsletter pull-quote↗ Tweet quote
38:40
“Whenever we encounter a bug in our code base, it is important to not just address the bug, but think about what we can fix in our AI layer so that it doesn't happen again.”
the core habit of the whole system in one sentence→ TikTok hook↗ Tweet quote
The Script
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
17px
metaphoranalogystory
Everyone knows that you need a framework for working with coding agents, but not many people have one that's simple, really their own, and something they can evolve over time. Now, there are a lot of over -engineered frameworks out there on GitHub. All these multi -agent systems people are creating, I respect what people are working on, but a lot of times you just need something really simple that just gets the job done for you.
Because I know that you have good ideas that you want to build, and you don't want to spend more time creating your agentic coding workflows. than you do actually coding. And so that's what I have for you right now.
This is my dead simple framework that I use every single time I'm starting a new project with my coding agent. Now, brownfield development, working on an existing code base is slightly different. That's for another video.
This we're focusing on greenfield development. We want a simple framework to get our feet on the ground running as fast as possible, building anything new. And everything that I am covering here is universal.
These principles will apply no matter the code. agent that you are using. So there are really two parts to this video.
And I'm going to be doing a live build with you as I'm explaining everything here to make it super concrete. And so what I have right now with my code base is pretty much nothing besides my AI layer. So there's a few commands and skills that I brought over.
This is what I use as a starting point for every single one of my projects, we're going to be creating something from scratch. And so we need to start with our initial planning, creating what is called a PRD. This is the initial scope of work.
that we have to create the minimum viable product for our application. And there's a lot that goes here, setting up our initial AI layer before we get into any of the actual coding. And then we take our PRD and we split it up into phases of work.
And we're going to knock it out with PIV loops. And so I'll talk about what that means. We'll see an example of that.
And then while I'm going through this entire implementation, I'll be covering the four golden rules that we want to follow all of the time. So these golden rules are going to fit in pretty naturally as I'm going through creating the PRD, our AI layer, and doing a PIV loop. For example, the context management.
Context is your most precious resource when working with AI coding assistants. That's gonna be a big theme throughout. Also creating commands and skills for everything and the system evolution mindset because what we're going for here with our system is to create something that is reliable and repeatable.
And so I'll be speaking to that as I go through everything. So just trying to hit on some of the core themes that you'll see throughout this. It's gonna be a very value -packed video.
And so we'll start here with our initial. planning, creating what I like to call the AI layer. So I'll explain what that is and we'll build it together right now.
So your AI layer is all the assets in your code base that you created to be context for your coding agent, like your PRD, what are we going to build, your global rules, how are we going to build it, the commands, so we have reusable workflows for our coding agent, we'll focus on the prime one at first, and then also sub -agents so we can delegate for research.
And generally how I work with my AI layer, and I have this as a resource for you is I have a more generic set of commands that I'll bring into any new project. And then the point of this is as my code base grows and I start to build it out, I will also evolve my commands to make them more powerful for the specific use case, just making them more specific to my code.
And that's generally my recommendation for you. And so use this as a starting point if you want. I'll have a link to the GitHub repo in the description.
The point of keeping this so simple is that you can take it for yourself and easily easily evolve it for your use case and how you like to work. That's why I recommend something like this over a more complex framework like BMAD or the GitHub spec kit.
They're really, really powerful, but it's hard to really make it your own. I want you to be able to make this your own. So right now I'll show you what it looks like to create an entire PRD, define the initial rules for our code base.
We'll even customize our first command a little bit, and then I'll talk about sub -agents throughout. And I know we're doing a lot of planning before we write any of our actual code. with the piv loops, but it's important to do this.
Doing the planning upfront might seem like we're taking things too slow, but if we create a really good plan, like we have good rules, a good PRD, it means that all of our development after is going to be a lot faster and more reliable. So let's start with our PRD. A lot of people call this a spec.
Again, it's just the entire scope of work to build out the initial version of our application. And then after that point, when we have a good foundation, it moves more to brownfield. development.
That's the next video that I've got coming. So stay tuned for that. And so what I'll do here with my cloud code, I got a basically empty project here besides my AI layer is I will simply have a casual conversation at first, just telling it about my idea, maybe some ideas I have for the tech stack and the architecture, you start really unstructured, which also just makes it easy to get started.
And then you eventually get to the point. where you use your conversation as context to create a structured PRD. And I have a command that'll help us get the job done.
I'll cover that once we get there. But first, let's just start with our idea. And so what I want to build just as a fun example for this video is something kind of like Linktree, more like a self -hosted version where you can set up your own kind of landing page that has a bunch of links that you can organize.
You have analytics like the click -through rate on your different links. I want to build something like this. It's a good example.
for right now because it's not super trivial where you could just vibe code it really easily with some of the more cool features we can add in. But also it's not going to be overly complicated where we'll barely have anything by the end of this video. And so I'm going to use a speech to text tool to get the job done here.
I highly recommend using something like AquaVoice. This is what I use. There are a lot of good free and open source options as well.
WhisperFlow, Epicenter Whispering, great tools that we have here. I love using speech to text because I can promise you I will never be able to type 226 words per minute so i'll use a tool like this just to give a big brain dump at first for what i want to build and this is going to be really raw but i'm going to go ahead and do a brain dump live for you right now and pay attention to what i asked claude code to do for me because this is just as important as the ideas that i'm sharing i'll explain a little bit about that after as well and by the way you can do this entire thing with any ai coding assistant so here we go I want to build a link in bio page builder.
So something kind of like Linktree. Users can create an account. They can create their own landing page where they specify the links.
They can change the order. I want them to be able to have analytics so they can view the click -through rates on their links as well. And they can customize the theme.
And then for the tech stack, I'm thinking probably like Next .js. I'd like to use Neon for my database and Neon authentication. So definitely spin up a sub -agent to do some research for that.
And then for the architecture, not super picky. that definitely want your recommendations for that and just how we're going to handle the theming and the link building all of that and so i want you to also spin off an agent to do a bunch of web research on just like best practices for creating these link tree type applications and then what i want you to do after is come back to me with a bunch of questions so we can get on the same page with even the little details for what we are building here all right very good so i'm going to go ahead and send that off and it'll just transcribe in a couple of seconds here There we go, and boom, we are off to the races.
And the most important thing that I did there is actually right at the end when I told it to ask me a bunch of questions after it does its research. So this is really important to drive home here. Your number one goal for any kind of planning with coding agents is to reduce the number of assumptions that your coding agent is making.
Because in the end, when a coding agent makes a mistake in your code base, half the time it's not that the code is bad, it's that you - just weren't aligned on what exactly you should be building. The common adage is that one line of bad code is just one line of bad code.
One line of a bad plan is maybe 100 lines of bad code. But then one bad line in a PRD, that could be 1000 bad lines of code because you have misalignment. And so I have been doing a lot of experimentation with ways to, you know, reduce assumptions over time and having the coding agent actually just give me a flurry of questions has worked so incredibly well for me because especially Claude code with its ask user question tool, where it can give like multiple choice or write your own answer.
We'll see that in a second. It's so powerful. Like they do a really good job thinking about all the edge cases and little details that maybe we aren't even thinking about.
Like it's hard for us to just reason ourself about what assumptions the coding agent might make. So it's very, very powerful. And then the other thing that I did, as you can see right here is we have different sub agents that are running for research.
I love using subagents for any kind of planning, creating the PRD, or even for the planning process of the piv loops that we'll talk about in a little bit. And so with Cloud Code, I don't actually have to create my own subagents because we have the exploration and research subagents built right into the tool. For other coding agents, you might have to build your own, which is why I wanted to call it out here.
But pretty much every single good coding agents these days supports the idea of subagents. I love using... them for research.
And the reason for that is context isolation. Again, one of the key themes here is we want to really protect the context of our main coding agent. And the reason that research is such a good use case for subagents specifically is because when they explore, they're looking at everything.
They're doing a bunch of code -based exploration or web research. They're loading in tens, even hundreds of thousands of tokens for their work. But really all we care about is their findings, the summary at the end that they were...
to our main context. And so we can keep our main context clean. I don't recommend using sub -agents for implementation because with implementation, we usually care about all of the context of the files that we've been editing and creating.
Otherwise it leads to a lot of hallucinations in my experience. And that's also why Cloud Code doesn't have any built -in agents for implementation. It's just for research.
And that's exactly what we are seeing right here. And so I'm going to let everything complete and then I'll come back once it has the questions for us. so all of our sub -agent research is done and we now have the initial set of questions to answer and as i go through this i think you'll really appreciate as much as i do because we are clarifying a ton of things every single question that we answer here is removing an assumption from the coding agent and because it's multiple choice and usually one of the options it presents here is good we can blitz through this really quickly and so we can be pretty confident going into the implementation that we have all of the details locked down and so for example how should public page URL structure work?
I actually like option number one here. And then boom, on to the next one. How many pages should each user be able to create?
Let's just do one page per user. I mean, some of these are just going to keep going with the defaults here. But there are a lot of instances where it really fundamentally misunderstands something.
And that's where I can type my own answer to really clarify. So I don't know if I'll run into an example right here. But what I'm going to do is I'm just going to go through and answer all of its questions come back once I've done that you don't really need to see me do every single question here, because it might do up to like 20 25 questions like it will take this pretty far and so again you have to be a bit patient with this but every single question you answer could save you from having hundreds of lines of bad code so actually here is a good example where i want to clarify something entirely different from what it suggested here so it's saying this is the second batch of questions that claude has asked me by the way should the link editor have a live phone frame preview so kind of like lovable or bolt -on new where you have the of what you're creating.
And then you have the builder on the left side, or should it be in line and I kind of want to actually have both options here. So I can go to the chat about this. And so then it will ask me the other questions after but now we get to have a little bit of a conversation for this thing specifically.
And so I'll say right here. I want to have an inline editor, but I want the option to be able to see the preview as well. So essentially, I want to have three buttons, one where I just see the editor, one where I see both, and one where I just see the preview.
So I send that in, and then it'll come back and ask me more questions, and I'll just continue the process. So here we are. Claude finished asking me a bunch of questions, probably more than I need, but you can really just tweak this to whatever you want to do.
And now it's time to create our PRD, because as we can see from the final spec summary, really does have a clear understanding of exactly what we're going to build, even where I'm going to deploy it. I'm going to deploy this to Vercel after I build it.
This is fantastic. Like I feel like it isn't really assuming much anymore. So now what I'm going to do is just run my create PRD command.
I'll just put this in .cloud slash PRD .md. You can really put this wherever you want. You can even call it whatever you want.
And so I am using the command that I mentioned earlier, because going back to our four golden rules, one of the big ones here, is to commandify everything. If you do something more than twice, which I have definitely started more than a couple of projects, you should make it a command.
And then otherwise known as skill because cloud code did recently merge commands with skills. But I still like to have the distinction of commands are things that you invoke yourself like slash commit. And then skills, that's when an agent decides to read context, like understanding how to do something new.
And so I'm creating a command here because I'm deciding, okay, at this point in the conversation, I want to run this command to output a structured PRD. So as a part of this command, I'm giving it the exact. structure, all the different sections that I want in the PRD.
So that way, I'm making my whole process repeatable, right? A big part of this system that I'm showing you here is you can create something that works for you. And then you can do it over and over and over again for new features and new code bases.
And so I'm going to do slash create PRD, I'm going to let it rip and I'll come back once we have our final PRD. Alright, so our PRD is now created and it is very comprehensive, but that's good, because it's Not like we're going to send this into our coding agent to implement.
Instead, we're going to build things in phases that are described by our PRD. So I'm not going to do a ton of validation on camera right now. Definitely not worth your time.
But I do want to say that it is important to read through this and make sure that you really are aligned on everything. Otherwise, it is going to lead to a lot of bad code in the future. So the first thing I want to call out really quick here is we have our MVP scope.
And in this, we can see all of our questions coming to life in our PRD. And that's important because the conversation we just had was really just unstructured context to feed into the PRD. The PRD is the only thing that's going to survive.
So we need to make sure that the entire conversation that we have with our agent is really put in here. We have our out of scope, which is equally as important what we don't want to build right now. We have the entire directory structure.
So it already understands generally what is going to go into our code base, which is good because we've already established our tech stack and architecture. And the important thing with this is that we... have our phases of work.
And so from this, when we use our prime command that I'll talk about in a little bit, we're able to establish like, okay, what have we already built in our code base? What do we have to build next based on the PRD? So this is going to be one of the important pieces of context at the start of every conversation as we build our MVP.
And by the way, here's the section itself where I lay out the phases. Each one of these is going to be a granular implementation, one of our pivots. So we build the foundation and we build the link.
then we do the theme. And we're gonna plan each one of these individually so we're not trying to have the coding agent ever do too much at once. Okay, so we just created our PRD and that really is the biggest thing.
So we're almost there getting to our first implementation. The next thing that we have to set up is our rules. And this is gonna be pretty basic at first because our rules are definitely going to evolve the most as we are evolving our actual code base.
And so I'm using cloud code. I'm just referring to .agents and agents .md because this is more of the universal standard for the naming for global rules. so the important thing here is that the constraints and conventions that we always want our coding agent to follow this goes in our global rule file and so this is things like the commands to run our application our testing strategy our logging strategy no matter what we're building we always want our coding agent to see this and so we want to create this right now at least an initial version to get us started and then the other component i have here is the reference folder you can also use cloud code skills for this by the way but this is just more universal because a lot of times we have other contexts we want the agent to have in mind but only when we're working on specific parts of our application like a guide to building front -end components if we're working on the front end and the reason we don't want to just dump this all into our agents .md is this is loaded into the context of the coding agent every single conversation and remember context is precious so we want to keep this really concise and then just point it to each of these files so we can tell the coding agent if you are working
the front end then you can read this file or if you're building new api endpoints then you can read this file so this is essentially progressive disclosure we have different layers of context that the agent can discover over time to make sure it's only loading what it actually needs based on the current task at hand and so for this one i have yet another command again commandify everything just like i have a template i like for my prds i have a template that i like for creating my global rules and so first we are going to discover what we are have in the codebase because i created this to work for existing codebases and new ones and so for this really all it's going to explore is the PRD.
It's going to figure out what's our tech stack, what's our architecture, do some web research for testing and logging strategies, and then bring all that together with my guidance to create my global rules. And I have the exact structure here. And so it's going to be based off of this template that I have.
So I'll show you this very quickly as well, because this is the template that I love using for all of my global rules. And you can see that everything here, we really do care about our agency no matter what. Like, okay, here's our tech stack.
commands to run and test things, our project structure, so it has essentially an index of our code base, our architecture, our code patterns, like things like naming conventions, testing and validation strategies, it's pretty basic overall. But we're going to create this first. And then I'll give you a couple of examples of reference documents, like our secondary on demand context.
And so I'll go into Claude here. And really just in the same conversation where I created my PRD, I'm just going to do create rules, because I can really use all this conversation as con text to help.
So it just right away it knows, okay, here's our PRD, here's our tech stack and things like that. All right, so our create rules command finished, and we now have our global rules. And so I have it pulled up already.
Pretty standard here, we have our tech stack, the commands, like we're using drizzle ORM for our database, for example, project structure, architecture, code patterns. For the sake of brevity, I'm not really customizing things here or applying my own thoughts to this very much. But depending on how technical you are, this is your time to make sure that the constraints and conventions, the code patterns is really aligned with how you want to create your code bases.
So you can spend a lot of time with this. If you want, I'm just not doing it, because I'm focusing on the high level ideas with you right here. And so I also had to do some web research on best practices for creating things like front end components and API endpoints.
And then based on that, I had to create some on demand context as well. And again, these could be cloud code skills, if you would like. And so if we go back to the global rules, let me scroll down to the on demand context here we go when working on front -end components read this file when working on api routes read this file so the claw .md is the only thing loaded in up front but then it'll decide to bring this in when it needs and in my experience it's really good at referencing this especially if our global rules is concise like it should be like we don't even have 240 lines there's 233 lines for our global rules and then we have our api .md and components .md these are a lot bigger because when we are working on the task, and it's very specific to this, then it's okay to bring in a lot more information to make sure we have good guidance for our coding agent.
So again, going back to our diagram here, the rules, this is how we want to build things, the PRD is what exactly we're going to build. And so with both of these things in mind, the last thing that I want to talk about here is commands, specifically the prime command, then we'll get into building the plan for our first phase and creating the code.
So at this point, we have the initial We have our PRD, our rules, and those generic commands that I brought in that you can feel free to use for yourself. And so we're going on to the implementation now.
But here's the thing. At the start of every new conversation with an AI coding assistant, we need it to catch itself up to speed on the code base. What are we building?
What comes next? That is where the prime command comes in. And so this is a command.
We'll run slash prime at the start of every new session. It is a guided process for it to explore our code base and get itself to the point where it has a mental model, where it's ready for the next feature implementation. And so we'll have it read documentation, explore the structure.
It can use subagent. to do all this as well checking the git log because that's another thing that i'll talk about more in a bit as well is using git log as our long -term memory so it can see over time how our code base has been evolving because that'll help it make decisions around what it's going to build next and so after this command it's going to output to us its understanding of the code base so we can validate it knows what's up with our code base and we can go on to building the next thing and so not to cover the prime command in too much detail right here but we do some operations with git to take advantage of the history and then we're reading through the core files and identifying anything that we need to pay special attention to that are like main entry points to our application for example and then this output report is how we can validate its understanding and we can evolve this over time to make it specific to our project just to give you one really small example here for reading core documentation i could say read the drizzle migrations so you understand the database schema right
had the tab complete there knew exactly what I was going for. And so as you kind of build your own understanding of like, what are the core things I want my coding agent to pay attention to in this code base, like maybe other documentation we have in the reference folder, for example, we can add that here. And so now what I'll do is I'll go into Claude, but I'm going to start a brand new conversation because now we're going to get into our first pivot loop.
And I'll explain the entire pivot loop in a little bit here. But watch this, I'm just going to run prime. And that's going to be the beginning of my conversation before I do anything I want to explore.
And so in this case, it's going to realize like, okay, this is a brand new project. Let me check the PRD. And it's going to recommend like, let's do phase one first, let's create the foundation for our project.
So our prime completed, here is the project overview link and bio page builder, the current state, it's an empty repository with adjust documentation, I did do a test build earlier, which is why it says this, but I cleared everything for right now. And then it pulled the first phase, the foundation from our PRD. And this what it's recommending that we build and that's exactly what i am going for here i want it to pick out phases one at a time from the prd so we have granular implementations for our piv loops which speaking of the piv loops we are going to get into this now and so piv is short for plan implement validate we take focused work usually a phase from a prd and we run it through this entire process so we create a structured plan that's this part right here around what we're going to tackle and this process is actually pretty similar to creating a PRD.
Let me go into the implementation. And our goal here is to delegate all coding to the coding agent. And then we do the validation after and so i'm going to cover really quickly what this process looks like then we're going to go through it in action and so first of all when we are in our planning we have two layers of planning we have the top level project planning that is what we already did creating our prd and our rules and now we have the task specific planning So like I just mentioned, these are pretty similar.
Creating a structured plan is pretty similar to creating our structured PRD. The main difference is the structure plan is just very focused on an individual feature and all of the tasks that come with that. So now we're getting down to the code.
We're not as high level, but we are still going to start with a very unstructured conversation. I like to call it vibe planning, where we're just going to explore general ideas. What's the architecture?
for what we're building specifically, spinning off sub -agents for code -based analysis and documentation. And then just figuring out like what are the specific tasks that we need to knock out for this feature. And so we have this conversation and I'll show you an example of this.
And then we turn that into a structured document, just like with the PRD. So the goal here is to create a detailed plan of attack for the AI coding assistant based on our conversation. So the conversation is a part of our context.
But here we have very specific sections that I want to create in the structure plan. The goal and success criteria. of this feature, any documentation that we want to reference that maybe one of the sub -agents found, our task list, which can be as specific as even the individual files that we want to create and update.
And then probably the most important part out of this entire plan is the validation strategy. This is kind of like test -driven development where we want to be very specific with how we can validate the feature before we even write a single line of code. This forces both us and the coding agent to be very specific about the success.
criteria and so we create our structure plan and we are very much a part of this but then we delegate all of the coding to the agent itself this is not vibe coding though the only reason that i'm going to trust the agent but verify is because i am sandwiching the implementation with the planning and the validation that i am very much a part of the process for and so we are going to have the coding agent check its own work with unit testing integration testing and end -to -end testing we'll see that as well but then i am going to run my own code review and manually test the application i'll spin it up myself i'll go through the application just like a user would make sure that everything is working good before I make that commit and send it off to production or staging or whatever.
The important thing here is that in between the planning and the implementation, I am going to be resetting the context. This is one of the golden rules. Context is very precious.
And so I have a long and detailed conversation figuring out this feature we're going to implement. And then the structured plan that I create right here, I want it to be all of the context the coding agent needs to get the job done so that I can have a fresh conversation where the plan is the only thing I send in because it has.
all the documentation to reference. It has the entire task list. So we know what we have to do.
We know how to validate. So that way we can just cut things off and go into execution to keep things very focused, right? We want to not have a bunch of context bloating the conversation when we get into writing the actual code.
All right, so with that, let's now get into our first pivot loop. And this is gonna be a lot simpler than you would think because we really are going to reap the rewards from all of the planning that we did up. front we are on the same page with our coding agent we're confident understands what we want to build and so there's not even that much planning we're going to have to do for each of these faces at least at first and so going back here we have finished the prime we are on the same page of the coding agent and i just gave it a really simple prompt here like yeah phase one looks good just confirm to me exactly everything that we're going to build now usually for piv loops after the first one it's a bit more detailed like let's look at the code base and figure out how exactly we're going to build this but right here it's really simple so this looks good.
And now remember, commandify everything. I want to turn this conversation and this idea of phase one into a structure plan with a task list and validation. So I have another command for that.
It is just called create or plan feature slash plan feature. There we go. So I'll send this in.
And now the plan feature, just like the create PRD, it has this idea of a structure plan built in. So I'll show you this command as well. so a plan feature open this up so it accepts an optional argument where i can specify what i want to build in this case i was just using the conversation history so it already knew but we go through a phased process here so feature understanding diving into the code base which is again more applicable for future piv loops but it does a lot of research pulling relevant documentation making sure we have a rich set of context going into the execution and then what you're looking at here this is the template so we want to describe the problem statement, any context or reference.
We have our implementation plan. with the task list right here. And then, of course, we have our testing strategy.
We want to define the validation up front. And after we create this plan, of course, we're going to validate it. We're going to make sure that we're very specific.
The step -by -step, here's exactly how we want you to validate the application. And I am actually using the Vercel Agent Browser CLI skill, which I made a video on that I'll link to right here. So we're going to build in full browser automation.
The agent is going to spin up the backend and frontend, run the database migration, go through and like build its own link tree and basically just make sure everything is working exactly how a user would use the application. So pretty exciting.
But the validation is gonna be very detailed here so that by the time control is passed back to us, we can be very confident in the implementation. Still doing validation ourself, but it's gonna be a lot less work. Okay, and our plan is created now.
So let's go ahead and take a look. So I did a bit of validation off camera. I'll show you that in a little bit.
Usually you will... iterate a good amount because you want to make sure that it's understanding of phase one is aligned with what you have in the PRD, what you actually want to build, go through all of the sections, I encourage you to do so. So here's our implementation plan with the task list.
It's very detailed, which is good. We want to be specific now that we are very focused on a single feature. We have our validation with the whole validation pyramid, as I like to call it.
So type checking and linting and unit testing. And then we're very specific for the end to end testing all the user journeys you want the agent to go through. So we can be confident in implementation when it comes back to us and that's something it didn't really do that well at first and so i did have a follow -up prompt here just to give you a quick example of how we can iterate and refine the plan before we send it off to implementation and then one other little golden nugget i promise we'll get into implementation in a sec but this is really important generally coding agents aren't the best at working with environment variables they'll get tripped up If you don't have the environment variable set before implementation, it'll just do a bunch of mock testing and say everything's validated when it isn't actually.
It's really frustrating. And so usually what I like to do in parallel with the planning is I will create a .env .example. And I'll have it look here so it knows all the environment variables that I have set.
And then I will set up my environment variables as well. So obviously I won't show this file because it has my secrets for the database URL and things like that. But because I already have...
that set up, now we can rip through the entire implementation and then not just write the code, but it can run the database migration, start up the back end and front end, use the Vercel agent browser CLI to test everything, and it doesn't have to get interrupted for me to set my environment variables. And so I have the stage set up perfectly now going into implementation and I'm pretty happy with this plan.
So now remember context reset because context is precious. I am now in a brand new context window where I'll use my execute command and the one parameter is the plan that I'm pointing it to.
This is all it needs for its context now. And so what I'll do is I'll pause and come back once it's gone through the entire thing. And really, we are delegating all the coding to the agent now, reaping the rewards of all the effort we put into planning.
Every single PIV loop after this point is gonna be so fast now because of the work that we put into this. All right, our implementation is complete. We can see from the screenshots that it did full end -to -end testing.
So we can be pretty confident in the implementation because the agent already took care of everything right here, but it's still important for us to do the human. validation. So we can really make sure that we are trusting, but verifying.
And so the code review, that gets pretty in the weeds. So I'm not going to do this right now. But if you're more technical, it's definitely important that you do so.
But what I am going to do is test the application live with you. So the only thing I did off camera is I created an account already just to make sure that the basic authentication is working. But I haven't done anything here yet.
And take a look at this. This is so cool. It already looks really, really nice.
So I can set my display name, I can do a bio like cool AI builder. All right.
I can set my avatar URL. So I just uploaded a image to Imgur. So, okay.
That's looking really nice as well. I can add some links like, okay, I'll do YouTube and then that's HTTPS, uh, youtube .com slash at Cole Medin. All right.
Looking nice. Add another link. I'll do LinkedIn.
I don't have my LinkedIn URL right now. So I'll just do like linkedin .com. Don't really care.
All right, cool. And let me just add one more. I'll do X.
All right. So, uh, let's just do X .com. Very cool.
And I can drag. these around to reorder them it's automatically reflected here i can view just the editor and then adjust the preview the theme doesn't look the best right now like it's just white but i think that comes in a later phase anyway because right now we are just building the foundation so a lot of this isn't perfect yet but it's still looking extremely good for a starting point and then i can click save and um okay it has to load the api endpoints is running this localhost there we go changes saved successfully so i can do a refresh and everything is still going to be there all right that's amazing So this is looking really, really good.
Now, what I want to talk about, since we've gotten to a good foundation built, is the commit message. Just really quickly here. And so I have another command called slash commit.
And this one's really, really basic. You can make this more detailed if you want, but essentially you just want to provide instructions to the agent for how to create a git message because we are going to use that as our long -term memory. So going back to the diagram here, this is one of those golden rules.
Your commit history is your long -term memory. So if we are standardizing our message, and that's why we're using a command slash commit to make this reusable, then our agent, when it's going through the prime, it can look at the git log to see a history of what we built recently, which will guide what comes next and maybe patterns that we want it to follow.
And so that's the power of this commit message right here. So I'll do slash commit, which I could just run git commit myself. It's really, really easy, but this just makes it so it's always the...
same kind of message for consistency so in this case there's nothing to commit because i already ran this off camera as well but that is important to take care of after every single implementation now one other super important thing to cover after we have the foundation of our project laid out is we want to set up a framework for regression testing we want to make sure that as we go through future piv loops so we go through this process over and over again for all the features we want to build we need to make sure the old stuff doesn't break and so this i'm going to cover more in a different video all the strategies that i have for implementing this sort of testing harness yourself because essentially you go into the agent you say like okay what we have now is great but i could also go into aqua voice here and say I want you to list out all of the end -to -end testing that you did.
Put this into a command for me so I can run this later after I build other features so that we can make sure that everything that we built previously is still working. Something kind of like that. Again, I'm not going to get too in the weeds of this right now.
It takes a while to set this up and kind of create a test harness, but this is how you make sure that your application is stable as you're continuing to build on top of it. And it does take a lot of work to create and maintain this because you constantly... have to update it.
And so there are also solutions out there that take care of this for you. And they are very powerful. And one of these applications is QA tech, they have AI testing agents that evolve, they adapt with your code base.
So as you're adding more and more features, they add more and more test cases to make sure that everything your application is working well, as you're continuing to build it out. And so I'll show you an example of this really quickly. It's so easy to get started.
So you go into QA tech, they got a free tier for you to get started and try this out. I'll create a project here. And then you just have to paste in a URL that you want to test.
And so I took this application since I already made a commit and push it to GitHub. I deployed it in just like a minute to Vercel. So the easiest place to host your sites for free, especially when you build with Next .js.
And so I'm going to go to my project here and just paste in this URL. And so it'll take a little bit to create your project and analyze your code base. And what we can do is just say, I want a good test setup for my site.
Help me create the first three to five test cases. And this is kind of like, you know, bolt .new or lovable, or you can just give a prompt for whatever you want it to do to set up the test suite for your project. But this is what they recommend to get started.
So I'm going to go ahead and send this in. And it's so cool because it will dig through your website, like actually crawl through it, but you don't have to manage. the infrastructure at all.
So it analyzes your website and comes up with the test cases. And so I'll come back once it has done that. So mid execution, just want to show you really quick that it crawled my website in just a couple of minutes.
And then one of the really important things is we need a way to log into our website, we want the automation to be able to do that. And so they have a way for us to enter in our username and password, and they're going to store it in a secure way. So I just have a test account created here, I'm going to go ahead and save that.
And then it'll use that to get into the website, really dig in and understand all of the user journeys that we want to test here. And there we go, it has generated a bunch of test cases for us.
And we can even click into each one of these. And we can see the exact flow that it went through. And so now we have all these tests that are set up.
And the AI testing agents in QA tech are going to evolve these test cases over time to make sure it continues to cover everything in our code base. As we build more and more features. It is super, super cool.
And again, we can build our own kind of command system to do something like this. But I really appreciate having a platform that just takes care of all this for me.
And there's agents under the hood that I can chat with, to even just like work with the testing here and make sure that I am truly regression testing everything. And so then whenever there's anything that breaks, I can come in here and say like, hey, there's a bug with the application right now, create a test that should be failing, let me address the problem, and then the test should be passing.
And so that takes us to the last golden rule that I have here, the system evolution mindset. So whenever we encounter a bug in our code base, it is important to not just address the bug, but think about what we can fix in our AI layer so that it doesn't happen again. Like maybe we need to be more specific about our style guide and our rules or create a new on -demand context for that.
Maybe we need to have more end -to -end testing that's laid out in our commands, our workflows, whatever it takes to make sure that we don't encounter this issue again. And then we can also do what I just showed in QA tech or our own command system, where we add a test to make sure that we don't encounter that issue again in the code base.
And so the power of this, even though it takes time to do it, is that we make our coding agent more reliable and repeatable over time, evolving it along with our code base. And so we're doing three things in parallel. As we're building out our code base, we are evolving our test base, our code base, and our AI layer.
And man, does that compound over time. And so going back to Cloud Code here, I'll just give you a really simple example of this. So one thing that I did do to iterate once off camera is I worked on the style for the site.
Because if you go back to the start of the video, you'll see that I kind of forgot to talk about the style, exactly how I wanted the site to look. So Cloud Code just kind of made its own assumptions there. And it didn't look the best.
And so I had to iterate on that. And so one thing that I can do here is... You know, at first I didn't like the style that you implemented for the front end.
We definitely don't have enough in the AI layer with our rules and on -demand context for a style guideline. So I want you to do some meta reasoning here. Don't change anything, but help me think about right now, what could we change with our rules or on -demand context, something we could add or update so that we have more consistent styles that we're going to be building as we continue to, you know, build up the analytics and other things, other pages in this application.
And so the important thing I'm doing here is telling it to not change anything yet, because usually I want to have a lot more control over changing the AI layer versus for the code base. I just want to delegate as much of that to the agent as possible. So I have it reasoned with me, but I usually like to make these small and very focused changes myself.
And you can see here that it recommends creating a style .md in the reference folder. So a third piece of on -demand context for us. And so this, I guess, would go along with the components .md.
That's more like, here's how we should layout things. the styles .md is here's how it works here's how we should work with tailwind css and probably shad cn for example so i'm not going to go through the full implementation of this and correcting everything but just trying to give you a good example here of how when we encounter anything where we have bugs in the code or just isn't quite aligned with us like we have right here it's always an opportunity for us to evolve the ai layer so we're more and more in tune with our coding agent for this specific project as we continue to build it out and that my friend is the most high leverage part of the entire your process, really saving the best for the end.
So that is everything. It really is a dead simple process for getting reliable and repeatable results with your coding agents when you are starting new projects. Because now after the system evolution, we just take it back up to the top and we go through more pibloops, going through the exact same process to build out all the phases in our PRD, add any other features, whatever it takes to get to that minimum viable product.
And then that'll take us into brownfield development with one of the next videos that I'll put out on my channel. And so if this all sounds good to you and you want to dive even deeper with my full resource library of commands and rules, you want to see what system evolution really looks like and get deep into that, definitely check out the agentic coding course that I have in the Dynamis community.
I'll have a link to this in the description and the pinned comment. And so that's everything that I got for you right now. So if you appreciated this video, you're looking forward to more things on agentic coding, that brownfield development video, I'd really appreciate a like and a subscribe.
And with that, I will see you in the next video.
The Hook
The bait, then the rug-pull.
The title promises a complete workflow with no overengineering, and the opening line sets up the gap: everyone agrees you need a framework for coding agents, few have one that is simple and their own. What follows is a live build of a link-in-bio app that shows each step instead of describing it.
Frameworks
Named ideas worth stealing.
23:21model
The PIV Loop
Plan: vibe planning, then a structured plan
Implement: delegate all coding to the agent from the plan alone
Validate: agent runs unit, integration and end-to-end tests; human does code review and manual testing
Each phase of the PRD runs through one loop. The human owns planning and validation, the agent owns the code in between.
Steal forany repeatable build process where a tool or contractor does the middle step
01:59list
The Four Golden Rules
Context reset: context is your most precious resource
Commandify everything
Git log as long-term memory
System evolution mindset
Principles that run through the whole workflow rather than living in one step.
Steal fora short operating-principles section in any team or agent playbook
02:37model
The AI Layer
PRD: what to build
Global rules: how to build it
Commands: reusable workflows
Subagents: delegated research
Every asset in the codebase written as context for the agent, started from a generic kit and made project-specific over time.
Steal forauditing any agent setup for what context it is missing
25:05list
Structured plan sections
Goal(s)
Success criteria
Documentation to reference
Task list
Validation strategy
Desired codebase structure
What a per-feature plan should contain so it can be the only context the executing agent needs.
Steal fora reusable template for briefing any agent or contractor on a task
07:49concept
The cost of bad lines
1 bad line of code = 1 bad line
1 bad line of plan = ~100 bad lines
1 bad line of PRD = ~1,000 bad lines
Errors multiply the higher up the planning stack they sit, which is why the PRD gets the most scrutiny.
Steal forexplaining why up-front planning pays off
29:20list
Validation pyramid
Type checking and linting
Unit tests
Integration tests
End-to-end user journeys via browser automation
Layered checks the agent runs on its own work before handing control back to the human.
Steal fordefining done for any agent task
CTA Breakdown
How they asked for the click.
VERBAL ASK
41:40product
“Definitely check out the agentic coding course that I have in the Dynamis community. I'll have a link to this in the description and the pinned comment.”
A soft close after the payoff: the free workflow is complete, and the course is framed as the deeper resource library and a fuller look at system evolution. A mid-video sponsor read for QA Tech is woven into the regression testing lesson rather than bolted on, then a like and subscribe ask that teases the brownfield follow-up.
Add Modern Creator as a preferred source and Google shows you more of our breakdowns in Search, Top Stories, and AI Overviews. It only changes what you see, and you can undo it in your Google settings anytime.
Add to Preferred SourcesOpens your Google source preferences with us pre-loaded. Tick the box and you're done.
A lightweight alternative to built-in computer-use tools: one markdown skill and a handful of Python scripts that let a coding agent click, type, and screenshot its way through any desktop task.
A software engineer who hasn't handwritten a line of code in over a year opens up the actual skill library and two-loop system that runs his AI-assisted development process end to end.
Boris Cherny told a Y Combinator crowd to delete your AI layer every six months. Cole Medin ran the actual benchmark to find out which parts of that advice hold up and which don't.
A 25-minute honest breakdown of loop engineering — what the AI coding elite actually mean by it, why it gets expensive fast, and how to build a harness that makes it reliable.
00:47
01:19
02:54
03:58
05:29
06:05
06:37
07:09
07:40
08:12
08:44
10:19
10:51
11:23
11:55
12:27
12:58
13:30
14:02
14:34
15:05
15:37
16:41
17:13
17:44
18:16
18:48
19:20
19:52
20:23
21:27
21:59
22:30
23:02
23:34
24:06
24:38
25:41
26:45
27:17
27:48
28:20
28:52
29:24
30:27
30:59
31:31
32:03
32:39
33:21
33:55
34:42
35:13
35:45
36:37
37:21
37:52
38:24
39:59
40:31
41:03
41:35
13:01
23:07
23:00
Video of the Day20:00
21:55
24:39