Intent-driven development with Claude Code & Fable 5 Transcript, AI Summary & Key Points

00:04 Lockport has become one of the most talked about developer tools in the world right now. Engineers everywhere are rethinking how they can build software because of it. And sitting right here with me today, I've got Lyria Haley from Anthropic, the company behind Cloud Code. You might also know her online as the coder, and she's here to pull back the curtain on how Cloud Code actually works and where it's heading.

00:29 And I've also got YC showy, the creator of CS Dojo, and he's also the author of the Cloud Code tips repository, which is one of the most popular community resources for mastering Cloud Code. So if you've searched on how to get better results out of Cloud Code, you've probably landed on his work. Welcome to the Asian factory, both of you. Before we get into it, a quick one for both of you.

00:54 What is the one thing about Cloud Code that most developers are completely sleeping on, I would say auto mode. I mean, it's pretty new, so I get it, but using auto mode and we'll go over that a bit more today in your workflows will enable so much like so your Cloud Code tips repository has over 8,000 stars. And post about it. Keep going viral. So what was the moment that really clicked for you with Cloud Code.

01:25 And what made you start documenting those tips for other people. It clicked for me right away. I remember I started to use Cloud Code as soon as it was launched, and a quick story about it. I was going through an interview for my current job. And daft, and I built like a demo project for that job interview, and I didn't tell them I used Cloud Code, but they were so surprised with the quality.

01:54 So even back then, I think there was so much promise and I just kept using it. Using it. I kept learning and kept sharing my lessons. Linear from the Anthropic side. What's it been like watching the community run with Cloud Code. When you see someone like YC building out these workflows and he's sharing them at scale, how does that feed back into how the team actually thinks about the product.

02:19 Yeah, I feel like most of my job is watching these power users, like YC, use Cloud code and seeing how they're using the tool. I feel like everyone uses it slightly different. How we use it internally might not be how people use it externally. Even all the engineers on the Cloud Code set here, we all use it differently. So it's extremely important for us and we really enjoy getting all these feedback and seeing all these patterns coming from the community, because it really helps us shape our roadmap as well.

02:46 See what's missing or what features we need to add or improve. We hear now the term intent driven development actually being thrown around a lot. And the idea. Where you're telling Claude what you want to build rather than how to build it. So what made that shift for you and what made you start sharing that. First of all, there are many different terms for it.

03:11 But I personally like this term because to me, it's not about the exact prompt. Sometimes people say, oh, use this prompt and you get better results. Sure, maybe. But to me, it's more about expressing what your intent is exactly. Knowing what your intent is, exactly what you want to build, and then just being able to express it. So one thing I recommend that people do is using your voice to type instead of using your hands to type.

03:37 And one way where it's better is, so that you can express your intent faster. You might make mistakes, you might say, but it doesn't matter as long as you're able to express it. Yeah Lyria, I'd love your take on that, too. When Anthropic kind thinks about how developers should be working with Cloud Code. Does intent driven development match how the team designed it.

04:01 And what's it been like watching the community shift in this direction. Yeah, I like the term intent driven development. I feel internally we do focus a lot on making sure people understand that Cloud needs verification, right. And I feel like that's kind part of intent. Part of it is how you structure your prompt. I still feel like having a software engineering background does help refine your prompts, and you can tell Cloud a lot better what you actually want it to do.

04:30 So in that case, like using plan mode, adding images is verification. I feel like it's kind part of the intent, but also voice mode. By the way, I still have to use it. It seems really fun. I feel like I probably would prompt a lot better if I'm not in my head as much, because I think I noticed when I type a prompt, I'm like, maybe I shouldn't ask this, maybe I should do something else.

04:49 But just brainstorming out loud might actually be very fun. I still have to use it, but yeah, just I feel like it does show a pattern where we want people to use Cloud Code the moment they have an idea, and we want to make sure that friction point going from your idea to an actual deployed website is as small as possible or as easy as possible. So yeah, again, this is also a great community feedback.

05:12 I feel like we might focus more on these types of patterns. It's like, hey, you can use Cloud Code. The moment you have inspiration, just talk to it, brainstorm maybe in plan mode and get your website deployed quickly I love that. And also, I knowest that I love using voice mode too, because I feel like I'm much quicker at talking than I am at typing.

