← все видео

The Agentic Engineer Workflow You Need In 2026

Zen van Riel · 2026-05-20 · 17м 11с · 48 785 просмотров · YouTube ↗

Топики: ai-loop-engineering

🎧 Аудио

📝 Summary

model=deepseek-v4-flash · prompt=summary-v7 · 5 710→2 084 tokens · 2026-07-20 11:48:19

🎯 Главная суть

Агентная инженерия с AI — это не про максимальную скорость генерации кода, а про умную параллелизацию, контроль контекста, качество через классические инженерные книги и реальную интеграцию с командами. Эффективный прирост производительности — 30–60%, а не 5x, и он достигается за счёт небольших, но принципиальных практик.

Четыре параллельных потока с разным уровнем усилий

Рабочий процесс строится вокруг четырёх окон Cloud Code, запускаемых одной командой T. Окна не равнозначны: top left и top right настроены на высокий уровень усилий (high effort), bottom left — средний, bottom right — низкий. Это позволяет одновременно запускать долгую задачу (например, «проанализируй код и предложи пять потенциальных фич») и быстрый запрос (например, «какие языки используются в проекте?»). Быстрый запрос завершается, пока медленный ещё думает. Предел в четыре потока — не случайность: ментальная ёмкость не позволяет эффективно контролировать больше параллельных задач.

Управление контекстным окном

В каждом окне отображается текущий размер контекста (printed on the bottom right). Когда контекст заполняется, AI начинает отвечать медленнее и терять фокус. Нужно периодически сбрасывать контекст командами compact или clear — момент определяется интуитивно по сложности проекта и текущей задачи. Универсального ответа нет, но чувство меры приходит с опытом.

Принципы вместо модных методик

Популярные техники вроде spectrum development или BMAT method — по большей части временные тренды. В работе стоит опираться только на то, что остаётся релевантным после 3–4 месяцев. Функции вроде встроенного трекера to-do в Cloud Code уже заменяют ручное ведение markdown-файлов. Вместо гонки за хайпом — фокус на фундаментальные практики, которые не устаревают через полгода.

Качество кода через классические книги

Для повышения качества AI-кода применяется команда smell, основанная на паттернах из книг «Clean Code» и «Design Patterns for Good Software Development». Она не учит модель с нуля — LLM уже содержит эти концепции, но команда «подталкивает» её в нужном направлении, заставляя следовать проверенным инженерным подходам. Вместо готовых репозиториев с промптами («ты senior-инженер, не делай ошибок») стоит переносить идеи из книг, которые создавали лучший софт в мире.

AI-ревью в связке с человеческим

Пулл-реквесты проходят двойную проверку: автоматическую (GitHub + AI-ревью платформа вроде Cloud Code Reviews или самодельный pipeline на headless Codex) и человеческую. До создания PR полезно запускать собственные команды ревью, но универсального рецепта нет — команда зависит от языка, сложности, стиля кода и предпочтений команды. Важно не полагаться только на AI, иначе в коде накапливаются долгосрочные баги.

Подключение внешних сервисов: bash vs MCP

Для интеграции с GitHub, Jira и другими системами используются два подхода:

Git worktrees для независимых параллельных потоков

Если четыре окна Cloud Code делят один git-контекст, параллельная работа в одной ветке ведёт к путанице. Решение — git worktree: создаётся временная копия репозитория, позволяющая работать в полностью независимых потоках. Cloud Code может создать worktree, переключиться на него, а затем удалить. Единственный нюанс — после создания worktree иногда нужно переустанавливать зависимости проекта. В таком случае стоит написать skill или сценарий, который автоматизирует этот шаг.

Реальный опыт: от фриланса до enterprise

Работа с AI-кодингом в разных контекстах даёт разные ощущения:

Мышление: vibe coder vs AI-native engineer

Выбор не в инструментах, а в подходе. Vibe coder гонится за объёмом и выживает рамки кода каждый день. AI-native engineer использует AI для повышения производительности, но понимает ограничения, умеет чинить сломанные системы и владеет полным стеком. Реальные инженеры, которые эффективно применяют AI на production-проектах, не кричат о пятикратном ускорении — они работают спокойно, получая 30–60% прироста в конкретных задачах.

📜 Transcript

en · 3 355 слов · 42 сегментов · clean

