YT YouTube2Text

YouTube2Text → Transcripts → Роадмап по Агентской разработке в эпоху AI

Роадмап по Агентской разработке в эпоху AI — Transcript

by Артём Шумейко · 4,249 words · 650 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00Most of us start our days the same way
0:02these days. You turn on your computer
0:04in the morning, open Codex or Cloudcode
0:07, and it helps you develop software or
0:09write code. It seems like you've
0:12mastered AI, mastered agents,
0:14understand how it all works, and can
0:16confidently move forward in your career
0:18. But in reality, there are quite a few
0:22pitfalls and pitfalls you can encounter
0:24when using agents and LM. This applies
0:28especially to becoming as proficient as
0:30possible in their use, and it's worth
0:33delving deeper into how to use them.
0:37Today, I'll walk you through a
0:38step-by-step roadmap of what you need
0:40to implement in your development, in
0:42your project, so that, firstly, it's
0:43faster, secondly, it's cheaper, you'll
0:45have plenty of tokens left over, and
0:47you can simply solve more problems—in
0:49other words, optimize your work as much
0:51as possible. My name is Artem. I'm a
0:54senior end-to-end developer. I'm also
0:56currently developing with agents. So,
0:58if you like this topic, be sure to
1:00support the video by liking and
1:01subscribing to the channel. And here we
1:03go. So, let's start with the basics and
1:06gradually work our way up to the most
1:08subtle and advanced options for using
1:09agents. So, the first step of our
1:11roadmap, which most people have
1:13probably already taken, is the
1:14transition from LLM to agent-based
1:16development. That is, you have some
1:19software running on your computer—an
1:21application, for example, Codex, or
1:23you're working with Cloudcode in the
1:25terminal—and it has access to your
1:27computer, allowing it to execute
1:29commands, open files, and modify the
1:31Git repository, so that it's as close
1:33to your code as possible. You don't
1:36have to manually copy-paste something
1:37from the browser and paste it into your
1:39code. This step is quite simple and
1:41straightforward. I would have skipped
1:43it pretty quickly if not for one thing,
1:45and that mostly concerns GPT chat. If
1:47we're talking about Cloudcode, this
1:49doesn't apply to it. But GPT chat does.
1:53If you have fairly large, complex tasks
1:55, such as speech-related or
1:57planning-related, that are somewhat
2:00abstracted from the code, or can easily
2:02be given some context in the browser
2:05version, then it's perfectly possible
2:07to spend tokens in the browser version
2:10on heavy resarch, best-practice
2:12research, planning a complex task, or
2:14decomposing it, and then transfer them
2:17to the agent. Why does this happen?
2:20Simply because we have two sets of
2:22tokens: one for the browser version,
2:24for chat GPT, and one for the agent,
2:27for code, for example. VCLD code
2:29doesn't work this way; the same tokens
2:31will be spent in the browser and on the
2:33computer, but for neural networks,
2:35including chat GPT, it's very
2:36convenient. You can delegate such tasks
2:39to the browser version for thinking.
2:42Okay. Nevertheless, of course, we spend
2:4390 percent of our work in agents, and
2:45we need to understand how to work with
2:47them. So, before we move on to agent
2:50files, instructions, configs, skills,
2:52and hooks, let's just talk. What's the
2:55difference between an agent and a lamka
2:56? Many people might not even understand
2:59. The point is, we still communicate
3:03with the lamka, it still makes
3:06decisions, but the executor is often
3:09our computer. For example, the lamka
3:13understands, "Aha, I need to read these
3:14files." It issues a command to the
3:18agent, and our computer knows it can
3:20run the ls command and see what files
3:23are there, for example, in the
3:25repository in the current folder, or
3:27read or search with grep, for example,
3:29on Linux or Mac, simply by using a
3:31command to search for a certain word in
3:34all files. So, the lamka doesn't do
3:38this; it only receives data from the
3:41agent, what it found on our computer,
3:43and gives it certain commands to make
3:46changes. Well, besides that, of course,
3:49our agent can work with external MS
3:51Lists, external tools, access the
3:53database, and much, much more. And
3:55while the agent has quite a lot of
3:57freedom, it's important to remember
3:59that you always need to give it
4:01constraints. We'll look at the formats
4:04for this a little later, but it's
4:05important to limit it, specify your
4:07project architecture, the stack you're
4:09using, and what boundaries it shouldn't
4:11cross, what it shouldn't do. This is
4:14very important. That is, not only ask
4:16it to define a goal, yes, a definition
4:18of done—what needs to be done, how to
4:20know when a task is complete—but also
4:22prohibit it from certain things. And
4:25it's also important to remember that
4:28agents are very fond of context,
4:30especially if it's running, for example
4:32, like you're developing a product, and
4:35it has 100 tests. If your agent runs
4:38tests after every task, and the tests
4:40generate, say, 10,000 lines of logs,
4:43just to confirm that the tests passed,
4:45then LMKA still loads those 10,000
4:48lines of code. There's a huge number of
4:51tokens there, say, 300,000 tokens. And
4:54then they live in your context and
4:55simply saturate it. You spend more
4:58tokens, or more money, and you work
5:00less efficiently. LMKA simply devours
5:03unnecessary data, analyzes it for some
5:05reason, and thinks everything is fine.
5:07Although, of course, this could be
5:09eliminated, for example. We'll talk
5:10about that a bit later. Okay, let's
5:13move on to configuring the agent,
5:15because this is something that is a
5:16must-have in your project. Moreover,
5:19what are the specifics of files like
5:21agents.mdown or clod.m? Markdown,
5:24they're not universal. Depending on the
5:28project you're working on—a website,
5:30a Telegram bot, a frontend project—
5:33you'll have a different agents.m file.
5:36You need different rules, different
5:38important settings, different launch
5:40methods. So, in this Markdown file,
5:43essentially just a text file, you can
5:45describe everything, and most
5:46importantly, quite concisely, for
5:48example, no more than 100-200 lines.
5:50You don't need to write down or cram
5:51the entire project architecture in
5:52there, how everything works, how
5:53everything is interconnected, or any
5:55diagrams or pictures. No. This file
5:58usually stores basic information about
6:00the project. For example, if it's an
6:02end-to-end project, what kind of
6:04architecture and stack it uses, and
6:05what commands can be used. For example,
6:08this command to launch, this command to
6:11run tests, this command to run the
6:13linter, this command to run a migration
6:15—so it definitely uses them and
6:17doesn't reinvent the wheel every time.
6:21Then, be sure to specify restrictions
6:24on what this agent is not allowed to do
6:27in this project. For example, they're
6:29not allowed to access the product
6:31database, or they're not allowed to
6:33access it and modify data or attempt to
6:34modify data. Obviously, these
6:37restrictions don't guarantee the agent
6:39won't go and delete your product
6:42database. Of course, it's important to
6:45have a good head on your shoulders and
6:47not give them the login and password
6:49for the product database user, or only
6:51give them the username and password so
6:53they can only read the data, even if
6:55they try to modify it and violate the
6:57instructions, so the database simply
6:59refuses them. So, we rely on this file,
7:04but we never trust the agent. We're not
7:09sure they'll always use it. We need to
7:11protect ourselves in this case and
7:13carefully weigh the risks. Also,
7:15something very important that many
7:18forget or don't know is the nested
7:21files agents.m or gemini.md for Gemini
7:24or clot.mD. They all have their own
7:26names. What's the point? For example,
7:30for each directory in my project, I
7:32have a directory associated with tests.
7:35I can have a specific set of rules for
7:38tests, including how they're written,
7:40which directories they're created in,
7:42what exactly we're testing, what
7:44percentage of test coverage we need,
7:46how much we're testing for each
7:48attribute, key, value, and so on. And
7:51this is then written down in each
7:53folder separately. That is, if the code
7:55that the agent or feature that the
7:57agent is developing is writing involves
7:59testing, when it gets to the tests
8:01folder, it will see a file called "
8:03agents.Markdown" there, and it will
8:05understand: "Aha, I need to do this,
8:07this, this." Or if it goes, for example
8:10, to the payments folder and needs to
8:11change something about payments, the
8:13payment system, the connection,
8:15whatever—Cloud Payments, Stripe—it
8:16will have a set of instructions: what
8:18can be done, what can't be done, how
8:20and where to place things so that
8:21nothing breaks, right? That's probably
8:24the most important thing. And all these
8:26instructions are, like, local, related
8:28to payments, users, authorization, and
8:31tests. You don't need to write them all
8:33into one huge "agents" file. At the
8:36root of your repository and your folder
8:38. No need. Break them into small nested
8:41subfiles. They can be nested not only
8:45one level deep, but also nested under
8:47folders, and then under folders, and
8:48then under folders. And it has its own
8:50"agents" file. And always remember that
8:55it's loaded into the context, and then
8:56always passed on to the next one. The
8:59context accumulates, but this file
9:01lives there, so there's no need to make
9:03it huge. You'll just quickly fill up
9:05the context. And as we know, if our
9:08model has a fairly large context, it
9:10can start hallucinating. This is, of
9:12course, undesirable behavior. Nobody
9:14wants that. Therefore, don't even think
9:17about how this will save us tokens, but
9:19think about how our neural network will
9:22work properly and deliver the result we
9:24want. Make it concise, very short. Okay
9:29. The next step is creating skills for
9:32common tasks. Or maybe you're not using
9:35skills yet. Maybe you've already
9:37accumulated skills, like me, for every
9:39common use case. And that's definitely
9:42something worth using. Let me clarify
9:45right away what's the difference
9:46between the "agents" file. Markdown and
9:48skills. Agents are probably just a
9:52description of your project, how we
9:54work with it, and how we don't. That is
9:57, a very high-level approach. Skills,
10:00however, relate to a specific task.
10:04Imagine that you regularly create new
10:06tables, add them to the database, and,
10:09naturally, you need to do this through
10:12migrations. If you're a developer, you
10:14understand what a migration is. We
10:15create a file that describes which
10:17column and type is added to the table.
10:20And there may be rules for how this
10:22migration is added, what else needs to
10:24be done. For example, we run this
10:26command to create a migration on a
10:28specific database, a local one, for
10:30example. We check that the file
10:31contains this, this, and this. And we
10:34make these changes to the migration. We
10:36don't forget to check this, this, and
10:38this. Basically, a checklist or simply
10:40a workflow for the agent so that when
10:42creating a migration, they always
10:44follow a single pipeline and don't
10:45forget important things. Or another
10:48example. Say you're developing an
10:51endpoint, and you need to create a new
10:53endpoint, a, through which the user
10:55gets their statistics, like, I don't
10:58know, completing their tasks on some
11:00platform. It's important that we
11:02already have a lot of endpoints in the
11:04system, hundreds, let's say. And we're
11:07constantly adding or changing new ones.
11:10And if the task is frequent, it's
11:12routine, something is always repeated
11:14in it, some pieces of code, it makes
11:16sense to wrap it in a skill so that we
11:19can always, for example, check whether
11:21the user is an administrator, a
11:22moderator, or a regular user. Secondly,
11:26don't forget to pull up the user ID.
11:28Third, for example, some plugins, based
11:30on their own experience, absolutely
11:32always require adding a certain
11:34parameter, otherwise caching won't work
11:36. And obviously, this kind of local
11:40information is specific to my project
11:44and my library; it's relevant only to
11:47me. If someone writes in another
11:49language, there's no library, and this
11:51skill or this skill point isn't
11:53relevant to them. Therefore, we often
11:55write our own skills for ourselves, for
11:57our own projects, for our own needs.
11:59It's not like we simply copied a skill
12:01from someone else and it will work for
12:04us. But only if the other person is
12:07using the same stack, with the same
12:09architecture, and roughly the same
12:11library versions. Then you can copy it,
12:14but that's, of course, more rare. MCP
12:16plus tools. And, surely, most of you
12:20have heard of MCP. If you don't know
12:22how this works, what it looks like
12:23under the hood, or if you'd even like
12:25to write your own MCP, please let me
12:26know in the comments. It's not for
12:28nothing that I'm a Python developer; I
12:30can show you how to write one. But
12:32let's get down to business. Many people
12:36have heard of MCPs, but for some reason
12:38forget to implement them or don't
12:41realize that the system you're using
12:43has one. Imagine a work task. In your
12:47corporate system, you have GPA for task
12:50tracking or Asana, Affluence for
12:52documentation, and some important
12:55context is stored there—yes, it is.
12:58And centry, where all the bugs
13:00accumulate from the frontend, backend,
13:03and, let's say, some database that
13:05stores data—testing or production
13:07data. And you keep going: copying a
13:12task from Jira, some documentation from
13:14Confluence, from Gitlab, I don't know,
13:17the latest EMRs or the latest commits,
13:20basically, some information from the
13:23repository, say, and you provide a link
13:25or, again, copy the entire bug report
13:28from Cry or Glglip. It's just a stupid
13:33job. And it's stupid because it can be
13:34optimized. That is, everyone used to do
13:36it this way. As if it were normal. You
13:38copy something, search Google, Stack
13:40Overflow, Habr to see if anyone has
13:42encountered this problem. Now it's
13:44simply inefficient. You're just wasting
13:46time. It's much more convenient to
13:48connect the MCP of all these tools.
13:50Connect the Confluence MCP so that the
13:53agent always knows, "Oh, I have
13:55Confluence." And LMKA, when it's
13:58thinking about the task, will say: "Aha
14:00, yeah, okay, let's first go to Jira,
14:02see what the task is, and let's see
14:04what links there might be. There might
14:07be a link to the central bin inside
14:09Jira. It will itself go to the central
14:11MCP, go to confluence, combine all the
14:13data into a single context, and,
14:15together with your code, it will
14:16understand:" Aha, there was an error
14:18here, let's fix it like this, like this
14:20, like this, like this. "That is, the
14:22point is that most developers know
14:24about MCP, but they forget to connect
14:26them. And one more thing, sometimes MCP
14:29doesn't need to be connected or isn't
14:31worth it. And here's an example, for
14:33example, with a database. You use
14:36Postgql or MongoDB or ClickHouse there.
14:40You most likely have it locally on your
14:43computer, well, if you're a developer
14:45watching this video, and you have a
14:47console client, for example, PSQL for
14:50Postgress, and it can easily do queries
14:52to your database. You don't need, well,
14:55these are tools, yes, it's a tool, it's
14:58just a console tool. You don't need to
15:01connect an MCP, which under the hood
15:03will also call PSQL and query the
15:05database. You can simply use the tools
15:08you have on your computer, like Bash,
15:10like Curl, for some queries and testing
15:13. And you don't always need to connect
15:16an MCP, because it's somehow cool and
15:17awesome. If you already have Tolza on
15:20your computer, please use it. Next.
15:22Different models for different tasks.
15:25This is a more advanced story. Ah, and
15:28many don't think about it, don't think
15:30about it, in principle. They always
15:32work on the latest model and, well,
15:34quickly burn through tokens. If you
15:37have a lot of tasks and you've already
15:39used up all the tokens, you understand
15:41that you'll spend all the tokens very
15:42quickly, up to the limits, and you
15:44don't have the money or the company
15:46doesn't pay you, there are several
15:48accounts, otherwise it makes sense to
15:50separate them for different types of
15:52tasks, uh, different models. Let me
15:54give you an example. Example: You have
15:56a large, complex problem. It needs,
15:59well, the huge context, yes, which we
16:01discussed earlier, there's fat,
16:02confusion, uh, some kind of bug. To
16:06understand all this information and
16:08come up with a solution plan for this
16:10problem, it's better to use the latest
16:11model, the most advanced one, including
16:13the most expensive one. And it has a
16:17pretty good, high level of reasoning—
16:19yes, reasoning high or extra high, if
16:21you have it available or you don't mind
16:23the tokens—and then it will think for
16:25a long time and will most likely come
16:27up with a better, higher-quality
16:29solution. But the plan it creates, some
16:33parts of this plan, will consist of
16:35simply mechanical corrections to some
16:38files. For example, in this, in this
16:41function, change the parameter name
16:43from this to this or swap these two
16:45lines. These are stupid mechanical
16:48actions that make sense to use a
16:51different model. Oh, and, for example,
16:55you can use an older model, if we're
16:58talking about GPT, for example, The one
17:00I use is to use 5.5 instead of 56. It
17:03sounds like a good idea at first, but
17:06when switching between different model
17:08families, we degrade in the sense that
17:13our context is compressed, and tokens
17:15are also spent. And it's better,
17:17instead of using other models, for
17:19example, if there's a small mechanical
17:22fix, or maybe a medium one, to simply
17:24reduce the reasoning level from high to
17:26medium-medium or low, or even change it
17:28back to the GPT family from GPT 56, 5.6
17:33to Terra or Llu. That is, take some
17:36other weaker models with an even weaker
17:38reasoning level, so that fewer tokens
17:40are spent. If you rarely use agents
17:42there, well, this feature is useless.
17:44Just use the maximum model. If you
17:46don't spend all your tokens, you don't
17:48need to do this. But of course, I know
17:51how developers use it, how I use it
17:53myself, how my senior friends use it.
17:56And tokens are burned very quickly, so
17:59this feature can very well help you.
18:02Regularly spend 10, 15-20%less tokens.
18:06Next. Subagents for independent tasks.
18:11Just when you figured out what agents
18:13are, some unknown thing called
18:15subagents appears. It's actually not
18:18that difficult to understand. But let's
18:21take an example: you open two chats in
18:24parallel and give your prompts, and
18:27agents are working. These are two
18:29independent agents. These are not
18:31subagents. Subagents are when you work
18:35in one chat, and the main orchestrator
18:39spawns its own subagents, or one
18:42subagent. It has its own context, this
18:46subagent, and it can independently
18:49perform some task. For example, you
18:51have a pipeline—well, we haven't
18:53gotten to that yet, but in general,
18:55let's say you have a good pipeline
18:57where the neural network first creates
18:59a plan, then decomposes the tasks,
19:01distributing them according to the same
19:03, for example, complexity or
19:05risangulation. in models based on
19:08reflections and starts to act. And it's
19:12important that some of the actions are
19:14performed by independent experts, I'd
19:16like to say, okay, by independent
19:18subagents who don't have this entire
19:20context of reflections. That is, if you
19:24feed an agent a subagent the entire
19:26context where the decision-making chain
19:28was, it will consider it reliable, and
19:30it won't be able to conduct an
19:32independent, impartial code review. But
19:36if you tell the subagent, look, this
19:39was the task, this is the result. Check
19:43it, well, as if another developer is
19:44actually checking it. Check if
19:46everything is okay, if there are no
19:48problems, if everything is according to
19:49standards, according to our agents file
19:51. Check that everything is okay. And he
19:55really, well, will check your code more
19:57impartially than an agent with a huge
19:58context of all the reflections. And
20:01sometimes this can speed up the work if
20:04subagents are doing several seemingly
20:06independent things in parallel. That is
20:09, there is some complex bug, and it
20:11needs to be investigated. There's a
20:13problem. Either there's a cache issue,
20:16or a database issue, or a problem with
20:18some other service, or there are
20:19problems in our code. And we can easily
20:23, if the tasks are independent, launch
20:25two or three subagents. It's also
20:28important to remember that if we have
20:29an agent and its subagents, the main
20:31agent itself can also perform work.
20:33It's not just a manager who sits idly
20:36by and says," You do this, you do that.
20:38"It can also work. Therefore, you can
20:41give the main agent its task, and the
20:43subagents, well, those little ones, so
20:46they can look at this RAIDIS, look at
20:48this database, and they will return
20:50their research results and feed it to
20:52the main agent. Okay. The next step is
20:56parallel work via GitWork 3. This
20:58applies, of course, more to developers,
21:00especially when you have a lot of tasks
21:02in progress, several new bugs have
21:04appeared, you are developing several
21:07features. And if no one has used Git 3
21:11before, well, simply because We used to
21:14use Git Stash, but now it's a really
21:16cool feature. What does that mean? Git
21:203, and you can edit the same repository
21:24from different branches simultaneously
21:27on one computer. So, let's say you have
21:30a branch for one feature. Previously,
21:32we'd have either a feature or a bug
21:34open, and we'd be editing one at a time
21:36, which makes sense (we're kind of one
21:38person, we share one brain, and it's
21:40hard to do two tasks in parallel). Now,
21:42agents can: one can implement a new
21:44feature, the other can fix a bug,
21:46especially if they don't overlap in
21:47code, so there won't be merge conflicts
21:50later. That would be ideal. If you have
21:53a lot of features, a lot of deadlines,
21:56and it's a startup, then I definitely
21:58recommend using Gitwork 3. Next up is
22:00verification loop and hooks. This is,
22:04of course, probably one of the most
22:07advanced scenarios, when we clearly, uh
22:10, give commands to the agent, which is
22:13the definition of, That is, when a task
22:16is completed or not completed, how many
22:20times must the agent fail before it
22:23stops working? Or, let's say it tried
22:26to fix a test three times, failed, and
22:28instead of burning the token further,
22:30it runs for another hour. And there
22:33might be a bug, you know, when you
22:34change something in one place, the
22:35agent changes it, something breaks in
22:37another, then you change it in another,
22:38something breaks in this one. And the
22:40agent might not find the dependency,
22:41that something needs to be changed in
22:43both places at once or one of these
22:44places needs to be deleted. It might
22:46not understand the dependency, how some
22:48elements depend on each other, because,
22:50for example, we didn't convey this in
22:51the context. Or it's not obvious to the
22:54agent. Well, of course, this might be
22:57increasingly obvious to the latest
22:58models if it can't match such simple
23:00things. Most likely, it can. But in
23:03reality, complex things happen,
23:05especially when external systems
23:06somehow influence them. External
23:08specifications, databases, which,
23:09perhaps, someone is editing in parallel
23:11or through some triggers. There are
23:13still some fixes that the agent doesn't
23:15know about or doesn't have access to,
23:17so they can only guess, and you know.
23:21It makes sense to create a feedback
23:23loop like this, it's called a feedback
23:25loop for the agent, so it understands,"
23:27Aha, I messed up, the tests didn't pass
23:29, the linter didn't pass, I go back to
23:31this step, run it again, fix the code,
23:33run the test. Aha, it didn't pass. "And
23:36so, in this cycle, you determine how
23:38many such circles there are, and is the
23:40same context being transmitted there or
23:41not? Is there some kind of context
23:44saving and independent checking with
23:46subagents? This is a complex,
23:49configurable system, although it
23:51actually sounds quite simple. Okay. And
23:53let's highlight a few more things that
23:56didn't fit in this video. This is, of
23:58course, context management. I've
24:00touched on this topic many times, but
24:02technically it's more difficult to
24:04implement than just describing it in
24:05words, right? This is observability, so
24:08we can monitor the actions of our
24:11agents, Ideally, we want the system to
24:13be able to improve itself. These agent
24:16files, configurations, all the scripts,
24:19hooks, so that our system can
24:21automatically improve without our
24:24intervention or with minimal
24:26intervention. And again, I'll explain,
24:29each project has its own set of tools,
24:31MCP, hooks, and feedback loops are
24:33relevant. It's hard to just copy the
24:36entire set from another project and
24:38that's it, everything will work,
24:40everything will fly. Most likely, you
24:43need to customize, tune at least some
24:45things. And a fairly popular thing is
24:48Spec Driven Development, which is used
24:50in bigtech companies, in many teams,
24:52I've heard, including myself. A very
24:55cool methodology. And these are all
24:58those things, if we zoom in, all those
25:01things, and, of course, there are many
25:03more besides them that are needed in
25:05software development or simply when
25:07writing code, if you're a developer,
25:09analyst, tester. DevOps, well, just
25:13doing something Programming, coding, or
25:15wipe coding. This is something you
25:18absolutely need to know. If you liked
25:19the video, please support it with a
25:20like, a comment, and a subscription.
25:22This channel hasn't had a video about
25:24AI yet. However, I have a lot to share.
25:26So, if you're interested, let me know
25:28in the comments. And all the best. Bye.
25:30M.

About this transcript

This page contains the full transcript of Роадмап по Агентской разработке в эпоху AI by Артём Шумейко, generated from the public captions YouTube serves with the video. The transcript has 4,249 words across 650 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.