05:33 So I'm getting frustrated at how slow I'm typing. So I just switched to voice mode. I think what's also been really exciting is that Cloud Code is not just a solo developer tool, it's also being used at enterprise scale. So Cloud Code can now of course, you can run it on Google Cloud platform. So when you're actually ready to go from just experimenting to actually rolling this out across your team, the platform is already there.

06:00 So let's actually get into some of the Super exciting demos that we have planned for. You and I are going to kick off the first demo together. So in this demo, I'm going to show you how you can set up Cloud Code on Azure platform. And yk is actually going to demonstrate how he built something really cool on there. First, I'm going to quickly show how you can set up Cloud Code on Google Cloud.

06:22 And then this is going to be the foundation right. So what I've done is I've installed Cloud Code on my Mac already. And if you have not done that can do that super easily by running the following commands. And then what I'm going to do next is actually install gcloud SDK. If you don't already have that, that's a great place to start because we're going to be using gdcloud to run all of these commands.

06:47 And then I'm going to set my Project IDX, which you can get from your own Google Cloud Console. So I'm going to set my Project IDX. And then I'm going to enable Vertex AI API, which will allow us to use all of the Cloud models. And next I'm going to enable a bunch of other variables which will essentially enable the Vertex AI integration for Cloud. And all of these commands can actually be found in the links that I'll be leaving in the description box below.

07:25 And then once I've done that, I can just start Cloud. And now it's going to be running on Google's Vertex AI. And after you. Yay Thank you so much for that. What I'm going to show here is essentially a demo of what I would call intent driven development. And I'm just going to get right into it. And as I wait for the output to come in, hopefully I'll have some time to discuss these tips and share some of these tips.

07:52 So here I'm just going to start prompting. I'll say I want to create a 3D game. It's going to be a slingshot game where you're going to have a stationary slingshot right in front of you, fixed camera, fixed slingshot. And I want to be able to drag a ball that's attached to the slingshot in x and y direction. So dragging should determine the x and y directions, or the coordinates, and the duration of how long I'm holding the ball should determine the z direction.

08:24 So that way I should be able to control the ball in three directions. And whenever I release it, I further back it is held. The faster it should shoot. And what should I use to build that. I want it to be all front end HTML, JavaScript and CSS. Feel free to use libraries if you need to but tell me the options I should use. I think that should be good enough.

08:47 So as I said, this is exactly what we're doing. Building a slingshot game. And one quick tip I want to share is setting up an alias. And your command might look like it. This Depending on the exact OS you're using. So this is so that you don't have to type Cloud every time. I mean, you can if you want, but this is a little bit faster for me that way.

09:14 So here we have different options. And this model is suggesting Three.js and control hand-rolled physics. I don't think I want to hand-roll physics. Three.js plus cannon. I actually remember there's another option for physics. I remember there is another option for physics that's not cannon. I don't remember what it is. Can you remind me. Let's see if that works.

09:40 So as you can see, I've been talking to the agent with my voice here, as I recommend it earlier. There are a couple of different options for it. You can just use the voice option or alternatively a dedicated desktop app. I actually built a desktop app for myself just for me, and that uses a local model. So if you want to go that route, there's that option too.

10:04 So we have ammo wrap here. So let's go with wrap here I did a little research beforehand. Let's go with wrap here and Three.js. And then I will say let's create a new folder for it. Let's call it something like slingshot podcast. Because I'm building this on a podcast and just build a slingshot. I don't have to have any targets right now. All I need is the slingshot fixed camera, as well as a way to control it and release it.

10:37 And then I'll just say manually, let's use beat for building it. So you may have noticed that I'm in the Projects folder, and I personally like to do it this way, where I have most of my projects in a single folder. It's not necessarily for everyone, but I highly recommend it so that it's convenient for the agent to be able to refer to different projects.

11:03 And you can say stuff like, I want to take this element from this other project and this other element from this other project and combine them into a single project. So it's pretty helpful for that. And as you may have noticed, it's helpful to start with broader questions first and then dig deeper as you go. So these might be questions like what architecture should I use.

11:28 What libraries frameworks should I use. And then go back and forth with the agent to refine your idea over time. And I'm confident enough of this model that it knows enough for this particular problem. But if it needs more latest information later kind of community feedback and stuff like that. You can ask it to do research on your behalf as well so that you can make better architectural decisions.

