Transcription
Greetings everyone on AI Dialogs. And today the topic is code and AI Driven Development. Alex, hello. Hello everyone. Well, let's talk today about how the company Anthropic applies the AI Driven Development approach. Today we will analyze an article from Anthropic's engineering blog, which is called Best Practices for Agent Programming or Coding. It's not such an ancient article, in principle. And overall, of course, Anthropic talks about best practices in relation to their own tool. Well, that's logical. But at the same time, of course, there are many tips and recommendations that, uh, are general, as if they are easily transferable to any other tools even without any extrapolation. Both console-type and, in principle, even integrated environments, such as Cursor, uh, or whatever you prefer. And let's go through this article. There is an ideological basis here, how they created it and why this tool is good, and any other similar to it. In principle, one can draw such a conclusion from this. and recommendations on how to use it effectively from the perspective of, like, configuration outside the environment and workflow approaches, and from the perspective of directly using the capabilities of the Clotcode itself. Well, they say, clдкод was born as, you know, an experimental project. Engineers used it, integrated it into their work in various ways. Everyone differently. And, in principle, it is a tool that is integrated at the lowest level without any specific processes, specific limitations, directly into the models. And this is a kind of philosophy of absolute flexibility, customizability, and such powerful diverse use of this tool. That is, its flexibility is its core advantage. And it must be said that behind this flexibility, there is a certain complexity, and they note that, of course, in principle, such a tool needs to be learned to be integrated into one's work, to stumble a bit, or to develop some approaches to apply it effectively. And, in principle, they say that in fact, below there will be recommendations. This recommendation is essentially just a starting point from which you can push off to configure your own processes, your own approaches to work, because nothing, no recommendation is a dogma or an absolute recommendation that works well. That is, each developer within their team, competencies, their own principles, will build their own workflow that will be most effective for them. And let's go in order. So, uh, well, clod code is a console tool, it runs in the console, it can be integrated with some environment quite natively, uh, for example, with VS Code or with Cursor, meaning it can use some functions of this environment. But the very first and probably the most important and conceptual thing, again, is that all work is built on automatically providing context to the prompt, that is, to some instruction that you give in one way or another. And this is all, firstly, like tokens, secondly, it's speed and efficiency of work. Therefore, this prompt, this context, must be of high quality. For this, they use, an instruction, a special file called clд MD. This is a default file that allows you to set this basic prompt for your project. Well, and they say that, in general, you need to treat it carefully. In principle, everything that concerns your project is recommended, it is important, you need to know, and, in principle, you also need to indicate there, used commands, some important points regarding the project structure or implementation features that need to be noted, some important coding style conventions, for testing, for naming anything. Well. Everything that is important for building, running, testing, it would be good to indicate there. Because any task always has several solution options, for example, how to run a Python file. You can come up with 10 ways. Naturally, the language model, if not explicitly instructed, can use different tools at different moments for various reasons. Therefore, everything that concerns your project, please put it there. And what they recommend using. There is no specific format. They suggest keeping it simple, concise, so that a person understands this file. Here's an example, yes, please run the linter like this, or rather, perform type checking, JavaScript code style is set like this, and, like, a certain process. This is the very, very base. And it must be said that, well, if, I don't know, consider other tools, then all other console tools have exactly the same files. Gemini has its own file, Codex has its own file. And in general, even if you didn't know about this, or you use some other one, for example, in Cursor, then it doesn't matter at all. Something that describes your project. And in relation to clod-code, they say that it is probably also useful to know about this, because it can be used not only with this tool. They say that this file can actually be placed, for example, in the root of your project repository or in the root of your project. If it's some kind of monorepo with a large number of projects and you want to share it with the team, commit it. If you don't want to share your own processes, you can ignore it. And you can build a whole chain of such instructions right up to your home directory, which will add some recommendations and instructions to the prompt, which will apply to all projects. And if this file doesn't exist, then you can always run the init command, which will automatically create this file. That is, clod-code will scan your files, your directories, get acquainted with the project, and write, in principle, everything that the project needs to know. And, what's next? This is the main instruction, as we already said, it is passed to the model along with, like, some dynamic recommendations related to solving a particular task. And it needs to be kept up-to-date, improved iteratively, and its structure, quality, and everything else should be checked. Of course, clod has tools with a hash sign. You can easily add some instructions directly to one of these file locations. And they say from their experience that in fact, we regularly, these files, their engineering and other teams run through a prompt enhancer, which clod also has, of course. This is the base. The project has been described, all agreements have been fixed. Next, in general, in principle, clod-code and console tools, by and large, are very effective code agents. That is why? Because a huge amount of work is done through the console. That is, in principle, even when we work in some integrated environment like Cursor, many tasks are solved by launching the terminal and executing some commands. Accordingly, the number of commands or available tools significantly increases the possibilities that, in principle, such an assistant or agent can implement. And they say that, please, in principle, add and manage, most importantly, the list of tools. Well, and the issue of permissions is considered here, yes, like, some of these commands can be quite dangerous in general, yes, like deleting files, editing, commits. Well, in principle, you need to be attentive and monitor. And clod, of course, has many ways to grant and manage these permissions. Configuration files, commands, various flags, but tools are important for solving tasks. Use tools, again, console tools, if you work with GitHub. That is, GitHub is a separate whole section of tasks, meaning it's a tool for collaboration, review, testing, CI/CD, task management. And in general, clod-code is very good at working with the GitHub command-line utility and doing various things. And besides the tools that are available from the operating system, that is, just various commands that an agent can execute, you can use more complex things with the MCP protocol or some APIs. And clod, of course, like any other modern tool, supports these technologies, but you need to understand that they are also not safe. And here, several options are proposed on how to use them safely, how to configure them. In general, add MCP, please, with caution and expand the possibilities. And the last thing that is said is that, in principle, Clod code knows the entire environment, if we talk about the bash terminal or any other environment, it knows all the commands, but it doesn't know the commands that you manually type, with arguments, for executing your tasks, it doesn't matter what it is, with source code, with testing, running, with everything. And it says that in clod-code and others there are such, in principle, variations of some regular tasks. Here it is called slash commands or customizable commands that are configured through, essentially, a prompt, that is, directly within the context of clod-code, you create a markdown file, write an instruction in it, you can operate and pass arguments. And here, by and large, is an example of analyzing an issue on GitHub by its number. That is, take a task, figure out what is written, and, like, complete it. Well, and here is an example of how to use it, how it is available in the command line with clod-code. And thereby you will expand the standard set of clod-code commands and get easy access to these regular tasks that are part of your workflow, your own. And this is the block that is related to the environment, so-called. And the next section is directly some recommendations for building workflows. Anthropic says that in fact, they themselves do not want to limit the tool or the use of agents in any way. And moreover, flexibility is the philosophy, but what they describe below are effective patterns that they observe or have taken from their engineering teams, and how they use them, and from their clients or from the community. They have aggregated them, and they do not differ from, in principle, the usual software development practices in general, either in a team or personally, it doesn't matter. And they are doubly important when we use language models, and let's figure out why. The first effective pattern is to understand the task, research it, then plan the implementation, then implement it. The implementation phase will be discussed in detail separately. This is, let's say, a high-level process, and the result is to commit the changes. Here, working with Git is an important aspect from all points of view. For fixing results, for using a code agent in general. The first phase, about how we deal with the problem, is to set the context as clearly as possible and ask the language model what we need to do. At the same time, the phrase like: "Please explicitly specify certain constructs when interacting," always appears. Why? Because, well, and in this case, it is said that in this research phase, collecting requirements, perhaps, or conducting some research, be sure to indicate that you should not write anything, no code, because if you don't say this, then any assistant, any LLM, Cursor, Clod code, anyone, even if you formulate your question: "How to do something," you will get the encoded result immediately, without approvals, without any agreements. It's good if you have a clotd md file where the desired programming language is specified. Well. And, in general, this research phase is a very important part of the entire workflow. Here they also offer, promote the capability of their clod-code as sub-agents. And in principle, people probably do this too, even if they don't call it a sub-agent. If it's some kind of long process, while waiting for generation, even for analysis, there's nothing to do. You can set a parallel task, in principle, in some Cursor. Just open a new tab and do another task. Planning phase. And, in general, it's also an important aspect that when you've figured out the task, some context of the future solution, meaning the solution itself, needs to be planned, and again, please explicitly specify, for example, recommendations in this case, thinking. So, plan, using thinking, or the capability that is in the dialog mode, by writing think, you stimulate the model to use reasoning. Moreover, reasoning is usually controlled, and there is a whole gradation. So, think, think well, think even better, think ultra. And in fact, all of this ultimately converts into some budget for reasoning tokens and, like, more thoughtful planning. And what's next? This is super logical. And in regular teamwork, fix the result, this plan in some document. Why? Because when you go to do something, at the next stage, you might not like this result. You will have to return to it and redo it. If it were just in a dialogue, then, of course, it would be difficult to re-explain what needs to be done and what went wrong. Therefore, in the form of a document or an issue, please fix the implementation plan, and this is also super logical. Then implement, let's figure it out. And send the result to the repository in any form. Pull request, commit, all that. And they note that phases 1 and 2, research and planning, are critically important. Without them, no implementation. In the context of predictable industrial programming, development, it is simply impossible. And this is, essentially, the foundation. The requirements that are fixed and decomposed significantly affect the speed of further development and the model's adherence to some instructions and task resolution. Next, how to implement. And they note: "Implement iteratively, please, commit regularly, and always with tests." Moreover, those who are involved in development have heard of the approach called Test-Driven Development. For those who haven't heard, it's when we first write tests, run those tests, the tests are red. Then we implement the functionality that makes the tests green. That is, we wrote a test, implemented the function, ran the test, it passed. Good. Accordingly, after that, we can do some refactoring, improvements, reliable changes. And they say that this approach with LLMs works very well. We personally confirm this with our practice. And again, they say, please specify explicitly. To get a better, higher quality result, explicitly indicate that we are using the TDD methodology. First, we write tests, no fake dummy mock implementation is needed. And then we run these tests, and within the workflow fixation, this can also be explicitly noted, that we first write tests, they become red, so we commit them, write the implementation, they become green, everything is fine. And so on indefinitely, until we do everything. TDD is a very well-working approach in the context of using code agents. And here's how you can use it. In principle, nothing supernatural, they remind you to explicitly and clearly state what you need. Plus, the recommendation for iterative development is also to decompose. Ask the LLM not to run all test suites at once. You wrote the implementation, run only that test, that specific testable function. Accordingly, this also greatly improves both speed and quality. How to write code and not just code in general? Monitor the result. Provide as much context as possible to both a human and a code agent. They note that CLD-code and all modern models understand texts, images well, can read logs. And MCP technology allows easy integration with external systems, to see what was written to the database, to see what is actually on the screen, both from the perspective of implementing a function according to a mockup, and from the perspective of fixing an error. Well, we have this layout. I don't like the indents, or I want a style that I can't even explain, and I'm not a CSS expert. Please do it. The next recommendation is a mode that greatly increases efficiency. This is the so-called YOL mode, or when clod doesn't ask for permission every time for some actions, executing commands, creating calls to MCP, and so on. This is, naturally, a mode that super accelerates, but you need to be careful. If you are doing something that you know for sure and is not risky, then please, if it is risky, use containerization, run with a flag in a container that does not have access to something that can be broken. Further, this is not even a recommendation on how to conduct development, but code agents explain the codebase very well. Here is just a personal recommendation and addition that these sessions are perfectly done by converting them into project documents. If you learn something, immediately ask to save it as an instruction, as a document. Here I will only note that Git is a cool tool. Specifically, it's about the console version control system and console commands. It is very functional, very fast. Everyone works with it, it's the absolute industry standard, but it's incredibly unfriendly. Even the most experienced users get confused when working with Git, they shoot themselves in the foot, even if they love the console very much. And I have experienced this with LLMs many times. Working with Git in dialog mode becomes an excellent option. That is, you say: "I want to revert to the previous version, I want to merge some branch, I want to resolve conflicts." And even conflicts are resolved coolly without even looking, because the LLM can merge normally, even if changes were made to the same pieces of code. Also, as I said, they recommend working with GitHub, it can do a lot. In general, let's not dwell on it. And they also say that there is a format like Jupyter notebooks. It is also more often used for data science and machine learning specialists, but not only. You can, please, there are no special recommendations here. Except that the console and the file of this notebook should preferably be opened side-by-side in some VS Code, so that you can see this very dynamic format, it implies constant execution of cells. And in principle, the recommendation is that if you work with notebooks, open them like this, and it will be effective. There is a separate video about working with notebooks. Please watch it if you are interested. By the way, yes, a link will appear here somewhere, be sure to watch it. Further recommendations regarding how, in general, to interact with a language model, with an agent, it doesn't matter. It is very important to be clear and understandable. Express yourself in a limited scope. Well, here are examples of good and bad, like, it's bad to write "add some test." Why? Because, well, it's unclear what you'll get, mocks and so on. And God forbid to do such implementations. I personally confirm that I have gone through all these pitfalls. You will get a fantastic result, but most likely you won't be able to do anything with it later. Therefore, be concise, specific, clearly, clearly and understandably, as with people. Try to convey what you want to do. Context is very important to provide. For this, there are all possible tools. Provide images, screenshots, files, URLs, list paths within the project where to look. That is, it is very, very important to clearly state what, where, in what context, that is, to limit. LLMs generate code, documents, anything, with fantastic speed. They really like to do this, and they need to be constantly limited in this. If you are doing a large task, please decompose it, use lists. And they, in principle, speak in a rather abstract language. Just make some checklists, list them, and then take an element from this list as a unit of task execution. But in our work, we often expand this into more complex, understandable constructs, we divide work into iterations. Classic, in principle, usual development, provide maximum data. There are plenty of ways for this. We have listed them all. We will not dwell on it. There is a mode for automating CI/CD, there is a variant, in principle, of using. These are already tricks, meaning different models for different tasks. One model wrote a plan, another the implementation. One wrote a test and another checked it or wrote the implementation. From this article on best practices, it can be concluded that this can be replicated in any tool. And even several times better, which Anthropic itself convinces us of. So, yes, Alex, thank you for the detailed analysis of the article. I will analyze two reports that took place not so long ago, and company employees talked about the best practices for working with clod-code. They are both developers and constantly prompt in their activities and develop their own best practices and approaches for working with their company's model. My part summarizes some of the main points that were definitely in that article, because it is comprehensive. Well, this is like a summary of our dialogue, it fits perfectly. Clod-code is a helper, an assistant that works in the terminal. And, accordingly, what's coolest is that since it's terminal-based, it can work with any IDE, and, in general, with any tools that have command-line interface calls in the terminal, which is also very cool and gives us many, many possibilities. How does it work? Accordingly, essentially, it works in the terminal, possesses all the capabilities of creating, deleting, editing files, calling other tools, calling tools via MCP, with broad capabilities, gets acquainted with your project, studies it, in detail at the start, and accordingly, perfectly masters all information about it. In principle, it works, regarding security and safety. Everything is great here. You can configure separate permissions for it, to execute certain commands. Read, please, if you want to perform dangerous actions with my bash shell commands on the file system. We can limit this to make our work safer, if we run all this in some automatic mode. Accordingly, it suits any workflow, integrates with any tools that are in the command line. General purpose, accordingly, it will suit the solution of any tasks. That is, you can build anything you want with it and configure it as you wish. That's what's cool about it. It is suitable, essentially, for automating the entire product development lifecycle, software. Analysis, documentation search, onboarding, explanation. New employees when they join the project, tasks at the design stage, planning specifications, developing architecture, creating the development stage, essentially, writing code, writing tests, executing them, creating commits, pull requests at the automation stage, devops, deployment, support, in general, refactoring, migrating from one codebase to another project, in general, maximum broad use, in general. In our practice, we even use it more broadly, even more broadly. Sasha also showed design, presentations, and documentation, user documentation, lessons, and video lesson scenarios, test lessons, so, maximum use. Configuration, setting up the environment, configuration, yes, it basically analyzes the project at the start, creates all its main database that it needs for the project, places it in cloud md. And here you can also place various work rules, how it should work and according to our workflow, our projects. An important point was also discussed about context management. Accordingly, the Clear command clears the context. There is a Compact command that compresses it, summarizes it, and, in general, continues to work with a cleaner context. Well, and here on the slide, other commands, tool settings, configurations, theme settings, in general, enabling notifications, and so on, which can also be used. Effective workflow, yes, since plot is a multi-purpose tool, each is configured for themselves. Well, key moments, we noted planning, to-do lists, planned, did smart coding, when, accordingly, test-driven development approaches, regular commits, plan, explain, then do, then write tests, execute them. Use screenshots for implementation, for bug fixing, this is very, very helpful. General workflow: explorer, plan, confirm, code, commit, write test, commit code, iterate, commit, write, screenshot, result, iterate. Yes, we see this life cycle, a compact solution to one of the tasks. At the very beginning, if you are just approaching it, work as question answering, see where it executes certain prompts out of the box, where it requires more specific instructions, as recommended by Anthropic employees. Typical Q&A questions, what can they be? Well, please, how do I create something, why does it work like this, how do I fix this issue, in which release version was this or that. What did I do last week? Can it form a report perfectly? Configure, direct clod to use tools in your way. Again, we set a process. Suggest several implementation options for an issue. Implement what I choose. Identify the main critical points of implementation. Let's write tests, close the commit, push PR, used three parallel agents. By the way, about parallel agents, that's a separate story. It was cool. And they asked questions, and these guys themselves highlighted that the most advanced developers at Anthropic use four simultaneously running clods. But, in principle, even using two is already like level twenty. That is, this is like multi-clods, this use of parallel implementation, but it is, of course, beyond the usual typical use, for advanced gurus. Well, they recommend using escape to interrupt work, double escape to return to, well, to make a clarification in the current code work. You can expand with your own tools, if there are company tools, your own MCPs, train clod, use your tools, it's quite possible. You can write a prompt instruction and, supply it with a workflow for solving the task. Well, here are examples of how we connect our own tools and say in which case they can be used. An important point, of course, is to give it as much context as possible and tune the context, just like any language model. There are excellent approaches, the cloud md file, you can specify context via slash, specify file names, or accordingly, commit, mcp resources, connect to collect additional context. And examples, that CLMD can be your own personal user directory. It can be, so to speak, project-dependent. And in particular, if a dot is present, it will not be used only locally, it will not be shared among the team, which is a useful story, and memory and permissions can be distributed, you can additionally, embed specific parts into the context, connect files. Settings, commands, and so on. And accordingly, configure this Cloud MD, MCP servers, permissions for your team and send them to Git so that everyone can use them. So, that's it, the overview of these reports is complete. By the way, while you were talking, a very interesting thought was highlighted about, I might have missed it in my story and article review, that the Q&A section, well, it is quite important. To understand the code, often some answers to some questions, why it is implemented this way, lie in the history. And in principle, the ability of a language model to work with history, with commit history, the ability to see what was there before, what messages were written in commits, can thereby quickly answer your question, why the solution is exactly what you see. And the second very important point, which I also probably didn't emphasize enough, is that yes, a language model can do a lot very quickly, and it needs to be directed, and if you see that something is going in the wrong direction, then stop it. And Sergey said that there is a command for this, escape interrupts, double escape returns. But the point is, as soon as you see something wrong, and in this case, any tool can be used, you need to go back and redo it, correct your prompt, specify the task, or detail it in some way. Perhaps in Cursor, there are also checkpoints, you can restore and regenerate. Clod-code itself has a number of other capabilities, commands, functions, which do some automatic versions, hooks, and so on. Well, and of course, all this is growing. But the most important thing is that this flexibility allows you to build any workflow. And in fact, separate elements, attributes of this process, are present in any tool. Take, for example, a new Kir, it clearly has specrien built into the tool, specification, decomposition into user scenarios, and then implementation. And various hooks to automatically do, I don't know, tests, write documentation, and so on. If we take Cursor, then in Cursor it's project documents, sets of rules. Sets of rules that are automatically connected based on templates. From this, you can aggregate, extrapolate, that these recommendations, best practices can be implemented anywhere with any tool, and they stem from ordinary quality software development processes when there is a life cycle, requirements gathering, design, planning, implementation, and then iterative incremental development. And by and large, even before the existence of clod-code as such, with all the recommendations, we used the Cursor tool and in this tool actually built a similar approach. We call it an AI-driven approach. And we teach this approach in intensives. We talk about our methodology and reinforce it in practice by developing agents using Cursor. But this can be done, in principle, in any other. And this methodology includes all those aspects, in the form of rules, principles, templates, prompts, precisely best practices, which can be implemented anywhere, that is, in any assistant, on any project, personally or in a team. And these practices are reinforced by implementing various assistants, agents, RAGs, agents that make decisions independently, from simple to complex. Code assistants allow you to do this without writing code at all, in dialog mode. Even if you don't know programming, you can go through everything with iterations, with Q&A sessions, both technological and architectural, and problem-solving. Everything can be done quite calmly. And the practice of past cohorts already shows that analysts and business specialists can all create quite complex AI products using this system. We invite everyone with pleasure. The next cohort starts on September 6th. Please come, go to the landing page, familiarize yourself with the program, projects, and participant reviews. And for everyone who listened to the end, we remind you that we have a Telegram channel where we share and post more useful materials, links, some of our thoughts or project examples. Subscribe if you liked the video, give it likes, write comments, questions. We will gladly communicate. Thank you all. Goodbye everyone.