💻Video + Code Examples·11 mins
Implementation Workflows with Agents and Skills
Design implementation workflows using custom agents for role separation, skills for reusable patterns, and TDD handoffs for disciplined execution — all governed by least-privilege tool boundaries.
Transcript16 entries
Instructor:Planning is clean because nothing has touched the code yet. Implementation is where the heroism can become the bugs, unless you separate the roles. Keep the slice small, and force it through a proper validation gate. Lesson four, that gives us a plan. Lesson five turns that plan into a focused implementation. Also, we will see why generation alone is not enough. The reusable idea here is role separation, not the agent syntax. The tester owns the tests, the implementer owns the production code, and the reviewer owns the validation. Tool boundaries make those lanes enforceable. Every agent should have minimum tools it needs, not more. The planner has no access to write. The implementer can edit but can't run the tests. The tester can run tests but shouldn't touch the production code. And the reviewer can't modify any files at all. This is a useful demo, and you can actually go to the GitHub repo.
Instructor:The link is available in the description below. For a local try, start this action from a lesson folder. Run the scripted demo and then immediately run the validation utility. And let us see what we provisioned. Let's go now. This is the VS Code instance here, and see how it works. So I'm in my VS Code instance and I managed to run it before. as well, so I'm gonna clear here and I'm gonna run this script again. This time we'll be running GPT-5.4 because I don't think it is capable of Claude Haiku 4.5. GPT-5.4 it is, so we'll be running on GPT-5.4. My bad, pardon, I mispronounced earlier. Anyways, so here's what will happen. This is the application which is currently not running, but this is the current snapshot.
Instructor:And this is the product spec that we have copied from Lesson Four. It will implement the complete product spec into the code we have copied already from the standard app test setup. So it's basically here, app, and this is where we always copy. So we always start with the state that we want to actually validate. So we do not mess up in the previous states. The expected files are generally the rule file and test file because you are following TDD. And you can see here in the context we have agents, planner, ah sorry, this is the planner. We have implementer, reviewer, and tester. We have a prompt, implement feature, that we are using, and review changes. And then we have a skill as well to follow the TDD.
Instructor:That's a good enough context for this particular use case. And then we have the documentation, the same documentation. We have architecture, implementation playbook, implementation workflow example, how we should implement. This is very important. Using a playbook, we actually provide good hard negatives and false positives as examples. So making sure that anti-patterns such as this can never happen. It's very essential to declare the anti-patterns that we want to avoid clearly in any context file and make sure that is discoverable. Also the non-functional requirements are very important. With every spec, ensure you attach the correct non-functional requirements and the hard negatives that you can provide there as well. Now while this is running,
Instructor:I will go to the run and see that we just have it run. By the way I have managed to run it before on Haiku 4.5 and it did work pretty much well. It all passed, but with Haiku I was not able to get the tests successfully run. With GPT-5.4 it actually worked perfectly. It was anyways the high cost on self-sufficiency when it comes to this code implementation. So basically, we will look for everything. Now, the reason why I'm showing you is because when it fails, my unit tests can also make sure that this code change is valid. So every code guard you have seen passed, but you imagine that, how did that come to pass? Here in that unit script, it generates automatically whenever we run this. It generates and makes sure it validates against every potential dimension that I want to check.
Instructor:And these are deterministic dimensions. That means they do not work on a probabilistic view, whether it should pass or it should not pass. It will define if it does pass or it doesn't pass. That's it. It has no further ambiguity on those contextualizations and everything works well, or it fails with a direct human-state input that was not something it managed to get through. Also, neither implementation was behind the wrong gate. And this is why I'm showing you that every AI coding request or every ask-code request must be not just backed up by simple unit tests or integration tests. But you also would need a session test. That means whatever the session has done, has the session followed the correct path and the right outcomes. And this is what we validate using not just code implementation but also the reasoning and thinking process
Instructor:that has been generated. So if we find something in process that is not up to the mark, then we also sometimes pick it up and maybe make the session fail and understand why it went wrong because right-by-the-flow is worse than wrong-by-the- wrong-by-the-deterministic output. Right-by-the-flow is something that we can manage once, but in future when we want to have an incremental update on that application, the right-by-the-flow will definitely go the wrong-by-the- persistent. So that means there are three different gated possibilities that we have to validate. First, of course, the unit test that actually runs, that is actually generated by the AI itself. In any test folder here, we will see the test folder. It has, I think, already created the unit tests that we look for.
Instructor:Then there is also the utility which runs certain utility commands that I have created. You can always look for this utility here, how I created it. You can recreate it for yourself as well. It's not very difficult. But more importantly, there are deterministic tests. So these tests are not part of this session itself, but these tests were generated beforehand for the session in anticipation of what we are expecting in terms of functionality. So there are deterministic tests in anticipation of what we should get. And these tests should pass. Without passing these tests, the session will not be successful. That means by passing these tests, it validates that whatever it anticipated as expected has been passed. Because bear in mind, when generation works,
Instructor:the code is generated and then subsequent unit tests or integration tests are generated. If the LLM somehow makes a mistake during the code generation, most probably the same mistake will be carried over with the unit test. So the parity between the implementation and the unit test will always be a false positive or false negative in case one of those goes wrong, and that's very important as well. Also I have noticed if unit tests fail on the first time, then generally the session will go and update unit tests in a manner that it should pass. So anticipation tests are very important here. That you anticipate beforehand and your LLM does not have access to, which will tell you whether your implementation is accurate or not. And this is a really big concern with many implementations,
Instructor:where implementation and the test parity is driven by the same session. So make sure you break the session. Now here the demo is completed and if we see the changed files, then we get exactly the result we wanted. If we see the demo page, it did perfectly what we expected of it. And now let's see if we can run this particular. Just Python util.py --test, and I will show you. It's, I don't know why it's going through. And I will run the test. First, it is installing the dependencies because the npm or the Node.js components are not installed. So we will install it first. We have just created, validated, and it will run all the AI-generated code. And then, once the AI-generated code successfully passes,
Instructor:this is immediate, we also go and run the anticipated code that we see. So all the AI-generated code has passed, and this is the code that we anticipated, we expected them to generate by AI. And these are the Python code which I mentioned using Playwright. So it actually runs this. It runs the application inside and validates, and goes through the UI integration tests, and they all pass. So basically, the anticipation of the UI changes and the functionality has also passed outside of the session scope. And this is what I want to show you: multiple validation gates. Without these multiple validation gates, it is very difficult to assess whether AI has successfully managed it end to end. So let's go back and try to run the application and let's see whether we get the application up
Instructor:and running. I don't think so. I have run the application before, even before this session. But let's see. So npm run dev. It's running on a 5173 port and if we refresh it, then it should. Yeah, I think it's already been refreshed. So we see here the manual escalation and also stuff has been updated. Ah, and boom, perfect. The work queue is good. So we got all this element and the API is there. We validated as well in this session portion. So let's see if we can manage one of the applications. That app state, it's in decision mode finalized now. It's been finalized. We can see here the notification handler actually managed pretty perfectly, and if we see the queue, yes, we got this latest here: notification requested.
Instructor:Because of the California law, so I think everything perfectly worked here. Ah, as we anticipated. Ah, these are the same test cases which actually ran by our Playwright. And also the unit tests that were previously run by the same utility. But unit tests, generated unit tests and integration tests, generated by AI itself, and these are not generated by the same AI session. They are generated outside of the session in anticipation. So beforehand. So this is what we have, and if we see anything that we need to validate here. Let me just double-check if we have assessment updated. I don't think so. We got assessment updated. I need to run something else once I'll get the assessment updated as well and the run tool updated as well to see what it
Instructor:can. Um, but what it means there, you can absolutely work through exactly whatever you like to and make sure that. Ah, you follow the same, um, ah, same step-by-step guide and it will it will give you access to everything that. Ah, you basically are looking for. Um, so let's go back on our presentation. Welcome back to the presentation. The prompt does not sprawl into the whole notification system. It adds one rule file, one test file, and one route change. This is the right size implementation for the workflow lesson. The generated change clears the lesson harness. Files match. Patterns match. The current checked-in workspace then passes the real gate.
Instructor:The validator confirms the escalation guard, the LEGAL-218 California restriction, and the allowed false-positive case where escalation SMS is off but email stays on. The useful lesson is not just that the diff looks tidy. It is that the run stays small, the handoff stays readable, and the validation gate agrees with the implementation. That's the workflow worth reusing. The main point is pretty simple. Keep the slice small, keep the roles clear, and keep the workflow readable. That's what makes your implementation easy to review and repeat. Next up in lesson six, we cover the tools and guardrails. That wraps up lesson five, implementation workflows. Here is my question for you: Share a prompt file that saved you real time on a recurring implementation task.
Instructor:What did you automate and how did it change your workflow? Drop your answer in the comments and we'll select the best one to join our upcoming live session. Subscribe and turn on notifications so the next lesson, when it drops, reaches you the moment it drops. Thanks for watching and I'll see you in lesson six.
Learning Objectives4
- Explain how custom agents and skills support role-specialized implementation work
- Apply least-privilege principles to implementation and review workflows
- Describe how TDD handoffs improve reliability in AI-assisted coding
- Design an implementation workflow that separates planning, coding, and review concerns
Q&A
Q & A
Q
Why are skills useful if I already have agents?
Agents define roles. Skills define reusable capabilities or workflows that those roles can invoke when needed. They solve different problems.
Q
What is the practical benefit of a reviewer agent with no write tools?
It must report findings instead of silently changing code, which makes review explicit, auditable, and easier for the developer to reason about.
Q
What does TDD handoff improve?
It preserves discipline. A test-focused role writes the failing test first, and the implementer focuses on the smallest change that satisfies it.