11:52 Do you ever use plan mode for this, or do you just ask Cloud like, hey, don't code anything yet because we have a specific plan mode, but often I just end up talking to Claude instead, like a coworker. What do you prefer. OK, I don't think I ever explicitly turn on plan mode, but I know it sometimes does that on its own. So that's how I do it. All right.

12:15 While the output streams in, I'll just keep going with the tips. So number 5 is you want to learn to use Git and GitHub CLI. Well and just CLI commands in general because it turns out CLI is really, really powerful. There is so much stuff that you can do, just starting with Git and GH. So definitely learn to do that. And here what I'm going to do is it looks like it created this folder and the result is already coming in.

12:48 But I'll just go in a new tab and I'll say, if this project is not a Git project yet, turn it into a Git repository and then create a public repository out of it. So I'll just do that in this other thread. It looks like it's actually testing it itself. I didn't ask it to do it, but it looks like it started it in playwright testing it. But I should be able to personally test it myself here.

13:20 All right. It looks like it's sort of working. Nice all right. It looks like it's working. Commit if you haven't yet. And let's show the trajectory before I release it so I know where the ball is going. I mean, I guess it depends on how hard you want to make it, but I think it's more convenient that way. All right. So it looks like it was able to create this project.

13:47 Open it for me. I think it used the open command in the terminal because I didn't open it explicitly. And going back to the browser here. All right. It's getting confused with the different agent doing the work. But it should be able to figure out what it's doing here. Looks like it's adding this trajectory feature. Not quite there yet. All right. Nice So it's got trajectory.

14:33 I think I can go to the next tip as it finishes the work. You want to learn to verify the output. There are a few different ways to go about it. As I just showed can directly verify the behavior of the app. Not necessarily the code, but you can also check the code yourself if you want. And you can also automate the process of verifying the output as much as possible by writing tests, by writing GitHub actions and things like that.

15:08 It's much better, it looks like, and it looks like it's committing a trajectory feature. That's perfect. And next up, I think this is going to be the last feature I'm going to add here. I want to have a few big targets in front of me in front of this slingshot. They should be like disks, circular targets. And when I hit them I want to have satisfying visual effect, maybe them shattering into particles or stuff like that.

15:40 So, as you may have noticed these prompts sometimes are a little bit vague, but as long as your intent is clear enough that I found that Claude is able to figure out what I mean, even if there are typos or transcription mistakes, it's basically smart enough. And meanwhile, while we wait for that particular feature, what I'm going to say here is this project is almost done.

16:04 So let's give admin access, because I think this is still a private repository to the following user. That's Lydia's GitHub account that I pulled from the different screen. And it's saying let's add sharable targets. Plan three big bullseye disks at different distances. Hit detection that catches the ball crossing the disk plane looks good. And this thread is running these commands so that Lyria should be able to get an invitation with admin permission on this project soon.

16:47 And it looks like this thread is just finishing up with these targets. Nice it might actually not reload automatically. That might be something to fix next, but I think it's already a pretty satisfying game. I feel like this was such a good example of your intent driven. The first moment that you wanted to use a specific physics library. I feel like that's also where it perfectly shows.

17:17 Having more context around what you want to build helps so much. Definitely I think the rule of thumb is you ask more questions when you have less context. Because I didn't know about these particular physics libraries. I needed to ask questions earlier. But now that I'm a little more familiar, I can. I mean, just like in a real colleague. You would still talk to them before you implement something.

17:39 So just to wrap up this demo, I think one last prompt I'm going to do, hey, I think it was trying to test the app for me, but it doesn't have to do that. I'll say, all right, let's commit and push, but don't push directly into main. Instead, create a new branch because I want to simulate the process of code review and then push that branch, create a draft PR and then open it for me using the open command.

18:13 And that should be able to wrap up this demo, because one of the tips I had actually I have this whole section about managing your code base. But one particular quick tip I had is creating a draft PR. You can just ask the agent to create a draft PR just like I did, and then check it before marking it as review so that people will OK, this PR maybe was created by the agent.

