YT YouTube2Text

YouTube2Text → Transcripts → Agentic Engineering Operating Level: WHERE to FOCUS your AGENTS?

Agentic Engineering Operating Level: WHERE to FOCUS your AGENTS? — Transcript

by IndyDevDan · 7,854 words · 1,169 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

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

About this transcript

This page contains the full transcript of Agentic Engineering Operating Level: WHERE to FOCUS your AGENTS? by IndyDevDan, generated from the public captions YouTube serves with the video. The transcript has 7,854 words across 1,169 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to choose a caption track available on the video.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, caption language selection, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.