¶1What's up engineers? Any Dev Dan 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.
¶2Click away. Thanks. See you next time. Software factories are massively misunderstood and under appreciated. The key is to understand that they're useful for one reason alone.
¶3They 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.
¶4In this video, I'll share my super simple software factory to show you how you can begin to unlock this [music] leverage. This factory is a combination of the big ideas we've discussed on the channel and inside TAC, [music] except it's been rebuilt from the ground up for the next phase of agentic engineering. If you understand [music] that agents plus code beats agents alone, and if you want another edge in the age of agents, stick around and let's break [music] 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.
¶5All 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 swim lane view. We have Kimmy K3, Gemini 3.6 Flash, GPT 5.6 Terra, GPT 5.6 Luna.
¶6We have an abundance of great models to work with at different performance speed cost tradeoff 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.
¶7Software 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 agent. 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.
¶8Agents 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 kmk3's plan. Of course, you can see all the events, and we can see all the configuration.
¶9We 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.
¶10You can see the coding agent we use, 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.
¶11It'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.
¶12I'm 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.
¶13It'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.
¶14I have engineered the 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.
¶15We'll run this prompt, break down what this app is, its features, and suggest three new features to enhance the application. 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.
¶16So, 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.
¶17We 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 prompt engineered that into the super simple software factory. And now our scouter agent is just running and it's going to report its results. So, we have a simple two-phase workflow here.
¶18The request comes in and then we have a scouter 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'm tracking all the models, state of the art, we have workhorse and then we have lightweight models that run on your device.
¶19Gemini 3.6 flash is our A-tier workhorse model at really cheap prices. You can see here this thing operates at $1.50 in, which is beating out pretty much every model above it, minus Luna. Luna is 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.
¶20It'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 AI developer 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.
¶21Just scouting, just looking for code, finding information, presenting ideas. So, that prompt was really simple. Break down the application, suggest three new features, and then we have a definition of done. So, that's exactly what my agent did. So, super simple.
¶22You can see here we have three proposed features. 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 hot keys.
¶23We 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.
¶24I 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. So, you can see plan, build, test, build, review, build, test.
¶25And 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 technical agentic coding member, this all looks very familiar to you. You've likely mastered these ideas already.
¶26Let'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'm going to run the ADW plan, build, test. Add light mode to contrast with dark default.
¶27Build a 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.
¶28You can see here we're going to use the ChemK 3. It's a pretty good model. It's definitely not outperforming Opus 4.8, Soul, 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 Soul, but it's still an incredible model.
¶29I've been using this model through Fireworks. I've been really enjoying using Fireworks, using ChemK 3 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?
¶30And we really answered that question in depth. Check out that video, I'll link that in description if you're interested, but Fireworks is responding to this very idea of AI ownership. I'm not sponsored, 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.
¶31So, 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 inverted.
¶32Fantastic. 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?
¶33So, simple enough feature. We didn't need a huge workflow for this. We used ChemK 3 just to plan and we used Gemini 3 Flash to actually build out what was implemented in the plan. So, just chain 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.
¶34Right now everyone is like very agent pilled. I think that's very cool. You know, I get it. I definitely understand that. But everyone in their AI psychosis has seemed to have gotten that code cost nothing, literally runs at the speed of light, and can be changed in instant.
¶35And a big thing people are re-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.
¶36I 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.
¶37I 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, what I sit down to build now, I'm not thinking at the prompt level anymore.
¶38I'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.
¶39The system is built to be reusable, observable, and customizable. Let's talk more about customizability and reusability. Cuz you can see here full observability. This isn't new. Everyone's got their agent framework that they use to view what's done.
¶40But 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.
¶41But 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.
¶42And then we have the outputs. So, we're handing off contexts 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 base. It's not all of the code, but the essential pieces.
¶43You 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.
¶44But, this is a deterministic type. So, 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 every one of my agent steps. They must output specific types, specific structures.
¶45I'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.
¶46That's the key. And then we have the build step. Guess what the build step does? We can go into the compile prompts, go into the user prompt build task. There's the actual prompt, and here's the previous envelope.
¶47This 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. itself, again, keeps chaining its output to the next agent or to whatever agent's coming next.
¶48Changed 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.
¶49I'm making a couple key moves here. I'm making sure that we directly address engineer work 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.
¶50A 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.
¶51There are just things you likely are having your agents do like execute tests that you could run into 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.
¶52Let'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 Inkoo editor a side-by-side markdown viewer.
¶53In the app right now, there's no actual markdown render. 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, togglable.
¶54And then 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 us doing a little bit of research, understand the system, AWS DLC. There's a frontier config we'll look at in just a second.
¶55Confirm 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.
¶56Shout 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.
¶57Does 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 cuz I think it's still a notch above and I've seen all the benchmarks.
¶58I know that the benchmarks are saying Opus 5 beats Fable. It's just what I'm feeling with my benchmarks and my execution. 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.
¶59You 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? 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.
¶60I'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 do some typing when I'm writing out my prompts inside of VS Code. So all of 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?
¶61Your code is always validating what just happened. It's always doing the deterministic things and the code actually controls the entire workflow. If you've taken Tactical Agent Coding, this is going to look very familiar to you. We have an ADWS 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.
¶62We 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 it with agents to build this out. But, you can see here we have phases.
¶63So, we're using the width 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.
¶64We have our plan. We have the commit plan, build, test. If something goes wrong, fix. Something goes wrong, review, revise. Again, if something goes wrong, document and our commit docs.
¶65So, 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 ahead and just get rid of this.
¶66Search, 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 agent to coding tool. If you go into AGW modules, I am running the pie coding agent. I've got it all configured here.
¶67And at the end, it's just going to run a pie 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.
¶68Always the same thing. If you match 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 Chem E K3 through fireworks, thinking high, nice purpose. We have our prompt engineering section. So, the system and user prompt.
¶69And then we have the harness engineering. On the channel, we've been breaking down, looking at different types of pie coding agent, custom agent harnesses. We've been building them and we've been sharing them. Mostly in public, some private or tactical agent to coding and agenda 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.
¶70So, this pattern repeats. Here's the builder. Same thing. Specify the tools, specify the prompts, specify how your agent is going to operate. Specialize it.
¶71We'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? So, you can see here, I've added sub-agent 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 sub-agents. Just one simple example of how you can build out and specialize the agent harness that your individual agent executes.
¶72The 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?
¶73So, 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 agents call, and if we search our phase here, it should be a class that we can look at here.
¶74It's going to just do validation for us, and then it boils down into an agent run call. So, if you 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.
¶75And 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 overfix it on the code. Just wanted to kind of share that. What we're doing here is really simple. We're staying in distribution.
¶76What 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.
¶77It's just YAML. It's just agents. And it's just a skill. Let's go and check on our workflow. There we go.
¶78All finished. Here's that like 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.
¶79We 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.
¶80It'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.
¶81It'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.
¶82Of course, you're going to want a 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.
¶83This 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.
¶84So, 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.
¶85So, then we 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.
¶86We'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 runs. This is the art and science of agentic engineering.
¶87It's not just about the one thing you're doing right now. It's about the hundredth time. It's about the thousandth time, and it's about scaling your compute to scale your impact in a way that is high leveraged, in a way that gives you flexibility, optionality, extensibility. And so, that's the core idea here. It's super simple.
¶88Literally called the super simple software factory. For context, I needed to kind of rebuild a reusable system for building agent available workflows for my work coming up here for the next phase of agentic engineering. It's very, very clear that there's a new cohort of engineers that are just building these now. It's stacking up code plus agents, and then when you need to human in the loop, there's many next directions to take that. Maybe that's a great place for us to go next.
¶89Like, where does this go from here? This system was designed to be fully customizable at the atomic level. Let's first validate that that feature was built out. Let's go ahead and refresh this. Let me go and get that split view.
¶90There's our preview. You can see there's that line there. Let me try an underscore here. Okay, very good. Let's try a bullet point.
¶91Low. Another bullet. Great. Let's try a list. Here's a list item.
¶92Great. Let's try a header. H2 item. Very good. You can see that this is working pretty expected out of these models.
¶93You can go into full preview mode and just view it here. Edit, split, so on and so forth. That's working very well. Again, SDLC kind of built this out, validated. These models are more than good enough to prompt this.
¶94In fact, this is something, again, you probably could have just thrown in a single agent and got the work done. I fully acknowledge that. I know a lot of engineers watching this is just going to be like, at what scale do you need something like this? This probably isn't the scale. We're getting close, but this will absolutely save you time at some point.
¶95Cuz at some point your system will get so large, so complex, that validation will be the only way forward. And whether you hand that to an agent, it's going to be more expensive across some dimension, likely time or cost, you will pay that cost. Meanwhile, myself and other engineers are going to be scaling the compute to scale their impact in a high leverage way by combining engineers, agents, and code, specifically code plus agents. I can already see the comments >> [laughter] >> in the comment section. Please think a little further than that.
¶96Think about scale. Think about production. Think about standards. Think about the thousandth run, not the first, not the tenth. So, you know, like, where can we take this system next?
¶97What comes next in a system like this? So, this super simple software factory is designed to be an atomic tool. Everything is composable, and I've taught an agent exactly how to operate this. So, how is this tool so extensible and reusable? So, Ducklog skills SSF.
¶98What I've actually here is a skill that allows an agent to operate this system. And what I've built here is a skill that allows this software factory to be built into new code bases. There's going to be a link in the description. You can clone this code base, and and then you can run the {slash} install command. And so, {slash} install is going to run this workflow, where the agent is actually going to copy everything into the code base.
¶99So, this is a fully reusable system. It's designed to be deployed across your code bases. You know, a lot of stuff I bring to the channel and share on the channel, I need myself. I need a reusable, extensible, customizable AI developer workflow system that allows me to build software factories. So, I built it.
¶100I have and will invest a lot of time into this specific tooling because it has the properties that I mentioned, observable, customizable, reusable. Out of the box, it gives you what you need, and then you can see all the cookbook recipes here. How I like to design my skills is there's a central idea, super simple software factory, deploy and operate repeatable agents plus code in any code base. So, that's the kind of core idea. And then the cookbook is the kind of lazy loaded actions, the incrementally adoptable contexts that the agent can look at to execute, right?
¶101So, we have this table here, we can go ahead and go into render view, and you can see the requests routing. So, the requests set up the factory in a new repo, create an ADW, modify an ADW, create the config, set up a new agent roster, so on and so forth, right? I've taught an agent how to operate the super simple software factory. And this is agentic access, one of the five key pillars of agentic engineering. You are moving too slowly if you are doing pretty much anything by hand unless you're building the system that builds a system.
¶102That's exactly what I've done here. That meta concept is going to reign true throughout the age of agents. If you're doing something you can teach your agents to do, why aren't you? This system here is a great example of that, super customizable. Of course, it's got a bunch of templates in here.
¶103It uses all this to create that first version inside your code base, and then of course, after that, the whole goal is that you should customize it to make it your own. The tests I have set up here are not the tests you need. The plan quality is not the plan quality you need, so on and so forth. It's designed to be a customizable. It's atomic.
¶104Software factories give you more leverage on your prompt. How well is based on the effort, time, and investment you put into your AI developer workflows, which make up your software factory. 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?
¶105This 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.
¶106Deploy 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.
¶107Roll 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.
¶108Those 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.
¶109We'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 branding 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.
¶110Vibe 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.
¶111You're going to scale far beyond AI coding and Vibe coding with advanced agentic engineering. So powerful, your code base 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.
¶112But 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.
¶113If 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.
¶114We 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.