Agentic by Default: Rethinking Developer Workflows with Claude Code

Hey, there, welcome to the AI Coding Summit. My name is Ado Kukic and I am a community manager at Anthropic. And today, we're going to talk about agent decoding, what it is, and concrete patterns that you can use today to get dramatically more done with Cloud Code. And I promise I'm going to try to keep this as practical as possible. And everything I show you today, you're going to be able to go and try in your terminal in about five minutes. So let's get into it.

So the obvious first question is, what makes something agentic? And to me, it really comes down to this loop of plan, act, and verify. How most people use AI for coding today is they will ask their LLM a question, they'll get some text output back, and they might copy and paste it into their IDE and see if it compiles. And if it doesn't, they'll paste the error back in, get some more output, and try again. You're basically playing telephone with a very smart AI. An agentic tool is fundamentally different. When you give it a task, it doesn't just spit out code and hope for the best. It plans first, it reads the code base, tries to understand the context, and figure out what files matter, and drafts an approach.

Then it acts, writes the code, runs commands, uses tools, and makes actual real changes to your project. And then finally, it verifies what it did. It's going to run the test, it's going to try to build the application, it's going to read the error output or the logs, and if something's broken, it is going to try and fix it. And if it doesn't, it's going to loop back again, it's going to replan, react, and re-verify over and over again until the job is actually done. And if we look at each of the phases, the planning phase is going to use a certain set of tools like read, grep, and think to actually try to understand the problem. In the acting phase, it's going to write new files, edit existing files, run bash commands, and access additional tools through MCP servers. Verifying finally is going to use those same tools to check its own work. And if we look at the glowing dots on this slide, bouncing between the three nodes, that's really what is going on with Cloud Code. It continues this cycle until the task at hand is complete.

And here is another way you can think about Cloud Code, it is just an agent in your terminal. Your prompt goes in on the left side, something like add email notifications when a user gets mentioned. And that's it, that is the instruction. We're not telling it how to do it, we're not telling it where to go, we're just giving it what we want, we're giving it the task. And in the middle, we've got Cloud Code, an agent sitting in the terminal with four core capabilities, the ability to think and reason, the ability to read our code base, the ability to write and edit, and the ability to use various tools via bash. It's going to reason about our code, it's going to read files in our code base, write new code and execute the commands until we get to the right-hand side of working code. Our test passing, the code being PR ready and ready to merge. And what happens in the middle box is where all the magic lives. Cloud is learning about our existing notification system that we have in place to understand the patterns that we're implementing. It is writing new code that matches those conventions and not new ones. And then it's running the test suite to make sure that the new code that it wrote and added is actually not breaking. And if something does break, it goes back and fixes it until we get to our working code. So at the end of the day, you give it the what and it's going to figure out the how.

Okay, so that's just a very high-level overview. But now let's get into agent decoding patterns and practical techniques for getting the most from our agent decoding tools. We'll kick it off with context. And honestly, this is probably the most important one, giving the agent the right context. And the best way to do it is via a cloud.md file. It is a markdown file that lives in the root of your project and cloud reads it at the start of every single session. Think of it as onboarding documentation. And if your project does not already have a cloud.md file, you can run the slash init command to have cloud code automatically read the code base and write its own cloud.md file based on what it finds. Some good things to add in your cloud.md file are your frequently used commands, your coding style and preferences, naming conventions, things like that, your architectural patterns that are specific to your project, and your tech stack and key directories. And we can see on the right here, I have some commands. I have the tech stack that I'm using and conventions that I want cloud code to follow when working with cloud code. The next pattern goes hand in hand with having really good context and that is plan mode. Now, a problem that people will typically run into when they are first trying agent decoding is they'll give cloud a very complex task and expect it to just go out and do the work and get it right on the first try. And don't get me wrong. Cloud will attempt to do it. It's going to go look at the code base, it's going to do its best to make as many changes as possible to accomplish the task. But without a plan, the odds of it going off the rails are significant.

And plan mode can fix this. When you toggle it, instead of cloud going and eagerly making changes to your code base based on the prompt you gave it, it's going to give you a detailed plan and instead of immediately rewriting half your application, cloud code is going to read your existing code, understand the patterns, maybe ask a clarifying question or two, and then propose a plan of attack. Here's what I'm going to change. Here are the files I'll touch and here's the approach that I'm thinking of making. You get to review this plan, you get to push back. Cloud is going to adjust the plan and only once you approve does it start making changes. I highly recommend using plan mode for any non-trivial tasks as it's going to make your code output much better.