Показать текст транскрипта
I've shipped AI code on real engineering teams across enterprises and startups with code reviews, production users, and full accountability for everything that I merge. Today, I'm going to show you what my agentic engineering coding workflow looks like, which relies on real engineering practices. I will show you my parallel setup for any coding agents while sharing stories from our real engineering experience that will teach you how to speed up programming work. while preventing AI code from hurting you in the future. First, I want to show you how I work with coding terminals. In my case, I'm going to show you a shortcut that I have here that launches four cloud code windows by just typing T. And the reason why I create four cloud code windows is because very often there's an opportunity to parallelize some work with AI code, but not too much. I'm not going to pretend like I'm running 50 agents at the same time. My mental capacity is pretty much at four parallel work streams. This is just what I've discovered after working on multiple bigger projects together with real teams. And in my case, to understand my workflow, let's imagine that we're working on this application together. This is a bit of an auctioning demo app that's developed in both Python as well as Java. Now, these four terminals are not the same. If you've got a keen eye, you can already see that here on the top left, we have cloud code with high effort. Here on the top right, it's high effort as well, but on the bottom left and bottom right, it's medium and low effort respectively. And I'm doing this for a good reason. Some work that you need to delegate to an AI agent will take a long time to complete because it's a big batch of work. For example, I can start a new plan session in here and say scope. out five potential features we can work on i'm just giving it the opportunity to explore be creative now on the bottom right i can now ask a much simpler question explore the code base to tell me which languages are used and because this one is using low effort it will be done much faster with the agentic loop so now you can see that the top left is still going whereas on the bottom right we already have an answer to a question it's using java python html and a little bit of sql so based on this i know where certain tasks need to go in my work stream as we work in a chat you will see that eventually the current context window is printed here on the bottom right and this is very important because as your context window fills up not only will the ai take longer to respond but also it will eventually start to drift away from the intended context of the conversation. So you might be super familiar with this, but of course you can just run something like compact or of course clear. to start your conversation from a fresh context window. And here too, as you work with these AI tools, you'll get a feeling for when you need to reset the context window. There is not one magic answer to this. It depends on the complexity of your project, the complexity of your current piece of work. This is the whole point of being an agentic engineer. You need to just get a feeling for when to compress your context window. If you want to get access to my workflow, including all of the scripts to launch these windows, check out the link in the description down below. You might be wondering why I'm not talking about specific planning techniques like spectrum development or the BMAT method, or why I'm not talking about the difference between being a context engineer, a performance engineer, or an agentic engineer. And to be honest, it's because I think that a lot of these things are just gimmicks that don't really stand the test of time. Just think about all of the different AI projects that have become so popular over the past three years. How many of those projects are still relevant today? i'm not saying that things like spectrum development are a fad but i do think that anything that does work will just be rolled up into something like cloud code as time goes by like how clock code now has a good way to just keep track of to-dos you don't really have to screw around anymore and do that yourself with markdown files and this is honestly just the thing that i've learned i'm just awaiting the hype and anything that survives three to four months is probably a really good pattern to apply And you're not going to see anything in this video that won't be relevant anymore in six months. I'm only going to show you principles that will stand the test of time. So another aspect that's really important to understand is how do you get your code to a high quality? if you are an indie hacker or even in some cases a freelancer code quality might not be the most important thing because you are not necessarily accountable for code quality of course if you're creating your own business software eventually your customers will get into trouble if you're the one creating the bugs but at that point you could just fight code a fix right well in the professional world this doesn't really work because you've got a team that you need to work together with if you create 10 000 lines of code in an hour time How are you ever going to get the code into production are some commands that I use that really helped me out. And one example of this is this smell command. And this command is based on a couple of engineering patterns that I found super helpful from books that I read many, many years ago, including clean code, as well as architectural design patterns, specifically design patterns for good software development. so the smell command for example refers to the clean code book and clean code is a book that i definitely recommend you to buy but of course the concepts are already part of the language model but it can help to kind of push it into that direction by reminding it of a couple of concepts like this. And this way you can actually make sure that it follows the patterns from those engineering books. And to be completely honest, you can choose to ignore my advice and go out there and look at a prompt repository that has 60,000 stars on GitHub and just copy paste all of that and use prompts that say you are a senior engineer. code and do not make any mistakes. It's completely up to you. But if you want to get serious with authentic engineering, why don't you just apply the patterns from really good engineering books that have already been used to create some of the best software in the world. In any case, if you want to make a start with that, check out the link in the description below. Now, how about AI code reviews? What do I do there? Well, I actually do often connect GitHub to all kinds of AI code review platforms, whether it's a specific hosted platform like the newer Cloud Code Reviews, or just some self-created loop where I create some kind of pipeline that just automatically checks for my code using something like the headless mode of Codex. It doesn't really matter what you do here, but... I do think it's important to have at least some kind of AI review in your pull requests. The most important thing, though, is that you don't just rely on that, but you still combine it with human review. And in fact, I also have a couple of commands that I often run to do some of the AI code reviews before I create the pull request out of it. Now, I'm not going to share those commands with you. Why not? Well, because there is not one command that fits all. The right review command depends so much on what you're building. It depends on the programming language, the complexity of the work, how many human reviewers even are in your project and what their preferences are, what the code style is that your team agreed on. There is not one size fits all. Speaking of creating a pull request, how do I connect to external services using my coding agent? For example, it's super simple for me to just take this GitHub URL, go to Cloud Code. even the low effort one and say, create a test issue in this URL. It just already knows how to call the GitHub CLI and I'm already authenticated to it. So there's no authentication mechanism that cloud code is aware of directly. The credentials are already injected as part of my authentication workflow that I went through when I set up the GitHub CLI. And you have a click on it to go through directly. And there you go. nowadays there's a big discussion on whether mcp servers are really useful for this whether you should use a skill that defines how an api should be called or whether you should just use a cli as is you can of course just use the bash tool and with bash you can basically execute any kind of arbitrary script so you can use bash to execute say a simple python script that calls a web api maybe if the api is simple enough You can, for example, use curl to make a direct web request, or you could use some kind of special CLI. For example, GitHub has a CLI that you can use to create issues, create pull requests, etc. So you can simply create and use a bash tool. What you can also do, of course, is you can rely on an MCP server. And MCP servers were really popular one and a half years ago. I think they're still very relevant, but you need to understand when to use each service. Personally, if you're using a very common platform like GitHub or let's say Jira, then there are already a lot of bash tools you can use that even the LLMs might already know about. When it comes to MCP servers, this is really where it can connect with unknown internal services much better. for example you have a coding agent that you want to connect to some internal diagnostic system then an mcp server can be quite useful but even here i think the nuance of using an mcp serve or not really comes down to how simple of an operation you need if you just need to execute a single command then bash makes a lot of sense but there are still mcp servers that i really like i really like context 7 for example because with context 7 can pull in the latest documentation for your programming language or your framework of choice and of course you can do this with the web search skill as well in cloud code but it's much less specialized it will just do a generic web search and then it might return something relevant whereas with context 7 there's a very specific back end that will search the web but it will also cut up the documentation and present it to the language model in the most efficient format similarly with serena you can connect any coding agent to a language server of choice which will often make search operations much more efficient so here too there is not a definitive answer whether you need bash or mcp servers it just depends on intuition intuition you can only develop when you create interesting systems with these ai agents now i wanted to talk a little bit about my experience using ai coding at a freelancing gig at a smaller startup scale and even at the enterprise level because i've done ai coding at all three now and i will say that my experience has been wildly different let me start by explaining how i felt when i was a freelancer at a couple of side gigs that i did next to my regular job well these gigs were creating proof of concepts and vps and when you're starting off on your project well that's when you can really feel like you are some kind of god developer because you're able to just be so productive in the beginning just push out so many lines of code and when you're creating proof of concept there's not really a lot of people that you need to give accountability to you're not having to show your code to a development team every single day sure at the end of the project period you might need to improve the code base a bit add tests etc but it's really not the same as working inside of a software development team every single day regardless of whether you're working at a startup or an enterprise When you're creating code with AI, the code needs to be reviewed. Now, depending on what kind of company you're working for, the reviewing process is partially manual, partially AI augmented. But in any case, if you come to other developers with 10,000 lines of code every single day, I can guarantee you that things aren't going to end very well. Either they're going to send you back to create smaller skill pool requests. or you're all going to suffer from longer-term bugs caused by AI code that was generated too quickly. Now, here's where I have to face the reality of things. I feel like the people who are doing the best of digital coding aren't screaming from the rooftops that they're five times more productive. They might see 30 to 60% performance gains, and to be fair, they might be really fast on certain cases, like creating one-off scripts to test something in production. But in general, these people are benefiting from real production gains without all of the hype that is unsustainable. Because again, if you're working on real projects, you will find that the coding portion of the engineering job is actually not that much anymore. This is not saying that you don't have a job anymore. Engineering is much more than just coding, but it is a shift in how you need to distribute your daily work time. oh now one more thing about my cloud status line that i really want to share i also have the name of the current working branch you can see here that i'm on the main branch and if i for example ask cloud code to check out to a random branch you will see that whatever called code chooses will also show up here on the status line so it's going to do checkout to a couple of iran and branch name totally fine by me and once it runs this command you can see that this branch shows up here the only problem with this approach is that the git context is shared between these four different cloud code windows so if i for example say hi here you will see that my branch name will update to the current branch there we go This can work. You can still do parallel work in the same branch, but eventually it will get messy quickly. And this is where you can create a Git work tree. With a Git work tree, you basically create a temporary copy of your code of sorts that allows you to work in completely independent work streams. So even if Cloud Code might be iterating on the same files, for example, if you ask Cloud Code to generate three different approaches to the same problem. you can still achieve that without any conflicts by using git worktrees and you can of course ask cloud code to create a work tree for you in this case let's for example create a work tree called branch work tree test You can see here that it switches the branch name to WorkTreeBranchWorkTreeTest. And I even have a bit of an indicator here that shows that this is a proper work tree. Oh, and now I'm actually lacking the room here to show my context, but this isn't a problem because these windows are actually resizable. So I can resize the window like so to get the full context again. And just to show you what this work tree looks like in my file explorer, I'm going to open Visual Studio Code. and then what i can do is in my cloud folder you have this work trees folder and you can see that branch work tree test is kind of just a copy of the entire repository and of course once you're done with this work tree you can fully delete it because you don't want your disk to be full of copies of your code right so for example you can just say exit and delete the wt will understand that i'm talking about a work tree just fine so now it's cleaning up the work tree go back to visual studio code and the work tree is gone Just knowing how to use a work tree is a big power move. Just remember that when you create a new work tree, you might have to reinstall the project dependencies again, depending on what programming language you use. Here too, it all depends on your project. There's not one trick that will work. But if you do find yourself having to install dependencies every time a work tree is created, well, that's exactly when you should create a reasonable skill or command that will be called every time a work tree gets created. Maybe you can even customize my scripts to create a work tree whenever you start cloud code. If that's your preferred workflow, you should really get creative and customize it to your own needs. I also remember working in a much more complex repository where I was able to create a brand new feature in just two days. So I thought I'm going to create the pull request, get immersion by the end of the week, and we'll be all set. The thing is, though, I got quite a lot of pushback from a more experienced engineer in the pull request because while my code was functional, it lacked a lot of long-term architectural thinking. And I have to admit, when I actually read the code, because I only skimmed it because I wanted to create AI code faster, I realized that this engineer was totally right. It missed the bigger picture and it was going to cause a lot of bugs in the longer term. So when you're thinking about the genetic engineering, it's not so much just about the tools that you choose to use. It's also about mindset. What kind of engineer do you want to be? Do you want to be a vibe coder who pushes thousands of lines of AI code to production every single day? Or do you want to be an AI native engineer? Someone who benefits from the productivity gains of AI, but also knows when to fix systems when they really go down and can actually master the full stack. Of course, I'm a little bit biased. You probably know which type of engineer I prefer to be, but it's up to you and it's definitely good to think about it. If you want to get started with agentic engineering, you can check out the resources in the description down below or check out, of course, more of my videos where I cover many more topics like this.

