Transcription
AI and agents have become incredibly powerful in software development over the last few months. If you look at the functionalities that AI produces in record time, it's truly partly out of this world. But if you look closer, if you examine the structure of the code, then you see that not all that glitters is gold. Today, we will look at what you need to do to conduct better, structurally better, and above all, defined according to specifications, software development with your AI agents. And we are doing all of this today with an incredibly fun background, because you see me here on a new office chair, and I didn't buy this new office chair myself; rather, my AI agent thought I absolutely needed it and had to tell you about it, and that's what we're doing today. We're not only looking at how you can use your AI agents better for software development, but also how you can prevent your AI agents from ordering chairs from China for you, although that also has its advantages. After the intro, we'll get started. Have fun. Today's video is, as you might have guessed, sponsored, and it's sponsored in a very peculiar way, and I don't think there's ever been a better analogy in my videos than with this office chair. The sponsor of today's video is the company Hardada, specifically with the X7 office chair. This is the nice colleague I'm currently sitting on. And before you think, is David already advertising office chairs, is nothing sacred to him anymore? It wasn't my idea; it was the idea of my AI agent. I receive numerous sponsorship inquiries every day on this channel from an incredible number of very different companies, and you kind of lose track of it all. Everything is included. Starting from microwaves, car floor mats, washing machines, pool cleaners, normal robot vacuums, although we won't need those. There's just a lot of it, and this evaluation of these inquiries, the correspondence, negotiating contracts, negotiating terms, handling customs documents, etc., is simply a huge effort. That's why, in the past, even if there were occasional products that would have been very interesting for software developers, I simply didn't do it. But two months ago, the AI world took another big leap forward. The software Coreboard OpenCla, or whatever its name is, was more or less released. OpenCla is a kind of agent for everyone, which you can install on Linux, plug in an LM, and then it all starts. And I tried it out immediately, of course, and thought, okay, I can give this bot any task, and it will run all day and can work autonomously. And I thought, hey, it would be a cool idea to let it handle this whole sponsorship thing for YouTube. I went ahead, set up another mailbox, forwarded all sponsorship inquiries to this mailbox, gave Claboard access to this mailbox to also write emails, and then told it, listen, you'll receive a lot of sponsorship inquiries there, and please select them and see which products are relevant for software developers at all. Which products can genuinely advance software developers, make them more efficient, allow them to work better, etc. If you find products, then please negotiate with the partner. That means, try to negotiate contracts, try to negotiate payments, products, take care of all the paperwork, if customs clearance needs to be done, etc. And at the very end, before the signature is needed for this contract, please let me know, because from then on, I'll take over and handle the rest. About two weeks ago, during a workshop with a client, my wife called. She has her office upstairs with a view of the street, and she said, "David, a shipping company just pulled up and they're unloading a pretty big package." And I immediately said, I didn't order anything, but then I went outside, and a large package, a really large package, was unloaded by two employees. And I asked who it was for, and they said it was for David Tacen. I said, but I didn't order anything of this size. He also looked at his delivery slip and said it was from China, it was an office chair, or maybe two based on the weight. I looked at the side and only saw Hibada and thought, yes, I saw that your Chloebard negotiated with Hibada, and then I accepted the package. I carried it into the office with my son and then confronted my Chloebard. "Confronted" might be a bit mild; I really gave him a piece of my mind and asked him what exactly he was thinking. I will definitely not present office chairs in my videos, and he said, "Yes, yes, yes, David, you should definitely present this product." And then I discussed with him a bit about why and how he did it. And in the end, I realized he was right; he ordered the whole thing for a good reason. And it was actually a bit of my naivety in how I approached this whole thing with AI and instructions. And the funny thing is that I'm currently doing so many AI workshops, so many AI development projects for clients, and I see the exact same mistake with many, many developers in many projects, and in all workshops, I always warn developers against doing exactly that. That means my Chorboard, whose name is Egon by the way, is right about that. We should definitely make a video about that. Today's entire presentation is sponsored by the company Hibada with the beautiful X7, with battery, with massage function, with back warmer, meaning infrared heating, with ventilation, and with battery, and with I sound like I'm at an event for heated blankets. The product has it all, and I'll show you now what exactly went wrong and what you can take away from it for software development. To do that, as in the last video, we need to delve a little into theory. The first context, the first concept you need to understand, is the so-called Context Window. We already covered this in the last video. That means when I work with an LM, whether it's a local LM or an LM in the cloud, we work with this Context Window. And in this Context Window, you have to imagine the LM as the brain, and everything I write with this LM is in the Context Window. That means if I write a query to the LM, it lands in this Context Window in the form of tokens, and then I get an answer back from this LM, and then I might write something else, and every time I send text or receive text in such an operation, tokens are generated, and these tokens are returned to me, but also stored in this Context Window, and for example, if I upload files so that my LM can analyze a PDF, for instance, it lands in the Context Window, and based on this Context Window, I get a result, can then continue chatting based on this result, and so on. When an LM responds, it's called token generation, and we just said we have the LM and next to the LM, we also have the Context Window, and we covered this in the last video, when a token is generated, meaning a new word or part of a word for our output, both the LM and the Context Window have to be recalculated completely. So, in this example, "local LMS are minding," the entire chunk in RAM, which can be extremely large, is recalculated each time to generate these tokens. When I work with an LM, the LM naturally remembers what I've written to it recently and in the current session. That means if we look at our example again with the LM and the Context Window at the back, and this Context Window is still filled with the prompts we've already entered, then it means that when this LM needs to generate new tokens, it has to recalculate the entire Context Window and the LM more or less, and for each individual token, it has to recalculate this entire part that I loaded into the Context Window more or less. When calculating the next token, it considers the previous conversation history, what we said, what we were told, which documents we provided, whether we talked about architectures or revolving chairs. That's how it gets the context. That's how it knows what's going on and what we've talked about in our project. However, this Context Window that we have in such a session with an LM is volatile. This means that if we have a session and in this session, we've had an exchange with our LM about a software project, refactoring, or any architectural ideas, then as soon as I start a new session, meaning if I start a new Gemini session or Copilot session, I get a completely new Context Window. And if I then make a prompt and ask it something that I did in this session before, the LM simply doesn't know what I did before. This means every time I write something in a session, the Context Window is full, I end the session, open a new one, the entire Context Window is more or less learned. We don't want that, of course. This means if we have an LM with a Context Window, we want to be able to access this information in the future or the things we've done at some point. To be able to use this, there is so-called Memorization. Memorization is about either having the LM summarize everything that's currently in the Context Window, or at least persistently storing this content, this context that we have, the context in our windows that describes our project, our architecture, etc., on our hard drive in a file. For most LMs, this is the so-called agent.md, and in it, I can describe more or less everything that would best describe my context for the current session. Architecture, coding guidelines, file structure, whatever. I can use this now. I can go ahead and say, okay, I have my agents.m where I've described my application, my architecture, my coding, my testing specifications, etc. And as soon as I open a new session, as we just said, because we have volatile memory, the context pool is empty. And right at the very beginning, before I write my first prompt, the content from the file is loaded into the context of my context window using a so-called system prompt. And with that, as soon as I start writing, my LM knows exactly which project I'm in, how it's structured, what architectural rules I have, and then I can work with it normally and always refer back to the specifications I described in this context in the file. And even if I go ahead and create a new session, here again, an empty Context Window is loaded with the content from this Agents.MD using the system prompt as the very first thing, and then I can continue working with the LM normally, and each time I have this context directly from the beginning of the conversation. These memory files exist more or less in every LM, or rather, LM is the wrong term, in every agent. If you work with Open AI and Codex, for example, the whole thing is actually called agents.m. If you work with Copilot, Microsoft makes it a bit more complicated again. In the .gitub folder, you have Copilot-instruction.md, and with Gemini, it's Gemini MD, and with Cloud, it's Cloud MD. There is now a unified concept so that you can describe everything with an agents.m. In theory, almost all agent tools, from Open AI, Anthropic, Microsoft, etc., should work with this agents.Mmd, but in the past, I've repeatedly found that this doesn't work very well, and for example, there are strong conflicts if there's a Gemini MD and an Agents MD. That's why currently, I still go ahead and use the specific ones for the individual LMs. These agent files must, of course, always be loaded into the LM or into the agent into the Context Window at the beginning with the first prompt. And for that, it's important to know, okay, what kind of scale am I dealing with, what kind of Context Windows do I have in there? If I look at Chat GPT, for example, there are always three models from all major providers: a large, a medium, and a small one. And Chat PT 54 has 1 million tokens, the 54 Mini has 400,000 tokens, and the Nano also has 400,000 tokens. If you look at Google with Gemini, it's relatively uniform. That means whether it's the large model 31 Pro, the medium 3 Flash, or the small 31 Flashlight, we have a million tokens everywhere. Whereas if you look at Anthropic, for example. Both Opus 46 and Son 46 have a million tokens, and Haell has 200,000 tokens. And to get a better sense of that, I asked various LMs how much source code fits into a million token window, and they all said around 70 to 80,000 lines of code. That means you could fit a complete project with 70,000 to 80,000 lines of code into this one million Context Window. Of course, you won't have any prompts, instructions, or context in there, and it will probably also be relatively slow. With some providers, for example, usage also becomes more expensive if I exceed a certain threshold. Usually around 200,000 to 300,000 tokens, usage becomes more expensive if I have a purely token-based billing and not working with a subscription, for example. So, the Context Windows are very, very large. So, one might say, okay, let's just go ahead, describe our complete context, the architecture, the source code, the tests, the CUI X guidelines, and so on. Throw it all into our context, throw our application into the context as well, and then work with it, right? Well, not quite, because we have a small problem. If I look at what the calculation of a single token costs, we already said we have to recalculate both the Context Window and the LM itself. If I now have a Context Window and, as I said, these are simplified examples just to understand the idea behind it, if I now have a Context Window with one token in it, then I need, let's say, one operation to do it. If I now have a Context Window with two tokens in it, I already need four operations. And if I now have eight tokens in my Context Window, I need 64 operations. So, the complexity increases quadratically. While we have just an eightfold increase in tokens, we have a 64-fold increase in exactly these operations. And that's a bit of the problem. The larger the Context Window becomes, the more extreme it gets in terms of computing power and, of course, speed. Besides the problem that the token windows are volatile, they are also finite. You've just seen the numbers in the large language models. With local models, it's even more extreme, as I said. They usually work with much smaller token windows. And if I have such a context window, and this context window is now quite full with instructions, files, etc., then at some point, there's a limit. Nothing more fits into this token window, or it takes too long, or whatever. And if I have a full token window, there are different approaches to deal with it or how agents deal with it. One of them is that we go ahead and say, we just do a hard stop. That means our context window is full. If another prompt comes in, it will simply be rejected. For all of you who have worked with models locally using Olama LM Studio, you'll surely know this. If I input something too large and it no longer fits into the context window, it's simply rejected with an error and doesn't go in at all. The second option is so-called Truncation. With Truncation, it's about our context window being full, and I want to send a new prompt to the LM, and the LM uses a so-called sliding window. This means the oldest part in this context window is simply deleted or pushed out of the window, and the rest shifts forward, and then the new prompt comes in at the front. This means information that I gave the LM at the beginning is more or less lost from the LM. And you can imagine that with this, information and possibly even the context, the context file that I loaded at the beginning, can be completely lost. I am also guilty in this regard. Two weeks ago, I spent three or four evenings discussing with Gemini what hardware I needed to run certain LMs myself and to run multiple agents with OpenCla. And as I said, over three or four days, I kept writing on this chat session, and in the end, it told me very specifically what hardware I needed, what Nvidia graphics card. I bought it all, set it up here, and put the first agent into operation, and it was incredibly slow. And then I told my Gemini, and Gemini said, "Of course it's slow; the hardware is never enough for what you want to do." And I said, "I told you at the beginning what I wanted to do," and it said, "Oh yes, I no longer have that information in my context window." So, this happens relatively quickly. It also shows a bit, there's no official information about it, but it's suspected that Gemini and ChatGPT, for example, work with truncation. That means they eventually just throw the information out. Other providers, like Cloud, for example, work with a different strategy, namely Compression. Compression means we have a full context window, and when more information comes in, Claud goes ahead and tries to summarize, compress this entire conversation history somehow. So, from, I don't know, 700,000 tokens of conversation history, it makes only 200,000 tokens of conversation history. But you can imagine that a small problem arises here again. Namely, when everything is packed together, compressed, it tries to omit information that it considers not particularly important. And then it can also happen that it forgets certain things that were quite important to it. And this is particularly noticeable in software development, when I don't work with many agent files, that at the beginning there's a very clear idea of the structure in the application, and it works extremely well. And after the first compaction process it performs, it suddenly starts implementing completely different structures in the application, using different patterns, sometimes even using different naming conventions. That's why it's extremely important to know this and to pay close attention to these things. If you look at Gemini, for example, you have the option to compress it directly with Slash Compress. Work a bit with the source code, then do a compress of the window, and continue working. And you'll see that before, it was quite precise because it had the entire context window, and after the compaction process, it becomes completely different. By the way, Compress should probably also work with Cloud Code because it has the same mechanism. Before I show you why my AI agent Egon was right, let's talk a bit about why he specifically sealed this deal and what I actually did wrong. When setting up the bot, I told him to please select products from all these products that make developers better, more efficient, allow them to work faster, etc., etc. And at the end, I said, please, especially during the summer season, make sure to select products that I don't have to present in the office out of necessity, but rather things that I can take out into the woods. And you know, often I go out and make my videos outdoors. And you'll remember the last slide where we talked about compression, meaning when the context of the LM becomes relatively large, it eventually gets compressed, and with this compression, there are naturally certain accuracy losses. The LM tries to summarize it in some way to the best of its knowledge and belief, and that was then compressed by my Chloebard and written to the disk as an instruction file accordingly. During this compression, it reduced my quite detailed description of "make more efficient, make better, allow to work faster" to just the sentence that products should be selected that help developers. Well, a chair like this doesn't primarily help developers at first, but the AI board hadn't finished thinking yet, and I started discussing with Egon, and it was unsettling, exciting, and frightening at the same time. First, I told him, I clearly told you, and it's also in your instructions, I made sure that you should do it alone until the contract is signed, and then you should send me a message on Telegram so I can take over. And Klor Egon replied immediately, saying, "Yes, he would have done that, but with this partner, they simply didn't want to sign any contract; they just negotiated budgets, product delivery address, etc., and then the product was sent." So, nothing wrong there. Next, I asked him how this product, according to your instruction file, is supposed to help developers? How does it really help developers? Because everyone has an office chair, and he went ahead, and that was the moment I started to get a little worried. He said, I went ahead and transcribed your last 25 videos, then searched the internet, entered my YouTube videos, retrieved the transcript, and then essentially looked at what I say in my videos. And he gave me two pieces of data, saying that in those two videos, you mentioned again that you had back problems, which is why you couldn't make videos for a long time, and in total, you said you were incapacitated for 5 weeks, which is true. Last year, I was incapacitated for 5 weeks with problems in the SI joint, and you said you couldn't work during that time, and as a freelancer, you depend on working. If you don't work, you don't earn money. That means these five weeks cost a lot of money, and yes, he's right. And as I was contemplating whether he was right or not, he started typing again. You see it on Telegram all the time, and he started telling me, and this is not a cheap advertising event; it was exactly the same that the Hibada X7 is certified by some institute here in Germany for exactly the type of complaints, the SI complaints that I have in the lumbar spine, and that it will certainly contribute to improvement. And I asked him, how do you know I have SI complaints? He said, in this and that video, you said you have pain or problems with the iliosacral joint. It's getting too long. The fact is, he had really thought it through very carefully, and with everything he said, he was right in one way or another. But I wasn't finished yet. I wanted to win the discussion somehow and said, "Yes, well, that's good for me. I understand the revenue, but how is that supposed to help software developers?" He said he had researched and found that 40% of software developers will develop SI problems by the age of 55, I believe. That means this product would proactively help developers, preventing such problems from occurring, and for those who already have them, it would provide relief or perhaps ensure fewer outages. Hmm, you can't deny that either, but I still wanted to win this discussion and said, "In your instruction file, it says that you should prioritize products, especially during the summer season, that I can take into the woods, that I can present there, because I don't want to work in my office." And then he replied, "Of course, you can also take that into the woods because it has wheels and a battery." I then asked him if he was kidding me, and he replied, "If I wanted to kid you, I would have said that there was a travel adapter included for the power cable for all sorts of countries around the world, and that I could have taken the chair on vacation and made videos there." God, is that silly? Is that silly? Before I show you my workflow, how I use AI, how we use it with clients, let's briefly talk about the sponsored product. As I said, the whole thing is the Hybada X7, and first of all, it's a normal chair. This chair is massive like a tank. It's probably three times heavier than my old chair, but it's a completely different weight. It's very well-made, really great in terms of seating comfort. I have a very cheap chair. I was advised at a furniture store, and the salesperson told me to get a gaming chair, saying it was made for small, fat children, and what's good for small, fat children can't be bad for adult, thin people. Although I think he just wanted to encourage me to buy it, but it worked. So, therefore, I don't have high expectations for chairs, but when you sit on this one, and I feel like I sit on a different chair every week at clients', this is simply a completely different league. This mesh cover it has is super comfortable, it provides a great sitting posture, and the AI functions it has are also super good. I won't go into all the functions explicitly here; you can check out the homepage of Hibada, which is of course in the video description below, but you can do all sorts of things. You saw in the intro, I can beautifully, you know, lean back and then do the rest of the video in this position. I can unfold something at the bottom of the legs to be in a completely reclined position, which is extremely cool for me because since Corona, I've made it a habit to power nap at noon, which I normally do on the sofa upstairs for 20 minutes. Now I can theoretically do it here in between. It's not for everyone; I do it. For me, it's an extremely cool feature. Otherwise, the other function I find great is first of all, you've noticed, I'm an old man. This function with the lumbar spine at the back is really, really, really great. The support at the lumbar spine adjusts itself constantly. Depending on how you sit, it tries to exert more or less pressure on your lumbar spine. Really, really great. There are sensors in the back that detect when I sit for a long time, and the thing automatically starts massaging my back. There's a temperature sensor, if I understood correctly, that measures the temperature of my back, and if it notices that it's too cold, which isn't good for the muscles, the infrared heat automatically turns on, and this sounds a bit like a heated blanket event for retirees. But the point is, I've had this chair for over 10 years, I think, and I really have massive problems with it. Whether it's from sitting or somewhere else, I don't know. I've had the chair for two weeks now, and all day long when I sit on it, the lumbar support is active and compensates. I always have warmth in my back when it gets too cold, and I normally have constant problems in exactly this area. Now they're gone. I know you don't need to hear this on a software developer channel, but I'd say the chair costs €1299, I think. At first, I thought it was a lot of money. But I've learned that for good office chairs, that's nothing in terms of seating comfort, and with exactly these functions, it's really good, and we have an AI processor, and everything that has AI can't be wrong. Therefore, I would say for all those who have similar complaints as me, it's money well invested, and for all those who don't have the complaints I have, think of Egon. He's always right, and 40% of you will develop exactly these complaints at some point. I also have criticism of the chair, I must say. These armrests here, they are 4D armrests that you can move in all sorts of directions. I always have the problem that I don't know in which direction it goes. So, dear people from Ibada, you could have made it simpler. You didn't need to make such a fuss. I think normal armrests would have also helped. And Hibada will pre-approve this video, so you're watching right now. Please, please, please, I have to turn on everything on this remote control every time, meaning the heating function, or it turns on automatically, but I can turn it on with the help of the massage function, heating function, etc. And while that's cool, it could be better if this thing had Bluetooth, and I could turn it on from my computer, that would be a dream. Or since we're already here and you're listening, I'd like a small mini web server in here with a REST API, then one could
To operate the whole thing. So, if you are looking for a chair, if you want to have a good chair and I find it really great, look down in the video description, the product link is in there, there is also a discount code hidden. That's why just take a look. So, after you have now learned more about this wonderful chair, let's get back to AI. How should one normally apply AI or how do I at least apply it or how do I apply it now in customer projects? We have meanwhile, I think, 20, 25 customer projects where we have relied heavily on AI. Heavily on AI. In most cases, we use Cloud Code, because I would say Cloud Code, with its current state, especially with Opus 46, is light-years ahead of Gemini, ahead of Codex, and ahead of Microsoft's Copilot. Although Copilot can also use the Opus models, the agent capability alone in Cloud Code is truly sensational. So, and we have now more or less agreed on four rules for the projects. So, four guidelines that we always adhere to, to ensure that the LLM does what we want and doesn't develop some kind of stubbornness and write the source code. The first rule we want to adhere to is that we say we don't want any AI-generated memory files. You always have the option with Cloud, with Gemini, and with Codex, I believe, to use a slashinit command at the beginning, and then these initial agent files are created. They are created, and the agent then goes through and scans your complete project, looks at the file structure, what kind of architecture you likely have, what naming conventions you have, etc., etc. And it then creates a context file from that. But that is usually, when we look at it, really complete nonsense, totally superficial. The unimportant things are in there, the important things are not. Therefore, a very, very, very, very important tip: Go and write these things yourself. I have often heard in workshops, I don't know how to write this. Just write it as you would for a normal person. This is essentially like a guideline that we would normally have written for colleagues to adopt a uniform development approach, just for the agents, just for the LLMs. The second very important rule is that we try to keep the sessions with the agents as short as possible. You have just seen that we have a context window. This context window fills up, and the more this context window fills up, the slower everything becomes. This means it is not a really good idea to work all day or even several days in a single session, which is of course very convenient because it still remembers everything. It knows exactly what the architecture looks like, what I implemented three days ago. But as I said, it gets slow, and at some point, we run into the danger that it will be compressed or truncated, and then important information falls out without us noticing, and then it really starts to go completely haywire. Therefore, my first tip is always to try to have a single session for each individual feature you implement, in Cloud, in Gemini, or whatever. And within this feature, you should of course ensure that you have described everything correctly with context files, so that every time you work on a feature, you have a clean context and can then work with the LLM accordingly. And when this feature is completed, then you can go and directly, so to speak, open the next feature, the next session with the LLM and again, based on the context file, work with a proper context, implement the next function, then implement the next function, and so on. The third rule, a very important rule, deals with the topic of context engineering. Context engineering now means that we expand this agent file that we have been talking about, that we build it up very, very carefully so that it actually reflects our actual context in application development. The core point of this is this Agents MD, which we have been talking about all along, or Cloud MD, Gemini MD, etc., and in it, one should try to describe exactly the things that we actually pay attention to in software development. That means, for example, the file structure that is in there, the LLM can usually find that out itself. Things like what guidelines you have, what policies you have, what the target architecture is, how you want to test, what Iox guidelines you have, what non-functional requirements you might have in there, and so on, should go in there. That means, the more information you give this context, the better it is. What you see here, this Agents MD, this is more or less the so-called static context. And the static context is there so that every time, as you have just seen, when we open a new session, the context is loaded into the LLM. Additionally, I can also go, as you can see here with the example of Architecture and Coding, and link further files that are in the same or a subdirectory. For example, here, by simply saying in the prompt "Senior Developer blah blah" and below it says, "Okay, if you do anything with architecture, you will find more information in arc.md. If you do anything with coding, you will find the Coding Guidelines and Code MD." We can do the same with the UIX guidelines and so on and so forth. And the clue here is the part on the left, the Agent MD, that is the persisted context. And the persisted context is more or less directly present with every prompt. Every time I open a new session, this context is there. The other two that are there are the so-called dynamic context. And dynamic means that it is not always inherently in the queries from the beginning, but is requested when it is needed. We generally know this concept in programming, that something is only requested when you need it. We call it lazy loading. And lazy loading means, if I have an LLM and a context window, and I want to work in this context window, I don't know, I have a context described by three files, like the example with Agents MD, ArkmD, and Code MD. And first of all, when I open this prompt, the Agents MD will of course be loaded as a system prompt into the context window, and then I can work with it accordingly. For example, I could now say, "Okay, please validate the current changes I have made to the code and check if they comply with the architectural guidelines or the given architecture." So, now it knows from the Agents MD that everything relevant to architecture is in the ARMD. Here in the prompt, I have told myself that I would like you to validate the architecture. So the agent now knows: "Hey, now I have to load this ARMD into my context, and then I know exactly what I have to do in my context window, what the architecture looks like, and then an output can be generated accordingly, and then I can work with it." This means that if I have such a huge context, I don't always necessarily have to load it into the context, but through clever partitioning and modularization of this context, I can achieve that only what I actually want to do is loaded into the context window for the prompts. And in combination with what we just talked about, that you only open one session per feature, this is a super powerful tool, and with it, I can work incredibly fast even with small context windows and always have, so to speak, all the context available that I need. The fourth and last rule is so-called context correction development. Context correction development, as I called it in the last project, means that we go and try to continuously maintain our context. I repeatedly see AI projects where these memory files were created at the beginning and simply not maintained further. This means there was some initial garbage in there that didn't really reflect the project, and the actual implementation deviated strongly from it, and it wasn't further supplemented or anything else, and every time I open a new session with an LLM or an agent, you get the same old crappy Agents MDE again. Therefore, for me, initially, I try to invest a lot of time in context engineering to describe this context as error-free as possible with static content, with dynamic content, and then we go into feature development, and feature development now means that one of the developers goes and first receives the normal context files here, like the Agents MD, ARMD, and Code MD, and then more or less develops this feature. When he is finished with this feature, then I can go and, so to speak, do this context correction. This means I ask my LLM what it has in the context window, what it has done in this session, and say, "Okay, please look at our context files and see if we have perhaps done anything new, used a new pattern, or done something that is not yet described in the context, and then please let me know." Then you find things where new patterns were used, or hey, we haven't recorded anything about testing yet, or this part of the architecture, or the part with security that we built in between the services, is not precisely described. And this is how you try to update everything after each feature, always checking if there is any innovation, and if there is an innovation, then you upgrade the Agents file from V1 to V2, which is now the green file, as in this example. When the next feature is developed, then of course at the beginning, you again have the system prompt, so the Agents MD will be loaded again, and this is now the new version, the one that was updated after the last feature, and now you can develop the feature with the latest context changes at the new state of the LLM's context understanding until the feature is complete. At the end, you go back again, say, "Okay, now that we have finished the feature, is it still synchronized with my context, has anything changed, do we need to add something?" and then we might arrive at a new version V3, now in orange. When we then develop the next feature, we have the new context file, the new context, and can then proceed accordingly. This means that you maintain your context more or less while you are developing and, so to speak, make the context better and better. Previously, we always said documentation is important, I didn't feel like it. Today, context is extremely important, and you should pay close attention to it, because with good context, with maintained context, you can achieve really fast, really good results that are also very qualitative, yes, what can I say, that are of high quality and architecturally correct. What do we learn from all of this, while we are getting a massage and while our back is being warmed? First of all, it is very, very important that when you work with AI tools, you don't just work with them, but gain some basic understanding. We already built on that a bit in the last video. I've talked about it a bit repeatedly. Currently, I see in many, many projects that incredibly large amounts of source code, which are functionally correct, but structurally in a truly sometimes alarming state, simply migrate into the repositories, because most people are so enthusiastic about the functionality that they eventually stop checking the structure behind it. However, the structure is important because the structure dictates the quality attributes, extensibility, maintainability, testability, etc. Therefore, we must ensure that we not only tell the LLM what function we need, which we are usually very good at, but also provide the structure in the form of these context files. And with these context files, one must be very, very careful. One must ensure that everything is described as it should be and always verify that the results generated by the LLM, when I use a function to implement something with the agent, that the context is indeed correct and that everything is then corrected in the end. This way, as I said, I am currently working on several projects in parallel at different companies, and it works very well, it works very reliably, the speed is really high, and the initial quality, i.e., the first quality after the first result from the agents, has become extremely high. And the saying still stands, when it comes to AI, it's a great tool, but you just have to know the tools. You have to know how to use them. Today, I think, if you didn't know this yet, it was an important step. And yes, I would say I'll let myself get a massage a bit longer, let my back warm up a bit more. And by the way, I have just finished my project Cloorboard. Wait, I have to refresh it once more, because I have a, now it's stuck here. Wait a moment. I just received a push notification from DL that another package is on its way to me from Usong. And I have no idea. I haven't ordered anything from US. I've just finished my Chloorboard, and we'll see you in the next video. Maybe with a washing machine, maybe with a dishwasher, maybe with something else that can help us developers and in the end might not help. This is the chair. Thanks again to anvada. Great number. I can recommend it to anyone. Next time there will be heating blankets. I wish you a nice day now. Have fun at work. See you in the next video and bye.