18:40 It's not ready for review yet. Or it is ready for review. So I think it makes things clearer. As you can see, it's doing Git push here using auto mode here as you can see. Create draft title and body. It's opening it for me and that's it I'll just say ready for review. If I can check the code manually or interactively using Cloud Code. And then I'll just merge it here and that's it for the demo.

19:13 I think this is such an awesome. And Lyria, as Lyria was mentioning. It's like seeing the intent driven development. I think this is a super clear example of that. And then so now the source code is kind of going over to Lyria for her demo. So Lyria, it's your turn. I'm super, super excited on what you're going to showcase for us. Yeah let's get started.

19:36 So basically, first what I did over the weekend is I pulled one of yc's GitHub repositories because he already showed me the game that he wanted to build, which, by the way, this is such a difficult level to pass. I have not been able to do this, but when I see this game, this is already really impressive. But I want to make it a bit better to make it an actual game, I might want to add more levels, I might want to change the environment per level, all that kind of stuff.

20:02 And I want to use Claude, of course, to help me out there and what I really like to do. Instead of prompting Claude with the changes I want to make, I really like to use a visual flow. This is all created in Claude design. I don't know if you've used Claude design yet. It's new in our research preview, but basically you're able to create a presentation's slides, entire websites based on your prompts as well.

20:26 It's basically Cloud Code, but for design. But I really like having this visual approach for a plan. This is just HTML. At this point. I could have also exported it to Figma or Canva or anything else, but this allows me to really think about the plan and the changes I want to make. So for example here Cloud came up with this slingshot V2. So how can we actually make it into a game.

20:48 So we have the game flow with a main menu. We have a level select gameplay loop. All of this. So more like visuals that we want to add here the gameplay screen. And this is our HTML. So this is pretty much already kind of what we had here. But we have some health bars and also some systems to design. So we have the health bar here again to charge and aim.

21:08 We already had this or at least in the demo that I just showed in the original didn't have this yet. We have some haptics which I think are nice to add. If you're on your phone, you kind of want to feel, that something is like pulling and then smashing the plates. And of course, also scoring. We have some extras that maybe they want to add as well the different levels, which I think looks so cute.

21:32 So again, this is all Cloud design. Cloud came up with this. OK, so this is basically all the prompts that I gave Cloud design. So this is in Cloud design itself. And the nice thing is that I can also just edit everything. So if maybe I want to change some of the planning, I don't want to say slingshot here, I want to say slingshot, whatever. It doesn't matter.

21:48 I can just do that and then I can later export this and use this as my prompt to Cloud. So what I did for the design wireframe is I just added it to my demo assets here. So this is all just HTML. The entire plan that we just saw with the different screens and everything else is just here. So now I can just open Cloud real quick Cloud is already running here.

22:09 And to make this, use the Agent platform, it's already running on Vertex AI. But how I did it is that we actually have a really nice built in Wizard called setup Vertex. So we have setup Vertex and when you run that it'll automatically do most of the setup that we just saw. So for example here I can just say, OK, I want to use my application default credentials.

22:30 Perfect I want to use a different project. This one is called Project on scratch off. I want to do global. It's going to do a quick check to haiku. Just making sure that everything is set up correctly, and it's going to see which models we can use here. Here we see that we have access to opus 46. We can also enable more in Model Garden in Google itself.

22:55 And we also have access to fable 5, which I'm very excited about. I'll be using fable for this demo. Specifically, I'm going to pin the working models to 1 million, save it, and now we're good to go. So anyway, that was a quick setup. So now we're still running on Vertex just like we saw before. The only thing what I really enjoyed doing is using auto mode.

23:16 And by default in an agent platform that is an environment variable. So we actually have to turn that on first. I'm actually going to quit this real quick. I'm just going to clear it. You can do this by doing export Cloud Code enable auto. Mode so now with that enabled and Cloud restarted, we can now see with a Shift Tab that we have auto mode here.

23:38 And you could also see why I was using auto mode as well. The nice thing about auto mode is that it makes it so much easier to just not be as hands on. So just to show real quick what it is, if you've used Cloud Code, you may have noticed that you can use, ask almost ask everything, in which case Cloud Code will always ask you like, hey, is it OK if I delete this file.

