Transcription
Hello. Glad to welcome you again. We are starting our next, well, let's say, deep dive into the materials. Today we have on the table, so to speak, excerpts from a rather interesting webinar. It was a webinar by Mike Savchenko, from the Codex Town Club channel. And the topic raised there was, well, very relevant. Uh, it was about the evolution of how we interact with artificial intelligence, especially in development. You know, this transition from what everyone has gotten used to calling, well, prompt engineering, to something more complex, more fundamental, to an approach that can be called context engineering. That's what we'll talk about. Our task today is, well, to try to figure out why these old methods, simple commands like "do this for me," are increasingly failing, especially when the tasks are complex, like in programming, for example. And most importantly, what is replacing them, how this very competent preparation of information, preparation of context for AI, and how it can, well, radically change the whole game, improve results. Well, let's dig deeper into these materials. Yes, welcome. The topic is undoubtedly hot and very timely. The term prompt engineering itself, well, as was noted in that webinar, already seems somewhat outdated, or at least insufficient. We are observing right now how a shift is happening. A paradigm shift in interaction with AI. And this context engineering is not just some new fashionable term, no, it is, in essence, the core of a new approach. It's no longer just about how to more cleverly or accurately formulate the request itself, the prompt, but about how to create the right information environment for AI, how to give it all the necessary ingredients, all the necessary information so that it can qualitatively perform the task. >> This is exactly what was discussed in the source. The problem of unpredictability of results was mentioned there, especially when AI generates code. Mike Savchenko even used the term "vibe coding." >> It sounds like this code, which, well, is easy to generate once, and then also easy to "vibe" delete, throw away, because it's unstable or not quite what's needed. >> And examples were given. >> You give, say, the same request, and today you get perfectly working code. And tomorrow, bam, the same request, and at the output, either errors, or generally some other solution that doesn't suit you. >> Uh-huh. >> There was an example with multilingualism for a landing page, and it seems to add a language switcher, but it either doesn't work, or, which is also interesting, for the same task, AI each time pulls different packages, different libraries, sometimes some outdated ones, sometimes simply unstable ones. Where does this lottery come from? What is the root? >> The root of this unpredictability, well, or let's say, instability, was precisely explained at the webinar. It lies in the lack, or more often, in the incorrect presentation of context. You see, when we give AI such a general, broad command, like "make me a landing page with support for multiple languages," we are essentially leaving it too much freedom, too much uncertainty in choosing tools, in choosing libraries, approaches, architectural solutions. And AI, well, it's not a telepath, it cannot know the standards of our specific project, our preferences for the technology stack, the specifics of a particular task within our large system. It can choose a library that, say, was popular five years ago, and it was in its training data, or simply the first one it found from its, well, so to speak, internal catalog of options. The first suitable pattern it found. And this is where this instability, errors, suboptimal solutions come from. There was a very apt comparison in the webinar, I think. It's like asking someone to build a house, >> without providing any blueprints, any list of building materials, or even, perhaps, the exact address of the plot. Just build a house. Well, the result will be, to put it mildly, random. AI is pretty much the same story with a lack of context. Yes, yes, absolutely correct. By the way, a very telling example of this was from one of the webinar participants, Andrey. He shared his case, he tried to create a WordPress plugin using AI. The task was to integrate WordPress with some ticketing platform. He first used the Cursor tool. This is, well, for those who don't know, a code editor with a built-in AI assistant, quite popular now. And with Cursor, the result was, well, let's say, unsuccessful. Andrey initially thought that the problem might be in the context window limits, i.e., in the amount of information that AI can simultaneously hold in RAM, so to speak. Then he tried GPT4, but before that, he pre-loaded it with documentation for the API of this very ticketing platform, and the result was significantly better. But here's what's interesting. Mike Savchenko himself expressed the assumption in the webinar that the issue here is most likely not so much the window size. Yes, >> yes, absolutely correct, >> but in the approach to providing information itself. >> Exactly. This is a very important point. Having a large context window is, of course, good. It is a necessary condition for complex tasks, but it is completely insufficient. >> Uh-huh. >> As it was very aptly noted in that source, just loading a ton of information there, all the project files, all the documentation you found, team correspondence, maybe some old specifications, it's like dumping a real mountain of random details in front of the AI, a dump, as they said there, and asking: "Now, please, assemble a Boeing 747 from this." Well, yes, the chances are slim, to put it mildly. >> Exactly, the chances of success are slim, to put it mildly. It is much, much more productive to provide AI not with this dump, but only with the necessary relevant parts for the specific task. And clearly labeled. This is a part of the Boeing chassis, and this is the documentation for the engines of this particular model. Do you see the difference? >> Yes. So, not just quantity, but relevance and structure. >> Precisely. The window size is important, of course, so that all these necessary parts fit in there. But even more important is what exactly and most importantly, in what form, how we put this information in there. We need not just a lot of information, but the right information, structured, relevant to the task, presented in a way understandable to AI. And the ability to prepare and present this information is precisely what context engineering is. Not just giving AI a fishing rod, but giving it the right bait and showing where the fish are. >> Uh-huh. Okay. If the problem is in the context and approach, and not just in the window size, then how does all this look in practice? The webinar actually reviewed a very specific methodology that Mike, as I understand it, uses himself when creating plugins with AI. It seemed to me an excellent illustration of this very context engineering in action. Can we go through it step by step, >> which demonstrates these principles of context engineering in real work. There are indeed several key stages, and not only each step itself is important, but also their sequence. This is important to understand. So, step one. Let's call it immersion in the environment or collecting source files. First and foremost, you need to download all the source code of the platform, the system for which we are writing the plugin. Whether it's WordPress or some automation platform like N8N, or, say, an application builder like Bubble, it doesn't matter, the entire core code of the system is needed. This is our foundation. This is the initial basic context. Without it, AI will act, well, practically blindly, guessing. >> Uh-huh. Okay, downloaded the code. What's next? >> Step two. Training and indexing. We load these downloaded source files into a tool, for example, into the same Cursor that was mentioned. And here's an important point. A good tool doesn't just store these files somewhere, it indexes them, meaning it analyzes them, breaks down the project structure, dependencies between files, classes, functions, studies the internal APIs of the platform, any code style conventions that are adopted there. It effectively builds a detailed, well, you could say, mental map of this codebase for itself. It begins to understand how this system is structured internally. >> Aha. So, it doesn't just see a set of files, but understands the connections between them. >> Precisely, it builds a dependency graph, understands where everything is located, how modules interact. This is critically important for the next steps. Step three. I would call it ground truth check or local launch. This is a very, very important practical step. You need to ask AI, now familiar with the code, to generate instructions. How do we run this project from the source code locally on our developer computer? >> And preferably without any complex wrappers like Docker, if possible. Just so that it can be run and debugged. Why is this so important? >> So that we can immediately check changes. >> Exactly. So that we can quickly make the changes that AI will suggest in the next stages, and immediately check locally if they actually work, how they affect the system, if we haven't broken anything. This speeds up the development and debugging cycle many times over. >> Logical. What's next? Step four. Let's call it calibration or small changes. Before rushing into battle, writing some complex functionality, it's very useful to start small. Ask AI to do something very simple. For example, "Please find the menu item named 'Settings' in the admin panel code and rename it to 'General Settings'." This is a kind of test. A check. Did the AI correctly understand the project structure after indexing? Can it find the right places in the code? Can it make correct, albeit small, edits? This helps calibrate the interaction with AI for this specific project. Step five. Finding relatives or analyzing analogs. Now we ask AI, our trained and calibrated assistant, to search within this loaded code for existing plugins, modules, or just pieces of code that do something similar to what we need to create. Perhaps there is a plugin that also integrates with some external system, or a module that adds a similar interface element, and AI, having the code map, can do this quite effectively. >> And if such an analog is found, >> found - that's just great. We take it and give it to AI as a sample, as a reference. And based on this specific example, we clearly describe to AI: "Look, there is such a plugin, I need to make a similar one, but with these changes." Or "I need this new functionality, integrate it the same way it's done here." Do you understand what's happening? AI now has not just some abstract technical specification. It has a concrete example of how similar tasks are solved in this system, how to integrate with the core, what platform functions to use, what code style is adopted. >> Aha. >> This sharply narrows the space for errors and hallucinations. Yes, exactly. This dramatically narrows the space for hallucinations, for choosing incorrect approaches, for generating non-idiomatic code, and works not in a vacuum, but relying on the best relevant example from the existing codebase. This is a key moment of context engineering in this case. >> Uh-huh. And if, well, a direct analog is not found, >> then step seven. Adaptation and combination. If there is no direct analog within the system, the strategy changes slightly. You can look for examples of similar functionality implementation elsewhere, in other libraries, frameworks, open-source projects, >> find suitable pieces of code or approaches, and then ask AI to adapt them to our target platform, but based on the same project map that it built in step 2. That is, not just to copy someone else's code, but to competently integrate it into the architecture and API of our system. Possibly combine ideas from several sources. >> Understood. Also working with context, but already with external context and adaptation. And the eighth step remains. >> Yes, the eighth, but not the least important. It's information accuracy or direct documentation. We're talking about documentation for APIs, platform functions, libraries that we use - a very important point. Instead of letting AI search for this documentation itself on the internet, >> where it might find something outdated or incorrect, >> precisely where it can easily stumble upon an outdated version of documentation, some unofficial guide with errors, Stack Overflow, or simply irrelevant information. Instead, we should find the up-to-date official documentation for the APIs or functions we need ourselves and provide AI with a direct link to it >> or even copy the relevant piece of text directly into the context. This ensures that AI will rely on correct, fresh information, not on its outdated knowledge or random finds on the web. >> M. So, if we summarize this methodology, it seems the whole idea is indeed to, well, as Mike put it in the webinar, prepare the food for AI as thoroughly as possible. Not just to throw it a task: "Make a plugin," but to provide all the necessary ingredients: the platform's code, examples of similar things, and accurate documentation. And in addition to that, to give clear instructions at each step, these very subtasks. And all of this together, it, as it were, greatly narrows the scope for possible errors, for misinterpretations, for the AI choosing unsuccessful solutions. Did I grasp the essence correctly? >> Absolutely correctly. The essence is precisely in this, and it includes not only providing this relevant information, code, examples, documentation, but also another important aspect of context engineering - decomposition, i.e., breaking down one large complex task - writing a plugin - into a sequence of small, manageable subtasks, the very steps we discussed. And for each step, creating clear, unambiguous specifications, instructions for AI. That metaphor with the culinary recipe that was mentioned in the webinar is very, very fitting here. It's not enough to know what dish we want to get in the end. You need a precise recipe. >> A list of ingredients and steps. >> Precisely, the list of ingredients is our prepared context: code, docs, examples. And the step-by-step instruction is our decomposition and specification for each step. And, by the way, AI can help us write this recipe, i.e., create a plan, a specification. But it is our responsibility as engineers, as developers, to check this recipe, to make sure it is complete, logical, that it meets our taste preferences, i.e., the project requirements, that all steps are feasible and lead to the desired goal. We manage the process, and AI helps at each stage. >> Uh-huh. Okay. We've dealt with plugins and methodology. But there was another case in the webinar that, frankly, caught my attention with its non-standardness. It was about transferring a landing page, a rather complex landing page made on the popular Tilda no-code platform. And it turned out that a simple request in the style of "take this website link and transfer it to HTML CSS JS" didn't work. And, as they said there, it simply skipped entire blocks, couldn't figure out the intricacies of the code that Tilda generates. Well, it's quite specific there, right? How was this task solved then? Was context engineering also applied there? But how? >> And here, indeed, a, well, let's say, non-trivial approach was applied, which also perfectly illustrates the very idea of context engineering, but from a different, visual side. >> Uh-huh. Since direct analysis of complex automatically generated HTML, CSS, and JavaScript code turned out to be a difficult task for AI, well, it couldn't parse this structure correctly, Mike decided to approach it from another angle. >> From which one? >> From the visual one. Look what was done. Step one was to take a full screenshot of the entire landing page. A really long, long picture that captured the entire page from the very header to the very footer. >> Uh-huh. This screenshot was saved as a regular graphic file. Well, say, JPEG. >> Just a picture. >> Just a picture, yes. Step three. This picture was fed to AI, specifically to the same CURSOR tool, because it has image analysis capabilities. It has so-called vision. >> Uh-huh. And what? Asked AI to write code from the picture. >> Not immediately. Step four was an intermediate, but key one. AI was given the task to analyze not the website code, but this picture. And based on the analysis of the picture, to create a detailed block structure of the website, i.e., to describe in text what are the main visual blocks on this page. Here's the header, here's the banner, here's the block with some advantages, here's the application form, here's the footer. What is approximately inside each block? Text, image, button, icons. How are these blocks positioned relative to each other. >> Uh-huh. So, AI itself created a specification, but based on the visual. >> Precisely, it generated a structured description of the task for itself, but not from the code, which it didn't understand, but from the visual image that it could analyze. This block diagram, in essence, became that very clear, understandable task specification. And only then, in step five, based on this structure generated by AI itself from the picture, it was given the command: "Now, please, write the code for the landing page with this structure and this approximate content." >> And what was the result? >> The result, according to Mike, was very interesting. The generated code was not only working, it correctly displayed the landing page, but moreover, it even turned out to be better than the original in some ways. >> Better. In what sense? >> In terms of code cleanliness and, consequently, possible UX user experience. That is, AI, creating code from scratch based on a clear structure, made it more logical and cleaner than what was automatically generated by Tilda. >> Wow. Using a picture as a prompt, as context for code generation. I would never have thought it was possible. This is, well, a completely different approach to context. It turns out that we are, as it were, looking for that language, that format of information, in which AI, at the current moment, for the specific task, will best understand what is wanted from it. Sometimes it's source code, as in the plugin example. Sometimes it's a clear text specification, and sometimes, as here, it can even be a visual diagram, a picture. >> Absolutely correct. These are all different forms of providing context. And the ability to choose or even create the right form of context for a specific task is the mastery of context engineering. This is another example of that very engineering in action. Finding a way to convey the essence of the task to AI in the most understandable way for it. >> Yes, impressive. And if we look ahead, what does all this mean for the future of programming in general? The webinar voiced a thought that, well, might seem a bit provocative to some, that programmers as such will not disappear, but perhaps soon we will all become, well, a little bit programmers. How should this be understood? >> Yes, this was one of the key conclusions or, let's say, predictions that were made in the discussion. And the idea there was deeper than just everyone will code. It was emphasized that the very essence of a modern developer's work is far from just, and not even so much, writing lines of code. According to Mike's estimate, which he cited, an experienced specialist's actual coding process, well, typing on the keyboard, might take only about 20% of working time, or even less. And the remaining 80% >> And the remaining 80% or even more goes to other things. Understanding the business task, communicating with the client or manager, designing the system architecture, decomposing a large task into small ones, writing these very specifications and instructions, searching for optimal solutions and technologies, testing, debugging, refactoring. That is, in essence, the main work is creating detailed instructions and monitoring their execution. And AI is now rapidly learning to take on this routine part of writing code based on ready-made, clear instructions. >> Uh-huh. So, AI is like the executor, and the human is the task setter and controller. >> Mmm, in a sense, yes. And the need for people who can create these instructions, i.e., clearly formulate the task, break it down into logical steps, provide all the necessary context, which we've talked about so much, and critically, then check and evaluate the work results, and this need, it not only doesn't decrease, but on the contrary, it increases. It turns out that natural language, our usual human language, is becoming a kind of new programming language, a language for setting tasks for AI. But this language requires no less, and even more engineering discipline, precision, unambiguity in formulations, than traditional code languages like Python or Java. >> Because if the formulation is unclear, then AI can understand it in any way. >> Precisely. Therefore, the key skills for a future specialist working with AI, not only in development, become systemic thinking, the ability to decompose complex tasks, the ability to create clear, consistent specifications, the ability to manage context, and, of course, the ability to critically evaluate the result. A good example with tests was given. AI can generate a lot of unit tests that look absolutely correct, use the right frameworks, run and pass without errors, a green light. But if you look closely, it might turn out that they don't actually test anything properly, they test themselves or some trivial cases, so-called empty tests. >> And only a person who understands the essence of the original task can notice this. Yes, only a person who understands the business logic, the context, the goal of this module, can understand that these tests are useless, despite their formal correctness, and AI is not always capable of this yet. Therefore, the role of a person as a task setter, architect, and quality controller is only increasing. >> Uh-huh. Yes, this changes the perspective. Were there any other, perhaps more down-to-earth practical tips or observations in the webinar? Like for those who are already using AI in their work, or planning to start, especially in development? >> Yes, there were several such useful points that stem from the practice of applying these context engineering approaches. Firstly, regarding project structure in AI tools. A specific recommendation was made. If your project consists of several logical parts, well, say, a frontend React, a backend on Node.js, some deployment scripts, then it's better to keep them in separate folders, but definitely within one common workspace, one workspace in a tool like Cursor. >> And why specifically like that? >> This helps AI better understand the overall structure of the entire project. It sees all parts simultaneously. It's easier for it to navigate relative file paths between these parts. And it can correctly separate contexts when you work with the front-end, then with the back-end, without confusing them. In general, for complex projects, this is important. >> Uh-huh. Understood. Structure is important not only for humans. What else? >> Secondly, about writing specifications for AI. We've already said they should be clear, but there was also advice on the format: use the most concise and unambiguous syntax possible. For example, Markdown with its lists, headings, code highlighting. It's well-suited. >> Uh-huh. >> The main thing is to avoid fluff, i.e., unnecessary words, to avoid ambiguity, synonyms for the same important concept within one spec. Do not duplicate information unnecessarily. The clearer, shorter, and stricter the specification is written, the fewer tokens it consumes from the model's limited context window, and this is important, and the more accurately AI will understand the task, which will ultimately lead to more predictable and high-quality results. Fewer chances for misinterpretation. >> Uh-huh. Conciseness and unambiguity. Understood. Anything else? >> Yes. The third important point concerned teamwork with AI. This, I think, is a very relevant problem that will only grow. Imagine several people working on one project, and each actively uses their AI assistant. If the team lacks common, clearly written standards and rules on how we structure the project for AI, how we write specifications, what context we provide for typical tasks, then chaos can arise very quickly. Why? Because each developer and their personal AI instance can form their own local ideas about the project, their own code generation habits, their own implicit agreements. And this will inevitably lead to code inconsistency, discrepancies in architectural solutions, in approaches, everyone pulling in their own direction. >> Yes, I can imagine, each AI pulling the blanket towards itself. >> Uh-huh. Or in its own direction, yes. Therefore, having unified guidelines, common specifications, standards for interacting with AI within the team becomes even more important than before, otherwise it will be very difficult to maintain and develop such a project. Okay, thank you. These were indeed useful practical tips. Let's try to, well, somehow put it all together. What is the main idea, the main conclusion that runs like a red thread through this entire discussion of materials and the webinar? >> I think it's precisely this fundamental transition from simple, perhaps even a bit naive AI requests in the style of "Let's do it badly." To thoughtful, purposeful management of the information we give it. i.e., to that very context engineering. And it seems that this is the key, the key to effective, predictable, and, most importantly, truly useful work with AI, especially in such complex, precision-requiring fields as software development. >> That's right. >> Yes, absolutely correct. You have formulated the main idea very accurately. Context engineering is not just another hyped term that will soon be forgotten. No, it is, in essence, a set of necessary skills, methodologies, approaches for working with modern, powerful, but still not omniscient AI systems. This approach requires deep understanding from us, from people. Understanding not only the task itself that we want to solve, but also understanding how AI thinks, well, "thinks" in quotes, of course. What are its strengths and weaknesses, what are the limitations of current models, those context windows, so that we can provide it with information, be it code snippets, links to up-to-date documentation, clear text specifications written in Markdown, or even visual interface diagrams, as in the Tilda example, provide it in a form that will be most digestible for AI, most useful for solving the specific task here and now. This, apparently, applies far beyond programmers and developers. I think this skill of correctly formulating a request, preparing and structuring context for complex intelligent systems, is becoming more universal, >> in demand in almost any field where we try to use AI to solve tasks that go beyond simple internet information search or generating some template text in science, analytics, medicine, education, everywhere where precision and predictability are needed. >> Absolutely correct. It's becoming a 21st-century meta-skill, if you will. The ability to effectively interact with complex systems by providing them with the right context. >> Uh-huh. >> And in conclusion of our today's dive, I would like to offer a thought for reflection. It seems to me, it logically follows from everything we have heard and discussed from the webinar materials. If AI is indeed taking on more and more of the technical implementation, i.e., answering the question of how to do something, writing code, routine operations, >> Uh-huh. >> Isn't the main value, the main complexity, the main intellectual load shifting entirely to the human specialist towards the most accurate, deep, and comprehensive definition of the task itself? >> Uh-huh. That is, towards answering the questions, what exactly needs to be done and, perhaps even more importantly, why are we doing it, what is the ultimate goal. >> Uh-huh. >> And won't this require all of us in the future to have, well, almost perfect clarity of thought? True engineering rigor in setting goals and developing specifications, much greater rigor and clarity than was required of us before, when we could figure out a lot as we went along. I think this is something to think about. Yes, thank you for this deep and detailed analysis of the sources and for this final thought. Indeed, there is something serious to ponder. That's probably all for today. Thank you to everyone who was with us. See you again in our next dive. M.