Enjoying this issue?
Get tomorrow's AI & engineering digest in your inbox — hand-picked, summarized, and always spam-free.
TLDR
Cole Medin presents a systematic approach to making your entire software development lifecycle AI-native, moving beyond 'vibe coding' to a structured process using an AI layer of rules, skills, and MCP servers. The key insight: most engineers think they're faster with AI but are actually slower because they lack a system. The solution is a repeatable PIV loop (Plan, Implement, Validate) with human gates, all checked into source control so every team member works the same way.
Key points
- The productivity mirage: engineers feel 20% faster with AI but are actually 19% slower because they waste time fixing AI mistakes without a proper system.
- The AI layer consists of global rules, skills (reusable prompts), MCP servers (connecting to Jira/Confluence), sub-agents, hooks, and LSP — all checked into source control alongside code and tests.
- The PIV loop (Research, Plan, Implement, Validate) replaces vibe coding: spend time upfront planning with the agent to reduce assumptions, then hand off a structured plan to a fresh agent for execution.
- Skills standardize workflows across the team — every engineer uses the same process for creating tickets, planning features, implementing, and validating, making results predictable and reviewable.
- MCP servers let coding agents directly interact with platforms like Jira and Confluence, so they can fetch PRDs, create tickets, post comments, and update status without manual copy-paste.
- System evolution: when an agent makes a mistake, don't just fix it — update the AI layer (rules or skills) so the same error doesn't happen again, and treat those updates as pull requests.
- Automated code reviews with coding agents in CI (e.g., GitHub Actions) give reviewers a starting point, cutting review time by 2-3x without replacing human judgment.
- The approach is tool-agnostic: while Claude Code is used for the demo, the same principles apply to Cursor, Codex, GitHub Copilot, etc.
Tools mentioned
Techniques
- AI layer construction (rules, skills, MCP, sub-agents, hooks, LSP)
- PIV loop (Research, Plan, Implement, Validate)
- Skill-based workflow standardization
- MCP integration for platform connectivity
- System evolution (improving AI layer from mistakes)
- Human-in-the-loop gates for planning and validation
- Speech-to-text for faster agent interaction
Stop scrolling. Start reading smarter.
Receive the day's most important AI & engineering updates in one concise email. No spam.
Transcript (captions)
A couple of weeks ago, I hosted the AI Native Engineering Org Workshop, teaching you how to make your entire software development life cycle AI-centric, and how to adopt a team
standard for using coding agents so everyone's on the same page. And so, if you run an engineering org or team, and you want to boost everyone's productivity with AI, or you just want
to see how coding agents can scale to an enterprise level, this is it. And I wanted to post this recording to my YouTube channel because I haven't done a session this value packed in a long
time. And so, without further ado, over to the workshop. Welcome everyone to the AI Native Engineering Org Workshop. This is a 2-hour value packed session. Going to have a ton of time for questions, as
well. And so, I also want to make this super interactive, but my goal here is to share with you guys how you can go from a traditional software development life cycle in your organization to one
that is fully AI Native. Now, 2 hours is surprisingly a not a lot of time. And so, I'm not going to get to go extremely deep into every little part of the SDLC here, but I am going deep enough to give
you the entire process. And so, you have the starting point to bring your organization into something more AI Native for everything in your SDLC. We're going to be hitting on things for
your PMs, developers, and QA, as well. So, really everything from ideation all the way to deployments and validation in production. And so, let me go over to the diagram
here. We got a couple of nifty diagrams that we'll be using for today, as well as a primary template that I have that I'll talk about in a little bit. And so, I'll I'll start with just a a
little bit of an introduction here. I know that most of you are probably familiar with what I do, uh, but also I think it'll it'll lead in really nicely to what we're going to be talking about
today. So, if you guys didn't know, I have been a software engineer my entire life. Literally since I was 8 years old. If you guys know the programming language Scratch, that was
developed by MIT. It's a It's kind of a language more for kids, if you can even really call it a programming language, but that was the beginning of me programming. Just building video games
as a kid. And so, I took that through, you know, middle school, high school, all the way through college, got my bachelor's in computer science. Yeah, I've loved engineering, building
software my entire life. And I've always kind of been a jack-of-all-trades. So, a web developer, systems admin, cloud engineer. Uh you'll have to excuse
me cuz I have a bit of a cold right now, so that's why I'm coughing once in a while. You know, but I want to power through this for you guys here. Uh but yeah, anyway, I've been a
jack-of-all-trades for a long time. And I always knew that I wanted to specialize in something for my career. And so, when generative AI really became a big thing, especially in 2023, I knew
like very quickly, this is what I want to go all in on. And so, I did. I started building out AI agents for my friend's startups. And back at then, I worked for a wealth advisory company
called Ameriprise Financial. So, it's a Fortune 200 company here in the US. I was a cloud engineer there, but I dove headfirst into stretch assignments for building out their initial generative AI
POCs. Like AI was my life. It was my hobby, and it was my work. And so, I was investing so much time into this. And that's what eventually led me to actually quit my full-time job and start
my YouTube channel. So, I started my YouTube channel like just as a hobby back in July of 2024. And it only took 3 months for it to replace my engineering income. So, I left my job then to do
everything I'm doing now with my YouTube channel, my consulting, and the Dynamis community where I have all of the workshops and courses that I'm doing on a weekly basis. And I'm living the
dream. Like this is what I've always wanted to do cuz I've always been an educator at heart. I love teaching people. And that's actually a bigger shift I've done even more recently. Like
when I first started my YouTube channel, a lot of like the revenue for my business was through contract work that I did. So, I you know, I had like a sort of like AI automation agency kind of
where I was building agents for companies, right? Like I'm still a lot of the builder. But now what I've been doing more recently, and this is what really leads into what we're talking
about today, is I I've shifted from like done for you, I'm building the agents to now the training. So, I'm training up a lot of organizations on how to build agents and leverage AI coding assistance
effectively. So, I'm teaching them how to fish instead of catching the fish. You know what I mean? Like I'm teaching them here's how you take your software development life cycle and make it AI
native. And so, really bringing that into what we're doing today, I'm bringing all of the lessons as I've helped dozens of organizations go through this process,
and I'm packaging it up into all of the takeaways and the full process for you guys today. And obviously, I can't get into your SDLC. What we're
covering might be a little bit more generic and high-level, but obviously that's what I need to show without being, you know, at your company doing the training for your engineers. Of
course, that's something that I offer, and I'll talk about that at the end of this workshop as well. Uh but right now I'm going to cover an SDLC that is, you know, pretty
commonplace, and we're going to take it and make it fully AI native in the 2 hours that we have today. That is the promise for you guys. And everything that I'm going to cover
today is based on a template, not a framework. And what I mean by that is there are a lot of systems out there. Maybe you've seen these open source systems on GitHub
like Claude flow or GitHub spec kit or B and those frameworks are great, but they're very opinionated. I've heard of so many organizations that really struggle to bring those frameworks into
their SDLC because it requires changing their entire process, which just because you want to go AI native does not mean that is actually realistic. And so what I'm more of a fan of is bringing AI into
the way you already work, right? Like augmenting your current SDLC instead of totally scrapping the playbook and implementing things from scratch. In fact, a lot of organization
or a lot of organizations that I work with, they've actually tried implementing one of those bloated opinionated frameworks at first and then they come to me cuz they're like, you
know, I like your minimalistic and systematic approach. Let's start from there. I want you to train my engineers. And that's a lot of you know, when I first come into a company.
And so really what we cover here uh hopefully in some ways is actually going to feel like pretty simple, right? Like I'm not trying to blow your socks off with how much we're changing the way we
build software. Uh I mean really the biggest change is we're going to try delegating as much of the coding to the agent as much as we possibly can. But the full workflow from PM to developer
to QA, it's still going to have a very, very familiar shape. And I'm doing that on purpose. And so we'll get into this in a little bit. I just want to read the chat here
cuz I see a couple of things. Um Sean asked, no more microphone. Um so yeah, let me know guys if uh you're not able to hear me.
I'll I'll type in the chat here. Uh cuz the microphone's working on my end. Let's see. Okay, you guys able to hear me now?
Looks like my uh video was cut short. Can you see Can you guys see me as well? I just want to make sure we're good before I I dive right in. Um okay.
And Pat said, "Can we expand?" Yeah, don't worry, Pat. I'll be zooming in here uh once we get into things. Yeah. Okay, sound fine. Okay, good. Thanks, guys. Just wanted to confirm that cuz
that would suck if I went through, you know, half hour you guys can't hear me and then finally I look over to the chat. So, okay, good. All right, sounds good.
I am tiny. Uh yeah, I mean that I don't think I can really control that cuz I want the screen to be the focus anyway, so I think I think we are set.
And um yeah, one more thing I want to say before we get into this here is uh feel free to put any questions that you guys want in the chat. And specifically, if you put a question in
the chat and I want to answer it, what I can do is I can highlight the current comment. It's a really cool feature in the platform that we're using here. Uh like I can spotlight what Simon said
here. So, yes, we can see but you are tiny. Like I said, I think that's kind of just what it's going to be in the platform here cuz I want my screen to be the
focus anyway, but yeah, so when you guys ask questions, there's going to be good time for me to answer your questions because we're going to be waiting for the AI coding assistant to do things as
I'm demonstrating the full AI SDLC live. And so, don't shy away from questions. Hopefully, different parts of what I show you today will just spark questions that you have. Like, "Oh, this is cool,
Cole. How do I apply this to my SDLC?" Or we do a little bit We do things a little bit differently, so like how would you think about applying AI to this? Like, those are the kind of
questions that I'd love to get into here. The sponsor of today's video is Bluehost, one of the best cloud and VPS hosting solutions for your agents and applications. Anything you need running
around the clock without relying on having your computer on. One of their coolest features is their app marketplace. When you spin up a server like I'm doing right here, they have an
application tab where we can select different software to be pre-installed with our instance. Like for a second brain, open claw or Hermes, they have claw code, beam ad for AI coding, laying
flow, o llama, they have an awesome list of software here. So when you select it at checkout, it automatically comes with your instance once it's booted up. They also recently rebuilt their entire
infrastructure. They have nine global data centers now. Response times are four to five times faster and a 99.99% uptime SLA. You get full root on KVM isolated hardware, AMD EPYC, DDR5 and
NVMe. It's a real machine that you control, not just a sandbox. And pricing is flat. Plans start at $4.69 a month and your bandwidth is unmetered. So if you have a busy week for your app or
agent, you don't have a surprise bill. It's a fantastic platform to host anything. I'll have a link to them in the description. So, the first thing I want to talk about is and and this is
where I'll zoom in, so hopefully it's pretty easy for you guys to to see things here. There are a lot of organizations that are trying to adopt AI coding assistants
already, but really not doing a good job at it. And this is what I want to help you avoid. Did you know, there's there are a few
studies that have been done over the past couple of years that show that on average, software engineers, they feel like they are 20% faster when they use AI coding assistants, but they're
actually 19% slower. You've probably heard those statistics before. It's cited all the time on YouTube and LinkedIn. It's kind of crazy. It's like people think they're
faster because AI is writing some or all of the code, but it's actually slower because they're fixing a lot of mistakes and they're dealing with slop. It's a very common word in the industry where
AI coding assistant is spitting out things that's just straight-up broken code. And um yeah, it's it's unfortunate because we have This is what's called
the productivity mirage. You think you're better, but you're actually slower. And another statistic that's kind of unfortunate is um 84% of engineers throughout the world are
already using AI to help them code in some way. But out of that 84% only 46% actually trust AI coding assistants. So, we have this really weird disconnect
here where almost everyone is using AI to help them code, but only half of people, actually less than half, actually trust the coding agent. And so, the big question we have here is why is
that the case? How come everyone's using a tool that people don't actually trust? And what's the solution here? Well, let me let me show you what a lot of engineers are doing with AI right
now. And trust me, I've seen this at organizations, even larger ones, when I first come in to help them out, this is how people are currently using the tool. And so, first of all, you have your
input for the engineer. Usually this is something that comes from your product manager, like you have the epic as a document in Confluence, right? Like you have that PRD. This is
our input. And then the product manager is going to by hand split everything out into tickets. So, you're creating those tickets in Jira or Linear or whatever. You're assigning the story points. You
have your meetings to establish that and get the technical details from the developer. If you guys have been in an organization, you've seen this kind of process. You've been a part of this kind
of process. And then what happens is the developer, they are going to take one of those tickets and they're going to just do some kind of really basic prompt to the
coding agent, like, "Hey, here's the description from the ticket. Go and build this now." Which for some of you who have, you know, gone through the agent of coding course in Dynamis, that
might sound kind of silly to you where they're they really have no process, no system at all. But, you'd be surprised how often I have seen this where they don't even think about like, "What's my
workflow? What are the rules or the conventions I want to give my agent?" They just dive right into development. And that's what leads to so many developers not trusting AI. Because, of
course, if you're not giving good guardrails and guidelines for your agent, you're going to get a mess that comes back. And the productivity mirage is caused by
the fact that you might write the code quickly at first, but then once you get into, you know, reviewing the code from the agent, you find a bunch of mistakes and you actually waste more time fixing
the AI's mistakes than you saved from not having to write the code. Let me repeat that again. When you don't have a system like we'll talk about today, you waste more time fixing the AI's
mistakes than you save from it writing the code. And so, obviously, the engineer will realize that over time and the productivity mirage becomes
apparent to them and they're like, "Okay, I don't even trust coding agents anymore." This is what unfortunately happens all of the time. They lose that trust
because they never gave the coding agent a fair shot. They don't have a system for AI coding. And really, the rest of what we're going to be talking about today is building that system. Like,
when I show you how to make an SDLC AI native, we're going to be talking about the system. So, I'll make that really concrete for you. I know that term, you know, the AI coding system might feel a
bit vague right now, but, you know, we're going to fill in the blanks as we go here. And so, I'll I'll show you what this looks like. So, like I promised when I
was uh you know, first presenting this workshop to you guys, I said that we were going to work on a real brownfield code base that is not AI native at all,
and we're going to make it AI native. And so, I'll go over to my browser now, and I will show you guys what we have. And so, uh so, this application, it's not like something actually deployed to
production, but I created a simplified version of an application that I've helped build out in the past. And so, it is a a real brownfield code base in the sense that it is like it's it's derived
from something real. I'm not just creating some like stupid silly demo for you guys. And so, this is an application to help with scheduling meetings. Kind of application probably all of you guys
use where you can create meetings and and sort of like manage your calendar here, people that are booking with you. This is the brownfield code base that we're going to be working on here.
And so, I have this as a GitHub repository because you can imagine you have an entire team of engineers working in a GitHub repo, obviously very, very common.
And then, we are managing all of the tasks for our our epics and sprints here within Jira, and then we are using Confluence for our documentation. Right, so I'm just kind of setting the
stage here for what we're going to be working in. So, this code base right now has nothing with AI. There is no global rules, there's no skills, there's no hooks, all the
different things we'll talk about in a little bit. I'll show you I actually have the repo up right here. There is nothing for AI at this point. So, you can imagine this is a brownfield code
base that your organization has been working on for maybe even years, and you're trying to apply AI to it for the very first time. That's the context for what we have
here. And so to start, we have a PRD for our Q3 initiative. And so you can imagine that at this point a product manager has created this document. Now, obviously
it's over simplified right here just for the sake of demonstration, but a product manager, they you know, had some meetings with the stakeholders or leadership in the company, whatever, and
they've established like these are the things these are our goals for this quarter, and these are the things that we're not doing. And obviously you could expand this to
be like a full PRD. And so this is our input into the work that we're going to be doing. And so if you don't have an AI native process, what this is going to look like is you're going to create the
tickets by hand, right? So like this is our epic in Jira, these are the individual tickets that we have split out that we're going to hand to our developers, right? Like this right here
is a ticket to a add a CSV export to the meetings page that we have right here within the scheduler website. So this is our platform, that's the work that we're going to do here.
Um and so if I go back, what a developer would do if they are not AI native, they're just trying to adopt AI coding assistants for the first time, is they're going to take the description of
the Jira ticket, maybe you have something like a tech spec like this. Obviously it depends on the uh the way that your organization works, but you're going to have some kind of context that
the PM created maybe in like a sprint meeting with the developers. This is what you're going to send into your coding agent, right? So a developer, and this is the the naive way of doing
things, the developer is literally just going to copy all of this. They're going to jump into their coding agent, right? So this is the scheduler repo that has nothing for the AI layer
right now. So I'm going to let me actually close the I have a conversation going for when I was prepping for this here. So I'm going to open up a brand new conversation with Claude code.
And you paste in the context, right? So, I I have the full uh summary pasted in here. And the developer is just going to go here and say, you know, implement this
ticket, right? That's it. This is not the way you want to do it, but this is what so many people do. When they're just trying to get started, they don't know how to really work with
coding agents effectively and actually connect them to their platforms like Jira and Confluence. And so, this implementation is what I would call vibe coding.
Right? And even even experienced engineers fall into this trap of just getting lazy and sending in the request without thinking about how they're going to plan with the agent and build up a
validation harness and strategy, how they're going to connect it to their platform like Jira, so maybe you could actually add a comment after the pull request is made. Like they're not
thinking about any of this. And so, this request right here, it might get the job done. Maybe. Especially for a simpler ticket, it could work. But the point here, and I'm
I'm going to escape here. I don't need to like go through the full build right now. The point here is that the coding agent might do a fine job, but it's not going to follow your conventions.
There's not going nothing documented for it. It's not connected to your platforms, so it has no way to, you know, add a comment to the uh Jira ticket after. Right? Like it's going to
be a very disconnected part of your process. That's why we're not AI native here at all. Like sure, we're using our AI coding assistant within the SDLC because the developer is using it to
build, but they're not really ingraining it into how your engineers already work. Like your coding agent should be an extension of your developer. And right now, it just feels more like a one-off
tool where we're trying to just have have write some code. But coding agents are so much more than this. And so, that's what really gets into the system that we're going to build here. Like,
we're going to talk about how we can use rules to teach our coding agent how to work as we do. We're going to cover skills, which are the uh prompts, like the workflows that we guide our coding
agent through. Which is also important to make this repeatable between people on our team. We'll talk about MCP servers, so we can connect Claude code directly to our Jira and Confluence. And
so, we can rely on it to post comments. We can not have to just dump in the context, but actually point it straight to the ticket. Like, just giving you a high-level overview of the kinds of
things that we're going to look at here to make it more AI-native. And talk about how we can help the PMs, developers, and QA become more AI-native with this process.
And so, going back to the diagram here, this is what we don't want in what I just covered. Now, what we do want, the AI-native SDLC, it still starts with the same input. Right? You have that epic
that is defined by the PM. You have that PRD that is the starting point of your workflow. And by the way, PMs can even use AI coding assistants to help them build their PRDs. That's
outside of the scope for what we'll be covering here, but you can use AI coding assistants from the very, very beginning when you have that initial meeting with your stakeholders. And maybe you
literally feed that transcript into your coding agent and ask it to help you plan out the initial PRD. Like, you can start ground zero with your coding agent. And uh by the way, another thing that I
wanted to mention, actually Shawn just asked this. This is fantastic timing for your question, Shawn. Uh yes, everything here is model and tool agnostic. So, it doesn't matter if you're using Claude
code, GitHub Copilot, Codex, everything we talk about here is going to work, no matter the tool that you are using. So, obviously I have to pick one for the demo here, which is why I'm using Claude
Code. It is genuinely the one that I use every day, but there are a lot of fantastic tools, and generally you're going to already have some kind of agreement in your organization with a
you know, a place like Anthropic, and so you're going to be limited to the tool that you can use. Right? Like most organizations that I work with, well, actually frankly most have an
enterprise agreement with Anthropic. 90% 90% of organizations that are using AI coding assistants have an enterprise agreement with Anthropic. Claude Code is the most popular tool by
far. It is the one I would recommend, but I would say that other tools like Codex are not far behind. Right? You can't really go wrong with a lot of the popular tools. I've worked with a lot of
companies using Cursor as well. So, yeah, there are a lot of great options out there. But anyway, the point is you start with the same input. But now instead of the
PM creating all the tickets by hand, you can use a coding agent to help you do that. Right? So, you create each one of the tickets, have the coding agent help you format those and put those in Jira,
and then the developer is going to pick one to work on. And we're going to build the coding agent directly into our platform, so it can reach out directly to Jira to pull
the information, maybe read the PRD in Confluence as well. After we pull the context from Jira, we're going to walk our coding agent through a process of planning,
implementing, and validating. And that is the most important three-step process that a developer can do with a coding agent. One of the things that guides us away from vibe coding, like I just
showed you. And then we'll even talk about how we can use AI to assist with the QA and the code review. And so, ending all the way with a
shipped pull request, where we were using an AI coding assistant every single step of the way for PM, developers, and QA. That is what we're going to be going
through here. And so, like I said, we're starting with something that doesn't have AI in it at all. So, what we're looking at here, like
what I have cloned locally. So, someone pointed out they spotted a dot claw folder, and that is because what I have in this repo right now is not the same version I have cloned locally. Because
what I have cloned locally, I have everything wiped, right? Like no dot claw folder, no MCP configuration, no claw.md. So, trust me, I don't have this locally.
We are going completely from scratch here in this code base. So, cool. We'll get into the next thing in just a second here, but I want to go through the chat really quickly, cuz
like I said, I I want to make this very interactive, so we'll have more time to go through questions when I'm waiting for the coding agent in a little bit, but I will I'll start by going through
the chat right now. All right. Uh let's see. So, Sean said, "Will I be discussing CI/CD? Do I have any experience with Jenkins or running a server?" So, uh yes, so we'll
be talk We won't be talking about CD. Like, [snorts] we won't do anything with delivery or deployment today, but we will talk about CI using coding agents in CI to automatically review pull
requests as they come in. I do personally have experience with Jenkins, but we're going to be using GitHub actions for our CI today. Uh I unfortunately I have way too much
experience with Jenkins. Um I did not really enjoy writing the groovy scripts for uh Jenkins CI/CD. It's a kind of a very legacy tool, I will say.
All right. Uh Chris said the Circle live stream needs work. Uh if you could if you could expand on why it does, I would appreciate that. Like, if it's like a quality issue or something, let me know.
I mean, at this point obviously we can't switch platforms, but that's that's too bad that you're saying it needs work. Cuz I I tested things ahead of time and it seemed like the quality was good.
There's a little bit of a delay, I know. So maybe you're experiencing that, but hopefully it shouldn't matter too much. Let's see. Question, does your Oh, and I can spotlight the questions here. So
take a look at this. I'll I'll actually spotlight it. This is one thing that we have in Circle that we don't have in Zoom, which is why I really want to use Circle here. I mean, there's a couple of
reasons, but does your SDLC cover the product specs PRD also instead of having a separate PDLC? So yes, we will talk about I mean, I'm kind of skipping over the PRD creation
here just for the sake of time, but we are going to be talking about like taking the PRD and splitting it into tickets that we put in Jira. So we are covering a lot of what the product
manager does here. It's not like a whole separate system that I would have to cover. That's a good question. All right.
So Ricardo said this is not what I call AI assisted. This is definitely vibe coding like you said. Yeah, I mean, it's kind of AI assisted like you're using a coding agent to help. So like
theoretically it's AI assisted, but yeah, it's definitely definitely vibe coding. Uh the example that I was just covering there. Yep.
Let's see. Bart said, "Frankly, I'm fine with the Jira MCP server Cloud Code does all this automatically. Basically does the pip loop itself with verification and adds to the ticket."
So I mean, Cloud Code, it's definitely going to do a good job. Like if you give it the Jira MCP, that alone is going to help a lot. But it's still not always going to follow your conventions and
your process, which is why we need to bring in a more AI native process with the rules and the skills that we build for it. And so like certainly a lot of the
things I'll show you guys today, it's going to be building on top of what your coding agent is already able to do, but we're making it as reliable and repeatable as possible. Right? Like when
we create our rules and our skills, and I'll get into all those things with our AI layer, as I call it, we are creating a system that every engineer at your organization will adopt. Or at least
that's the goal where everyone is going to adopt the same system for how you plan, how you implement, how you do a code review. And so, making sure that each person as they're working with
their coding agent, they're doing it in the same way. Sean said my organization is going with Microsoft Copilot. That Yeah, that is unfortunate, Sean. I'm sorry.
Yeah, [snorts] Chris said he could have access to Copilot services or through You could have access to Anthropic models through Copilot services. That's true, but still the harness of
Claude Code itself is still the best, in my opinion. All right. Uh the video is a bit glitchy. Okay, that is unfortunate, Ricardo.
Well, I appreciate you guys sharing. That's That's good to know for a future that it's uh that's the quality Oh, from a functionality perspective, not a quality of the video. Okay, so
Chris says that it's um maybe not the quality though. Well, okay. So, I guess it's kind of depends on the person. Still is good to know though.
Okay, so anyway, we'll we'll continue on here with the rest of the process. So, I gave you guys a a brief introduction of what the AI native SDLC looks like. I also have a detailed version of the
diagram. Right? So, like this second half right here expanded is what you're looking at here. And this is another one of the diagrams that I have for you guys in the starter template.
And so, this GitHub repository, I'm going to put a link to this in the chat right here. And so, this GitHub repo has the entire starting template that I'm going to be
covering with you guys here. All of the rules and skills, that example MCP configuration. Again, this is not a full AI coding framework. That's not what I'm teaching here. I just want a template to
help you guys get started so it's as easy as possible to mold this into your existing SDLC. And so, I also bring this up now because each one of the diagrams that we'll
cover here is in the diagrams folder right here. So, if you want a quick reference of everything that I'm covering today, this is the place to go. So, I'm just trying to make this as
organized as I can for you guys. And so, this is everything that we're going to go through here. And we're going to start at the very beginning. We have that PRD that defines our epic in
Confluence, and we're going to start by making our code base AI native. And actually, the very first thing that we're going to do here, going back to the read me of the AI layer starter
pack, is we're going to install this on on our current code base that currently has nothing, right? So, like let me open that up again. Close out of Cloud Code. Here's our code
base, and then I also have the starter pack that is cloned locally. And so, we'll just run these commands right now. Super easy to bring everything into your code base. So, if
you've never used an AI coding assistant on your code base before, we can bring this in very quickly. Excuse me. And then the very first thing that we're
going to do is we're going to run a workflow for our coding agent to document all of the constraints and conventions here to build up our initial rules for our
coding agent. And so, let me go ahead and open up a new terminal here. And then I have the commands ready to just paste so we can move quickly here. So I'm going to copy the dot Claude
folder from the starter pack. I'm also going to copy over the MCP configuration. That's going to hook us into Confluence and Jira. We'll cover that in a little bit. And then the other
thing and you can run these commands on your own code base once you have the starter pack installed. And then finally we'll just install the dot GitHub folder.
Oh, it looks like it already exists. So hold on. Let me do one thing here. I can't copy it because it already exists. So really the one thing that I want to copy that I have in the example here is
the Claude review. So this is going to get at the very end of the workshop when we have the part with Let me undo that. We have the part with CI. We'll talk about how we can
automatically review pull requests with coding agents in Claude code. So Oh, it looks like we already have that there. Okay, good. So I guess the copy brought that in. So we are set. Okay, so we have
the AI layer installed now. But the problem is we can't just start using it right away. The one of the most fundamental parts of our AI layer is our rules. You've probably heard
about global rules quite a lot if you've started to explore using AI coding assistants. And so I have another diagram here that we'll go through as we are building our
rules. But I'll go through every single part of our AI layer that we're going to build out and customize to our code base. And really create as the convention for how everyone on our team
works with the code base with AI. So we have our global rules, our skills and sub agents, our MCP servers, and our hooks. And then LSP is a little bit more advanced. Maybe we'll get into that
here. But these are the core things that we're going to be covering. So I'll explain this more in a little bit. But the very first thing that I want to do is open up a brand new Claude code
session and let us create our initial rules for our agent. And so, if you explore the starter pack maybe installed on your code base, if you look in the skills
directory here, we have all of the different workflows that I have as a starting point for you. Pretty much everything that you're going to be doing within a software
development life cycle has a workflow set up for you right here. Again, just made as a starting point for you to then customize that workflow for how you like to work. Right, so a lot of
my recommendations and lessons I've learned from working with organizations packaged up into these, but of course you're going to get the best results when you really customize these. So, for
your product managers, I have a skill to help them create a PRD so they can go through a, you know, brainstorming session with the coding agent and then create a structured document that they
could also save to Confluence. We also have a uh planning feature skill. So, we're going to use this later as well, but guiding the coding agent through, you know, given a specific
ticket that we have in Jira, let's create a structured plan for how exactly we're going to implement that and work with the engineer to build up that plan. A lot of different skills that we have
here. We have the spec skill, which we're going to use to take our PRD and turn it into the individual tickets to hand to our developers. Right, so I'm just trying to give you an idea of how
like everything in our SDLC can map to a workflow that we have as a skill. And for those of you who aren't familiar with skills, really they're reusable prompts. Right, like you take your
workflow. Here's how I like to do my planning or here's how I like to do my validation. And you just package that up into this prompt. Right, so like when I invoke a skill, I'm really just giving a
set of instructions for an agent to execute. And this is great because we don't have to type the prompt over and over and over again. Like go ahead and validate this. I want you to validate
against this criteria, this criteria, this criteria, right? We We don't want to type that out every single time. We instead want the agent to just read our skill and know our workflow. This is
also great because when you build a skill that works well, like this is my skill to create create rules. Like that we'll actually use this one a little bit. When we uh [snorts] create
this skill and it works well for us, we can now give it to other people to use. So, it creates a standard for how the team does every single part of the SDLC with the coding agent. And so, going
into Claude Code here, in order to leverage this skill, all I have to do is {slash} and then the name of the skill, like {slash} create rules. And so, now when I send this in, oh hold
on, looks like I have to authenticate first. Sometimes uh it's really annoying. Sometimes Anthropic does this where it logs me out of Claude Code. I don't really know why it does that. So,
let me just authenticate off camera really quickly here. It started happening a couple of weeks ago where like even in the middle of the day, like we're seeing right here, it'll just log
me out. So, okay, I'm I'm signed back in, so we're set here. So, let me just bring the browser back. So, anyway, it'll still continue here. So, I did {slash} create rules. You just
have to excuse the mess of logs here. But, when I do {slash} create rules, it's going to take this skill.md and it's going to bring all these instructions directly into the context
of our coding agent. So, now it is going through this workflow. And of course, this skill here is going to work no matter the coding agent that you're using. Now, depending on what you're
using, like Cursor or Codex, you might have to change where this the skill lives. So, like in dot in in Claude Code, it's dot Claude {slash} skills {slash} and
then the name of the skill, Then you have the skill.md. So, some coding agents like Pi, they'll support the dot Claude folder. You just might have to change where it lives
depending on your coding agent. But, of course, you can just ask your agent to take the skill and make it work for your specific tool. Very, very easy to do that. So, I'm not going to show an
example of that here. And so, yeah, if you're using Claude code, this will work right out of the box when you install the tar starter pack like I did. Otherwise, there'll just be a single
prompt to ask your agent to migrate it to your tooling. And so, anyway, we can see here that our coding agent is going through the code base right now. So, it's reading
everything and if you have a larger code base, this is where you can use sub-agents to scale your documentation as well. We can talk [snorts] about sub-agents in a little bit. But, right
now we're going through the code base, building up an understanding so we can document how the code base works, the constraints and conventions that we already have here. So, every coding
agent session going forward has those same constraints and conventions without having to, you know, do deep research over the entire code base again. Right? So, we spend the tokens and the effort
up front to document everything so we never have to do that again, but the agent can still have the same understanding of our code base. And so, going back to the diagram here,
I promised that as this is running, I would get I would go over the different parts of the AI layer here. And so, we've talked about every part at least very briefly at this point. But,
when we when you make a code base AI native, you are building six things into your code base. You have your global rules like we're building right now. We have the skills, which are our
workflows. That's the main thing that I have in the starter template. We have sub-agents. So, these are basically workers that you can delegate tasks to.
We have MCP servers, so we can connect our coding agent to our platforms like Jira, like our database. We have hooks. We're not really going to cover hooks in this workshop here
because it's it's really outside of the scope of the transformation I want to show you guys, but hooks are a way to build guarantees into your coding agent. So, a certain thing is always going to
trigger whenever an agent is about to call a tool or whenever the session ends. It's a good way to build security and guardrails into your AI coding workflows. And then, last but not least
is LSP. So, there's definitely a lot of opportunity to build better code search into your coding agent, especially when you're working on much larger brownfield code bases. And so, this is also outside
of scope, just like hooks, but it is an important thing to really scale how much your agent is able to sift through maybe, you know, thousands and thousands of code files that you might have in
your project. And so, the main four that we're going to cover today is MCP servers, sub-agents, and uh skills, and then our global rules.
And so, yeah, the global rules is what we are creating right now. And um so, yeah, one of the things that I want to say with our global rules here is that whatever we create here, like if
I go back to the code base, it should already be created. There we go. Yep, so we have our claude.md that we just built. This file, you want to make sure it
doesn't have that much in it. Because the context that we write in this file is going to be loaded into every single coding agent session going forward.
And we don't want our coding agent to be overwhelmed with information. Maybe you guys have heard of the idea of context rot before, also known as the dumb zone for large
language models. The idea is just because a large language model can hold a certain amount of information, does not mean that you should try to fill that window because
they get overwhelmed with information just like people do. And so token management is a really big deal in the industry right now. Like making sure that your coding agent has
access to the context it needs but nothing more. Right? Like it's important to have some kind of rules here to really guide it on our, you know, core coding patterns and our naming
conventions, right? We want it to build as we teach our engineers to build, but we don't need more information than it would really need, right? Like it If we have needless information here, we're
just going to confuse the agent with all the rules that we've built up. So it's important to keep this file lean. Generally, I recommend having less than 300 lines in a global rule file.
And so just all of the important things that apply to our coding agent that it cares about knowing no matter what it is working on in our code base. Right? So that's kind of the rule to have in your
in your head is when you're building up your rules here, for each individual line, if you really want to do that complete of an audit, just think to yourself, is this important for the
agent to know no matter what it's working on? Or at least like most of the time it'd be helpful for the agent to know like naming conventions or coding patterns.
If the answer is no, like maybe this is important but not all of the time, it probably doesn't actually belong in your rules because you can always have other documentation.
Maybe like in other markdown documents in a docs folder or over in Confluence and you can point the coding agent to look at that if it's important for the current task, but the global rules are
only where you put things that are important for basically every task. And so everything that I just taught you guys here, all of that is documented in the create
rules skill. Right, so like the the workflow that we just guided our coding agent through, it knows all of that because we teach it that here.
Right, we're telling it to draft a lean claw.md. Every rule must trace to something real in the code base. Let's make sure that we have only things here that apply no matter what the coding
agent is working on. That's the beauty of a skill is we're packaging up all of our best practices and workflows so that our coding agent can go through that same thing and we don't have to like
re-explain the entire workflow. That's what we're doing here. Like every single skill we go through in our workshop today, that's what we're doing. And so this conversation is done. We now
have our global rules. So the important thing here is that what we've just created is now something that we can check into source control.
And so before we had generative AI, we really had two parts to our code base because we had the code itself and then we had our tests. Right? Like that pair made up like what we'd put into, you
know, GitHub or GitLab or Bitbucket. That was it. Now with generative AI, we have a third thing that we check into source control and that's what I'm calling the AI
layer. Like everything that we just added here with our MCP configuration, of course we'll cover this more in a little bit, our global rules, all the skills that we've been talking about,
this is the AI layer. And I encourage you, just like you check your tests into source control along with the code, I recommend checking your AI layer in as well. Because now the
your entire team is working on building out the exact same workflows, constraints, and conventions, and connections for your coding agent. And that's powerful because we'll talk a
little bit more about system evolution later in the workshop, but whenever you are working with a coding agent and something doesn't quite go according to plan, instead of just taking over and
fixing the issue yourself, I encourage you and your engineers to work with the coding agent and figure out, you know, why was this Why did this issue come up in the first place?
What can we make better in our rules or our skills or whatever so that that issue doesn't happen again? Right? So, using every bug as an opportunity to improve the AI layer. And when I say
improve the AI layer, that can literally be making a pull request, right? Like one engineer says, you know, I propose changing the skill in this way because I had this issue came up that came up and
my agent said, you know, like if you explain the workflow better in this way, we would have avoided that. So, you can go through pull request reviews, like the full review process just like you
would with your code, but for making your coding agents better over time. >> [snorts] >> And so, I know a lot of teams that they're a big proponent of keeping the
code base pure and they like moving the AI layer to a separate repository or some kind of artifact storage like Artifactory or an S3 bucket. You can definitely do that if you want, but for
the sake of simplicity, I really do encourage you to include that directly in the code base that it applies to. Cuz you already do that with your tests. There's a good chance you already do
that with your tests, so it's really the same kind of idea. And that is like the most important thing. Like if there's one thing that you can
get out of this workshop, the way to really make it so everyone is using coding agents in the same way is to make it so that when when someone opens up a repository, a PM, engineer, someone in
QA, whatever, they open up the their coding agent in this repository, it should automatically have all of the rules and skills and everything that everyone else is using. So, there's no
setup, right? Like you don't have to ask them to go and install certain rules or uh go and download these workflows. Like all of that's just going to be there right away. Because then the barrier to
entry or just like the the effort that's required to leverage AI in the same way as everyone else is basically zero. Um so yeah, I mean like that's been the biggest
breaking of the barrier, I guess you would say, for organizations that I've helped adopt AI. Because everyone right now in your organization is probably already
experimenting with AI. But like I said, people are vibe coding. Everyone has their different way of working with coding agents. And so like the most important thing before you can get the
best results possible and really make your your SDLC AI native is just make it so everyone is on the same page for how we're using these tools in the first place.
And so it's kind of a two-step process of, you know, understand the AI layer and the system and then build it as something directly in the repo. That's really what it comes down
to, right? Like two-step process. That's like the biggest takeaway for you guys out of everything. And so let me go back to our PRD here. Because now what we're going to do is
we're going to take it back a step. So I showed you guys an example of, you know, what if the PM manually created these tickets. Like they they took the PRD and they split it out into tickets.
But the next thing I want to show you guys is how a PM can use a coding agent to help them create their tickets. And so this is really the next step. Like once you have some kind of initial
AI layer built into your code base, the next thing we want to do, cuz I'm going to show you the full SDLC, the next thing we're going to do is split the PRD out into tickets.
And so let's do this right now. So I'm going to actually clear this conversation. I'll just go to a new coding agent session right here. And I'm going to do {slash} spec.
So, this is another skill that I have for you guys here. And my plan is to explain this skill a little bit more as it actually runs cuz it'll take a little bit for it to go through the full
process. So, again, it's like every time I run a skill, while it's waiting, I'll answer you guys' questions and maybe explain it a little bit more. That's what I'll do for the next like, you
know, three, four skills that I show as we're going through the SDLC. So, I have a couple of things saved here. So, every single skill,
it takes a couple of arguments. Or or it can take arguments. And so, if you need to specify something, you do it kind of just like invoking a CLI command in a terminal,
right? So, {slash} spec, and this is where I can specify the PRD page ID, and then maybe I also want to specify the Jira epic key. Right? So, like this is the PRD that
we're going to split into tickets, and then this is the epic key that we're going to create the tickets as a child of. And so, going into Jira here, this is
using the MCP server, by the way. So, I'm already showing you an example of how we're connecting directly into the platforms where we already work. That's one of the most important things to make
your SDLC AI native. And so, going back to the PRD here, all I have to do is give it the ID of the PRD document, just right here from the URL. I know that's probably small and
hard to see, but you just copy the ID, and then you paste it in here. And then the second thing that we need to specify is the ID of the Jira epic where we're going to create the child
tasks. And so, I already have an example where it's split out. And so, just for the sake of demo really quick right here, I'll do the same thing within this epic.
Right? So, SCHED22, this is the planning epic for the Q3 reporting and analytics initiative, right? So, like this maps to the PRD
that we have right here. And so, the idea of this is just this right here, the SCHED22. So, I'll go back into my client code and then say that, right? And so, like all
of this is just what I defined as my custom skill for creating the spec. Like I specified these as the arguments, so now my PMs can just use this skill going forward to, you know, here's the PRD,
here's the epic, now go and help me create the tickets. So, I'll just go ahead and and send this off right now. And as a part of this workflow here for
{slash} spec, you could customize this to your liking. Like maybe there's a very specific interview process you want the coding agent to walk through with your PM. So, like really extracting from
the PM, like how do you want to split things out? How are we going to assign story points? Like whatever you want to do. Again, I want to reemphasize the point of all these skills is just to be
the template starting point for you. And so, what I explained here, like hopefully it it seems like a good starting point, but definitely you probably want to customize exactly what
the process is that we're walking the coding agent through with this spec skill. And so, let me open up the the preview so it looks nicer here.
And so, we're we're telling the coding agent, here's the input to this skill. It's the Confluence ID for the PRD and the Jira epic key. And then step one is to load the PRD.
So, we are using the Atlassian MCP server, which I already have the authentication set up ahead of time, to pull that PRD. And I also made it optional where if you
wanted to just specify a markdown document instead of a Confluence page, you can definitely do that. Because there are definitely a lot of people that prefer just using markdown
for everything. Right? I mean, most organizations are going to work in some kind of cloud provider like Confluence or Notion or whatever, and so that's usually why you
want to make that connection. And so, all I had to do to connect my coding agent to um Atlassian here, is [clears throat] just I set up a single MCP server.
And so, for any kind of connection that you want to make to the outside world with your coding agent, you're generally going to do it through MCP. Because most platforms like Atlassian, like Notion,
like GitLab, they have an officially supported MCP. Like, this is your connector for your coding agent to reach out to us. And like analytics platforms like Sentry
and PostHog, they also have MCP servers. It's very, very common place. In fact, I would say if your platform does not have an MCP server, you should probably avoid using it.
Because that means they're not keeping up with the times. And so, these MCP servers, they usually have like a very simple documentation page for how to install it for whatever
coding agent you're using. Like, usually there'll be some kind of drop-down where it's like Cloud Code, here's the command. CodeX, here's the command. So, you bring it in. And then, when you
first use an MCP server, you just obviously have to authenticate. Right? So, within Cloud Code, I do {slash} MCP. >> [clears throat]
>> You [snorts] can see that I have the Atlassian MCP server connected. And so, if I hit enter into here, I can reconnect, right? Or like, for the first time it would just say connect. And
then, it would bring like the OAuth flow up in your browser, so that you authenticate with your account. It could not be easier to bring it into your coding agent and set up your
connection. And so, that's what we're seeing playing it out here right now. Where it called the Atlassian MCP server. So, I mean, we obviously don't really care to get into all the logs of
Cloud Code here. But, the point is it is uh listing out all of the capabilities it has through Atlassian and then it is calling the right one in order to fetch the PRD and epic in Jira, right? So,
like right here PRD and epic loaded. Now, it's going through the rest of the process here to help me create the tickets. So, it's writing out some markdown first and then
it'll like actually call the Atlassian MSP again. There we go to create the the pages in Confluence and the tickets in Jira. All right. Cool. So, uh let me go
through the chat while we wait for this to wrap up here. Let me just see where I last left off. Okay. Let's see. Jason said, "Haven't seen a glitch yet. Get off dial up."
Okay, well, I'm glad Jason you haven't seen a problem. Uh cuz yeah, sometimes I hear I I think it depends on where you're at in the world.
Cuz I used to use the circle live stream feature a lot, but it seemed like if you weren't in the US, sometimes the quality wouldn't quite be as good. But uh Chris, I know you're in Germany and you're not
having a quality issue, so I don't really know. I just hope that it's good for most of you guys here. All right. Ricardo said, "AI assisted for me is L1
L2 autonomy with good structure, like context engineering and skills. But the difference between AI assisted and AI native for me is how much the agent does versus uh creation of fully autonomous
agents." So, yeah, one of the things that we could talk about here that I don't really want to get too deep into is the different levels of AI coding.
And so, level one and two is more like the vibe coding I was sharing at the start of our workshop. Where you're just sending off the request and you're having the agent
do a little bit of work, but you're still going to have to take a lot of the reins to make it really work well. Level three is where most people should be. And that's a lot of what I'm
teaching here, where you build up your AI layer. You have the constraints and conventions documented in your rules, you have the workflows and your skills. And the goal here, and like I'll show
when we get into the Piv Loop, as I call it, the goal here is to have the coding agent do literally all of the coding. We do the planning, we do the validation, so we're not just vibe coding, but we
build out the system where we have all the context and workflows the agent needs to write all the code. Right? Like I have not personally written a line of code myself for over a
year now. Which sounds crazy to say, because I used to write a like many hundreds of lines of code myself every single day, from the age of 8 to a year ago. I was writing code every single
day, and now I don't write a single line myself, because I've lived at the level three. And then levels four and five is when you really start to get autonomous, having an agent implements an entire
epic end-to-end, with you, you know, putting yourself out of the driver seat more and more and more. And you have to have a really good system to trust an agent to go that far, which is why I
typically recommend staying at level three. It's the sweet spot, where it's not just AI assistant, you're AI native, but you're not building some really intricate dark factory. Right? If you
guys have heard of that idea of the dark factory, it's really popular right now, where the idea is like you send a spec in and you get shipped code out, and there's no
human in the middle. That's why it's a dark factory, because there's no human operating in the environment where you're writing, validating, or even deploying your code.
And there are some organizations that are starting to get there, but you can't start there. Right? Like AI native, going AI native does not mean going from no AI layer at all, jumping straight to
spec in, shipped code out. Like there there's got to be human in the loop as you're building out your system to make it so that you're you're driving the coding agent and you're not just letting
it rip through an entire epic by itself. That's not going to be reliable. Shane said we've used over superpowers. I've heard great things about superpowers. Yep, it's kind of like one
of those frameworks where it's rather opinionated, but it is it it does work really well if you want to use it. Um helps with a lot of planning. Still needs markdown files for guardrails
though. Oh yeah, I mean every framework is going to need guardrails. A lot of them ship with the guardrails that they you know kind of teach you how to build out.
All right. Sean said question, could you clarify why would you something like Jira when all the tickets become issues in GitHub? Is it because Jira is used by the coding
agent to actively track project status and know what to implant or implement next? >> [snorts] >> So Sean, you can definitely use GitHub
issues. It's just a choice. Does your organization want to manage all the different pieces of work through issues or through a more dedicated task
management platform like Jira or Linear? The problem with GitHub issues is it's usually more developer-centric. So if you're working in a larger organization where you have PMs and
stakeholders and a lot of people are going to be looking at like what are we doing next? They don't want to live in GitHub issues. And Jira is nice because there's a lot
of other features for more than just like documenting the individual pieces of work that are a lot more friendly and needed for roles like the product manager. So usually GitHub issues is
great for open source projects or a team that is like just engineers. But it doesn't really scale well to having a lot of different roles where they need a lot more functionality to help with
planning and then like the linking to Confluence for your documentation. It it goes a lot further. Yeah, Ricardo said most orgs uh manage tickets in Jira, Notion, Linear,
not GitHub at least in my experience. And same here. Yep. Uh and I would say that uh oh so Shawn asked, "Would you say that a solo developer can buy a past year
altogether?" And yeah, the answer is yeah, like Ricardo said. Definitely. I mean, it can still help to work in a ticketing solution like Jira, uh, cuz it is very, very feature-rich. Like GitHub
issues is simplistic, I mean, mostly on purpose, but like it is pretty simplistic. But it definitely gets the job done for a solo developer.
Uh, Jira is definitely the industry standard, has a very good free tier, looked at Linear, but it limits its free tier to a few hundred issues. Yeah, Linear is great, too, but, uh,
definitely Jira is by far the most common platform for task management at enterprise level. I don't [snorts] remember the exact percentage, but I think it was something
like 60 to 70% of medium-sized to large companies use Jira and Confluence, which is one of the big reasons why I wanted to use this for the example here, because most companies I work with are
using Jira and Confluence, and I know most of you guys will be as well. So, all right. Um, Enker asked, "Will I share the recording?" Yes, the recording will be
posted in the description of the event afterwards. So, literally just right here. And then I'll also send out an email with the link to the recording as well.
So, I got I got you guys. If you have to leave early early for whatever reason, uh, I hope you can stay for the whole thing, but if you have to leave early or you want to share the recording with
others, I'll make sure that it's, uh, very accessible to you guys. All right. Cool. So, yeah, I know there's some more things in the chat here, but I'm going
to get back to where we're at. I just want to make sure that we make good time here. So, all right. So, we have our tickets created here.
And, uh, yeah, while I was answering questions, like there was a very full workflow that the coding agent was walking itself through with the {slash} spec skill. So, it created each one of
these directly in Jira. And you can see that it even has like the full links I can click to go directly to it. So, let let me go ahead and go back to Jira. And I can refresh the page.
And there we go. So, now I can expand 22. And we have all of the tickets that were just created. And so, obviously this might be a bit
more autonomous than you want. Typically, you'd want the coding agent to like, you know, actually talk to the product manager and help them ideate around how they're going to split
tickets out. I just wanted to do something more simple to to demo to you guys. So, this like out of everything in the entire workshop here, this is like the
biggest example of, you know, use the spec skill as a starting point, but you're probably not going to have a product manager like just run {slash} spec and then they're done.
Like they're probably more of a conversation with the agent to figure out how are we going to split these things. But the main thing I'm trying to demonstrate here is the coding agent
given all the guidance we have in our AI layer is able to take the PRD, reason about, you know, what is the work that has to be done and how can we split these things out into bite-size chunks
for the developers to take on one at a time. And you can make a a workflow or a skill like this as elaborate as maybe even doing like, you know, story point
analysis, laying out dependencies. You could figure out if one developer could maybe have, you know, three coding agents in parallel knocking all three of these out because they don't have any
dependency. There's a lot more that you can do here. Again, it is just a starting point. And so, now that we have this uh set of tickets here,
our next job is to, as the developer, pick one of these to build out. >> [clears throat] >> Excuse me. And so, again, we are glossing over a
little bit the whole like PM role cuz we started with the PRD that you could also use a coding agent to help build. But for the sake of time, I want to really get into the developers workflow now.
So now that we have the tickets and we're assuming that they're ready to be passed on to developers, we can just pick one and I'll show you the full pivot loop, the full process that we go
through to implement a ticket from scratch. And so going back to our coding agent here, of course, we have a couple of skills to help us with this process. So
the very first thing that a developer does when they open up their coding agent in their code base, they first need to have their coding agent load the context from the ticket.
And so if I want to, you know, pick a ticket for example, let me go back here and I'm just going to go back through the original epic here just to make sure that things are
reliable for the demo. But let's say we wanted to implement number three right here. So we are adding a CSV export to the meetings page. And imagine that with the
help of the coding agent, the PM created this tech spec page. This is the one that I copy and pasted into the coding agent earlier when I was doing the vibe coding example.
So this is our ticket. Now the developer needs to load this in. But of course, we don't want to just copy and paste this ticket and ask it to implement like we did before. We want a
more elaborate process and so we're going to start with something called a prime skill. Whenever you are beginning a new piece of work as a developer, I always
recommend starting with something like this. What prime is going to do is it is going to walk the coding agent through a workflow of pulling the Jira ticket
and then exploring the code base to figure out at at least at a high level, how would we go about implementing this ticket? So, I'll do {slash} prime and then I just have to do two inputs
here. So, I give it the Jira issue, which is schedule three, and then you can optionally like I mean the Jira ticket itself might have the full description,
but if there's a Confluence document to go with it, you can also specify that. I know it's a little bit specific, but that's just how I have it set up in the prime skill right here, right? Our two
inputs is the Jira ID and then the Confluence ID if we have that accompanying document. And then if the description of the Jira ticket points to it already, maybe you don't even have to
implement that, right? Like coding agents are pretty adaptable, they can understand like I was given this Jira ticket, but the description really only points to the Confluence document, like
let's go read that document. It's really up to you, I mean like you don't have to be that picky. So, let me go ahead and send off this command.
So, again, we are pulling, right, loading the external context and then figuring out how does this external context fit into our current code base? It's going to dive into both and then
help us create that initial idea, right? Like we're just exploring right now, how would we go ahead and implement this work? And so, going back to the diagram, we
picked a ticket and now we're going through this process, right? So, we just did the prime skill. There's actually four skills that we're going to go through in succession here, pretty
quickly. We're going to prime, we're going to work with the coding agent to get an understanding of what we're building here, and then we're going to create a structured plan.
And then we're going to send that plan into a separate agent for implementation. I'll explain a little bit why we actually want a separate agent, we want that separation here.
And then we're going to have a process where the coding agent is going to validate its own work and then we're going to check things as well. So, there's a validation gate both for
ourselves and the coding agent. And then once we're happy with the work there, we're going to create the pull request. And that's where we get into the code reviews and the QA side of things as
well. And so this this core system here, I call the Piv Loop. It's short for plan, implement, and validate. And there there's kind of like a new
phrase I like to use or I I add the R as well. So, I call it the R Piv Loop because when we're priming, we're kind of researching, right? So, it's like, you know, research the idea, plan out
the implementation, give it over to the agent to execute, and then make sure that the validation is happening as well. That's it. Like if if every engineer goes through research,
plan, implement, validate, you are set. And we have the skills here for each step of the way to make it so that's repeatable between engineers as well, right? Like the whole idea is we can
continue to evolve these skills and make them better and better for the entire team as we go. And so right here we loaded the external context, and then it also researched the
code base to understand how we're going to implement this. So, what we can do next, before we go into actually planning, this is where we
should have a conversation with our coding agent. Right? Like even though we're using skills to drive our coding agent through a lot of these workflows, we're not just going to invoke skill
after skill after skill because we need to be a part of the process, right? Like have a conversation with the agent to figure out how we're going to build this.
So, that's the thing that I kind of glossed over with the spec skill for PMs, but I I am encouraging it really do that all the time. Like so, what I'm going to do right here, let me actually
pull up something. Let me load up my AquaVoice. It's not up for some reason. Let me pull this up here. I love using speech-to-text tools. So, this is AquaVoice. There's a lot of
other great tools like Whisper um or Epicenter whispering, like some open source and free ones as well. I would highly encourage you to give everyone on your team a speech to text
tool because it allows you to just get your thoughts into the coding agent a lot faster than typing it yourself. So, AquaVoice is nice. Really doesn't matter the tool that you're using here.
There's even a voice mode built into tools like Claude Code. A lot of coding agents are coming out with this now. Because sometimes it can take a while to type out all of your ideas as you're
working with the coding agent to plan something like we're doing right here. And so, watch this. What I'm going to do here is I'm going to go into my coding agent with my speech to text tool. I'm
going to say, "Okay, now that you have all your context loaded for this ticket, I want you to help me ideate around how we're going to build this out." So, I specifically want you to make sure you
have full understanding in the code base as it relates to this ticket, and then I want you to grill me. I want you to interview me by asking me a ton of questions to make sure that we're on the
same page for everything with this implementation. So, there we go. I'll send this request off. The important thing, the reason why I'm having it ask me questions here
is because your number one job when you are working with the coding agent to plan something is to reduce the number of assumptions that it makes. Let me say that again. Your number one job when
working with a coding agent is to reduce the number of assumptions that it makes. Because what makes live coding fail is not necessarily the coding agent writing bad code, but just not writing the code
you want. Right? It doesn't understand exactly what you're going for. That's why you can't just send off the request with no context. You have to go through this planning process. We're
spending a lot of time going through the whole planning step here. Like it takes a while before we even write a single line of code with our agent, and that's very intentional because we want to set
up first our AI layer, which is our top-level rules and conventions, and then we set up the the the task-specific conventions like we're doing right now. So, we have sort of like the two layers
of planning as I call it, where it's our AI layer for everything, and then it's our current conversation as we're specking out this build. And so, even though coding agents will
make terrible assumptions and be very confident about it, what they are actually pretty good at is realizing the assumptions that they're making and identifying those. So, if we ask it
something like this to bring up anything where we might not be on the same page, it actually does a really good job. So, we're going to go through a little bit of an interviewing process here
where the coding agent is going to say, you know, like, "Hey, here's how I'm thinking about this. Is that good?" Or like, "Would you recommend something else?"
Right? So, right here, it actually came up with a massive list of 26 questions, which that's kind of ridiculous. I don't know if I want to go through 26 right now.
Um or actually 28. We through had 28 questions. So, if you really wanted to, you could take the time to go through every single one of these questions. It's obviously up to you how many
questions you want the coding agent to ask, or maybe you really do want it to come up with the number itself. This is an another one of those pro parts of the process that I would highly encourage
you to customize. But the point is, it's raising the concerns of like, "I'm not totally sure we are on the same page here." And so, for the sake of simplicity, I'm
going to say, "Use the use or sorry, use the ask user question tool to just ask me four questions right here just for the demo." So, I'm going to cut it down cuz I don't
have the time for this, but it is really worth the time. And I I know that like getting through this many questions, I mean usually it's less than 20. This is actually kind of
surprising to me. I don't know why Opus and Claude Code is deciding to do this right now, but regardless it is worth going through all these questions because every single question you answer
well here is a is an assumption that you're removing from the coding agent. And so when we create our structured plan that we'll do in a little bit, we'll see like all these decisions come
through in the document so that the agent is really grounded in how we actually want to go about this implementation. And obviously the more technical you are, the better you're
able to answer these questions, but even if you aren't as technical and you're maybe just a PM working on something or whatever, you can also have a conversation with the agent and say, you
know, help me understand the different options here. What are the pros and cons? So you can go as deep into this planning as you need to really get a full understanding because you and the
agent both need to be confident in what you're building before you should ever trust the agent to actually write the code. The only reason we are confident enough to ever delegate the coding to
the agent is because we're dedicating so much to the planning up front. And so another one of the little golden nuggets here, at least in Claude Code, most coding agents have this now, is
they have something called the user question tool. So it's able to ask us questions in a multiple choice format like this. So we can add notes, we can chat about it if
we think none of these options are good, or we can just go with its recommendations. And oftentimes are good, so we're just going to go with these here. You should usually take more
time with it. I'm just, you know, for the sake of brevity here. But it's nice because a lot of the times the recommendations are great. So you can just go, you know, like, all right,
recommendation's good, recommendation is good. So even if you do have 28 questions, you can, you know, kind of blitz through them in just a few minutes unless the agent is really mistaken on
the direction. And so just one of those things really help like, you know, sometimes it can be really a pain to get through all these questions, but that's the best way to
make it as fast as possible without sacrificing the quality here. So, here are the decisions that we settled, and then I'm going to go right into the plan feature skill just for the
sake of time here, but usually for any individual ticket, as long as it's more than just like a you know, a single story point, you want to spend a good like 20 30 minutes conversing with the
agent before you go and create the structure plan. Because when we run this next skill, we really are committing to like here is what we're going to build out when we
hand this to the next agent for execution. So, I'll do you know, plan feature right now. And then uh you can give it a
description of what you want to build. Obviously, I'm just going to go off of our current conversation, so I don't have to specify anything. So now, think about it this way. What
we're doing here is we are taking our conversation that's been very unstructured at this point, right? Like just a very free form conversation that maybe we've been doing
for 20 30 minutes, and we're now creating it into a structured plan of attack. And so, if I open up the skill for this here,
let me find it. The plan feature right here. >> [snorts] >> Let's go over the workflow really quickly. So, just as we're waiting for
this to actually run, I'll show you generally at a high level what we're doing. So, okay, we're transforming a feature request into a comprehensive
implementation plan. Okay. So, planning process. This is the [snorts] step-by-step we want the coding agent to go through to
make sure it really understands everything it needs in order to document our plan. And then the main thing that I cover in this [snorts] skill is the structure.
Right? Every single plan that I create with my agent for any ticket, I want it to have a description of the feature. I want the user story, the problem statement. I want the context references
we want our execution agent to read, right? So, like when we primed our coding agent, we dove into the code base. We identify the files that are important to our current implementation.
So, we want that to be documented here. Identifying any new files we'll probably have to create, like if we're building up a new model or a new service, any kind of external documentation, like if
there's anything in Confluence that would help us right here, we document that. Right? And then we have our implementation plan. Like even getting
into the individual task list of like here are the files we're going to be editing and updating or editing and creating. And so, the point here is we're not
writing any of the code, but we're getting as close to that as we possibly can. We're being very, very specific and structured with our plan here. And the beauty of having this structure
in the skill is now every single developer, when up their coding agent in their code base, they use the plan feature skill, they are always creating this in the same exact way, which means
it's also very easy for other engineers to review. If you ever want to, you know, hand the plan over to someone else to take a look at before you send it into the agent. Because the plan itself
is an artifact that can sort of go through a code review. Right? Like before we commit to the full process and all of the tokens and cost of implementing this, let's make sure
that the plan is rock solid. And so, right here we're almost to the point where we have the plan, it's in the middle of writing it right now. I'm not going to do much of reviewing the
plan here for the sake of time, but typically what you'll do because like this is the single source of truth going into implementation. You will generally spend a good amount of time, maybe not
reading through it line by line because a lot of times these plans can be, you know, quite large, even up to like a thousand lines long, but at least going through each one of the sections here
and making sure everything is aligned. Like the user story is really what you want to be building, making sure, for example, the validation strategy is actually good.
Because one of the things I actually didn't talk about this yet, that's really important, is when we're planning the implementation, we also want to plan how we're going to validate things.
Like, "Hey Claude, make sure you run the unit tests and the integration tests. Maybe there are some new unit tests we should make as well, or maybe you want to do some more like end-to-end browser
automation testing, so we're going through the application as a user actually would." Maybe we're using some other kind of skill or MCP server for that. So, we're
also doing a lot of composing different parts of our AI layer. Like, this plan is going to be using this MCP server for testing, and then we're going to create a pull request using the GitHub CLI. So,
we're we're just instructing on all the tools that we want to use and the process that we want to go through here. And so, okay, there we go. We have our plan. So, we have that just created in
our plans folder. And so, again, for the sake of time, I'm not going to um go and read through this entire thing right now, but the important thing to
call out here is the exact structure we have outlined in the skill is what we see right here. Like, we have our user story, problem statement, all the context that we're going to reference.
These are all the things that we pulled up during our priming and planning. We have our task list as well. And And if we wanted to, we could even like post this plan to Jira, right? Like, I could
even say like, "Upload this to the Jira ticket as an attachment." Boom, there we go. The Coding Ninjas going to take care of that. Like, whatever I mean, I could have built that into the skill. You
could build that into the skill. The point is we can integrate with our platforms very easily. And then, of course, we have the validation strategy at the bottom here.
We're going to run [snorts] our unit tests and integration tests, and then we're going to do our end-to-end testing. Making sure that we can, you know, click
this button cuz we're we're adding the CSV export here. Make sure we can click this button and that we download a CSV and the CSV is formatted properly, right? Like that's everything we're
doing. As well as our level one syntax and style stuff. So, we're doing like our, you know, linting and type checking as well.
Right? Like everything you'd want an engineer to test before they create the pull request or all the testing you would typically do with your CI, we're having the agent do that here. So, it
can also iterate if there's anything that's failing, even like regression tests that might be failing after it makes its changes. So, we're not trusting the agent just on its first
pass. We're giving it the harness here to actually check its own work and iterate. That's the important thing. The most important thing is not the agent one-shotting the implementation.
The most important thing is the agent is is just whatever we get back when the agent says it's done. Even if that means it's iterating for a while. Like I never really optimize for
time with my AI coding workflows. I just optimize for correctness. Okay. So, it says attachment isn't possible via the MCP. So, I guess that's just a limitation of their
MCP server. But anyway, I'll just like create it as a Confluence document and then just add that as a comment. So, same kind of deal. I mean that totally works. So anyway,
I'm [snorts] just going to move on to the next thing here. Now that we have the structure plan, we can go on to our implementation. So, all we have to do is use the execute skill.
And so, the execute skill, this is the next one we have in our workflow here. Sorry, that was the wrong Obsidian. There we go.
So, we did the plan, we created that. Now we're sending that into a brand new coding agent to write the code. And we just have to give it the path to our plan. This is the markdown document
that we just looked at or you could give it, you you a Confluence page if you uploaded it to Confluence first. And the the big reason why I'm doing this in a separate coding agent sesh
session is for the sake of context. Remember Remember the the dumb zone for large language models. This conversation right here is getting pretty long.
We don't want to continue the implementation here because we already potentially spent hundreds of thousands of tokens getting to the point where we have this single plan.
And so really this plan is what's called a handoff document. It's a way for us to package up all the work we did in this session so we can give it as context to the next session. And we're starting
fresh. We want the agent to start fresh so it's not bogged down by all the context from our research and planning. And really this plan that we just created is all of the context the coding
agent needs to get the job done. So we might as well start fresh. We're not really losing anything by going away from this conversation. And so we can see that it's already off
to the races here. Plan validated against the code. Now it's starting with tasks 1 through 3 and it's already writing out our implementation. And so we can see the task list the
coding agent made for itself. It's going to end by doing the validation. We can have it, you know, create a comment in Jira. We can have it open up the pull request that'll kick off the review I'll
cover at the end. We have the full process very end-to-end here. It's driven by the engineer. The point is we still have to invoke each one of these skills ourself because
we're checking things along the way. Right? Like we have the human review gate where we're looking at the plan and maybe even having other engineers on our team look at it before we go into
execution. And then when we execute like we're doing right now, we have the validation gates. We have the different things the coding agent is able to run by itself.
And then we can also check these things. Like generally when you have an implementation come back from an agent, before you go ahead and open up the pull request, you're typically going to at
least go through the application and do some manual testing yourself. And then, you know, if you are an engineer, you are more technical, you should probably dive into the code and
do a quick, you know, dev code review on your machine as well before you open up the PR. So, we're not going to have the coding agent autonomously go straight to pull request because again, we want
another human gate there. Now, if you really wanted to, you could. Like if you built up this system in a way where you trust it enough to go to that like level four or level five of AI
coding like I was talking about earlier, maybe you don't need the human review for the plan or the human validation before the PR. Maybe you want to go from prime straight to pull request without
any human in the loop. You can certainly build that if you want. You could chain these skills together so they all happen autonomously. I'm just not a fan of doing that. At
least at first until you really, really trust your system. So, okay, let's go back and see where we're at right now. Okay, we're get We're to the the validation gate. So,
we're we're actually already almost at the end. Of course, unless it, you know, fails a bunch and has to iterate, but hopefully [clears throat] because this
is a very well-scoped ticket, we won't have to worry about that. And we're using Opus 5 with Claude code, so I'm thinking it'll it'll knock it out of the box, so or knock it out of the park,
I should say. So, okay. While we're waiting for this here, I will go through some questions. We're almost to the end, by the way, cuz the
really the last thing that I want to cover here is just talking a little bit about how we can have some automated code reviews with coding agents to help the QA side
of things. So, we'll get to that in a little bit. I'll go through some more questions right here. So, let me scroll up again just to see where I left off.
All right. >> [snorts] >> So, let's see. Is it the {slash} and init command, which is in progress? That is a good question. So, going back to
our earlier conversation, where did I have that here? Yeah. So, when I ran {slash} create rules, this is a very similar skill to one that is built into Cloud Code called {slash} init.
So, if you open up Cloud Code, just do {slash} init. Even if you don't have any other skills installed, you have this right out of the box. Initialize a new claw.md file with code base
documentation. This will guide your coding agent through a very similar process to what I showed right here. The reason I prefer having a custom
skill is because it allows you to tune the process to how you like creating rules and documenting your code base. Whenever you use something out of the box of a coding agent like {slash} init,
it's convenient, but it's not going to be as powerful. You can always build something better yourself because you can make it custom to your process, your SDLC. That's why I'm a fan of starting
simple and building on top over time, instead of just using something that is handed to you. So, uh question. I set up Oh, and I'm sorry. I'm forgetting to actually highlight these. Let me do that
here. So, you guys can see the question I'm currently reading. So, I set up a similar system in a company I work with, but I added a
documentation layer, which is an auto-updated documentation of all features. That is very cool. Uh limitations and edge cases for all screens and features. The documentation
is parsed with a query script on a skill that makes uh research on each ticket. Do you think it is overkill? I mean, it depends on like how elaborate
the system really is, but I don't think that's overkill. I think this sounds fantastic. The one thing I'd be cautious of is if by auto-updating you mean the agent just
reasons about like here's what I'm going to document, that's dangerous. You would definitely want some kind of human gate for the agent [snorts] to propose what it's going to update before it just does
it. So, the downside of that is just going to take more time because you need someone to like spend the time to review that.
But, it that I mean I like the idea a lot. You could try to make it a fully autonomous process, but usually when I when I have an agent try to like auto document things or like auto improve my
AI layer, I'm never really happy with how it works. Because this kind of process large language models are very to just like dumping in a bunch of
context. Like they'll do like hundreds of lines of updates when it really should just be like 20. Even if you tell it to be concise. So, I just be wary of that.
But, yeah, that's a good question. All right. James said, "Have you built this out for any of your clients in Azure?" I haven't really done much in Azure,
James. So, when I work with a company, sometimes I'm building it out directly for them. Other times I'm just doing more of a high-level training. Kind of like what we're doing right here, but
but still like more in-depth. And so, I I've I've worked with clients before that it that use Azure, but I'm more just like, you know, teaching them something high-level, maybe like more
customized to their SDLC and their tech stack, but not getting like super into the weeds of like how they are working with things in Azure, if that makes sense.
>> [snorts] >> Uh let's see where we're at now. Okay, still working. Uh Shane said, "We have so many repos. We ended up with uh a central one
for just [snorts] skills and commands." So, okay, this is a really good point you bring up. I encourage you to have your AI layer associated with every single code base
you work with in your organization. But, what is really nice, and I think this is what you're getting at, Shane, is you have a central code base that houses the more generic version of your
AI layer. Like here is our global rule template, here are, you know, like the generic versions of our skills, right? So you have like your validate skill that isn't customized to any tech stack
in particular because then you take that as a starting point to bring into any new code base or, you know, brown field where you don't have AI yet and then you customize that to your tech stack and
everything in that code base. So you have like the generic version that's always really easy to pull in. Which that by the way is very similar to what I have here for the starter pack
for you. It's the same idea where it's a more generic version. It's not as powerful as it can be because to make it the best version you have to bring it in and customize it. This is my process.
This is my tech stack. This is my architecture. That kind of thing. But having a central place as a starting point is is a good idea. >> [snorts]
>> All right. Uh let's see. Ricardo said, "Yeah, I've seen orgs with large engineering communities and repos in the tens of thousands store this in a dedicated repo
and get some module them in." Yeah, I like that. You as long as you can customize it to your tech stack and architecture. Yeah, that's [snorts] cool. I have I've
never actually worked with Git submodules in that way, but that is a good idea. Actually something I would love to look into. All right.
Paulo said, "In Italy the video and audio quality are both good." Good to hear. All right. Let's see. At level three, writing no code anymore, how do you
still keep some understanding of the code? So that's a good question. I'm not going to show this here for the sake of time. I mean, we're already
getting pretty close to the end of our workshop here. But typically what I'll do after my implementation is done is as I'm validating things like looking
at the code, like doing a code review myself, which that by the way alone is one way to keep up with the understanding of the code, it's just reviewing it. But as I'm doing that and
my manual testing, I'm also taking it as an opportunity to ask follow-up questions to the coding agent. Like, hey, why did you decide to use this library? Or why did you decide to to
build the function in this way? Right? So like using the coding agent as a teacher as much as it is the workhorse, right? And so constantly asking questions cuz coding agents, they're
really good at just like being an educator in general. >> [snorts] >> And so especially if you're less
technical, it's a very powerful strategy to just dump it with questions as much as you want as it's planning things and after it's implemented things as well. And one little golden nugget here,
there's a feature in Claude Code called {slash} by the way. It allows you to ask a quick side question without interrupting the main conversation.
And so I can literally say like summarize the tests very quickly. And [snorts] so you can see that our main coding agent is still going through
the testing here, it's still operating by itself, but then I have this little sidecar conversation where it has full context from our current session where we're doing the implementation, but I'm
able to just like ask questions as they come up. So it'll give me a really nice summary here. I can fork it to continue the conversation or just escape to close and
then I'm back where I was. And so please use that to just dump questions whenever you want. Not every coding agent supports something like {slash} by the way,
but I think most do, most are working on that. I mean, the thing is whenever Claude Code builds something that's really nice and unique to Claude Code, the other coding agents are always quick
to follow. You know what I mean? Like everyone's working on the same features because coding agents are all kind of converging on the same set of features. That's why everything in the AI layer
here, like going back to our diagram, like we have our global rules, skills, sub-agents, MCP servers, hooks, like pretty much every single sub or every single coding agent supports all of
these, you know, primitives of the AI layer, as I call it. All right. Let's see. Corey said, "We've heard Archon helps solidify the system and
manage context." Yes, it does. "What specific capabilities makes Archon better than simply connecting an AI coding agent directly to Jira, Confluence, GitHub, and documentation
sources?" That is a very good question, Corey. I can talk for a while about Archon. I'll have to just give like the brief little elevator pitch here.
>> [snorts] >> So, let me open up the GitHub. I'll I'll try to make this very, very brief, cuz yeah, I can I can go on for a while. So, the idea with Archon
is it allows us to package up the hardest that we build for our SDLC. So, what I've been talking about here is like the full process where we have each of the individual skills that we're
invoking, and we have the different roles, like we're creating tickets, we're implementing the tickets, we're doing our code review at the end as well.
There's a lot of different coding agents that we're managing here. And we are responsible for what I'm showing you here to go through the different coding agent
sessions. Right? Like I do my planning, and then I have to open up Claude Code again, and then I have to pass in like I have to find the plan document, I have to copy that and give it in as a
parameter. I'm I'm really like manually creating each one of these coding agent sessions. What Archon allows you to do is allows you to automate all of that. You build the hardest where you have a
single workflow that you execute. And that workflow is going to string together all the different coding agent sessions, so you don't have to orchestrate things at that level. You
can still build yourself in the loop where you want, like you review the plan before it goes into the implementation, right? So, you can say, you know, do the plan, then the human reviews and
iterates with you, and then you implement. But the the nice thing here is you don't have to like spin up those different coding agents yourself. It also makes it
very easy for you to go between different models and providers. Like a lot of people love doing the implementation with Claude code and then the review with Codex. And then another
thing Arcode does is it allows you to build deterministic steps into your workflows. Sometimes you want to guarantee that there's certain context that's loaded from Confluence or there's
certain tests that are run after implementation. Just because you tell the agent to do something doesn't mean it will. They're probabilistic, so sometimes they ignore
instructions. And so Arcode workflows allow you to build in certain guarantees that happen in your AI coding workflows. The core idea with Arcode is instead of making your coding agent the entire
system with skills, you're instead building the coding agent into the system where it's actually appropriate. Because you don't actually want to give full responsibility to the coding agent,
you want to make things deterministic where you actually can. So, that's my little elevator pitch for Arcode. It really just allows you to take everything we're covering here and
make it more reliable. >> [snorts] >> And so, it is a great It's fully open source and free. If you guys want to check it out, I'll put a link to the
GitHub repo in the chat here. So, there we go. Great questions, guys. I appreciate a lot. In fact, there might I I not have time for all the questions here, which
is a bummer. And so I'll talk about how you guys can reach out with these questions if you if you want. Because I would love to answer every
single question. But for the respect of you guys' time, we're not going to go over here. But yeah, I'm always open to questions over email in the Dynalist community.
I'll talk about all of that here. So it looks like it's taking its sweet time with the testing. Usually that's what that's how it works is it writes the
code quickly, but then it's going to iterate all the little things and you know, usually if your test suite takes a little bit to run, that'll run up the clock as well.
But things are going pretty well. Like it's it's getting there. It looks like it's just on the last level of testing here. So all right.
What I will do though for the sake of time is I will show you what the code review looks like for a pull request that I already have. So let me let me open that up quick. Um
yeah, just for the sake of time, I'll cover this last part really really quickly here. So we don't have the pull request yet. But let's just assume that this is done
and we said like okay, great. Now that the that the work is done, I want you to create a comment on the Jira ticket to update the PM and then also open up the pull request. I went through everything
myself, the code review looks good. I tested the app myself. Everything is looking great. Obviously I didn't do that here. But let's just say oh, that's the wrong
page. Let's just say I went through the site, I tested things locally and it actually looked great. Which I mean, it actually is looking good. Like I have the export CSV right here. It looks like
it's in the middle of restarting the server, so it's not loading the meetings, but we have the export CSV button. That wasn't there before. So the feature is implemented. That looks
fantastic. This is the prompt that I would send in assuming that it was actually done. I'm just not going to wait for it to finish right now.
So we have the pull request created. So I'll just go to one that's already made like this one right here. So I just did I created a pull request for a different ticket that I had in
Jira. And so we can obviously review the PR, we can review the get diff here if we want to ourself, but the important thing is I have a GitHub workflow.
So I'm using GitHub actions here to trigger a workflow using Cloud Code directly in my GitHub repository. And so it does a high-level review of everything. So based on
the context from the summary and looking at the get diff, it is performing an automated review. And so we can click into GitHub actions here to view the logs. I mean obviously
it's going to look kind of messy. GitHub action it's CICD logs in general always look really messy. Uh but yeah, like this is everything that's doing here running the Cloud Code
action. This is what does the full review. So we have like the prompt that we send into Cloud Code. It's like, "Here's the pull request. Here are the things are like the criteria want you to
review against. Go through that and then submit a comment on the PR with your findings after you're done." And that's what leads to what we're looking at right here.
And so to get this built into our code base, it's as simple as just adding a GitHub action workflow in our .github/workflows folder. So I'll click into this, just show this really quickly
right here. So this is our prompt. >> [snorts] >> So I just had to add in my credentials for Cloud Code into my GitHub repo.
And so whenever a pull request is opened or if I do @cloudreview, so I can trigger it with a comment in the PR as well. That is when it's going to trigger this prompt. So I'm telling it to run a
skill. So I'm basically invoking a full code review skill that I've have So this is very custom to me and how I like to review pull requests. So, I'm reviewing
the full difference to the base branch, check for correctness, security, etc. And this is just like a little bit of a demo of what we obviously have as something more elaborate in the skill
right here. And then it we're going to post the review as a single PR comment. So, that is uh the workflow right here and my I I do this all the time. Like
every single pull request for all my code bases, I'm always running an initial PR review with a coding agent. The point is not for this to replace the QA engineer or the other engineer doing
the PR review, like whatever. We're not replacing, but we're augmenting. Because having the coding agent do that additional sweep of the pull request is really, really useful because it gives
everyone reviewing and testing the pull request after a starting point, right? Like, here are the things that you should look out for or here's the full flow that you have to test manually as
you're doing your QA. Whatever that is, like you're able to save a lot of time just giving that starting point. And so, I I found that like for me personally, I don't obviously don't have like an exact
measurement on this, but it's like two to three times faster for me to review pull requests myself now because I'm always like first thing I do when I open up a pull request
uh from someone else's, I just read the output from Claude code, like we saw right here. Right? Like, let me scroll back down. I
read this first. I'm usually not going to trust it fully and be like, "Okay, it said it's good, so I'm going to merge it." But, also that might tell me that like I don't
have to take a look at it for as long, right? Like this kind of like reading this right here sets the stage for what I'm going to look at and how long I'm really going to spend on the pull
request. It's fantastic. So, let me see if we're actually done here. Oh, there we go. We are. Oh, and take a look at this. It even
took screenshots. So, using the agent browser skill, it's one of the capabilities I built into the starter pack, it was able to navigate the website in its own browser and take
screenshots of the feature working. And we could even go so far as to say like, "Okay, now I want you to download a CSV and like actually check the CSV and make sure it works."
Right? Like uh I could have built that into the plan. I I didn't, right? So, I'm just saying that now, but yeah, you can you can take the validation for the coding agent very, very far here.
So, cool. And then one thing that uh so I want I want to close here pretty quick. One thing that I didn't really get to talk about too much is the idea of
system evolution. So, I'll just talk about this really quickly here. When you're going through your implementation with the coding agent, sometimes it's not going to do things
very well. It might not follow a standard you have for it, or there might be a convention that you're missing, and so it produces code that might be working, but isn't quite what you're
looking for. Or maybe it didn't fully understand the feature, and it made some incorrect assumption. Whatever it is, I encourage you, don't just fix the bug
and move on. Treat it as an opportunity to make something better in your AI layer, maybe even making a sidebar pull request where it's like, "During this implementation,"
and then link to the Jira ticket, "we encountered this issue, and I had a conversation with the coding agent and figured out like, you know, there should be a new section added to the plan
document, or there's a new rule that I wanted to add to my Claude.md." Like you can literally just say like, you know, "Hey Claude, this thing was broken, and I want you to help me think
about what we can make better in our rules or skills so that doesn't happen again." Obviously, that's kind of a silly simplified version of what you would do,
but it can be a simple as just having a conversation in the same context window where you just did the implementation. Like this is what's broke, help me figure out um you know, what could have
been different for you so that thing wouldn't have been broke. Now, that's going to be perfect every time, but just starting that conversation and having it help you give you ideas for how you can
make your AI layer better. That's the idea of system evolution. If you take the time to do that, your entire system for AI coding, like this whole process that we've been going through together
is just going to get better and better and better over time and better for everyone on your team because the AI layer is in your source control. So, there we go.
We've went through it all. Congratulations. We We gone through everything together here from PM all the way to the review at the end. Now, obviously there were some things at the
very beginning and at the very end that I had to gloss over cuz like I said at the beginning, 2 hours goes really fast. It is crazy how fast our 2 hours together were. There's so many more
questions I want to answer as well, but that is the full AI native SDLC at a high level. Just giving you the idea of how you can go in, bring in an AI layer, customize it, build out your rules,
split your epics into tickets, take those tickets and then go through the ARPID loop, research, plan, implement, validate. And then just an introduction to what the review can look
like when you've gotten to that end to you have that pull request and you're going into the QA side of things. And uh we are making good time. You know, I'm just about to lose my voice
here. So, it it's good that we got through everything within our 2 hours. And so, yeah, with that there's uh one thing that I want to offer cuz obviously
there's so much I could do to customize the training for your team, even [snorts] come in and help you build out this AI layer and really make your specific SDLC AI native. And so, if
you're interested, I do offer private team workshops where I do the training or do the building, help your team do the building. So, I'll put a link to this in the chat here.
I accept a limited number of companies every single month. And so, if you're interested, please apply here. I got the link in the chat. I'll include this in the
description for the event after as well. And I mean, I ask that you only fill this out if you are committed to investing in training for your team or building out your AI layer, making your
SDLC AI native. But, you will reap the rewards of it so incredibly quickly. Like, the return on investment for the teams that I work with, like, I mean, it's it's like weeks or even days
because of how quickly they make, you know, up to dozens or even hundreds of engineers saving hours and hours every single week immediately. Right? Like, you you take the initial, you know, 1 to
2 week investment to build out the AI layer, and you're reaping the rewards forever after that. Not saying you're going to build out every single thing 100 times faster, but
it is going to be like a noticeable improvement for every single one of your engineers. If everyone is working with the same standard within your existing SDLC, everything is as familiar as
possible, but optimized to be AI native. And so, there we go. I'll leave you with that. And then, I'll also put a link to the starter pack in the chat again. >> [snorts]
>> So, the main resource for the course, or not the course, the workshop here, I've got that in the chat for you guys if you want to use this AI layer as a starting point. And again, all the diagrams that
we used are in the diagrams folder right here. So, very good. All right. I appreciate all you guys being here, all your fantastic questions
as well. I'm going to go through the chat since we have a few more minutes here and just try to find a couple more questions really end things off here. I'll try to find the questions that
really apply to the most people possible. But, yeah, we We like almost 100 people here the entire time. Like I appreciate that a lot. So, for all of you who have stuck around or watched the
entire recording, thank you very, very much. And, you know, if you're within an organization, especially if you lead an organization with a lot of engineers, I really would love to work with you. I've
done this time and time again, and man, it's it's always amazing what we can do together. So, yeah, please feel free to to fill out the form if you are interested. But, yeah, if it doesn't
make sense for you to invest in a a private workshop now, you just want to go through training yourself or bring in a couple people on your team, the Dynamis community is where I have full
courses on agentic engineering, like what we're talking about here. I'm actually releasing the second version for it right now. Okay, so let me spotlight this one right now.
This is a really good question. Something that commonly happens in my org uh is the PRD and architecture produce epics, stories, specs, implementation PRs created. Then a human
reviewer who is a TL instructs the author to change something that fundamentally deviates from the originally written architecture doc. This means a course correction has to be
invoked to change the architecture, meaning some epics and inherently stories have to be updated or new ones have to be created. Would you classify this as being a part
of the PIV loop or would call the PIVR loop? This is a very good question. So, let me go back to the diagram here. >> [snorts]
>> Because I really would call this a separate part of the process. The PIV loop is operating on one version of your plan. If you have to go back and change your specs to architecture or PRD
or whatever, I would not say that you're working within the same PIV loop. Because at that point, if you're deviating enough where you'd have to like go through the same process again,
like you have to re-implement something, you might actually even do that in a totally new R PIV loop. It depends on how much of a deviation it is. But if it's enough of a change where you
actually have to go back and change the architecture doc or the PRD, usually that means that you're going to go through an entire new RPI loop. I mean, maybe you're still working in the same
branch as the first loop, so you're not scrapping the work, but you're going to want to re-go like you're going to you know, prime on the new PRD, right? Like here's the the things I have to change.
You're going to plan out that change. That second PR loop might be smaller because you already did a lot of the work and there's only a couple of things that are deviating, but if it's big
enough where you're not just like, you know, at the end right here change this before you re- re-push the PR, it's going to be a new PR loop. Like I I try to keep this as a simple primitive
where you're just operating on a ticket once. And then any re-architecture is another loop. I hope that makes sense. That is a very good question though.
All right. Wow, I'm very close to losing my voice. This is perfect timing. Okay, cool. I will take one more question here. All right.
Let me scroll up and see where we're at. Okay, we got a really good question on evals here. So let me spotlight this. What evals or processes should we use to know if we are getting good results and
outputs for the first version of our AI system? Or should it be manual evaluation in the beginning? And what can we fully trust for our AI native process?
Yes. So, here's the thing. When we're making our AI or [snorts] making our SDLC AI native, we're not totally throwing out the playbook of our existing process.
You probably already have some kind of PR review system in your organization where you have other people evaluating pull requests before you just ship it right to production or merge it into the
release branch or whatever. You're going to keep the same thing when [snorts] you go AI native. So, people are going to be evaluating pull requests just like they did when humans were the
one writing all the code. That is that first step of evaluation. So, it is kind of manual evaluation like you're talking about where we're not going to like have an LLM review the LLM output. I mean,
you can certainly do that if you want and you want to get more advanced. But, in the end, you first evaluate your system by just seeing like are these pull requests actually high quality when
they go through that, you know, final pull request or that final code review before we ship or merge. And if it seems like a lot of these pull requests are getting rejected when when,
you know, before it was AI native, like they weren't as much, like that is definitely an indication that you have to adjust your system and your system is underperforming.
And so, I I wouldn't I wouldn't overcomplicate the eval process. I think that's really what it comes down to. Cuz you really already have an eval process, at least hopefully, with just
your code reviews, you're just taking that further. If you really wanted to, I've done this kind of thing more to like pit a model against another one, but I have created
a sort of like LLM as a judge system where I have the code review um like [snorts] evaluate the pull requests, but then also evaluate the
rules of the code base and make sure that agent is actually following the rules that we have in the skills and the claw.md and everything like that. And then like assigning a score. So, like I
said, I've done that more to see like how well do different models convey or like conform to our conventions, but you can definitely do that as just like an overall score of how well your system is
performing. So, just something to think about, but mostly it's like your code review already covers that eval. So, cool. All right. Good. So, that I'm going to
go ahead and end it there. Thank you, Simon. I hope I get well soon as well. But, uh yeah, you all are very, very welcome. Thank you again, everyone who made the time to be here. 2 hours is a
long time, so I appreciate the commitment. And um yeah, just feel free to shoot any questions my way with the email I put in the chat. Feel free to join the Dynamis community cuz I'm doing
office hours and answering questions daily there as well. And a lot of other talented people I can answer your questions, too. So, All right. Thank you, everyone again.
Hope that you guys have a fantastic rest of your day, rest of your week. For everyone in the Dynamis community, hope to see you guys in the workshop on Friday.
And yeah, take it easy, everyone. Have a good one.