24:00 Is it OK if I run this command. And after a while you're just like, yeah, go ahead. Whatever And we call this a permission fatigue, where I do think it's very important that before Cloud does something dangerous, it has to make sure that it should be doing that. But at a certain point, if asked or if Cloud asks you questions every time won't read them as much anymore because you're kind of you've asked me 100 times now.

24:24 Sure, just go ahead. That's permission fatigue, which is also dangerous. And then previously. We also had the option to buy a dangerously skip permissions, in which case Cloud will never ask you anything, which is also not great because if it's about to delete your root file, there's no going back, right. So auto mode is our solution to that. It kind of sits in between your denial list and allow list.

24:45 So auto mode runs a different classifier between all the tool calls. So it kind thinks like OK is this tool called dangerous. First of all, if yes OK. Let's ask the user if they actually want to do it. But if it's just a normal read or edit or something else, then no, that's not dangerous in most cases. And let's not ask them, let's not bother them.

25:05 Another thing also is that it's much better against prompt injection. In some cases, a tool call might just be like ignore all instructions, that kind of stuff because it runs a classifier in between. It's much better at catching that. Also, another nice thing is that it's more context dependent. If you're asking Cloud, delete this folder. In some cases that might be dangerous, but if you've specifically asked for it, it's not dangerous.

25:31 So in those cases, automotive won't ask you because you asked to delete it. It's not a dangerous thing. So this is a very nice way of working. And this actually enables you to use Cloud Code or to run Cloud Code way more autonomously in these longer running sessions. But anyway, so far we haven't done anything yet. So I want to implement that entire wireframe that I just showed using something called dynamic workflows.

25:54 And this is a new feature that we've just added. And you just ask Claude to use a dynamic workflow. It's not a command, it's nothing else. So I can just do read this design file and use a dynamic workflow to rebuild the game and match it. And I added it to my demo asset so I can just see. Demo assets. It was in design wireframe. Yeah So what I'm doing now is I'm giving Claude a way to verify and understand what I want to build, because it has this HTML.

26:33 It has the context. I could have made this prompt like a lot more specific. I'm like, OK, add all these levels, add all these other features. But honestly, I'm kind of just waiting to see if Claude will understand it. So in this case, we're going to wait a little bit. I kind of also prepared it like a cooking show. So if this takes quite a while, there is a tab in which this is already finished.

26:57 So we can always just go there. But it's always interesting to see what Cloud comes up with. So to quickly explain what a dynamic workflow is, again, I created a little visualization. Hopefully this kind of makes sense. So subagents themselves aren't new. If you've used Cloud Code, you have noticed that sometimes it spawns a new agent to perform a certain task a agent is essentially an Cloud Code instance with its own context, and it's really good at just focusing on that specific task.

27:28 But if you're just asking Claude every time to use subagents, you don't even have to ask it. The downside is that it's very non-deterministic. Sometimes it might spin up for subagents, sometimes it might not even use subagents. The other time it uses 10 subagents, all that kind of stuff. With workflows, it's kind of our deterministic solution to that.

27:49 Workflows also spin up a lot of subagents, and that's a feature. It can go into hundreds of subagents because this is a feature for tasks that takes hours or days or these really long spanning tasks. But the nice thing is that Cloud Code actually generates a JavaScript file, and we'll see that in a moment as it's like eventually it will kick off the workflow, but you can see that JavaScript file and you can save a workflow to then rerun it later on as a command.

28:19 So if you really a specific kind of steps that Cloud Code took what specific subagents you can save it and rerun it in that very deterministic way. And because all these subagents run in parallel, you can also achieve a lot more within usually the same amount of time as a single subagent would have because it's parallel. And what you'll see is Cloud is pretty smart at delegating these subagents to be very focused on a specific task.

28:49 OK, so just like a cooking show, I figured that Cloud would take a while to spin this all up. That's all expected. Fable is a bit slower because it's such a large model, but here, I showed the exact same command. This is also what I just typed in my other terminal. Read this design file and use a dynamic workflow to rebuild this game and to match it.

29:09 It's the exact same HTML file as well. And it then ran this workflow. And we can see what it ran by with the workflows command. And here you can see that it ran this specific workflow. So here we had four agents and the build phase. We had built engine, build UI, build audio and levels and haptics. We then had an integration phase. So this is another subagent, a review phase and a verify phase.

