Assessment note: [[2026-08-31-indy-dev-dan-agentic-operating-level]].
What's up engineers? Indie Dev Dan here. The best engineers aren't the best because they work harder or longer than you or I. They're the best because they focus on high leverage activities when it's time to scale their impact and they slow down and focus on the details when they matter most. When you or I are performing like trash, sometimes it's a skill issue, but often times it's because we're not focused on the right thing. There's a powerful framework I've been developing over my 15 plus year engineering career that's helped me progress very quickly in the age of agents that I want to share with you today. It's a powerful way to engineer because it centers your work around your most [music] important resources, time, focus, and attention. In the age of AI, where we spend [music] our time as engineers has changed. And I'm not talking about prop context or harness engineering. [music] I'm talking about the level you operate on to produce valuable engineering outputs with your agents. Allow [music] me to ask you one important question to introduce this framework. What is your agentic
[00:01:01] operating level? From lines of code all the way up to the software factory. Let's define what the agentic operating level is. It looks like this. The agentic operating level forces you and I to answer the question, where is our attention being applied? What are we focused on? So, first off, I'm talking about you and your agent. You are operating your agent and your agents are looking at a specific level of operating in your system. At the very top here, we have the software factory where there is maximum system leverage. At the very bottom, you are in full control. The big idea here we're going to break down is that it's not about any specific one of these levels and it's not just about moving up because sometimes moving down is going to be more valuable based on your use case, based on the problems you're trying to solve. The agentic operating level is where you and your agent focus your time and attention to
[00:02:00] generate valuable software outputs. So, as you're looking at these operating levels, take note of where you spend the most time. Very likely it's the planning. very likely it's your agent. It's the application level and then maybe you drop down to the file. Keep that in mind because we're going to answer some really really important questions using the agentic operating level as our guiding framework. Here's the road map. We're going to talk about the pros and cons of each agentic operating level. We'll talk when to select leverage versus control. As you may have noticed, as you move up, you gain leverage. As you move down, you gain control. We'll break down the average operating level for every engineer. Then we'll break down why domain expertise matters. We'll talk about how to build domain expertise. So, a lot of my vibe coders, number five is going to be really important for you. And we'll talk about what level you should operate at. This applies to all fields, all roles. But of course, my channel is about and will always be for software engineers, specifically that mid to senior plus [music] level engineer building valuable software shipping to production.
[00:03:02] Let's break down each level and what you get at each level. Okay, starting with the foundations. So this is where us engineers used to spend all of our time writing lines of code all the way up to the class. The big thing you get here is direct control. Software is just individual lines of code. Of course, we can go a little bit lower than that, but it's not relevant for this. We start at the line. We start at the block. We move to functions, types, and then we have classes. You can get a lot of information by just looking at the class, by dialing into the type, by looking at the function, function definition, arguments, return type, and then the block of code you're looking at, and then the individual lines. Remember, we're always talking about you plus your agent. I'm not saying go in and write the line of code yourself. It's always you plus your agent. So, if you're operating at this level and you're actually spending your attention and time and focus on lines, blocks, functions, types, and classes, you will have the most control over your system. as we'll discuss there is a cost to [music] that.
[00:04:03] So at this level we're looking at code structure. So this is how your specific codebase is organized. You might reference file names, modules, and directories here when building and communicating with your agents. For instance, if you're building a new feature, you might specify how you want the files to be organized. And you might specify the names of files. You might reference the name of files as you're working. Here we have a little bit more leverage. But notice we're losing control. We're losing granularity because our agent is handling the lower level details. What next? Data and execution. This is where things start to get very abstract. When you're operating at this level, you're focused on your database tables and your individual databases. So, not just production, staging, dev, the variety of different databases you might have for your product. And that all goes under these two levels. The database and the database tables are the contracts you and your agents are building for the rest of your system, for all the
[00:05:00] modules, for all the code, for all the individual lines. So, we've abstracted a lot. And then we get into two really interesting levels, scripts and CLIs. This is how you control your system. Control it at the engineering level where you can move very quickly. You can run very specific lines of code. You can build reusable pathways for you and your agents. And then of course reusable scripts that go on top of it. So notice once again as we move up we get more leverage. We're doing lots of stuff here custom amount of things. We're specifying very important structures for the lifetime of the application and products we're building. But also we're losing control. We're not even looking at the file at the directory at the lines of code. And this trend continues. Let's go up another level. Delivery and intent. Now, a lot of engineers, probably bells are going off in your head right here. Some smart engineers are documenting their work for their agents. But we hit a really special level here. We hit the vibe coding level. Level 13 in delivery and intent. Many non-engineers focus on
[00:06:00] just this level. And notice how much control we've lost by the application level. Notice how much control we have lost. Okay. Now, this is a really important differentiating point that we've hit. If you can only look at the application and you can't look above and you can't look below, you'll be very very limited in the types of results you can create in the scale of impact you can have and when things go wrong in your ability to resolve those issues. Okay, lots of limitations here. But we can move above the application level and get into the repository level. So engineers operating at the repository level might do something really powerful like have an apps directory which contain many applications. This is a pattern I really like to use because a product isn't just one app. A product isn't just one repository. It could be many. But at this level, you and your agent are operating at a very, very high level of abstraction. Now, let's talk about intent, documentation, and planning. Planning in particular is really, really powerful place for any engineer to sit right now because you can look at the entire system below you
[00:07:00] and some of the system above you and you can detail what you want to have happen next, what has happened in the past. You can detail lots of different things. The plan level is really, really important. But again, notice all the information that gets lost here. You can type in natural language and really not have a good sense of every level below it. For instance, you could not open the application and make a change to the application. Seems like a really, really dumb thing to do. Trust me, it is dumb, but it's also happening. And then there's the even higher level above the plan. There's documentation. So, just concretely recording what's happened. And this is very, very powerful for obvious reasons. Many engineers would say that the code should be the documentation. I disagree. I think that's a very low level of operating. It has its pros. It also has its cons. We'll get to those in a minute. At the very highest level, we're at the agentic system level. At this level, we're talking about your agent. We're talking about your AI developer workflows, your agents plus code to outperform either alone. And then, of course, the software factory. one of the
[00:08:00] highest levels of leverage an engineer can achieve right now. If you are operating a software factory, you're moving probably an order of magnitude faster and higher than everyone else. And I would say the same thing with the AI developer workflow since it takes many developer workflows to make a software factory. If you're just running a plan, build, test, deliver workflow, that's not a software factory. That's just one AI developer workflow. We really dug into the AI developer workflow in our forget loop engineering video. That one went super viral. That was a really important video cuz we pushed away from the concept of loop engineering and really broke it down to what it really is and the real value you can get as an engineer. What you want is not a loop. You want to be able to build arbitrary AI developer workflows for your engineering work and for your products. Anyway, here at the highest levels though, and you'll notice we have pretty much lost control over everything. Looking at the final product gives you very little detailed information over how you can control it. Same thing with working on agents inside your products. Very similar idea with the AI developer workflow. And this really hits on a theme. If you want more
[00:09:02] leverage and you want to move up these high levels, you must first go down. You must understand the system. You cannot scale something you do not understand. So these are roughly the five levels of where you can focus your time and attention with your agents. Now, this brings us to a really important idea. Higher is not better. Just gaining leverage without understanding isn't going to work. Okay, let me just say that like point blank. moving just upward here, focusing all your time and attention on building software factories or AI developer workflows when you have no idea what your application does, what your product vision is, what the database tables are, how things are organized as types, and what the structure is here is going to end you up in a really, really bad place. I've been working on this framework for a while to really help myself and help other engineers focus on where they should be spending their time, attention, and focus with their agents because it's not very clear now. It is not clear in the age of agents where on this level should you spend your time. That's what we're going to concretely answer here. And we answer it by understanding that it's not
[00:10:01] just about moving up. If you've been with the channel, if you're a subscriber, if you show up every Monday, you know that we hyperfixate on this top level, but it's also because I'm communicating information with my intended audience, which is software engineers. You guys are already at these levels. You understand what a line of code looks like. you know about conditions, blocks, loops, data structures, algorithms, database table structures, SQL, NoSQL, trade-offs, designing architecture, load balancers, like all this air quotes boring engineering stuff that makes products run, you guys understand that. At least, you know, most of my audience does. Now, higher is not better. But once you understand the low level of your domain of your engineering work, you definitely want to be moving up because why would you keep doing work your agents can do on your behalf? The answer is you shouldn't. I know many engineers are. That's part of what I'm trying to help engineers push through every single week here. Let's just talk about this. Higher is not better. What we're really looking for here is a range of capability. This is what determines how far you can go, how big you can go, how successful you can be with your ability to engineer
[00:11:01] valuable systems. You want to operate in the right range at the right time. For example, right, you've seen this kind of going on the side here. At the very lowest level, you are just a vibe coder. All you can do is look at the application. That's the only output artifact you can inspect to understand what's going on. At just one level up from that, you might be a knowledge worker, right? Which gives you the ability to understand documentation plan, maybe the product. At the next level, you might be something like a data analyst. And the data analyst has even more ability to understand tables. Maybe they run a couple scripts. They understand more of the software level. So, they have a wider understanding. They have more capability. And then, of course, software engineer really opens things up. You get all the code primitives, all the code structure, and you get to move up even further. Some of the best engineers, the mid senior, principal plus level, they think a lot about the product, not just all the lower level stuff. I remember a big jump in my career, maybe 2018, 2019 or something like that, when I started planning all my work. I started documenting everything I've done and I started thinking through the lens of the product and the users using the product.
[00:12:02] Not even anyone on my team, right? I'm not thinking about the PM. I'm not thinking about my boss, my lead. I'm just thinking about the product itself. And this is where you make a big leap as engineers. Forget all the agents, just pure software engineering. This is where you make a big leap to like senior and even principal level if you do this right. You're thinking about the product. You're planning. You're documenting. And you're also thinking more. It's not just about this application or this repo. It's about more than that. And again, there's more leverage the higher you move up here. Yeah. To be clear, you can rearrange these a little bit. You can fill in additional items. I'm focusing on the big hitters here. For instance, you know, product maybe deserves to be lowered. That's fine. It's the concept that matters. So, the big idea here is higher is not always better. You do need to move down when it's time to move down and gain more control over the system. And you want to be moving up once you understand what you're doing, once it's time to scale, once it's time to add agents, once it's time to really become an agentic engineer. And that's that last true level. The agent plus level is
[00:13:00] where you really start agentic engineering. That's where software engineering really expands. Agentic engineering is software engineering with autonomous software that can take actions on your behalf. I'll link a description to a great blog post where I really break down what is agentic engineering, a definitive answer that really cuts through all the noise. So, let's keep moving. So, higher is not better, but what does higher give you? Moving up gives you more leverage and more speed, but it doesn't come for free. Any engineer with their head on their shoulder has noticed something crazy happening. We are losing understanding of the lower levels and we have less control than ever over what's actually going on. This is just the journey of technology. It gives and it takes. All technology does this. The question is are you willing to make the trade. This is not a question of if or when this stuff happens. It's what trade-off should you make right now. Moving up gives you leverage and speed. Very very powerful. But we are losing direct understanding and direct control. Now, this might look very familiar to
[00:14:00] you if you're in a lead position, if you're a manager, if you're, you know, CTO, any staff level. As you have more impact, you're put into roles and into positions where you directly have less control over what's happening and less understanding. But what do you get? You get leverage. People are working for you. People are working with you. You have a team. This makes you faster. You can do things that would not be possible if it was just you. It's the same thing as we move up the stack of leverage in the age of agents, right? It's the same thing when you take your engineering expertise and your agentic system, whatever agent harness you're running, whatever models you're running. As you move up, you gain leverage and speed and you lose direct control and understanding. Now, what happens when you move down? It's the inverse. When you move down, you gain control. You gain understanding. It's the same thing flipped. But what do you lose here? It's very important to just address trade-offs. Software engineering is trade-offs. It's about building the best system at the right price, the right speed, the right performance, and then
[00:15:00] making trades for what you're going to give up. You can't focus on everything. Your attention, your time, your resources. They're all limited. You have to make sacrifices here. So, what do you lose as you move down this scale here? And again, I'm still talking about you and your agents operating on this lower level. I am absolutely not saying as you do stuff by hand, that time is over. It's done. Final warning, any engineer writing lines of code by hand, you're cooked. You cannot compete. And I'll leave a little room, and I'm talking less than a thousandth of a percentage room for engineers doing very, very, very high precise work. And I'm talking about updating C and assembly statements to get micro optimizations for their highfrequency algorithmic trading system. Really, really, really tight stuff like that. But even that is like I'll bet you an agent could come in and multiply what you can do. So anyway, quick aside there, but I'm talking about you and your agent operating up and down the scale. More control, less speed. You have to pay more attention. they have to pay more time. Okay? So, you really want to be careful when you move up and down these scales. Now, let's talk about
[00:16:00] where most engineers are and what I recommend. So, as you can imagine, the most common levels really comes out of laziness, right? Engineers are getting lazy. Everyone is getting lazy. There's the floor, which I like to refer to as vibe coding. And then there's the ceiling, which is agentic engineering. Really pushing what you can do, treating this like a new craft, a new skill. Because guess what? Agentic engineering is a new craft. It is a new skill. I'm trying to paint a very very clear picture for you. This is traditional engineering include product down there of course and then you get to this higher level and I'm really compressing a lot of these levels as you know if you're a fan of the channel if you watch this channel there are many other subp parts that go under agent a developer workflow software factory I'm glossing over that a little bit but you get the idea there are many many many skills that you must learn now and of course prompt context harness engineering are the big easy ones to point to a lot of people are fixated on the agent very good people are ultra ultra fixated on the plan because what is a plan it's a prompt scale scaled up. It's a big prompt. So, being able to write these and hand it off to your increasingly powerful agents with their increasingly
[00:17:00] powerful language models is a very important skill. So, a lot of engineers realize this and they dive into that the application. A lot of engineers and vibe coders and just everyone all they do now is look at the application. Is it what they wanted? Nope. They reprompt their agent. Okay? So, they're very levered on the application level. And then some engineers are, you know, looking at the CLI, making sure that their agent has the right tools. A lot of this comes in the form of skills. And then of course the file level. So if you're really paying it, it's funny to call this really paying attention now, but oftent times you'll be working on individual files with your agents, tweaking, tuning things. Guess what I recommend? I recommend you do a bit more than that. So here's my recommendation. This is obvious at the top here. Gain leverage in systems you understand. And we'll talk about when to move up and why you should be moving up in a moment here. And also why you should be moving down. You understand the main theme here though. You want to move down when you need direct control. You want to move up when you need more system leverage. So, a couple really important ones I recommend you spend more time doing writing documentation with and for your agents, but also for you. The thing I do
[00:18:01] now is my plans, my documentation. They're all mediarich now. So, I generate images, I generate SVGs. I make it easy for me and my agents and my teams to understand what has been done and what has been done quickly. And this is, you know, again, we're talking about control and speed. If you really want to understand what's been done, you know where to go. Every engineer knows where to go. The code is the law. The code is the source of truth. It's the only thing that matters in the end. But that's slow and it doesn't matter as much as it used to because agents can do a lot of this stuff down here. So, how can we speed that up? We document. We have our agent summarize, compress, smash the information together and tell us in concise images, in audio files, in short videos, right? You can really do a lot here at the documentation level. You know, about planning, nothing new. Application level, nothing new. CLI level, nothing new. The database table level is a really really important place to spend time. If you're doing short-term prototype projects, obviously it doesn't matter, but any midl long-term project. I don't know how you're going to get by in trusting your agent and deploying your users's
[00:19:02] personally identifiable information and resources if you're not paying attention to the database table level, designing tables, understanding what your agent thinks the table structure should be. Again, a lot of this stuff feels stupid to say if you've been engineering for 5, 10, 15 plus years, because a lot of the product is the data, and that's never been more true than now. The valuable thing you're building now in your products is your relationship with your users. What form does that take? Data. Moving down, we have the directory structure and the file level. Probably the most controversial levels to go down into. I guess alongside type and function, many engineers just have no idea what the types are in their codebase. They don't even care about what functions are getting generated, why, when, how. The more control you need over your system, the lower you should go here. At the very least, you should have an understanding of what things look like. Vibe coding is fine unless you're building real production software you want to be profitable over the long term. Then I would ban vibe coding. Knowing the directory structure and the files inside of your codebase, it gives you a level of understanding without going too low. But of course, I
[00:20:01] recommend you understand the types because the types tell a story about the data that flows throughout your product. And then function level is for sure the bottom level that I would go every once in a while you should dig into the actual lines, but that's very very rare. And again, this costs time. Coming down here, gaining control costs time. When should you select leverage or control? We've been building up to this. So, when should you select leverage or control? Remember, everything we're doing here is a range. Okay? And there are multiple ranges. If you switch domains, right? If you're not a baker, if you're building some baking automation software, robots are going to come in and bake. Your range is not large and you think you can just jump in here and build a software factory right away. You're kidding yourself. You're going to want expertise. You're going to want to understand your domain. So, this is not only about raw software engineering skills and raw agentic engineering skills. It's also about what domain you're operating in. You want to move up. You want to choose leverage when you understand the domain because
[00:21:01] then you know when things are right and when things are wrong. You have expertise. When the work is familiar and repeated, this is a very obvious sign to automate. Three makes a pattern. Three should be your red blinking light. I should automate this. I should throw agents and code at this. I should build an AI developer workflow. So on and so forth. Start with the skill. Start super simple. Build a reusable agent. Then move it to ADW once you want to save money and scale it. When the output of what you're doing has many artifacts, there are many sequences of steps. many things being generated. Choose leverage when the evidence supports automation. As I mentioned, if you do something more than three times, you should be heavily questioning your actions because you're likely wasting time. And of course, you cannot move up if you do not have raw agentic engineering skill. That last block is completely off limits to you if you don't understand prompt context, harness engineering, multi-agent orchestration, when to use what model at the right time at the right price, how to build your own harness, how to combine agents and code to outperform either alone. There's just a bunch of stuff here. How to fuse agents like we talked about last week with the V2
[00:22:00] fusion harness. I'll link that in the description if you're interested. Right? You need raw skill, not just domain skill, not just engineering skill, but agentic engineering skill to move up. We talk about that on this channel all the time. If you're interested, you know what to do. Like, subscribe, comment, all that good stuff. When do you move down? When do you choose control? Because again, it's not just about moving up. You need to go up and down when the problem and solution calls for it. Okay? This is a range. This is not a single direction. Reality is too complex for these simple rules. When you have a little domain understanding, you got to go down. It's just a fact. If you don't know what your agents are doing, how will you know if it's right? So, if you have a little domain understanding, you can't prove something to be true. This is a massive problem that happens at the lowest levels. Me right now trying to, I don't know, build a little tiny physical hardware robot. I have no domain expertise there. Okay? So, I need to go all the way down to the low level. Look at the line of code that helps me do that. The line of code that helps me like turn the light on on the little robot or whatever like hardware engineering starting hello world problem
[00:23:01] there is. You get the idea. When the system is unfamiliar, this is like a perfect thing for when you're starting at a new company, looking at a new codebase, starting a new project, you should not move your agentic operating level up when you don't know what's even below you. Same kind of idea. Little domain understanding, little understanding of your system. If you're in a high-risk, high impact domain, if you're launching rockets into space, you better not be vibe coding. If you're architecting housing structures that people are going to live in, if you're doing biomed, it's high-risisk and high impact that make a serious case to go down to get control. It sounds obvious to say, but you'd be surprised if the debugging evidence is weak. If you're looking at some of the traces your agents are giving you and you're like, "That validation makes zero sense." Like, that does not look like proof of success or failure to me. You got to go down. You have to control it. You must know when things are working and when they're not working. You must have some type of fitness function, some sign of success or failure. That's what expertise is most of the time. It's you know with these inputs what outputs will
[00:24:00] be generated from some system from some function X. If you cannot delineate good outcomes and bad outcomes, you got to go down choose control. Understand what's going on. Go down to the class. Go down to the types. Understand the database tables. Understand the lines if you have to. if performance or details matter. You probably noticed this, and this is something that is starting to annoy me, too. All the UIs are starting to look the same. Hm. Why do you think that is? Why do all UIs look the same? Cuz everyone's vibes slopping the UIs. They feel like it doesn't matter. It matters. If you're building a new product and you're vibe, if you don't have a strong opinion, if you don't have taste, the details matter. You can see it. Engineers are really smart, but normal people are smart, too. You can tell when something is vibe slopped out. You can just tell. There's a signature that goes along with it. It's like loadbearing. It's like dashes everywhere. You can tell when detail matters, when taste matters, you go in. Obviously, performance is a lot more clear. If you're building a highfrequency trading algorithm and you don't know the line of code that's causing you to slow down that 5 milliseconds, you're cooked. Your competition is going to eat you alive.
[00:25:01] When performance matters, you got to choose control, right? And again, it's you and your agent going down. You and your agent harness, you and your team of agents, you and your multi- aent orchestration team, your fusion harness, right? You're going down together. I just want to make that super clear. And then one really really big one. If the thing you're doing is out of distribution. Now what do I mean by this? Maybe you've heard someone say it's out of distribution for the model. What does that mean? What does that actually look like? But this is the decision-making framework. You want to locate where you're spending your attention and time? And you want to check the constraints like your constraints. Do you understand the domain? Is this high risk, high impact? Does performance in every detail matter? If it does, go down. If you understand the domain, if the work is familiar and repeated, if you have the skills, go up. Apply that leverage. Go hard on your leverage. This is our main focus on the channel, but it's really important for me to like call that out. If you do not know what you're doing, you have to understand it. Why? Because if you don't, there are limits to what you can do. Your success is capped. What do I mean by out of distribution?
[00:26:01] You might have heard that. This is a simple idea of what the model knows versus what it doesn't or what you know that it does not know. So, what does this look like? It looks like this. It's really, really simple. There's a bunch of stuff common LLMs, workhorse LLMs, lightweight LLMs, state-of-the-art models know, and this is called in distribution. This is all the stuff they know. For instance, pretty much every model under the sun up from the workhorse level can build you an API, can design you a Postgress database, can build you a regular crappy UI, and even some nice ones. But then you would get the stuff that's out of distribution. And so this is stuff the model either can't do at all, doesn't know about, or actively punishes. They're actively told in their training not to do this. Don't talk about this. Don't reference this. I don't want to give specific examples here. I'm sure you can think of them. But there are just cases where the agent does stuff you don't want it to do. Out of distribution isn't just what the model doesn't know. It's also things you have to actively fight against that you don't want your model to do. This concept is really important, right? Because if the model doesn't have
[00:27:01] information, if it's doing things wrong, you have to step in. You have to apply your expertise, your engineering expertise and your domain expertise to effectively increase the distribution to effectively increase what your language model can do. That's what you're effectively doing. You're teaching it these new skills. Now, there are many techniques we've talked about many on the channel, right? Classic context engineering in context learning. But then there's advanced techniques like fine-tuning. Again, fusion harness, really important idea. You can combine models, get multiple opinions from your models, get multiple plans, have your agents collaborate to kind of fill in the gaps within each other. But that's the idea here. You need to go down the stack as the model has no idea what you're talking about. It's pretty simple. Don't collaborate with someone who doesn't know what you're trying to do. And if you are going to collaborate with them, if you need to for some reason or if they're helpful in other tangential areas, you're going to have to teach them. You're going to need to apply your expertise to help them fill in their out of distribution knowledge. So that brings to the question like, how do you build expertise? for my vibe coders, for anyone that wants to like level up their skills. And for even software engineers that want to increase
[00:28:01] what they can do in other domains, it's really, really simple. You have to build it. You need to get the experience. Some stuff I say on the channel, I know it's like, duh. Like, that's so boring, but someone has to say it. Some things are just so blatantly obvious, but you have to just admit it. If you want to get good at something, you got to do it all the way from the atoms. And the atoms of software engineering is lines. It's blocks. It's functions. It's types. It's classes. It's the file. It's the module. You get the point, right? You got to move through it. You have to learn it. You cannot scale something up that you do not understand. Agentic engineering is pointless if you do not understand what you are agentic engineering at some level. Now, the depth you need to go to build the result you're looking for depends on all the things we just talked about. What's your expertise level? How risky is this? How much does your agent know? You could debate all you want about how low you need to go to get the result you're looking for. There is no replacement for raw expertise. There just isn't. And every senior engineer, mid-level engineers, even engineers, you know, newbies that have been working,
[00:29:00] you know, building software for one, two, three, four, five years, you understand this. You understand that there is no replacement for how you got this good. There isn't. It's just raw time. You have to bang your head against the computer or whatever domain you're operating in. And that means going down to the low levels. Really scary stuff, right? [laughter] You got to work for it. And then, and only then, can you really get to these high levels? Can you point you and your agents at these high levels and properly steer them at extreme leverage and extreme speed? And my god, like the breakthroughs that are happening right now with these models and specifically, I mean the breakthroughs that are happening with engineers using these models at scale building out these agendic systems, it's going to be absurd. Absolutely absurd what you can do with this technology. The gap from using one agent to multiple agents is huge. The gap from using one model to multiple models in your prompts is also huge. going from just fixating on your agents to using agents and code together for your product work and your engineering work. It's like exponential and then the software factory is on a whole another planet and that gives us a
[00:30:01] quick opportunity here to talk about what's coming next. I'm really excited to announce something. There are levels above the software factory and this is where things get really really exciting for me and engineers on the edge who are maximizing what they can do with agents every single day. So we have the agent. We're all used to this. This is the industry standard right now. Everyone's using an agent. If you're just using an agent, you're getting average results. That's the state-of-the-art right now. But then there's the ADW, the AI developer workflow. Again, check out the forget loop engineering video. Agentic engineering is about this. I'll link that in the description. The ADW offers you a whole another level of power because it lets you build against the software developer life cycle and any developer workflow you, the engineer, used to walk through by hand yourself, and you multiply it with agents. Hence the A, right? AI developer workflow. It's not the loop you're after. It's a repeatable workflow that allows you to step through work at light speed with code and agents using the right one at the right time. So what happens when you start composing those? You end up with something like a software factory. And software factory is not just the SDLC.
[00:31:00] It's the hot fix. It's the feature prototype. It's the ideation. It's the launch to staging environment so I can test it. It's the let's try permutation, right? The support ticket that just came in. It's the system that starts working without you. These two levels really get into that. But then there are levels beyond. And so quick announcement, I am actively working on the phase 3 successor to tactical agent coding. If you haven't checked out tactical agentic coding, that's going to be available to you. Link in the description. Quick simple pitch on that. This is my take on how to scale far beyond a coding and vibe coding with aentic engineering. So powerful your codebase starts running itself. And just to give it away to give you a little teaser, if you haven't taken this, thousands of engineers, engineers from companies you know that you've heard of, they're all in here. They've all gotten massive value. This is for engineers that ship to production. This targets the top 20% of engineers. If you know that you are the bottleneck, it's not the models. It's not the tools. It's not the agents anymore. And if you're shipping to production, check this out. This is not for beginners. Again, this is for the top 20% of engineers who are ready to
[00:32:00] push their engineering abilities to the next next level. This is the phase 2 course and it's been ultra ultra successful. It's been out for almost a full year now. And yes, before you, you know, reach out to me and ask if it's still relevant, it's still ultra relevant. And why is that? is because I don't focus on models or tools or frameworks. I focus on ideas. I focus on hard tactics of agentic coding that bleed right into agentic engineering. What do I mean by that? What are concrete ideas? Let me be super clear. Build the system that builds the system. This is a belief mindset shift around where you should spend your time. What do you know? This looks very similar to what we've been talking about. The recommended levels here, you're moving up, you're gaining more leverage, right? What does that look like in practice? You stop working on the application and you focus on the agenda layer that does it on your behalf. You stop coding. You even move from plans and you start templating. Very advanced idea here that will take you to the next level. And we're scaling the core for the foundation of what makes an agent up. Context model prompt tools. So, as you can see here, I've talked about this several times on the channel. Now, this is probably one of the last times I'm
[00:33:00] going to pitch it before we move on to phase three. Okay, so this is phase two. We're moving right into phase three. I'm actively working on the next product. Little Easter egg for everyone that made it to the end. If you are a tactical agent decoding member, you will receive a deal on what's coming next. So that's the announcement I wanted to make. That is an active development. Things are going really, really well there. The ideas are once again next generation. I'm really, really excited to share that with you. Stay tuned. Stay locked into the channel to understand what's coming next because guess where we go from here. Yes, the software factory is key. Yes, ADWs are key, which again, tactical agenda coding is all about the ADWs. But we move beyond that. We move into the software factory and then levels beyond. I'll just tease a couple big ideas here that you've probably seen flying around the internet. The dark factory and RSI. Now, RSI is pretty much non-existent state-of-the-art. You know, no one's doing this yet. The leaders are trying. By the leaders, I mean the people inside the big AI labs everyone talks about all the time. OpenAI, anthropic being the two most important prominent ones. But these are the next two tangible levels
[00:34:00] you can get to right now. Again, just like stacking up your expertise and learning how to build and leverage agents. You don't just jump to RSI. You don't just jump to the dark factory. You don't just jump to the software factory. You start these low levels. You understand what's going on and then you scale them and combine them. So there are levels beyond. I want to paint you a picture of where this is all going as I see it on the field building products every single day. Our mission here on the channel and through agenticengineer.com. We're going to build living software that runs while we sleep. If you made it this far in the video, I don't know what you're waiting for. Join the journey. subscribe and check out Tactical Agent Coding before the next phase comes, before the next advantage, the next leap is available. But also, if you don't want to do that, just keep tuning in with the channel. My goal every single week is to bring you useful information right here for free. So, if you value that, again, show your appreciation. Like, subscribe, comment, all that stuff. So, what is your agentic operating level? By now, you should have a much better idea of where you sit on this. Where do you and your agents spend the most time? What artifacts are you generating? And then, where do you want to shift to? Do you need to go lower level? Have you been trying to stay too
[00:35:01] high level when you need more detail to understand what's going on so that you can then make the leap upward? Like be honest with yourself. Look for improvement. You got to stop focusing on how you look and how you rank among everyone else. And you got to focus on getting done. Getting done, learning and evolving. So sometimes in some domains, in some situations, some code bases that means going down. Other times it means going up. If you know what you're doing, if you have the expertise, move up. Understand a developer workflows. master prompt context harness engineering. So you have your agent level down. Grab yourself an agent SDK. Grab a closed source agent harness and an open source one. Use models together. Combine your compute. Don't select your compute. Tons and tons of other ideas we discuss on the channel all the time at this agent level which then helps you compose up into your ADWs and up into your software factories where you start getting this weirdly living like software that operates for you while you're present and while you're not. What is your agentic operating level? Big final takeaway. Leverage without control [music] and understanding is meaningless. Move up when you need leverage and speed. Move
[00:36:01] down when you need control and understanding. Choose the right level for the problem in front of you. Retain the ability to move both ways up and down. That is how you move through your agentic operating levels. You're looking for a range and you're looking to be dynamic, moving up and down the range when the time calls for it. Move up when you need leverage and speed. Move down when you need control and understanding. Links will be in the description for you. You know where to find me every single Monday. Stay focused and keep building.