Vollständiges Transkript anzeigen (7.889 Wörter)
What's up, engineers? IndyDevDan here. If you're building systems of agents that operate for you, stick around. This is going to be a valuable one for you. If you're mindlessly vibe-coding slop, this video is not for you. Click away. Thanks, see you next time.
Software factories are massively misunderstood and underappreciated. The key is to understand that they're useful for one reason alone. They give you more leverage on your prompt. That's it. Now, the amount of leverage you can get is determined by the quality of your investment into your software factory.
At the lowest levels, you chain together a few agents to do a little more work for you with some minor configuration. At the highest levels, you build a system of agents plus code that operates without you, just as well and sometimes even better than you would. In this video, I'll share my super simple software factory to show you how you can begin to unlock this leverage. This factory is a combination of the big ideas we've discussed on the channel and inside TAC, except it's been rebuilt from the ground up for the next phase of agentic engineering.
If you understand that agents plus code beats agents alone, and if you want another edge in the age of agents, stick around and let's break down the super simple software factory. There are three key design principles I've embedded in the super simple software factory. It's observable, it's customizable, and it's reusable. All things that are essential to operating in the age of agents. Observability is key. If you can't measure your agents, you can't improve them.
We can click into any AI developer workflow here and see exactly what happened in a swimlane view. We have Kimi-K3, Gemini 3.6 Flash, GPT 5.6 Terra, GPT 5.6 Luna. We have an abundance of great models to work with at different performance, speed, cost trade-off points, and your software factory lets you use all of them together. The best engineers now are building systems of agents. They're not debating which model is the best anymore. It's important, but it's less relevant every single day. Software factories are the system you use to scale your compute to scale your impact.
I've denoted the three actors of value creation. There's me the engineer, there's the code that actually executes, and then we have our agents. So this isn't just about running a bunch of agents in parallel or in different team configurations. It's about combining engineers plus code plus agents at the right time to get the best results. Agents plus code beats agents alone. We'll talk about that more later on in this video.
We can dial into anything here. Let's check out Kimi-K3's plan. Of course, you can see all the events and we can see all the configuration. We can see the compiled prompts, so of course both the system prompt and the user prompt. Your software factory depends on your ability to prompt engineer, context engineer, and of course, harness engineer. We can go up to the agent config. You can see all the tools, you can see the coding agent we used, and you can see the specific agent harness we used. This is very powerful.
This software factory is allowing me to do all the sub-engineering inside of agentic engineering. So I'm talking about prompt engineering, context engineering, harness engineering, and what's inaccurately called loop engineering, which is really all about managing the software developer life cycle inside your work. Check out the previous video where we dismantle loop engineering. It's a terrible rebrand of the software developer life cycle. I'll link that in the description for you.
But let's actually run our super simple software factory. What does this actually look like to execute? Let's open up the terminal. I am using Herder as my terminal multiplexer now. I've transitioned away from tmux. Great tool, but Herder gives me everything I need and a little more. It's more customizable, it's more configurable, it's simpler and it's faster. I'm going to fire up a Pi coding agent. We're going to run the new cracked state-of-the-art Opus 5 model here. So a key feature of the super simple software factory is that it has agentic access. That means we can move at the agentic speed. I have engineered this system to be operated by of course, us. So if we wanted to, we could boot up just commands and we could operate this ourselves, right?
You can see we have the plan workflow, plan build, so on and so forth. But why would we do that when we can move at the agentic speed and have an agent orchestrate the system on our behalf. Let's kick off a workflow. We'll run this prompt: "Break down what this app is, its features, and suggest 3 new features to enhance the app." And now our agent is going to get to work understanding lazy-loading the remainder of the skills it needs to actually operate this. We're using Opus 5, so you can see it's ultra smart. It's going to write this prompt and it's going to kick off this workflow. I'm going to open up the tool in the background here, and you can see it's already started to get to work. So this is observable in a live way.
So you can see we're running a simple ADW scout workflow. We're going to start simple and progress to a more complex prompt, more complex AI developer workflow inside our software factory. We're running a single scout agent. We can dial into the request, we can see what we the engineer inputted into the system through our agent. It has enhanced my prompt to make it even clearer, more concise. And of course, I've prompt-engineered that into the super simple software factory. And now our scout agent is just running and it's going to report its results. So we have a simple two-phase workflow here. The request comes in and then we have a scout agent. One engineer, one agent. Super simple.
We're running the Gemini 3.6 Flash model, which is a really, really cost-effective model. If we open up my model stack here, which is where I am tracking all the models, state of the art, we have workhorse and then we have lightweight models that run on your device. Gemini 3.6 Flash is an A-tier workhorse model at really, really cheap prices. You can see here this thing operates at $1.50, which is beating out pretty much every model above it, minus Luna. Luna's also another great option from OpenAI. But you can see here, I'm not really fixating on one model anymore. I'm using the right model at the right cost, at the right speed, at the right price, at the right performance. It's about your model stack now. And again, the software factory is how you get to that. Let's go ahead and open up our agent and you can see it has the results from our workflow. So an ADW ran, which is an AI developer workflow, all it did was scout the application. So this is a really, really simple, atomic unit of the software factory. Just scouting, just looking for code, finding information, presenting ideas.
So that prompt was really simple. "Break down the application, suggest 3 new features." And then we have a definition of done. So that's exactly what my agent did. So super simple. You can see here we have three proposed features. You can see that we are building an application called Inkwell, where we can basically just do some writing. So this is what it looks like. It's a super simple app. I'm using as a test, as a prototype to enhance and to build the super simple software factory. We have some nice hotkeys, we can go into focus mode, we can zoom in, we can zoom out, and we can create new ideas here whenever we want to. Let's go ahead and run a more advanced AI developer workflow inside of our software factory. I want to really show you how powerful this tool can be. If we scroll back up here, I've prompt-engineered this orchestrator agent to present all the workflows this software factory has. So you can see everything you would expect. The simple prompt, a scout, a plan, a build, quality check, so running our lints, running our formats, our type checks, documentation, and then the composite workflows, the heavy hitters, the workflows that really do the work on your behalf.
You can see plan build test, build review, build test. And then of course, ADW simple software developer life cycle, the full deal. Okay, so we're going to work up to this. Let's go ahead and run an intermediate step. If you're a tactical agentic coding member, this all looks very familiar to you and you've likely mastered these ideas already. Let's go ahead and kick off a new workflow. And I want a classic light mode. So I'm just going to paste this in. I want to run the ADW plan build test. Add light mode to contrast the dark default, build the design system such that we can add other themes in the future if we want. So we'll kick that off and now we're going to get a three-step agentic workflow that combines code and agents. And so we'll break down the internals of this application a little more in a second, but we can go ahead and see in our observability system, this new workflow running. So now we have a planner and a builder. You can see here, we're going to use the Kimi-K3. It's a pretty good model. It's definitely not outperforming Opus 4.8, Sole, any of the really big heavy hitters, but it is the first open weights model inside of the state of the art tier, which is an impressive feat. You know, something I've noticed that you likely have too, this model thinks a lot, so it's not actually as fast or as performant as Opus or Sole, but it's still an incredible model.
I've been using this model through Fireworks. I've been really enjoying using Fireworks, using Kimi-K3 on it. They have put out some really great endpoints. They have a fast and a priority serverless tier, US only serverless endpoints. One of the first to do this, I think. You know, last week we talked about this idea, is Anthropic stealing your data while you pay for it? And we really answered that question in depth. Check out that video, I'll link that in the description if you're interested. But Fireworks is responding to this very idea of AI ownership. I'm not sponsored and I don't take on any sponsorships. They're really addressing the need for AI model ownership and for just cheap serverless inference with great optionality without taking all your data. Let's see how our software developer life cycle is doing. So you can see here, we have two agents that completed this workflow. Okay, so we're adding light mode to contrast the default dark mode. So let's see first off, did our agents build the work? You can imagine they did. So here we have a light button, we can click it and the color is inverted. Fantastic.
So how do we do that? We built a simple software factory that contains a workflow that plans work and builds work and then we have, you can see here, two code checks that occurred afterward to verify. And you can imagine, if these verifications fail, they'll send that work back to the build agent, and the build agent will correct the mistakes. Okay, so simple enough feature. We didn't need a huge workflow for this. We used Kimi-K3 just to plan, and we used Gemini 3 flash to actually build out what was implemented in the plan. So just chaining together some agents while understanding that all this doesn't need to be agentic. This is like a really big idea that I think engineers are going to miss and miss pretty seriously. Right now, everyone is like very agent-pilled. I think that's very cool. I get it, I definitely understand that, but everyone in their AI psychosis has seemed to forgotten that code costs nothing, literally runs at the speed of light, and can be changed in an instant. And a big thing people are realizing now is that you actually own your code, whereas we don't actually own any of our AI models. We're renting them. Code is an essential piece for this. You can see I've designed it inside the workflow, and I'm treating it as a first-class citizen here in the software factory.
I recommend you do the same. By the way, I'm not trying to sell you my tool. This is going to be free for you, link in the description. This is open-source software. I'm building and sharing. I want to paint the picture where things are going because it's not just about your single agent, it's not just about your multi-agent orchestration, your orchestrator. Things have scaled quite a bit far beyond that and they've scaled into these software factories. I'm seeing it in the field, I'm seeing it in my discussion with engineers and in my own work. When I sit down to build now, I'm not thinking at the prompt level anymore, I'm not thinking at the skill level, I'm not even thinking about the teams of agents I need, which is super important. I'm thinking about the full end-to-end developer workflow that I would run to get the work done, and then I'm building that with agents. It's an AI developer workflow, and this way I can reproduce the success I want to see in my applications over and over and over. The system was built to be reusable, observable, and customizable. Let's talk more about customizability and reusability because you can see here full observability. This isn't new, everyone's got their agent framework that they use to view what's done.
But let's go ahead and just like look at the plan. So what happened here? Planning work happened, it has its own detailed system prompt and a user prompt. We can dial into the agent config, but the interesting part here is we're making sure that work was accomplished by adding deterministic gate checks. So this is code, right? Let's be super clear about this. This is code that runs at the end of the plan step and then we have, of course, a nice cost breakdown for this individual agent phase execution, and then we have the outputs. So we're handing off context by creating a shared directory here, you can see ADW sessions, and we'll look at the code in a second here if you're interested. I am, by the way, still reading the kind of essential pieces of my code bases, not all the code, but the essential pieces. You definitely want to read, especially when you're going to be rerunning the code over and over and over. Basically like the more you're going to productionize something, the more you should dig in and understand what's happening. So you can see here we have a nice handoff. There's the plan created some theme tokens, and then this agent has left a note for the next agent. Kind of a nice way to hand off things. But this is a deterministic type.
My agents are outputting JSON, it's getting formatted, it's getting validated, if it fails, the agent must properly output it. Okay, determinism is wired into everyone of my agent steps. They must output specific types, specific structures. I'm looking for consistency in my AI developer workflows, in my combination of agents plus code. I'm not doing one-off work here. I need these systems to work reliably over hundreds and thousands of executions without me. And that's the key we're moving toward here. The software factory lets your agents run, if you do it well, without you. That's the key. And then we have the build step. Guess what the build step does? We can go on the compiled prompt, go into the user prompt, build task. There's the actual prompt and here's the previous envelope. This is the work that was handed off from the planner. So it has all the context it needs, it has the task, it has its response, report format. If you've been with the channel, you understand this prompt format very well. Instructions, variables, workflow, report. And then it itself again, keeps chaining its output to the next agent or to whatever agent's coming next, changed files, just tracking what you would want to track in a build agent. Of course, we can see all the tool calls and we can really understand the system. If you don't measure it, you cannot improve it.
That's the super simple software factory. It is quite simple. I'm making a couple key moves here. I'm making sure that we directly address engineer work and incoming prompts. I'm making sure that we address our code directly. And then of course, we can customize the agent as much as we need to to get the work done. So again, code plus agents beats agents alone. A lot of engineers are just going to start throwing everything into skills, everything into a bunch of agents. Down the road, you will pay for it. You'll pay for it in some way, whether it's mistakes, hallucinations, which I know is becoming less and less of an issue as these models progress. It's not just that, right? There is cost, there is speed, there is performance. There are just things you likely are having your agents do, like execute tests that you could run in deterministic paths of code. And then if something goes wrong, hand it back to your agent. Tell me why you would need to pass successful passing tests back into your agent's context window. Again, this is just one more advantage you get by understanding what's actually going on. And again, that's that fine line between vibe coding and agentic engineering. Let's scale this up. Let's do something more interesting. I want to dive into how this tool is customizable and configurable. And now I'm going to be using this tool for my products for my code bases.
We're going to run the full software developer life cycle. You know, you can imagine I've invested more time into this AI developer workflow. We're going to give the Inkwell editor a side-by-side markdown viewer in the app right now. There's no actual markdown renderer. We would love to have this for writing. You need to emphasize things, you need to underscore things, blah, blah, blah. Let's go ahead and get this added, just kind of detailing that, we want a switcher, cover it with tests, toggleable, and we have this additional instruction here. Use the state of the art configuration for this work. So of course, with the system, we can customize every single model, every single role, every single agent harness, every single tool, so on and so forth. We'll just go ahead and watch our agent boot this up, so you can see it's doing a little bit of research to understand the system. UDW SDLC, there's a frontier config, we'll look at it in just a second. Confirm the roster, and now it's going to get this kicked off with the SDLC and that prompt that we're running. So that's that. Now we can go back into our observability system and we can see this running. Simple SDLC and of course, as our planner, we have the cracked Claude Opus 5. Shout out to Anthropic for putting out another game breaking model. It's state of the art. The one thing I will say is, it's reportedly above Fable 5. I'm not quite feeling that and maybe I'm just getting cost baited here, but I still feel like Fable 5 is above Opus 5. Comment down below, let me know what you think. Does Opus 5 clear Fable 5? I don't think so. Regardless, they're all kind of in this same frontier level model now. And so I'm really impressed with that, really a great model, and you know, the fact that it's half the price, obviously makes it the model of choice over Fable 5.
I'm just still using Fable 5 when I can here in the really, really critical situations just because I think it's still a notch above and I've seen all the benchmarks, I know that the benchmarks are saying Opus 5 beats Fable. It's just what I'm feeling with my benchmarks in my executions. Okay? So here we go, we're running state of the art workflow here. We want to give our Inkwell editor application a markdown side-by-side view. You know exactly what's going to happen here. We're going to run a full software developer life cycle. Let me go ahead and show you some of the underneath, some of the nitty-gritty of this, right? And it's important to understand how your system works so you can improve it properly. Let's go ahead and jump into this a little bit. I'm going to open up the code base here. For code viewing, I am using VS Code. There isn't really any reason to use anything else right now, and it's really just for code viewing and I do some typing when I'm writing up my prompts inside of VS Code. So all this is wrapped around a single skill, SSSF, super simple software factory. The whole idea with this application is that you can build these workflows where you have agents proposing and code disposing, right? Your code is always validating what just happened, it's always doing the deterministic things and the code actually controls the workflow.
If you've taken tactical agentic coding, this is going to look very familiar to you. You've likely mastered these ideas already. We have an ADW's directory inside this code base that contains our AI developer workflows that run end-to-end. This workflow that's running right now is the largest workflow we have here. We have the simple SDLC here at the bottom, and it's relatively concise, right? It's 180 lines, and I know like everyone's shocked right now and you can't bear the sight of looking at code. Yes, I do actually still look at the critical code in the main line of my code to make sure it is going to scale and to make sure that my agents can operate it properly, right? Yes, I coordinated with agents to build this out, but you can see here we have phases, so we're using the with statement in Python to denote the entrance and the exit of this block of code, and this is what makes up the individual piece of work that we want to do. We have planning here, we just search for name. We have our requests, which is our engineer type, we have our plan, we have the commit plan, build, test, if something goes wrong, the fix, if something goes wrong, review, revise, again, if something goes wrong, document, and our commit docs.
So we are clearly separating agents plus code, and we can do this by looking at this. We go kind equals, and so you can see how we are separating this out. Let me go and just get rid of this search. Engineer, agents, code. And so we're clearly delineating this for ourselves and for our agents. Every one of these is an agent call to my favorite agentic coding tool. If we go into ADW modules, I am running the Pi coding agent. I've got it all configured here and at the end it's just going to run a Pi coding agent with all the customization. But let's simplify this and just look at the configuration. So super simple config, and this is what really lets us customize our agents and their core four, context, model, prompt, tools. It's always the same thing, if you master the core four, you'll master the agent. If we look at our planner, you can see here in the base config, we're running that Kimi-K3 through Fireworks, thinking high, nice purpose, we have our prompt engineering section, so the system and user prompt, and then we have the harness engineering on the channel, we've been breaking down, looking at different types of Pi coding agent, custom agent harnesses, we've been building them and we've been sharing them mostly in public, some private or tactical agentic coding and agentic horizon members, but ultimately what we're doing here is putting together as mentioned the core four for every specific agent we want to run throughout the software developer life cycle.
So this pattern will repeat. Here's the builder, same thing, specify the tools, specify the prompts, specify how your agent is going to operate, specialize it. We've been talking about building custom agent harnesses, we're doing that because every single agent can have their own unique agent harness with specific abilities, all right? And so you can see here I've added subagent support to the planner and I've also added it somewhere down here for the scouter. So if it needs to, it can spin up its own subagents. It's just one simple example of how you can build out and specialize the agent harness that your individual agent executes. The implications of this are massive. One of these agent harnesses, as we've talked about on the channel, can do extraordinary things. So that's the configuration file, the system reads this in where the real magic is, is inside combining this with the actual ADW that runs, right? So let's go to the simplest possible ADW, right? Prompt, all this does is taking some inputs and it runs and executes the actual agent, we have our PH call, it's an agent's call and if we search our phase here, should be a class that we can look at here. It's going to just do validation for us and then it boils down into an agent run call. So if we look at our call, our agent is going to then start executing and this does exactly what you think it does. This is going to run right down into our agent Pi and run the run workflow we can just collapse everything to take a quick look at this, there's run so on and so forth. And you can see there we're setting up the Pi coding agent with our exact params, mode, JSON, provider, blah, blah, blah, blah, blah.
No need to over fix it on the code, just want to kind of share that, what we're doing here is really simple. We're staying in distribution, what does that mean? I'm not inventing a DSL, the only customized thing I have here is this config file, which is just YAML. With the super simple software factory, we're just staying in distribution of what these models know, what they're trained on, it's just Python, it's just YAML, it's just agents, and it's just a skill. Let's go ahead and check on our workflow, there we go, all finished. Here's that high-level view. Here's what it all looks like put together and so you can see how this could be really, really valuable. First off, full model customization, we can put whatever we want wherever we want it. We have a great cost analysis, we know how much some of our work costs, full agent configuration and then we have phased work. It's plan, build, review, one agent, one prompt, one purpose, we're keeping everything nice and focused. If we need to, we can restart the workflow with the session ID with the ADW ID. Communicating this idea is going to differentiate your engineering from the rest of the pack, it's not just agents here, we have deterministic checks to validate the work and proceed from there. There's a lot missing from this, there's a lot you can do with this, for instance, I'm just running this on the main branch, of course, you're going to want to branch, you're going to want to put your agent in a sandbox, you're going to want to isolate the agent run and then there's going to be a merge step later on, the whole point here is that this is an observable, customizable, reusable system that we can modify at the speed of agents, at the agentic speed. We can just dial into this, this is just committing the plan, very simple, here, we're actually running the test suite right after the agent is building, so if something goes wrong, we feed it right back into the agent, right? No problems though, so then we go on to the review step, so what's the review doing? Our review agent is asking the question, is what we built what we asked for? You can see our configuration, classic, cracked Opus model, everything's looking good there. So then we can continue to committing and then we diff the changes, why did we diff the changes, because we're documenting the work done for the next engineer and more likely the next set of agents coming into this work and so you can see, it's very concise, it's doing a streamlined set of things and this gives us extreme flexibility. We're not just throwing a state of the art model, we're not just torching tokens, we're not just token-maxing, we're thinking about what our system needs to win over and over and over hundreds and thousands of executions, without me and that's the key we're moving towards here.
The software factory lets your agents run, if you do it well, without you, that's the key. And then we have the build step, guess what the build step does, we can go on the compiled prompt, go into the user prompt, build task, there's the actual prompt and here's the previous envelope. This is the work that was handed off from the planner. So it has all the context it needs, it has the task, it has its response, report format, if you've been with the channel, you understand this prompt format very well, instructions, variables, workflow, report and then it itself, again, keeps chaining its output to the next agent or to whatever agent's coming next, change files, just tracking what you would want to track in a build agent, of course, we can see all the tool calls and we can really understand the system, if you don't measure it, you cannot improve it. That's the super simple software factory, it is quite simple, I'm making a couple key moves here, I'm making sure that we directly address engineer work and incoming prompts, I'm making sure that we address our code directly and then of course, we can customize the agent as much as we need to to get the work done. So again, code plus agents beats agents alone, a lot of engineers are just going to start throwing everything into skills, everything into a bunch of agents, down the road you will pay for it, you'll pay for it in some way, whether it's mistakes, hallucinations, which I know is becoming less and less of an issue as these models progress, it's not just that, right? There's cost, there's speed, there is performance, there are just things you likely are having your agents do, like execute tests that you could run in deterministic paths of code and then if something goes wrong, hand it back to your agent. Tell me why you would need to pass successful passing tests back into your agent's context window? Again, this is just one more advantage you get by understanding what's actually going on, and again that's that fine line between vibe coding and agentic engineering. Let's scale this up, let's do something more interesting, and I want to dive into how this tool is customizable and configurable and now I'm going to be using this tool for my products for my codebases. We're going to run the full software developer life cycle. You know, you can imagine I've invested more time into this AI developer workflow. We're going to give the Inkwell editor a side-by-side markdown viewer in the app right now, there's no actual markdown renderer, we would love to have this for writing, you need to emphasize things, you need to underscore things, blah, blah, blah, let's go ahead and get this added, just kind of detailing that, we want a switcher, cover it with tests, toggleable, and we have this additional instruction here: use the state of the art configuration for this work.
So of course, with the system we can customize every single model, every single role, every single agent harness, every single tool, so on and so forth. We'll just go ahead and watch our agent boot this up so you can see it's doing a little bit of research to understand the system. UDW SDLC, there's a frontier config, we'll look at it in just a second. Confirm the roster, and now it's going to get this kicked off with the SDLC and that prompt that we're running. So that's that, now we can go back into our observability system and we can see this running. Simple SDLC, and of course as our planner, we have the cracked Claude Opus 5. Shout out to Anthropic for putting out another game breaking model, it's state of the art, the one thing I will say is, it's reportedly above Fable 5, I'm not quite feeling that and maybe I'm just getting cost baited here, but I still feel like Fable 5 is above Opus 5, comment down below, let me know what you think. Does Opus 5 clear Fable 5? I don't think so, regardless they're all kind of in this same frontier level model now, and so I'm really impressed with that, really a great model and you know the fact that it's half the price obviously makes it the model of choice over Fable 5, I'm just still using Fable 5 when I can here in the really really critical situations just because I think it's still a notch above and I've seen all the benchmarks, I know that the benchmarks are saying Opus 5 beats Fable, it's just what I'm feeling with my benchmarks in my executions, so here we go, we're running state of the art workflow here, we want to give our Inkwell editor application a markdown side-by-side view, you know exactly what's going to happen here, we're going to run a full software developer life cycle, let me go ahead and show you some of the underneath, some of the nitty gritty of this, right? And it's important to understand how your system works so you can improve it properly, let's go ahead and jump into this a little bit, I'm going to open up the code base here, for code viewing I am using VS Code, there isn't really any reason to use anything else right now, it is really just for code viewing and I do some typing when I'm writing up my prompts inside of VS Code, so all this is wrapped around a single skill, SSSF, super simple software factory, the whole idea with this application is that you can build these workflows where you have agents proposing and code disposing, right? Your code is always validating what just happened, it's always doing the deterministic things and the code actually controls the workflow, if you've taken tactical agentic coding, this is going to look very familiar to you, you've likely mastered these ideas already, we have an ADW's directory inside this codebase that contains our AI developer workflows that run end-to-end. This workflow that's running right now is the largest workflow we have here. We have the simple SDLC here at the bottom and it's relatively concise, right? It's 180 lines, and I know like everyone's shocked right now and you can't bear the sight of looking at code. Yes, I do actually still look at the critical code in the main line of my code to make sure it is going to scale and to make sure that my agents can operate it properly, right? Yes, I coordinated with agents to build this out, but you can see here we have phases, so we're using the with statement in Python to denote the entrance and the exit of this block of code, and this is what makes up the individual piece of work that we want to do. We have planning here, we just search for name. We have our requests, which is our engineer type, we have our plan, we have the commit plan, build, test, if something goes wrong, the fix, if something goes wrong, review, revise, again, if something goes wrong, document, and our commit docs. So we are clearly separating agents plus code, and we can do this by looking at this. We go kind equals, and so you can see how we are separating this out. Let me go and just get rid of this search. Engineer, agents, code, and so we're clearly delineating this for ourselves and for our agents. Every one of these is an agent call to my favorite agentic coding tool. If we go into ADW modules, I am running the Pi coding agent, I've got it all configured here and at the end it's just going to run a Pi coding agent with all the customization, but let's simplify this and just look at the configuration, so super simple config, and this is what really lets us customize our agents and their core four, context, model, prompt, tools, it's always the same thing, if you master the core four, you'll master the agent. If we look at our planner, you can see here in the base config, we're running that Kimi-K3 through Fireworks, thinking high, nice purpose, we have our prompt engineering section, so the system and user prompt, and then we have the harness engineering on the channel, we've been breaking down, looking at different types of Pi coding agent, custom agent harnesses, we've been building them and we've been sharing them mostly in public, some private or tactical agentic coding and agentic horizon members, but ultimately what we're doing here is putting together as mentioned the core four for every specific agent we want to run throughout the software developer life cycle. So this pattern will repeat. Here's the builder, same thing, specify the tools, specify the prompts, specify how your agent is going to operate, specialize it. We've been talking about building custom agent harnesses, we're doing that because every single agent can have their own unique agent harness with specific abilities, all right? And so you can see here I've added subagent support to the planner and I've also added it somewhere down here for the scouter, so if it needs to, it can spin up its own subagents, it's just one simple example of how you can build out and specialize the agent harness that your individual agent executes. The implications of this are massive. One of these agent harnesses, as we've talked about on the channel, can do extraordinary things. So that's the configuration file, the system reads this in where the real magic is, is inside combining this with the actual ADW that runs, right? So let's go to the simplest possible ADW, right? Prompt, all this does is taking some inputs and it runs and executes the actual agent, we have our PH call, it's an agent's call and if we search our phase here, should be a class that we can look at here. It's going to just do validation for us and then it boils down into an agent run call. So if we look at our call, our agent is going to then start executing and this does exactly what you think it does, this is going to run right down into our agent Pi and run the run workflow we can just collapse everything to take a quick look at this, there's run so on and so forth. And you can see there we're setting up the Pi coding agent with our exact params, mode, JSON, provider, blah, blah, blah, blah, blah. No need to over fix it on the code, just want to kind of share that, what we're doing here is really simple. We're staying in distribution, what does that mean? I'm not inventing a DSL, the only customized thing I have here is this config file, which is just YAML. With the super simple software factory, we're just staying in distribution of what these models know, what they're trained on, it's just Python, it's just YAML, it's just agents, and it's just a skill. Let's go ahead and check on our workflow, there we go, all finished. Here's that high-level view. Here's what it all looks like put together and so you can see how this could be really, really valuable. First off, full model customization, we can put whatever we want wherever we want it. We have a great cost analysis, we know how much some of our work costs, full agent configuration and then we have phased work. It's plan, build, review, one agent, one prompt, one purpose, we're keeping everything nice and focused. If we need to, we can restart the workflow with the session ID with the ADW ID. Communicating this idea is going to differentiate your engineering from the rest of the pack, it's not just agents here, we have deterministic checks to validate the work and proceed from there. There's a lot missing from this, there's a lot you can do with this, for instance, I'm just running this on the main branch, of course, you're going to want to branch, you're going to want to put your agent in a sandbox, you're going to want to isolate the agent run and then there's going to be a merge step later on, the whole point here is that this is an observable, customizable, reusable system that we can modify at the speed of agents, at the agentic speed. We can just dial into this, this is just committing the plan, very simple, here, we're actually running the test suite right after the agent is building, so if something goes wrong, we feed it right back into the agent, right? No problems though, so then we go on to the review step, so what's the review doing? Our review agent is asking the question, is what we built what we asked for? You can see our configuration, classic, cracked Opus model, everything's looking good there. So then we can continue to committing and then we diff the changes, why did we diff the changes, because we're documenting the work done for the next engineer and more likely the next set of agents coming into this work and so you can see, it's very concise, it's doing a streamlined set of things and this gives us extreme flexibility. We're not just throwing a state of the art model, we're not just torching tokens, we're not just token-maxing, we're thinking about what our system needs to win over and over and over hundreds and thousands of executions, without me and that's the key we're moving towards here.
There's a ton of engineering work you just don't need to be doing anymore that continues to be true. So why are you? This is something I think about, this is something I tell myself and other engineers when I'm sitting here working, prompting back and forth like an idiot. So it's time to shift, it's time to make that next jump, build your software factory, deploy it into the cloud, set up sandboxes so that you can push all the 80% junk work of engineering away off to your agent stack in a reliable, repeatable way so that you can focus on the real net new hard work your agents can't do without you. So feel free to use the super simple software factory, pull in ideas, steal it, roll it into your own software factory. It's here for you. Again, every single week, my goal here on the channel is to bring you ideas you've seen, permutations of ideas, some net new ideas, and some just raw, hitting examples of how you can use agents and code, how you can engineer to scale, to get your work done, right? To build valuable software. At the end of the day, that's what it's all about. Those who can orchestrate intelligence at the highest level to accomplish work are winning, they're just in the lead right now and the software factory is the next permutation, it's the next step of this, it's not just about agents, it's about agents plus code. We're getting to a key point in the age of AI, where if you're not running a software factory, you're going to be behind. We're just at another branching point here and I want to make sure I say it clearly and concisely to you, so you're aware. Building these out, it takes time, I wanted to give you a head start here with the super simple software factory, always remember this, vibe coding is not knowing how your system works and not looking, agentic engineering is knowing how your system works so well, you don't have to look. You want to rise with the ceiling of agentic engineering, not the floor of vibe coding. If you want a complete understanding of how to build AI developer workflows, which make up your software factory, check out Tactical Agentic Coding, link in the description for you. You're going to scale far beyond AI coding and vibe coding with advanced agentic engineering so powerful that your codebase runs itself. This is what the name of the game is right now in engineering. This is for the top 20% of engineers, if you're a noob, again, if you're vibe-coding, I'm sorry, this just isn't for you. But if you're doing real engineering work, check this out, this is going to be ultra-valuable, all the ideas embedded in here are going to be the ideas to help you advance your career, thousands of engineers have taken this, I built this by hand from scratch. If you don't want to pay to play, that's totally fine, check out the links in the description, the super simple software factory is going to be completely free and available to you. Also, if you want to understand why I didn't mention loop engineering once in this video, watch the first video linked in the description, what you're really looking for is the software developer life cycle, not loop engineering, we go deep into that topic, and really the idea of building software factories in that video, so check that out if you're interested, you know where to find me every single Monday, stay focused and keep building.