29:32 So these phases run sequentially, but the actual build agents all run in parallel. You can see that this is all fable five. We can also go into it. And the nice thing is that if we like this workflow, in this case, it's like rebuilding a game. So it doesn't make too much sense to save this, but we could by just pressing S and then we could do like save dynamic workflow and save as rebuild slingshot game.

29:55 Sure for this demo, I'll save it as that. And now you can see that it's saved this JavaScript file. So I'm kind of just want to open it and see if I can open it this way. I'm just going to remove this. And you can see that this is a JavaScript file that Cloud Code created for this workflow. I didn't type this. This is all Cloud. And you can see that it's just a normal function.

30:20 It's like a build phase. We see all the builders. We see the prompt that it's using for all these subagents. We have a review phase, all that kind of stuff. So if we can also be very specific here. Maybe I don't want all subagents to use fable like here. If we go into workflows you can see that it all use fable five. In some cases, I don't need a model that's strong for the subagent.

30:41 Maybe I want to use sonnet or opus. We can. We can just ask Claude, of course, to change that. We can just ask Claude hey, please use sonnet for all your subagents. But we can also actually see it in our code and edit the code itself. And again, because this is all just a JavaScript file, this is deterministic. So then every time we invoke that command, it will just run these exact same subagents.

31:02 So that's incredibly nice. I'm just going to see what it came up with. I run dev. So yeah it uses workflow to rebuild it according to our design spec. Let me see if it actually made it look good though. So it actually did make it almost in the exact same design pattern with this kind of drawer look. But it definitely added some levels. It added, I know if you can hear it.

31:30 It added like audio to the levels and it actually made it into a real game. So now we have different levels, everything else. So almost exactly like our original design like spec here. So honestly, I'm pretty happy with this. I'm not sure if I can clear all these levels. It's honestly very difficult. Thank you both for those wonderful demos. So let's Zoom out and get into some bigger ideas.

31:55 Your entire repo is a playbook for maximizing what Cloud Code can do autonomously. But you also have tip number 38, which is simplify overcomplicated code where you note that code generation models have a bias towards writing more code than needed. So how do you balance the rapid prototyping with the discipline of actually keeping things clean. So I think in general, they have had that tendency over time, but it really depends on the particular model that you're using.

32:26 And depending on that it might be able to generate concise code. But the general principle that I try to convey through this particular tip and other tips on this repo is that you want to be in control of the code, not necessarily totally in control, micromanage everything, but in a way to make sure that your code quality is good, your output quality, the behavior is correct, and all of that.

32:53 So I would say just in general, don't necessarily commit all the code that's generated. Make sure that you only commit and merge the ones that are important and valuable to your code base and you need to be the decider of that. So Lyria, with agents writing more and more code, what does understanding your code base actually look like in 2026. And how do developers try to stay in the driver's seat.

33:23 The way I see it is, I think the role of the software engineer is changing more to be almost like a product manager. At least that's what I've noticed. And also it feels pretty logical, as a software engineer, you're not just writing the code, but you are in charge of owning it, understanding the architecture that you want to build. And it's still up to you to understand why you need to implement a feature.

33:44 All that more like product manager stuff. But we still definitely need the technical expertise, almost with the intentional design that I mentioned, is still very important. I always like to draw a comparison to I can write TypeScript or JavaScript, but I'm not going to focus on the machine code that gets generated afterwards. And it's almost like it's almost pretty similar, where it's like software engineering used to focus on the actual code syntax, almost like how machine code might have mattered.

34:14 But we're going a layer above that now. I think what's more important is understanding the architecture, understanding the feature and understanding still what the shortcomings are, but then also building the right environment for Cloud around it with hooks, permissions Cloud and all that kind of stuff. And it still requires a lot of technical expertise and good taste and high agency.

34:34 Can we also talk a little bit about what your own setup is. You're literally on the team that builds Cloud Code. So You're probably the best person to ask this. You're also shipping fast. I see all of your content on YouTube or LinkedIn. So what's your personal Cloud Code workflow and how does that look like. Personally, I think I really want to focus on setting up as many routines as possible.

34:56 I have a lot of proactive or scheduled Cloud Code sessions, kind of always keeping me in the loop. And it's not just Cloud Code, this is just Cloud in general. I see clouds entire ecosystem more as OK, what is the problem I'm trying to solve. Because we have Cloud Code, we have co-work or we have of chat where I try to identify or clarify as much in my life as possible, and I don't want to codify the things I actually enjoy doing.

