Transcription
Hello. Yes, the videos are getting a little, and the videos have started to drag on a bit because I have exactly two weeks. Today is March 9th, when I'm recording this video, but most likely it won't be released on March 9th, well, maybe it will be on the ninth. And on the twenty-second, I have a race. This is a serious race. Well, out of all the races I've had, this is the most serious race. That's why I'm preparing now. And I have the best coach in the Russian Federation, from the Russian Federation, from the Russian Federation, I don't know, for trail running, I won't say who yet. I've been working with him for 2 weeks, and he's just a killer. And, in short, if I suddenly have a free minute, I try to either eat or sleep. That's it. But a free minute is from work, from family, from training, from something else, well, from some household chores, worries, and so on, like insurance, paying bills, paying taxes, filing taxes. then I try to rest somehow. So, for example, this week, right now it's Monday, March 9th, I have a day off, uh, a day off from training, but this week I will have six training sessions. That's it. And on some days I will have two training sessions. This will be the last intense week, in theory. Next week, I will most likely... Well, okay, why am I even telling you all this, as if it's all interesting to you. Uh, in general, I hope you've poured yourself some tea. Today we have a very big, interesting topic, a controversial topic, and so on. DevOps, and not just DevOps, but Copilot vs. Cloud Code. Hello, Kladi Petrovna. Without being tied to any programming language, and so on. We, we, I will try to tell you something interesting, and you just draw your own conclusions and be sure to write about it in the comments. Sorry that I'm filming everything on the webcam of this MacBook, but what can you do? I ran around for half an hour, you know, with a camera, without a camera, where to put it, where to put it, how to record it, how to record it, then I just decided to record something, because I could have been writing something for half an hour already. So just turn it on in the background and enjoy life. In general, in DevOps, there's a strange thing. Well, more precisely, in the world of DevOps. Like, on the one hand, every month they tell us that AI can do almost everything, everything in this world. It writes code, fixes bugs, understands repositories, speeds up teams, almost builds the platform of your dreams while you drink coffee and engage in architectural thinking. And on the other hand, a real DevOps day, well, it looks approximately not like that. Well, I would even say not like that at all. Like, you open your laptop in the morning and don't see a revolution in software engineering. You see that your pipeline has fallen, or something else, and they're already trying to call you about an incident. In fact, you have, well, anything could have happened, or maybe the secret didn't get pulled, the job in GitLab or GitHype Actions fell, and Terraform suggests demolishing half of this world because someone just corrected a module or just changed something in this module. Somewhere in Kubernetes, a service is down, somewhere Kubernetes, more precisely, your health check is down, and somewhere it's not. Somewhere a Helm chart seems valid, but still, you get some kind of crooked construction of values, templates, conditionals, and human self-confidence. And in general, at this moment, the question is no longer about which AI model writes a function more beautifully, but the question is different. Which AI can really help a DevOps engineer, a platform team, platform engineering, SRE, infrastructure engineering, automation engineering, or even just someone who fixes pipelines, corrects, writes Python scripts, sorts out YAML files, and then spends the whole night looking for why their application is still giving 502 errors? Because it's almost never about one specific language, one specific problem. For example, there are Java developers, right? Well, they have the Java language, they might have different modules, like Spring Boot, I don't know, like fourth from fifth, I don't know what versions there actually are, like eleventh from thirteenth, and so on. For us, it's a whole wondrous world. And I wouldn't be surprised if somewhere SREs, DevOps, and platform engineers are still sorting out Java code for the Java developers. In general, yes, it's not about one language in DevOps. Today it's YAML, in half an hour it's Bash, then Python, then Go, then Terraform, then the Terraform you just wrote needs to be put into Terragrunt and everything needs to be put in order. Then Dockerfiles, then Helm charts, well, it can be anything from HashiCorp, in short. Then some policy, then API documentation, then incidents, then you get called, then they come at you with sticks, then security comes, or rather, they don't come, but they say: "Let's add security somewhere here, and something will be interesting and unclear at all what it will be built on." Then Prometheus queries, log configs, environment variables, custom resource definitions, admission controllers, and a couple of pleasant surprises to make life seem linear. I hope I've listed at least a quarter of what you have to do, especially every day. That's why in this episode, I want to talk about Copilot, about Codex, about Cloud Code not as tools for programmers in general, but as working tools specifically for DevOps. Probably, it's no secret to anyone that in our entire information world, IT world, right, the main link for us is the developer, but there have become so many developers, and currently AI is replacing a part of developers very well. It's clear that some developers understand well, analyze different channels well. In short, some developers are simply hard to replace, but nevertheless, all sorts of juniors and so on are easily replaced. Well, not entirely easily, but many are replaced. And Codex decided to participate in the podcast too. But DevOps is a bit different. And like, and under the DevOps, well, no one has written, like, about engineering, all this AI stuff, AI stuff is more focused on development rather than troubleshooting. So let's look at the tools specifically for DevOps. Not from the perspective of who codes better on one file, or rather, not the tool, AI, but from the perspective of who helps better with YAML and infrastructure code, who is more convenient in the shell and terminal, who understands infrastructure repositories better, who helps with troubleshooting, who is more convenient for CI/CD, who interferes less, and who is more suitable for a real working day where you don't sit for 8 hours in one main.go file. You jump between tools and system layers with different types of tasks, and so on. And separately, one can say, or rather, highlight such an important thing that I will not pretend that there is one absolute winner. This is a favorite human fairy tale, like choosing one totem, better X, rather, writing better, writing X better than Y, and then getting your comments and leaving satisfied. But in DevOps, everything is completely different for us. And you know this for sure, you know this. Our tasks are too diverse. Like, the difference between these is no longer so much in the quality of the text, but in the way of working. One lives better in the GitHub process, the other is stronger as an AI for real engineering work. The third is especially good in the terminal, in deep agent automation. So let's try to figure out who is for what. I am currently using two, but maybe I'll talk about it later if there's time. Why can't DevOps be evaluated by the same criteria as regular development? Like, when people discuss AI for code, they often unconsciously look at the world through the eyes of a regular application development task. Like, there's a project, there's a codebase. You sit in a file, write code, check tests, make pull requests, and like, well, that's a real scenario. But for DevOps, it's too narrow, because DevOps almost always works in several planes at once. The first plane is code itself. You can indeed write code in Python, Go, Bash, or something else. Well, now, well, not now, but Rust is also becoming more popular. But it, in theory, has always been popular in certain circles. And many wanted to write in it. Just when you study something, write something, you yourself, if you don't sit for a year, well, you won't know anything about Rust. Well, it will be harder to remember. Okay, in general, okay, I'm distracted again. When someone comes to work with you, or takes your place, in Rust, most likely, they will understand it even longer than you. Even if you haven't written anything in it for a year. So, in any programming language, we write something. This can be internal utilities, automation scripts, API bindings, generators, small services, operational tools. The second plane is declarative infrastructure. Terraform, Terragrunt, Helm, Kube manifests, and config files, CI/CD configs, and so on. The third plane is operational reality. Logs, metrics, traces, errors in pipelines, broken environments, misaligned configs, incomprehensible side effects, network problems, access problems, timeout problems, problems where everything seems green, but the system is already dying, or has long been dead, but everything is still green for you. And the last plane is communication and artifacts, like READMEs, runbooks, PR descriptions, issues, migration plans, module documentation, rollback step descriptions, comments for colleagues who will curse you in six months for this damn YAML. And when you evaluate for DevOps, you need to ask not only if it can write code. Well, this is like Codex. We had only one line, two words, and we're talking about everything else. We need to ask, can AI, can AI switch between these planes? Can it maintain the context of the system, not just one file? Can it run commands and test hypotheses? Can it make edits carefully, and not cause a refactoring apocalypse? Can it be useful where the task is not to write from scratch, but to understand what is actually happening? This, in general, is the main difference. For DevOps, the most valuable thing becomes not the best autocompletion, but the best working cycle. That's why in 2020, it's not enough to ask who writes code better. The correct question would be: "Who is more convenient to go through the full cycle of an engineering task?" GitHub Copilot today already goes far beyond autocompletion, including a coding agent for coding on GitHub. And IDE plugins, well, for example, if we take Visual Studio Code, you can connect Copilot directly into the IDE. Code review and different scenarios. Codex, for those who don't know, is from OpenAI. This Codex is positioned as a coding agent with a cloud, a separate application for parallel agent work. For those who don't know, you can also connect Codex to Visual Studio Code. Cloud Code focuses on working directly in the terminal, using CLI tools, MCP, sub-agents, and other ways to integrate agents into the existing engineering stack. What are these three AIs arguing about? It's tempting to reduce everything to a very primitive scheme. Well, you have to start somewhere. Like, Copilot is supposedly corporate AI. Codex is supposedly smart, or rather, the smartest agent. Well, it's still OpenAI, after all. And Cloud Code is Claude. I don't know, I want to call it Claude. This is supposedly the favorite of people who live in the terminal. There's a grain of truth in these images, but they are too flat overall. In reality, these are three different answers to the question of what engineering work should look like. And the first approach we have is as an integrated participant in the GitHub process. This is its strong suit. It's clear that Copilot is from GitHub, and they will do everything to integrate Copilot into their main tool. If your life revolves around GitHub and issues, well, in short, everything related to GitHub and corporate workflow and all that is built around GitHub, then Copilot not only helps write code but is integrated into the process of moving this task forward. It will help work in the IDE, and act as a coding agent locally, it can take a task from GitHub through a coding agent and work in ephemeral environments. For those who don't understand, it's like, God, stateless, stateless environment. That's it, I'm broken trying to explain these terms. In short, something that doesn't need to store any state, meaning it can be seen at any time, started from scratch, and so on. So, in general, Copilot can run in an ephemeral environment based on GitHub Actions, run some tests, linters, understand the first pull requests, and so on. And Copilot also has code review, where it looks at changes directly in your pull request. The second approach is AI as a full-fledged agent for daily engineering work. This is where Codex from OpenAI comes in. Here, the idea is not only to integrate into one platform but to give you a universal coder that can read code, edit files, run code, work locally through the CLI, and if necessary, go to the cloud mode or to an application where several agent streams can be coordinated. In Codex, skills like reusing a set of instructions, resources, are developed separately, and the product itself is increasingly moving towards multi-agent work on long tasks. So, from this, a picture is emerging, you just need to understand how all this can be set up. The third approach is AI as a configurable engineering environment, and this is Cloud Code. Here, there's less of a feeling of "just another function in the IDE" and more of a feeling that the agent is sitting right in your work environment. Cloud Code works in the terminal, can use your CLI tools, has IDE extensions, supports hooks, MCP, sub-agents, experimental agents, and so on. In short, Cloud Code is more, especially more interesting for those who don't just want suggestions, but want to build their own engineering ritual. And here it's important to understand from the beginning. This is not just a debate about the quality of the response, it's a debate about where the AI lives. In the GitHub process, in the local engineering cycle, in the terminal, in the cloud, in several parallel agents, in merge requests. For DevOps, this is especially critical, because the place where the AI lives directly affects how useful it will actually be. And my main thought in advance, to put it very briefly, so that you understand where we are going, is that for DevOps, it's more important not which AI writes code better, but which AI better navigates the chaos of engineering context, which I talked about for the first, I don't know, 20 minutes, maybe. Well, not 20, the first 5 minutes. So, DevOps tasks have unpleasant properties. Tasks can be long, multi-layered, often semi-exploratory because it's unclear what's going on. They are often tied to certain commands, environments, and side effects. They rarely boil down to a single language. They are very often associated with the risk of breaking something somewhere. Especially if we are digging, starting to dig in production. And the more your work resembles "make a change here and here and check the pipeline, run the linter, explain the diffs, update the documentation, don't break the contract, understand why Terraform plan suddenly suggests something absurd." Checking this is related to values and some environment variables, variable names, and so on. And then prepare a rollback. In general, if your tasks are related to all of this, then the less you need just some smart code completer. Just imagine you're writing or want to create some utility. You go and open a GPT chat and say: "Here are my thoughts, or rather, here are my thoughts, and write me code in Python." And like, when you want to work with AI in DevOps, to do real, normal, real, normal tasks. You can do real tasks, you can feed logs, the main thing is to make sure there's no data leakage of any personal data or anything, tokens, secrets, I don't know, personal data, and so on. You can feed logs, metrics, everything to ChatGPT. It will just tell you where to look. You go, you look. But this is not the approach you would want to get from AI. It's just an assistant that might have saved you half an hour, an hour, maybe a day, so you don't have to debug yourself, check a million things. It could have told you that 90% of it will be somewhere here. And look, give me a little more data. So, we live in a world where we would like our work to be easier, more convenient, and we could use that time to research or drink tea, for example. That's why you need more of an agent. An agent is no longer just some AI, an agent that can read a project, understand its structure, run commands, make multi-step changes, maintain discipline, not turn your local change into an architectural novel of, I don't know, four pages. And now we can try to analyze the tools that are already available more realistically. Copilot is best where DevOps already lives within GitHub. Well, that's clear, of course. The biggest mistake people make when discussing Copilot is thinking of it as the old Copilot from the era of "find Tab, get a piece of code." This Copilot has long since grown. And now Copilot is not just autocompletion, not just a chat. Although that's actually a very good, convenient feature. For example, in Visual Studio Code. Well, I mentioned the first AI where I use it, Visual Studio Code. And there I have Copilot. Yes, it's 90-95% accurate in what I want to do, what I want to change somewhere, what I want to add, complete, and so on. It understands what I'm doing, where I'm doing it, and automatically inserts values where I need them, where I will further insert these values. So, now Copilot is a combination of several modes. It's working in IDE mode with autonomous local edits. There's a CLI, there's Copilot Code Review, there's a Copilot coding agent that works through GitHub, like taking tasks, opening merge requests, and so on. Overall, a fairly tight integration into the GitHub process. This is more important than it seems, because for infrastructure tasks, teams very often have a strict process. Like, there's a repository, there are issues, there are pull requests, there are code owners, there are reviewers, there are actions, there are policy checkers, there are environment protections, there are templates for pull requests and issues, and there are some mandatory steps before you can press the merge button. In such a system, Copilot is not an external smart assistant, but an integrated part of the existing machine. Where is Copilot better? Especially good for DevOps. Firstly, it's better for incremental work within an existing process. For example, you have a repository with GitHub Actions, modules, and Python utilities. You need to add some new workflow, like fix reusable actions, update variables, and at the same time, don't forget about documentation. And Copilot in the IDE can help you move quickly through these small edits, like writing YAML blocks, suggesting a template for some step, I don't know, building a matrix, helping with Python scripts, generating, in short, you can generate a lot of things. And secondly, it's especially logical where the task is already well-formalized. For example, you have a task: "Add drift detection for a Terraform module on pull request. Extract duplicate workflows into a reusable action. Update README and ENF template." Such a task doesn't necessarily require you to write every line. It requires a careful, managed pass through the repository and the standard GitHub flow, workflow, sorry. And here, the Copilot coding agent looks strong. It takes the task, works in a separate action environment, makes changes, runs tests or linters, opens pull requests, merge requests, depending on preference. Then you finalize it through review. This is very powerful for routine and moderately complex infrastructure tasks that fit well into the backlog and don't require live investigation in a production terminal. Thirdly, Copilot is convenient where the DevOps team already thinks of GitHub as the platform center. If infrastructure as code, pipelines, automations, operational runbooks, all of this is located somewhere in GitHub, then it doesn't require a significant cultural shift. You don't teach the team to live in a new way, you just strengthen the current system. But of course, Copilot also has its weaknesses. Let's talk about some compromises. DevOps tasks often don't fit into a neat issue-PR scenario. Like, there's a task, there's a pull request. Many tasks start not with an issue, but with some symptom. Deployment failed. A plan is strange. Terraform plan behaved unexpectedly. Some network degradation appeared. Error rate suddenly increased, pods crashed, some Helm chart didn't apply, module version mismatch, compatibility broken, someone updated providers and everything went haywire. And here you don't have a well-defined task. You have an investigation, what needs to be done, how you will do it, and so on. And for investigations, for terminal troubleshooting, for diverse engineering tasks, Copilot is not always considered the most natural tool. Yes, it has a CLI, it has an agent mode, which greatly expands its capabilities, but its strongest suit is still that it lives within GitHub, the GitHub process, not the philosophy. Like, I'm spending half a day going through system layers, running commands, testing hypotheses, looking for the cause, and gradually building some solution, which might later go into a task. So, Copilot is good for DevOps if your team likes a formalized workflow. Well, it's more like bureaucracy, but if historically it's happened that way, or you want to achieve it, then it's great. If the team lives a lot in GitHub, wants integrations into reviews and merge requests, often does tasks that resemble normal engineering cards, and spends less time in chaotic terminal investigations. In general, in general, yes, my thoughts got mixed up, sorry. Codex. Next up is AI and Codex from OpenAI. A very strong option for DevOps in general. When the work consists of long engineering tasks, now Codex, again, thoughts, ugh, everything. Okay, I'll take a sip. And in general, in my opinion, DevOps is entering a very interesting territory with Codex, because DevOps engineers rarely need just an editor assistant. They need someone who can go through a long, multi-step task with them. So, open the repository, understand its structure, find where the workflows, Terraform, Helm, scripts, utilities are located, make changes, run commands, look at the output, correct, check again, prepare a diff, explain what has changed. It is for such a mode that Codex currently looks very strong, and it really can work like that. Like, Codex is officially described as a coding agent, again, that can read, edit, run code, but it's available through IDE extensions, like Visual Studio Code, for example, you can add it. Cloud scenario, a separate Codex application designed for coordinating multiple agent streams with workflows and long tasks. Plus, skills like a reusable set of instructions, scripts, resources for a specific type of task are being developed in it. That's why Codex is more interesting for DevOps, because DevOps tasks often look like a chain of work. For example, update a Terraform module, understand which environments it will affect, update Terragrunt bindings, add CI validation, update README, generate migration notes, check for discrepancies in conventions, don't break the old environment or vice versa. Add a new service to the Kubernetes platform, prepare a Helm evolution, add a pipeline, describe secrets, configure probes, add monitoring, update runbooks, check rollback. Well, it sounds like a regular, regular DevOps task. Well, not a regular DevOps task, by the way. We've just all gotten used to thinking that this is a regular DevOps task, although it shouldn't really be done by them. This is not just generation, it's a whole engineering chain, because this engineering chain can affect many different repositories. Codex is good because its entire construction is focused not only on response but also on execution. Like, the CLI makes it mostly natural in terminal life. And the extension is useful when you move away from local work with context in the editor. There's a cloud mode. And when, well, the cloud mode is more for when you want to offload some tasks, some parallel agent work, and look at them as a portfolio, not as a single chat. What does this give DevOps in practice? You can have simultaneous tasks for Terraform, GitHub Actions, and utility for inventorying something, migrating some values or deploying another Helm chart, I don't know, debugging flaky pipelines. So, Codex provides the ability to run multiple agent tracks in parallel. This is no longer a pretty toy, but a practical thing. That you can spread out. And yes, with such an approach, soon, well, in general, juniors don't do it that often.
They hire, and everyone wants some kind of seniors, engineers, and you just have five seniors sitting there, and with such an approach, a couple might sit. Here. And even then, just so that one can replace the other when one is sick or on vacation. This is precisely why, in general, the idea of Codex Application as a command center for several agents looks especially logical for DOPS. Officially, it is presented as an interface for managing work agents in production workflows and long tasks Across, well, like between projects. For engineers whose work does not fit into one session and one file, this is exactly what is needed. Here. Well, and like Codex is especially strong in devops task types. These are repository changes on several layers, when you need to touch the transformer, the documentation, text files, and scripts, and shell at once. And then there are research tasks in the codebase. For example, like a big request to understand how secret rotation is currently implemented across all internal tools, where it is duplicated, and to apply some kind of unification. These tasks often kill more time than the actual implementation. And here, an agent who can walk through the repository for a long time and gather this whole picture, which you can then tell everything about, is good. Well, of course, it might not be 100% correct, but nevertheless. Here. Well, and then there are some repeating operations, devops operations. Imagine, such things can repeat for you, like preparing a new terraform module readme, validating terraform configurations with some layer layouts, generating changelogs for infrastructure code, a template for checking helm charts, checking naming and tagging policies, parsing some CP according to an internal template, and so on. If you can wrap all this into a reproducible set of instructions, auxiliary scripts, the agent starts working not just effectively. Well, like, you take some steps to do something, well, to do your task. If they are repeated, you can automate them with the help of an agent. Here, Codex will help us. Here is the entire sequence of intelligence and half of intelligence, because random creativity in infra is a luxury that is usually paid for by other people. Here. And the skills in Codex are described as reusable, like instruction templates and reusable script instructions, resources for reliable execution of certain tasks. Where can Codex be inferior? There are two typical cases. The first is if the team, the team in the sense not of a group, but a team like you and I as two colleagues, we are a team. If the team is rigidly tied to GitHub as the main production circuit, then it's better to look a little at Copilot. The second disadvantage, or rather, where it can be inferior, is if you need not just an agent for engineering work, but an environment that you deeply customize according to your terminal workflow, like permissions, hooks, third-party tools, and special roles. Then some people are drawn to low-code. But if you look at it through the eyes of DevOps, where the work is multi-layered, long, not always linear, and often requires a combination of local and cloud modes, then Codex looks, well, more serious, even very serious. Well, and that's it, we've reached Cloud. Cloud, this is perhaps the most native, by feel, tool specifically for DevOps. I will probably say something provocative. If you detach from hype brands and comment wars, many DevOps engineers like Cloud not because it writes code better, but because its rhythm is very similar to DevOps work itself. Like DevOps lives in the terminal, DevOps loves tools, DevOps constantly switches between contexts, often solves research tasks. DevOps values control over its environment, over environments, and DevOps does not trust beautiful promises without a reproducible process. And Cloud is precisely the product that resonates very well with this style. It works in the terminal, can use CLI tools, has IDEs and integrations, well, like everything else. It supports MCP for connecting external systems, hooks for automating actions, subagents for specializing roles. There is also an experimental agent Teams for parallel work of several sessions. It also has a strong emphasis on the Permission Model and Sandbox, so that you don't turn into an automatic confirmation of dangerous commands. Why is this strong specifically for DevOps? And more precisely, why? Because, well, the task often starts with the words: "I need to look, I need to study something." And then there is no beautiful specificity. Like, I need to see why the pod is restarting, see where the drift is coming from, see how the layer is assembled in general, see what the new provider broke, see who is injecting this field into the Helm template, and so on. I need to look, I need to understand, I need to investigate. And, well, like, there is no specific information that can be fed somewhere, like instructions. So it turns out that the task is initially research, then diagnostics, then engineering, and then documentation. And when the tool initially feels natural in the terminal and can work alongside your utilities, like Helm, Vault, Kustody, OS client, and so on, then the feeling is very right. Like, I'm not opening a separate AI world, but AI is entering my already real working circuit. And what do hooks, MCP, subagent give to the DOPS team? Probably one of the most interesting parts, because for ordinary development, hooks and subagents sometimes look like pleasant but not necessarily exotic things. But for DevOps, it can be very practical, like hooks. Hooks are generally a very cool thing that was discovered 10 years ago and many started using, but not everyone fully understands what they are and how they can be used. Hooks allow you to automate, automatically launch actions based on any events. For example, after editing certain files, formatting, linting, and template validation can be automatically run. You won't believe it, but in Git, in any GitLab, GitHub, and so on, you have a gitconfig file. There, okay, I'm [laughter] gitconfig is completely irrelevant here. And you have all sorts of hooks, like pre-commit and so on. And before, like, making a commit, you run some checks, the same linters, and so on. Yes, this can be done without any AI, without any AI. That's it. Accordingly, let's continue. What can be automatically run if you don't run it? Like terraform formatting, terraform validation, some helm linters, yaml linters, kubernetes config, tf linters, terraform formatting, well, in short, everything related to formatting, linters, and so on. If you suddenly need to check something, you can also do it, look at one of my previous videos about Helm. You can create a schema for a helm chart and also validate something just in case. Well, in general, all this routine that people usually forget about, and then remember after the third comment in a pull request. Well, remember, like, you upload something, then you say: "I forgot to fix the README, I forgot the formatting." Or "I'll test it now, and then I'll do it again." And, in short, you get five merge requests. Official hooks in Cloud Code support various events, even advanced ones like asynchronous hooks and MCP to hooks. Well. And what is MCP then? In general, MCP is a very important topic for DevOps, because it provides a standard way to connect the agent to external tools and data for infrastructure work. This means that the agent can potentially live not only in the project's file system, but also get more structured access to GitHub, databases, internal services, inventories, documentation, and other parts of the engineering environment. Anthropic directly describes MCP as an open standard for connecting agents to external systems, which has already become the de facto common way of integrating tools and data. Well, yes, I've already said a lot, so, yes, I need a sip of this, a sip of tea, and let's go on. Accordingly, next we have subagents. This is very easy to apply to devops practices. Like one subagent is a terraform reviewer, the second is a yaml validator, the third is an incident bugger, the fourth is a README writer, and so on. The idea is that you don't keep everything in one mess, you distribute everything into your own roles. And officially, it is described, subagents are described as specialized assistants with separate contexts, their own permissions, toolsets, which help maintain context, limit tools, and specialize behavior for specific domains. Like for DOPS, where it is very important not to mix research, changes, and validation into one, well, any uncontrolled flow. This can be very powerful. Here. And after we've talked about all sorts of things in Cloud Code, we can say that Cloud Code is very good for devops tasks. Like the first is terminal troubleshooting, which is when you need to execute commands, read output, test hypotheses, and move on. This is almost our native environment. Some multi-step infrastructural changes, when your task is not for one file, but for a whole chain of dependencies, like module, environment, deploy, validation, rollout, runbook. Then there is a configurable engineering environment, when you don't just want a helper, but one who will work according to your rules, with your hook scripts, with your restrictions, with your roles, with your connected tools. Well, and if, well, I wanted to say, to be honest, or rather, we also need to touch on the disadvantages, like Cloud Code is not fully utilized where the team is ready to invest in the working environment. If you need the simplest, fastest, and organizationally predictable start within GitHub, then Copilot is obviously faster. Well, if you want products where the main idea is a universal coding agent for everyday use, then, well, like between, Application, then it's Codex. Here. And Cloud is good when you like not just to use AI, but to build an engineering circuit with it. That is precisely why many DOPS people find it especially their own, so to speak. Here. And, well, and it turns out, God, that's it, eh, I wish I could cut all this out, but I promised I wouldn't. Well, yes, the most honest thing is that Cloud Code reveals itself to those who are ready to invest in the working environment. If you don't want to develop and create your own beautiful infra, cool infra that is covered with AI, and in this infra AI does a colossal amount of things, then, well, Cloud is not for you. Here. And if you already have a huge infra and it's difficult to change it, then perhaps Cloud won't cover many things in your infra, won't take on many tasks, won't cover them, then it's probably better not to take Cloud either, it's better to look at Codex. Here. Accordingly, let's compare a little more by task types. We've already talked a lot, and we need to go back and discuss again what, precisely, based on the example of which task, which of the AIs is better suited for us. Like segment one is YAMLs, Kubernetes, Helms, values, manifests. If you have a lot of YAMLs in your work, then, well, like, this is bad news for you in general. AI still won't get rid of YAMLs for you. Like humanity, apparently, still has to go through this trial. But seriously, many people are initially enthusiastic and then disappointed. Why? Because YAML is often not a task like writing some text. This is a task not to break some structure, not to lose indentation levels, not to violate the schema, not to confuse types, not to shift values, and not to forget that on the other side there is also a Helm template with some special values, and so on. And Copilot for YAML and Helm. It's generally good when you need to quickly add or edit some familiar pieces directly in the IDE, like completing deployments. Suggesting some probes, assembling some workflow templates, adding environment variables, and so on. Well, or maybe fixing some service accounts, ingress annotations, volumes, and so on. Like, when the inline work is going on, it's very convenient, yes, it's really smart, I'm telling you, it understands 90-95% of my requests, it knows what I'm going to do. Especially if you're sitting in Visual Studio Code or some other editor where all this is open, well, it speeds up your local editor routine with YAMLs. But if the problem is not in writing YAML, but in understanding how charts, overlays, applications, environments, configs, CI, and so on are connected across the entire repository, then hints are definitely not enough. Here's how Codex works with YAMLs and Helms. Codex is strong here when the task is broader than a single file. For example, you can feed it a folder and say: "Find where we have repeating patterns with resources, probes, across three charts, unify it, update it by environment, check some templating, prepare diffs, and so on." You can feed several folders at once, you can give several paths, and so on. This is already more like some kind of, well, devops task, well, one of the typical devops task variations. And for this task, an agent that can go through the repository like a system and not just, well, add some block. Like, insert this here. You've changed something somewhere. Here's how Cloud Code works with YAMLs. It's pleasant when YAML is just part of the process. Like, you change values, then run a deploy, see what came out, then lint, then some checks, Kubernetes, then you look for why, I don't know, the generated manifest doesn't match expectations, and then you go to the template, then you look at a related secret. That is, here, the winner is not the best editor and YAML generator, but the best agent for multi-layered validation. By feel, Cloud Code here, well, here it is often very organic. Organic, yes, it's more suitable here. Here. But like, if you do it manually with Copilot, if you need something more and to find connections, dependencies, write something new based on this, or rework something, or make changes in many places at once, then Codex and everything related to checks, validations is Cloud Petrovna. Accordingly, in other words, a little shorter, Copilot is an accelerator for editor work, a YAML editor, a new profession, Codex is stronger on end-to-end repository changes, and Cloud Code is when YAML needs not just to be written, but to be run through a series of checks and research. And I suggest we finish the podcast here today. It's already 47 minutes long. And there will be a second part where I will finish my thoughts. And you write in the comments which AIs you use, in which IDE, how you configure your agents, what you do with AIs in general, what tasks you might solve. And write what, I don't know, typical devops tasks you solve. Maybe every day, or every other day, or something else. The second video, or rather, the second podcast in the same format, will be released after the first part. Don't forget to give a thumbs up, write comments, and have a good day everyone. Bye-bye. M.