Transcription
Code agents are changing how software is created. Modern large language models can work for days, hours, and even weeks, performing complex refactorings, running, and fixing tests. They can even create a browser or a C language compiler from scratch, with which the Linux kernel can be compiled. But to make working with a code agent truly effective, one must understand how it works. And at the beginning of this year, the team behind one of the most popular code agents, Cursor, released a guide in which they shared best practices for development with code agents, using their product as an example. And in this video, we will delve into the fundamentals of how a code agent works, and examine important stages of planning and context management. We will figure out what capabilities can be used to extend the agent's behavior. We will look at a number of typical workflows that will be applicable regardless of the task you are solving. We will also consider a number of advanced techniques shared by the CУРСР development team. And the first thing to start with, but which many often miss, is the concept of agent architecture or harness, or as it is also called, framework. Agent harness. It sounds complicated, but in reality, you need to remember that there are three main components. of this instruction, what guides the behavior, they include the system prompt and various rules that supplement it. These are tools that extend the capabilities of a large language model. For example, editing files, searching the codebase, executing some commands in the terminal, calling mcp tools, and so on. And, of course, your prompts, the tasks you set for the agent and direct its work. An interesting fact is that the Cursor team actually makes the work of a specific model truly effective under the hood. And they say that they specifically tune system prompts for each model individually, because different models can be trained on different data. Some prefer the terminal more. some models need more explicit instructions for running some verification commands, and so on. The first and one of the most important stages is the planning stage. And task planning, according to the Cursor team, and they even conducted special research, distinguishes experienced specialists from beginners. And for planning in Cursor, a special mode is provided, called "plan mode", within which the agent does not actually write code, but sets up the task. It searches for suitable files, explores the codebase. If there is any variability or ambiguity, it will ask clarifying questions. After that, it will create a complete plan, which will include instructions, code examples, possibly architectural diagrams, as well as a relatively small task list of decomposed tasks that it will perform. And after the plan is created, it waits for approval, confirmation from the user. The plan is a regular Markdown file that you can save in your project and use, which the Cursor development team recommends doing. There is one piece of advice they give regarding working with these plans, that if you have formed a plan, carefully reviewed it, and started execution, meaning the agent started writing code and possibly got confused or started doing something you didn't expect, then the best thing you can do is to rewind, correct, or completely replace the plan, and restart execution. This is actually much faster and more effective than trying to correct the agent's behavior using some prompts or adjustments. The next important topic, of course, is context. Cursor developers say that the most frequent question they are asked is: "When should I create a new chat?" "And when should I continue an existing one?" And there is, in principle, a simple enough recommendation: if you are starting work on a new task or new functionality, please start a new chat. If the agent starts getting confused, forgetting things, doing the wrong thing, that's also a good reason to start over. In cases where you are continuing to iterate, returned to it after some time, the best thing you can do is to take the old chat and continue working in it. Or, for example, if you have completed a task and are debugging it, fixing errors, the current dialogue will contain all the necessary context for the agent to do it as effectively as possible. What if we created a new chat, but we need some information from the previous one? The logical approach is to take the information we need, copy it into the new chat, and, in general, continue with the new task. But Cursor developers say that you should not do this. You should not manually copy any data. It is better to use special commands to refer to previous dialogues. And this is much more effective. Why? Because using this command and the search capabilities available in Cursor, semantic search, the agent will select and add only the most necessary information to the new dialogue. That is, it will find and select a semantically correct piece or pieces, or even a summary, and this will be better than you copying the entire history. Also a counter-intuitive recommendation: if you don't know where certain source codes needed for context are stored, it's better not to specify them. Provide the information you know, and the agent will select all the necessary sources to form a complete context independently. Developers say that they have a very, very powerful semantic search system, many commands that allow them to effectively find all the necessary information. And this will be much better than you forcibly putting in absolutely useless, huge chunks of context yourself. It should be noted that context is a very, very important component. Cursor has special elements that allow you to see how filled the context is, to make a decision about whether it's time to start a new dialogue, for example. Plus, under the hood, Cursor makes huge efforts to keep this context effective and minimalist. And by and large, they apply two approaches: static, so to speak, and dynamic. Dynamic refers to calling tools, which often, in large numbers, occupy a significant portion of the context window. And the second thing that can take up space is large results of tool calls or command calls that are saved in a fairly simple abstraction, a file. That is, all the outputs of commands, console utilities, Cursor tools are redirected to a file and can be effectively searched using these files. And they did an internal benchmark and are proud of the results. They managed to reduce token usage by almost half, by 50%, when calling some MCP tools. The next area is how we can expand the agent's knowledge and behavior. For this, there are several such approaches, a conditional division into static data, which is added to the context, and dynamic. In reality, developers themselves consider so-called rules to be static, and skills to be dynamic. You can draw a simple analogy, that a rule is like a light bulb that constantly shines, and burns electricity or consumes tokens from your context. And skills are like a motion sensor that turns on only when necessary. Rules, in reality, can be considered static only conditionally, because the current implementation of Cursor allows setting rules that will be loaded intelligently, meaning the agent will decide for itself whether it makes sense to load certain rules. By type, rules are divided, or by scope, rules are divided into, the most common are project rules, which define all the information that is important for the agent about your project. Rules that act globally are called user rules, they define things that are specific or important to you. For example, you like the agent to be concise, or, conversely, to explain everything in detail, or to write, I don't know, always in Russian or in English, something that will act globally regardless of the project. There are also rules that apply to commands, and they are available in the enterprise subscription for large teams and organizations. And an additional possibility. Cursor supports the AgentMD standard, which can also contain various rules needed for the project. A rule is, by and large, a text file located in a special directory Cursor Rules, and there can be several files there. Accordingly, it can contain a textual description of some important features, knowledge in your project. Project structure, build commands, testing, possibly some code, style, naming conventions, maybe some workflow attributes, what to do and when, and so on. The development team recommends keeping rules concise, easily understandable and maintainable by humans, and containing the absolute minimum of information needed. They do not recommend inserting voluminous guides, absolutely complete descriptions of all possible variations of corner cases, rare instructions into rules. And they give the advice that in reality, you should start with the absolute minimum and add these rules as needed. That is, if you see that the agent made a mistake in something or did not take into account some recommendation, which you repeated three times in the chat, that's a reason to consider writing down that rule, for example. The next capability to expand the agent's knowledge is called Skills. This is also a package of instructions, which is already a standard that Cursor supports. Initially, this technology was developed by Anthropic, made it open-source, and now most tools support it. Skills can include not only instructions, but also various executable scripts, document templates, some data. And this makes skills a very, very powerful capability for agent extension. Skills can also include additional automation capabilities that Cursor has. These are custom commands or slash commands, also called. And, such a concept as is probably the only deterministic automation tool available. These are scripts that can be executed before or after certain agent actions. This is how a so-called skill template looks like. The main thing is that in the upper part there are metadata – the name and a brief description. Brief why? Because the standard stipulates that, I think it's no more than a thousand characters. And in reality, it is precisely these limitations that make using skills so effective. That is, the full description is not loaded into the agent's context, but only these metadata are loaded. And based on the name and description, the agent can choose in which case to use a particular skill, if it is not explicitly specified. The next tip from the Cursor team is that modern large language models are very good at working with images. I confirm, I have used this capability many times. And there are essentially two main scenarios. The first is when we have a design in the form of an image, or possibly a design from Figma, that we want to implement. The second scenario is so-called visual debugging, when we have made some implementation, built our application, but we don't like something. And instead of describing in words what needs to be done, what to change, it is enough to send a screenshot with a brief instruction about what you don't like there, that something is not aligned, is the wrong color, or, for example, is not visible. And it must be said that Cursor supports working with images by simply pasting a file, or you can take a screenshot and paste it into a dialogue with the agent. But also, there is a truly amazing tool called the browser, which makes front-end development extremely efficient. This is how it looks when open. a browser tab from which you can, using Cursor, for example, refer to some element and link to it in the chat. In this case, the author asks to improve the syntax highlighting in this editor. Of course, this is not the only possibility. This built-in browser allows you to take screenshots, allows you to see practically the same tools that we have in Chrome Dev Tools or Firefox Dev Tools, i.e., see the console, see the tree, all properties, and even manage the layout. And, of course, the browser can be used by Cursor in cycles of checking, implementing some functions. That is, you can tell it to look at how the page looks yourself. One of the frequent scenarios, for example, is when you are too lazy to check mobile layout yourself. For example, you can ask Cursor using its built-in browser to check how the page looks on different devices. This can be very useful. Or instead of describing some errors, just say: "Check if everything is okay on the page." There are several typical workflows. The first is test-driven development. The agent also works very well with version control systems, with Git and GitHub through a console utility. It is naturally very useful to use the agent for code reviews at various stages of the task implementation process. And, in general, a typical scenario is diving into some new codebase. You can, of course, ask questions, ask for explanations of how something is structured or works. And they even have a cookbook of such workflows that can be effectively applied. Well, let's go through a couple of them. Test-driven development usually includes two or three phases. First, we write tests first, not the implementation. We run these tests, they all fail because we haven't written the implementation. We open a new dialogue, a new chat, or another agent, and ask it to write the implementation so that the tests turn green. Accordingly, they turn green, the functionality is ready. And the third step sometimes includes refactoring. If we rushed and made a simple solution instead of an elegant, universal one, then in this case, we can quite calmly refactor and not be afraid that something will break, because we always have tests that the agent can fix. The next thing that is very convenient to use is command sets. That is, we can create a small automation for actions that are repeated many times day after day, so that they can be quickly invoked. And such actions, in reality, include, for example, everything that works with source codes, with the version control system, sending changes, creating a request, or possibly writing documentation, running linters, and so on. And these slash commands can, by the way, be used, as I already mentioned, in skills. This is what it looks like. It's a regular prompt that contains an instruction, which can include, for example, the use of console utilities, in this case, a utility or GitHub. Using slash commands can greatly speed up such routine daily recurring operations. Code review is another scenario where code agents show themselves very well, and of course, code reviews can be done calmly in a chat. That is, you can ask for a review in a dialogue mode, and even mark some things, but Cursor provides several elements that can be used more effectively. For example, if the agent has completed the task, written all the code, we can switch to the review mode, where we see all the changes it has made. And in this mode, we have a button to find and fix some errors, i.e., to do a review. Another option is in the version control system panel, there is a separate section called Agent Review, where you can review all changes relative to a branch. And, accordingly, if errors are found as a result of this review, they are automatically corrected. Moreover, these things, buttons, need to be pressed explicitly. And there is also a setting in Cursor that allows you to do this review automatically. That is, you can put a checkmark in the settings, review all changes upon commit, and then the agent will do it completely automatically. So, we have covered the main scenarios and capabilities. And now for some advanced techniques. The first advanced technique is parallel use of agents. Cursor has a special mode and a special layout for displaying page elements, where the agent is in the first place. This is a mode that allows you to conveniently work with concurrently running agents. Moreover, parallel agent work is quite effective. The Gtworkt technology is used and supported, where even when working with an overlapping codebase, agents will not interfere with each other. The main recommendation, of course, is not to overdo it with concurrently running agents, but, for example, my typical scenario. If I have completed the planning of a number of tasks, I have a plan, then I can easily start executing this plan in parallel. And this is probably the most frequent scenario where one or two, at most three agents can run in parallel. The second scenario supported by Cursor is parallel work, but with different models. That is, they allow, for example, to try to make some complex decisions with different models, compare the results, and choose the most optimal one. The image here shows an example of such a comparative task solution. The next advanced technique is the use of cloud agents. Cursor developers themselves say that tasks that you would otherwise postpone, add to your to-do list, are suitable for cloud agents. When creating an agent in the Cursor interface, you can choose to run it in the cloud and continue working with the results, for example, on website.com in the agents section. Or from a browser, from a mobile device. Typical cases include bug fixes, documentation, some simple refactorings. So, the last concluding advanced technique is the use of a special mode for solving complex bugs, but in reality, there are quite a few applications for bug mode. It is activated in the chat, just like planning mode, bug mode with a red bug icon. The technique used is actually what an ordinary developer would do anyway. That is, if he cannot understand what is wrong, what does he do? He makes several assumptions about where a particular error might be located that leads to the unsatisfactory result. And having made these assumptions along the entire chain, he usually adds some logs to see what is happening during the process. And based on the result, he finds the point, the place where the correction needs to be made. This mode does exactly the same thing. It makes assumptions, instructs with logs, and tells you how to proceed, how to reproduce. Then you reproduce the behavior, it reads these logs and draws some conclusions, corrects errors. As a small conclusion, the Cursor team says the following: developers who get the maximum benefit from using agents are distinguished by several principles. The first principle is a maximally clear, specific task definition. Second is gradual improvement and correction of all processes of working with agents. That is, we start with some small instructions, rules, add as needed. If a workflow is established, for example, we make pull requests three times a day, then you can create a slash command. You update the documentation regularly. You can create such an instruction, do not immediately try to bring all possible automation methods into your project, but gradually, incrementally, build your own workflow. The third thing is the principle of control. That is, a code agent works very quickly. And sometimes it may seem that the written code looks great, but this does not mean that it is good and high-quality. And attentiveness to analyzing the results produced by the agent is a very important component. Moreover, the earlier you participate, for example, at the planning stage, the fewer surprises and problems you will encounter in the result. The fourth thing is the use of mechanisms that will allow the agent to understand that it has done everything correctly. These are tools such as writing tests, linters, checks that can be done automatically, type checking, checking code conventions. And the last thing is that all these developers treat the agent as a colleague, and, accordingly, if something is unclear, they ask for an explanation or clarification of the implementation, or if they disagree with this implementation, they can criticize it, discuss it. That is, it is an open dialogue. Applying these principles together with the knowledge they have provided about capabilities and approaches in Cursor can make working with a code agent truly effective and productive. What I want to say is that Cursor is a very mature tool. We have used many different tools in our practice, tried them for research purposes, and Cursor is not slowing down, it is constantly actively developing, adding new features that make work easier and more productive. We use this tool every day and teach it in our programs. The nearest programs are available on the website lstart.ru. The very next one starts in about a week, on Saturday, February 21st. This is the fastest way to dive into working with code agents. And if you want to delve deeper and learn to create full-fledged full-stack applications or create React or multi-agent systems, then in March and April, two programs start: AI Driven Full-Stack Development and AI Coding and Agents. I also want to note that we have a Telegram channel AI Dialogs, where we publish more useful materials. If you found this useful, please like it and subscribe. That's all from me. Thank you all. Goodbye everyone.