35:23 For example, I sound weird when I say this, but I really enjoy creating keynote slides and I used to use Cloud code to automate that as well, because we have computer use and it can actually do a lot on your behalf. But I noticed, I kind of just enjoy doing this and I don't want claw to do this. This is my creative outlet. And of course, with Cloud Code, we have the Cloud bot running on all of our issues and our PRS.

35:45 So Cloud automatically auto fixes all of our PRS as well. After your demo, I was like, oh, I kind of just want to run auto fixup PR now, I don't know if you've set that up, but if you've installed the Cloud app on GitHub, basically what happens is if your Ci fails or someone leaves a comment, Cloud will automatically try to fix it until your Ci is green.

36:04 So if a code or if a teammate leaves a comment like hey, you forgot to add this or that, Cloud will take that feedback and try to fix it. And immediately push it to that branch. So all of these systems, everything we've set up, is just to be as out of the loop as possible and just kind of letting it do its thing. Which sounds scary, but with the right hooks and permissions using sandboxes and all of that stuff get really, really far.

36:28 And also, of course, we're trying to push it as far as we can because we are Anthropic still Cloud codes number one user. It's like, OK, we want to make sure that features we're building are features that we like on the team. Yeah so mainly that I love the term cloudify. I don't know if that is an official term, which is used internally, but yeah, I think using just like in general, just using AI to automate the things that you don't want to do so that you can enjoy doing the things that you like doing more.

36:58 It kind of reminds me I was on X the other day and someone built an app to respond to their partner and I was thinking, maybe we're optimizing too much. That's so sad. That's now you just got to be scared that your partner is doing that all the time. You're right to push back. You're absolutely right. OK, so why can't. Lyria, I also want to get your take on what's happening in the developer community recently, right.

37:24 We have all of these coding agents out and then but at the same time on Hacker News and I'm on Hacker News a lot. I see a lot of popular posts, kind of saying, I'm going back to writing code by hand, or an AI coding agent needs to reduce your maintenance cost, not just write code faster. And so it seems like there's a real conversation about craft control, technical debt.

37:53 So what are your thoughts on that. I know you have a lot of tips on this. You said, the best way to get better at Cloud Code is by using it. You also said be braver in the unknown. So you're very clearly all in. So what do you say to developers who feel like they're kind of losing their craft. My personal philosophy, at the end of the day, it is a tool.

38:17 So I'm not sure if this is the right analogy, but it's sort of as a painter, instead of using a regular brush, you're using an electric automated brush. So you're responsible for the output. That's the first thing I really, really want to emphasize, because I get frustrated by this kind of discussion whenever I read it. People say, oh, people will produce like so much code and it's not good with AI in general, not just Cloud Code.

38:44 And I say, OK, don't produce it then don't push it. As I said, there are so many ways to review code. Make sure it's good before it goes into production. If it's like a one time by coding kind of casual project, like the game I built, that's totally fine. You don't have to check the code, but if it's more of a serious production code base that you want to really be secure and safe about, then I say, create a draft PR, make sure it's good, review it manually or with AI.

39:13 If you generate 100,000 lines of code, you don't have to commit 100,000 lines of code. That It's not necessarily the way it is. Just commit what you think is right. And at the end of the day, you're responsible for the tool and the output Yeah I can also only agree with that. I feel like you still need to verify and you're really good at this. Having that verification layer I think is still very important.

39:37 But this is also important when you handwrite code. But it's definitely true that I think when you handwrite it, you like 90% of the review process happens as you're writing it. I think with Cloud Code, we've kind of shifted from 90% coding to 10% review because as you were doing it, you were already reviewing with Cloud Code, it's like 90% coding or 90% you have to review it and 10% maybe hand-coding the changes.

40:02 So there's definitely a lot more like importance in the reviewing phase now. And I feel like a lot of people have yet to shift their mindset towards that, where it's like, no, you have to review more. You can also automate that, and you definitely have to make that as easy for you as possible with permissions and hooks and all of that stuff, just to make sure Cloud was following your design spec already.