For pattern three, I see this one is much more of a mindset shift rather than an actual pattern. And the reason I say that is a lot of times developers will give instructions to cloud on what they wanted to do and they can get very verbose and very specific. And what I want to challenge you to do is to focus on describing what you want done rather than how. We have a couple of examples here on the left-hand side and the right-hand side on what to do and what not to do. I always encourage developers not to give it very descriptive instructions on go to this specific line and make this specific change. Rather, I try to give it a task, give it an issue and let Cloud Code figure out how to best implement it. Rather than saying go to package.json and add .as a dependency, I might say something like add input validation to all of our API endpoints and ensure that we are getting consistent error responses for each API endpoint instead of telling it exactly how to do it and how I want all of the code written. And a pro tip here as well is Cloud Code has a concept of slash commands. So any prompt that you're using multiple times a day, you can actually store it as a slash command, save that prompt and then you just run the command and it's going to run the prompt, it can accept arguments as well, making the whole thinking and tasks workflow much, much simpler.

Starting with pattern four, we are moving into power user territory and the feature that I want to talk about here is subagents. So subagents are specialized AI assistants that run in their own isolated context. Each one gets its own 200k token context window completely separate from your main agent. And why does this matter? Well, two reasons. The first is specialization. If you look at the left example here, we have a code reviewer subagent. Its focus is on code quality, security and maintainability. It only has the ability to read code, it can read, it can grep, but it cannot accidentally modify or write code. And the second big reason is context management. Your main session's context window is precious real estate.

This agent gets the edit and bash tools for fixing tasks and has a different role than the code review agent. Subagents work in isolation to prevent context window clutter. Users can create agents with slash commands or markdown files. Utilizing subagents efficiently can optimize workflow distribution.

Hooks are shell commands triggering at lifecycle points for deterministic control over AI. Various events like tool use, permission requests, and session start can trigger actions. Notifications through hooks can enhance user responsiveness. Investing in hooks is crucial for serious Cloud Code users.

MCP enables Cloud Code to integrate with various servers, expanding functionality across systems. Access to tools like GitHub, Postgres, Slack, Jira, Stripe, and more is facilitated. With MCP, Cloud Code gains the ability to perform complex cross-system tasks efficiently. Configuring MCP servers unlocks a wide range of actions for Cloud Code users.

So, for example, pre-tool use, you can block or allow specific tool use. Permission request, you can auto approve or deny permissions. For a session start lifecycle, you can load additional context from a different place or set environment variables for that session that don't exist. And many, many more.

Notifications is one that I use a ton just to send me either an audio or a visual notification when Cloud needs my attention. Hooks are way, way underrated in my opinion and something that everybody that's serious about using Cloud Code should invest heavily in.

Pattern six is MCP or model context protocol. This is the universal integration layer and honestly one of the most exciting things happening in the AI tooling space. Without MCP, Cloud Code lives in your terminal and it can read files and run shell commands. But it can't directly query your database, it can't post to Slack, it can't browse to your Jira board or the browser. But with MCP, you can configure various servers in your settings and suddenly Cloud has access to everything that you would have access to. Your GitHub, your Postgres, Slack, Jira, Stripe, Linear and so many more. MCP servers expose various tools to let you execute actions across systems.

And here's what that actually means in practice. You can tell Cloud to find all the tickets assigned to me in Linear that are blocking the release. Check the corresponding PRs in GitHub and post a summary to our Slack channel. In Cloud, if you have the MCP servers set up, we'll be able to do all of that. It's going to use the various tools provided by the MCP servers to complete the tasks. And the best part is, this is just one single protocol. No custom integrations. If somebody builds an MCP server for a specific service, every MCP compatible tool can use it immediately.

For pattern number seven, this is a newer capability of Cloud and agentic tools called Skills. And Skills are how you turn Cloud from a general purpose assistant into a domain specialist who really knows your stuff. Every team has institutional knowledge. Your naming conventions, your deployment checklist, your API design patterns, brand guidelines, and so much more. Normally, this stuff is tribal. It might live in a notion page or an outline page. But with Skills, you can package all of this expertise and Cloud can load it on demand.

The design here is really elegant and is made up of three key features that make it so powerful. The first is progressive discovery. Rather than loading all of the Skills into context every single time you start up a session, Cloud will only load the Skill metadata. In our example here, it's only going to load the name, front-end design, and the description. The Skills will also be autonomously activated when needed. If you give Cloud a prompt that has something to do with front-end design, it's going to look at the Skill directory and see that there is a front-end design Skill, at which point it's going to load the rest of the instructions for the Skill and additionally, any scripts or any other files that are relevant for this Skill.

And Skills are universally portable. So the same Skills that work in Cloud Code, work in the API, work on Cloud.ai, or work in various custom agents. So you just have to write the Skill once and you can use it everywhere. And Skills are an open standard that any agentic tool can leverage and use. We talked a lot about hooks and Skills and MCP servers. And plugins are really where all of these different capabilities come together. The plugins primitive solves the share my setup problem. A plugin bundles everything into one shareable and installable package, meaning we can bundle commands, agents, hooks, Skills, and MCP servers and share them across our entire team.