⚙️ Pipeline jobs

StageStatusAtt.UpdatedError
download done 2/3 2026-07-20 11:47:43
transcribe done 1/3 2026-07-20 11:47:54
summarize done 1/3 2026-07-20 11:48:19
embed done 1/3 2026-07-20 11:48:20

📄 Описание YouTube

Показать
🎁 Get my FREE Agentic Engineer config: https://zenvanriel.com/ai-coding
⚡ Become a high-earning AI engineer: https://aiengineer.community/join

I've shipped AI-generated code on real engineering teams at enterprises and startups, with full code reviews, production users, and accountability for every merge. Most agentic coding tutorials show toy demos that fall apart the moment you join a real team. This video walks through my actual workflow: four parallel Claude Code windows tuned to different effort levels, context window management, git worktrees, MCP versus Bash decisions, and the engineering patterns that keep AI code from breaking your team.

What You'll Learn

- How to run 4 parallel Claude Code windows with mixed high, medium, and low effort levels
- When to use /compact versus /clear to stop context window drift from ruining your session
- Why most spec-driven development, BMAD, and prompt engineering trends won't survive 6 months
- The Smell command pattern that pushes Claude Code to follow Clean Code and design patterns
- When to use MCP servers, Bash tools, or skills to connect Claude Code to external services
- The honest difference between AI coding at freelance, startup, and enterprise scale
- How to use git worktrees for parallel AI coding without merge conflicts
- The realistic productivity gains from AI coding (30 to 60 percent, not 5x) and what they look like in production
- How to think about agentic engineering as a mindset, not just a tool stack

Timestamps
0:00 The Agentic Engineer Mindset
0:30 My 4 Parallel Claude Code Window Setup
2:30 Managing Context Window Drift
3:22 Why I Avoid Focusing On Spec-Driven Development and BMAD
5:04 The Smell Command for Clean Code Quality
7:28 Connecting Claude Code to GitHub CLI
8:01 MCP Servers vs Bash Tools
10:32 AI Coding at Freelance, Startup, and Enterprise Scale
12:58 Git Worktrees for Parallel AI Coding Streams
15:56 The Real AI Productivity Gains
17:01 Becoming an AI Native Engineer

#claudecode #agenticcoding #agenticengineer #aiengineering #aicoding #aiengineer #gitworktree #mcp #cleancode #claudecodeworkflow #aiproductivity #parallelagents #softwareengineering #ainativeengineer #vibecoding

Connect
LinkedIn: https://www.linkedin.com/in/zen-van-riel
Community: https://www.skool.com/ai-engineer

Sponsorships & Business Inquiries: business@aiengineer.community