Agentic Engineering Operating Level: WHERE to FOCUS your AGENTS?

Channel: IndyDevDan
Published: 2026-08-31
URL: https://www.youtube.com/watch?v=rPWCYB62wvI

Every engineer is racing UP the stack right now. More leverage, bigger agents, software factories. Here's what engineers are missing: higher is NOT always better, and the engineer who can only operate at the top is just as stuck as the one who can only operate at the bottom.

Resources:

Master Phase 2 Agentic Coding BEFORE Phase 3: https://agenticengineer.com/tactical-agentic-coding?y=rPWCYB62wvI
Understand The SOFTWARE FACTORY: https://youtu.be/haUfb1ievTE

Transcript

What's up engineers? IndieDevDan 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 important resources, time, focus, and attention. In the age of AI, where we spend our time as engineers has changed. And I'm not talking about prompt context or prompt engineering. I'm talking about the level you operate on to produce valuable engineering outputs with your agents.

Allow me to ask you one important question to introduce this framework. What is your agentic operating level? From lines of code all the way up to the software factory.

Defining the Agentic Operating Level

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 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.

Roadmap

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. 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 level engineer building valuable software, shipping to production.

Breaking Down Each Level

Foundations: Lines of Code to Classes

Starting with the foundations. 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 that.

Code Structure: Files and Modules

At this level, we're looking at code structure. This is how your specific code base 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.

Data and Execution: Databases and Tables

What next? Data and execution. This is where things start to get very abstract. When you're operating at this level, you're focusing 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 modules, for all the code, for all the individual lines. So, we've abstracted a lot.

Scripts and CLIs

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.

Delivery and Intent: The Application Level

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 just this level. And notice how much control we've lost by the application level.

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 will be very, very limited in the types of results you can create and the scale of impact you can have and when things go wrong and your ability to resolve those issues. Okay, lots of limitations here.

Repository Level and Intent

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 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.

The Highest Levels: Agentic Systems and Software Factory

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 highest levels of leverage an engineer can achieve right now. If you're operating a software factory, you're moving probably a 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.

Here are 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 detail 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 leverage, and you want to move at these high levels, you must first go down. You must understand the system. You cannot scale something you do not understand.

Key Insight: Higher is Not Better

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 with 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 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 hyper fixate 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, tradeoffs, 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.

Range of Capability

Let's just talk about this. Higher is not better, but 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 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 at 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, 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, 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.

Conclusion

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 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.

(capture appears truncated)