So for example here, if we have a front-end design plugin, it's going to, it might contain a design command, a front-end design Skill, a style check hook, and a Figma MCP server. And with a single command of slash install plugin, front-end design, we can get all of these capabilities on our machine and share it across our entire team. You can almost think of it as NPM for AI tooling because that's basically what it is.

Pattern number nine, working in parallel. This is one of the biggest productivity unlocks in your entire workflow. With Git WorkTrees, if you haven't used them before, they create isolated working directories that share the same Git history. And what this means for us is you can run a completely separate cloud code session in each one. And each session gets its own fresh 200k context window and each one can be doing a different task simultaneously.

Here we are implementing OAuth 2.0 with Pixy, we're building an analytics dashboard, migrating our user table to user UIDs, and fixing rate limit edge cases all simultaneously. So we have four independent cloud code sessions all running at the same time, all doing real meaningful work. I come in, I look at my sprint board, and I spin up multiple WorkTrees based on recent tickets that have been opened or recent things that I need to do. On a good day, I could close out 10, 20, 30 PRs by early afternoon. You should be using Git WorkTrees and parallelizing your cloud code work.

And I'm not exaggerating. On a good day, I could close out 10, 20, 30 PRs by early afternoon. And since we are using Git WorkTrees here, we don't have to worry about the cloud code sessions interfering with each other. Each WorkTree is fully isolated. Each cloud has its own context, so we don't have to worry about merge conflicts until we're actually ready to merge. If there's one thing you take away from this talk is that you should be using Git WorkTrees and parallelizing your cloud code work.

And for our last pattern, I want to talk about how you can make your agents non-interactive. We have two really cool capabilities that allow you to leverage all of the capabilities of cloud code in a non-interactive way. The first one is running cloud code in headless mode. So in your terminal, if you do cloud and pass in the dash P flag, it's going to run cloud without a terminal UI. With this, you can pipe in a prompt, get structured output back, meaning you can leverage this in your CICD pipeline or, for example, here we have a GitHub Action example that is going to automatically do a code review on every single PR. It's going to pipe in the diff, it's going to get structured JSON feedback on bugs, security issues, and static violations automatically. But it doesn't just have to be code review. You can have it automatically try and fix the errors, you can have it document the changes, create change logs, migration guides, and so much more.

And finally, we also have the Cloud Agent SDK, and this is the same agentic harness that powers cloud code but as a programmable library available for both TypeScript and Python. So if you want to build your own production agents, with custom tooling, custom workflows, custom everything, you don't have to reinvent that infrastructure. You can build on top of what's already been battle tested by millions of developers. And one thing to be really clear about before we wrap up this talk is that agentic coding isn't all or nothing. It's not trust the AI with everything or approve every single keystroke. It is a spectrum, and you should move fluidly along with it based on your comfortability level. On the left, we have full control where you are still heavily using the plan mode, you're approving every step, you're getting more and more comfortable with agentic coding, and this is really good for anything that is security sensitive, working on a new code base, and anything where the cost of a mistake might be pretty high.

In the middle, where I think most people are, is kind of this guided autonomy. This is where most of your daily work should live. You set the guardrails, you have a cloud MD for your conventions, you have set up some hooks for enforcement, permission settings for boundaries, and so on, and you let cloud code work within them. So you give it enough freedom to be genuinely useful, but enough structure that you can actually sleep at night.

And finally, on the right, we have full autonomy. Headless mode, adding cloud to your CICD pipeline, batching operations, fire and forget. Use this for well-defined, repeatable tasks where you've already validated the approach. Personally, I think the sweet spot for most teams is right in the middle with guided autonomy where you give it a good set of guardrails and let the magic happen.

And if this is all new to you and you really just want to dip your toes in, here are four steps you can take to experience agent decoding today. One, install cloud code and run slash init in your terminal. It's going to give the agent context about your project. In about five minutes, you're going to get a cloud MD file that is going to give you the basis for what cloud can do. Two, use plan mode. You can hit shift tab to switch into plan mode in cloud and give it a task.

Review the plan that it comes up with and if you feel good about it, let it execute. Three, iterate on your cloud MD file. Every time cloud does something wrong or does something really good that you want it to repeat, add it to the cloud MD file. Your cloud MD file should be a living, breathing document that evolves as your project evolves. And finally, let the agent do some work. Give it a task. Let it work. Let it self-correct when it fails. And resist the urge to interrupt it after the first misstep.

The plan act verify loop means that cloud will often catch and fix its own mistake. So give it room to do that. Four steps. That's it. Give it a try. That is your on-ramp to agent decode. So that brings us to the conclusion of this talk. I've shared a couple of resources here on what to do next, install cloud code, view the documentation, and if you want more tips and tricks on how to really get the most out of cloud code, I created an admin of cloud in December of last year that has 31 tips and tricks to really optimize your workflow. Thank you so much for joining me today. I hope you learned something, and I hope to see you online.