40:22 But it's definitely more important now than ever to be a good reviewer and verify that the changes for sure. Agreed yeah. And also kind of moving on from Cloud Code as just a coding tool. But beyond that you've said that it's the universal interface to your computer and the digital world. You use it for video editing, data analysis, storage, cleanup, research, writing, et cetera.

40:49 And you said you even saved $10,000 using it for research. So can you unpack that. And is the terminal really becoming the new everything. Yes so the research thing, I can definitely touch on that. But I think in general, I find it interesting how the computer started in the terminal. The computer just used to be the terminal. That was the whole UI.

41:09 But then we got these different GUI apps and stuff like that. But now we're back on the terminal, which I find pretty exciting. So I use it pretty much for everything, like research. If I want to go through a bunch of Reddit threads and find what the community is saying about a certain thing, I might copy and paste it manually, or I can just let Cloud Code handle it fetch information from different sources.

41:33 So I find that super helpful for that. On this particular case about saving $10,000. That's entirely true. I guess I can share a little bit more about it. Basically, I was in the process of buying a property and I wanted to find a good realtor. I didn't want to find it myself. So I had Cloud Code basically compile a list of Realtors. And I really specifically said, hey, give me a list of email addresses, give it to me, comma separated.

42:05 So I can write the email and email them directly. And that's how I was able to essentially, at the end of the day, save $10,000. Lyria Cloud Code is clearly being used for more than just writing code. Is that something intentional from nonprofit side. And how do you think about the expanding scope of what Cloud Code is turning out to be. Yeah it's interesting.

42:28 This is the backstory behind Cloud cowork as well, because back in December, we noticed that internally, a lot of our employees were using Cloud code for non coding tasks. So the marketing team was using it to create marketing files, data science, and so on. So we wanted to build a better harness for these types of tasks. And that's how cowork came out in a week because we of course, use Cloud code to build Cloud cowork as well.

42:52 And the desktop app. So right now we have two services. So if you're doing anything technical, use Cloud Code. If you're using something or if you're doing something non-technical like checking your email calendar, booking flights, all of that coworker is really good at that. It still uses the Cloud Code runtime underneath, so it can still do coding and can still do all of that, but we just have better connectors and better system prompts and code work to focus on that non-technical stuff.

43:15 But yeah, I also agree with what I just ended up using the CLI for everything on my computer, even certain kind of software related things where if I have a video and I don't want to edit it, or image manipulation, for example, like I always have to go to a website to do that, or maybe use specific software, but with Cloud Code, I don't have to use that software anymore.

43:36 I'll just ask it like, hey, please convert it to MP4, maybe reduce the volume a little bit. We edit a lot of our own videos just using Cloud Code in the CLI we generate simple audio samples, all that kind of stuff. So it's really like the bottleneck now is just your imagination. Cloud Code is can do pretty much anything on your computer at this point.

43:58 All right. Let's hop into the rapid fire round. I'm going to read out a statement. All you have to say is agree, disagree, or reason. You've blamed Cloud code for a bug that was actually your fault. That's a lie. Why can. Maybe I don't remember though. Yeah, AI makes senior developers more valuable, not less. Yes mostly agree. Yeah depends on the engineer.

44:27 Yeah, exactly. Yeah reading documentation is dead. No disagree. No I just assumed you guys had it on Claude is reading the documentation for you. It's also fun to read documentation, in my opinion. I like to just curiosity. Stay curious. Learning a new programming language in 2026 is a waste of time. No, I don't think so. I would focus more on software architecture over specific language features, but yeah.

44:58 Can you go back to coding without AI. You think. Yeah, I could. I wouldn't. But if I have to. Yeah final question. The one that I ask every guest. What is one tool, framework or workflow that both of you could never give up. And I think I can guess. But I thought I was going to say Cloud Code, but I realized I could build code with Cloud, so. Well fair enough.

45:28 But then you still depend on Cloud Code. So I feel like it's a Cloud code for both of us then. Thanks for watching. Everything that you've seen in this video is going to be LinkedIn the description box below from yc's repository on Cloud Code tips, as well as documentation showing you how you can run Cloud Code on Google's agent platform. To watch more Asian factory content, check out this next video on how you can run agent CLI on agent platform, as well as learn more about ADK 2.0. I'll see you in the next one.