Your Coding Agent Just Got Cloned And Your Brain Isn't Ready - Rustin Banks, Google Jules

Hi everyone. I'm Rustin. I'm a product manager with Google Labs, and I'm really thrilled to be here and get to speak to you today. This is really like a dream come true. So, I'm an engineer at heart. This is my first compiler, Borland C++ 3.1.

It came in the mail on 10 5.5-inch floppy disks. I ordered it from AOL classifieds. It was amazing. This is my bulletin board, yeah, that I hosted out of my parents' closet in salvaged computers. And I just think it's ironic that when I saw AI come out, I recognized the text-based interfaces perfectly from hosting bulletin boards.

And then when I saw this, like many of you, I dedicated my career to AI coding. And this is ChatGPT 3.5. Isn't it crazy how slow this is? And this used to be state of the art only two years ago.

It's pretty amazing. Right now I'm a product manager for Jules. And Jules is an asynchronous coding agent meant to run in the background and do all those tasks that you don't want to do in parallel in the background.

And we launched this just two weeks ago at I/O to everyone, everywhere, all at once, for free, while Josh was up on the stage trying to demo other Google Labs products. And so he called us. We said, oh, we've got to shut it down so that we can demo other products.

And luckily we got it up and going. But it was a super exciting launch. And the best part about it is to see these use cases where this is what we really want to solve. We want to do the laundry, so to say, so that you can focus on the art of coding.

So the next time Firebase updates their SDK, Jules can do that for you. Or if you just want to develop from your phone, Jules can do that for you. So in the last two weeks, we've had 40,000 public commits.

And we're super excited about what we can bring to the open source world.

But as developers, we're meant to think serially. We take a task from the queue, we work on it, we go on to the next one. That's our default workflow. Today we'll learn about how to maximize parallel agents. I'll try a real-world demo, and we'll go through a real-world use case.

And then I'll go through some best practices we've learned from watching people use Jules. So for this parallel process really to work well, we need to get better with AI at the beginning and the end of the workflow.

Meaning, if it's on me to now I just have to write a bunch of tasks all day, that's not fun. And if I'm reviewing PRs and handling merge messes at the end of the day, that's not going to work well either.

So luckily help is on the way. So for example, AI can easily work through backlogs, bug reports, to create tasks for you, with you. And then at the end of the SDLC, help is on the way where we can use critic agents, merging agents that can bring everything together and make it so that this parallel workflow that we've envisioned can really come together and not drive us crazy.

Remote agents are uniquely suited for this. Agents inside of our IDE are always going to be limited by our laptop. And when you have these remote agents in the cloud, essentially agents as a service, they're infinitely scalable. They're always connected.

And then you can develop from anywhere from any device. We've seen two types of parallelism emerging. This is the type that we expected, which is multitasking. Oh, I have 10 different things on my backlog. Let's do them all at once.

And then we'll merge them together and test them. Interestingly, you saw an example of the second type this morning with Solomon from Dagger showing how he wanted three different views of his website at the same time. This was the emergent behavior we didn't expect, which is multiple variations.

Essentially, we see users taking a task, especially if it's a complex task, and saying, try it this way, try it that way, or give me this variation to look at, or multiple variations to look at. And then you can test and choose.

And we can have the agents test and choose the best ones, or the user can test and choose. So for example, we see lots of people who are working on a front-end task test, and they're in a React app.

And they're saying, I'm adding drag and drop. Maybe try using this library, the Beautiful Drag and Drop. Or maybe use DND Kit. Or maybe try using the Testverse. And in this parallel asynchronous environment, you can just spin up multiple agents at the same time.

They can try it. They can easily come back together, choose the best one, and you're off to the races. OK, demo time. So exit out of this. For our demo, I'm going to use the conference schedule website. And Swix, for all his skills, as you can see, has probably not spent a lot of time designing the schedule website, as you can see there.

Any time there's a horizontal scroll bar, we know that's a problem. But luckily they knew that. And they said, we're just going to publish the JSON feed and we'll let hackers hack. Engineers do what we do. And let's build from it.

So Pal Love, who is here, built this amazing conference site where you can favorite things. You can bookmark things. And this is what I use to keep track of my sessions for the conference. And so I messaged him.

I said, hey, can I phone this and use this as an example for Jules? And Pal Love said, oh, yeah, sure. Actually, I was sitting in my last session on my phone and I fixed a bug using Jules.

So I thought that was perfect. So this is how I would start something like this. I would go into Linear and I would say, OK, first thing we need to do, we just heard Scott talk about it, is I want to add a way to know if this parallel agent is going to do a bunch of things at the same time that it's getting itright.

So first we're going to add some tests. And then I'm going to actually I'm going to kick this one off while I'm thinking about it.

And then using that idea of multiple variations, I'm going to say add it with Jest and add it with Playwright at the same time. And then we'll look at the test coverage and we'll choose the one that has the best test coverage.

Once that's done, then I can go to that other mode of parallelism. And I say, I would like a link to add a session to my Google Calendar. I would like an AI summary when I click on a description.

And these are all features. But what I'm really excited for is for AI to do the stuff that we never seem to get to, such as accessibility audits and security audits, all those things that seem to go on the backlog but are really important.

And I'm super excited for AI to do that. So we're going to also have it do an accessibility audit and improve our Lighthouse scores at the same time. This is mostly a front-end demo because, well, I'm mostly a front-end engineer.

And it's a better visual representation. But we've seen all these applied to the back end as well. OK, so here's Jules. We told it to add tests in a Jest framework. It connects to my GitHub, all my GitHub repos.

And it's going to give me a plan that looks aboutright. I can see it's going to test the calendar, the search relay, the session. That sounds great. I can approve the plan. So Jules now has its own VM in the cloud.

It's cloned my whole code base. It can run all the commands that I can run. And importantly, after it has these tests, it can run these tests. So it can know when we add a new feature if it gets thingsright.

So I'm going to fast forward a little bit here. And so this is adding Jest tests. You can see all the things or all the components that it's added to the tests. It's added to the README. So now next time that it goes to add something, it'll look at the README and remind itself, oh, this is how I run the tests.

Let's see how it did on test coverage.

OK, we got down to

looks like about estimated test coverage looked like about 80%. So that's pretty good. We could compare that with Playwright. And then we could just choose the one we like the best. We merge that into main. And now we're off to the races.

So again, it's automatically integrated into GitHub. We merge that into main. And now we can start saying, OK, now I want a calendar link. So I want a calendar button that can go in. And Jules will work on that.

And then sure enough, it ran the test. The test didn't pass the first time. It makes some changes. Now the tests pass. And I can review this code. Eventually I could look at this in Jules' browser. But I feel pretty confident about testing this knowing that all the tests pass.

Similarly, for the Gemini summaries, when I click on a description, I can get a Gemini summary. I put this one in an emulator, or I emulated a mobile view, just so you can see I could have done this from my phone.

So this is making an accessibility audit, fixing any issues from my phone. Never mind the console errors. Jules is going to fix those. And then I can go back. Now we have this big merge we need to do.

And to be honest, I ran out of time to finish the merge. And Jules should help me with this merge. And it's called an octopus merge. So surely Jules, as a squid, should help with the octopus merge. But let's just pull our checkout, our add to calendar button.

Go back to this. Localhost, refresh. And now I have a calendar button. Let's test it. OK, let's add this to my calendar to make sure I know to come to my own talk. And there, it's on my calendar.

I could then now pull this back into the main branch. And now everybody at the conference has the ability to add sessions to their Google Calendar, along with everything else that we saw there, a full test suite, all the accessibility audits, a Lighthouse scores improvement.

And that took me all about an hour and managing the parallel process in the back end. OK, so in summary, the secret to working in parallel is a clear definition of success. Because nobody wants to review PRs all day.

So think before you get started, how am I going to easily verify that this works? Again, Scott hit on this as well. Create disagreement with the agent. Tell it, don't stop until you see this, or don't stop until this works.

And then a robust merge and test framework at the end to put everything back together. And help is coming. This is how I prompt for Jules. I give it a brief overview of the task. I tell it when it will know it gotright, any helpful context.

And then at the end, I'll append a simple broad approach. And then I'll change that last line maybe two or three times, depending on the complexity of the task. So for example, if I need to log this number from this web page every day, I'll say, today the number is x.

So log the number to the console and don't stop until the number is x. That was a simple test that I wrote in. It'll keep going. I give it a helpful context, like this is the search query. And then I'll say, use Puppeteer.

And then I'll clone that task, because I can. It's in the cloud. And I'll say, use Playwright.

So again, have an abundance mindset. We're used to working on a single thing at a time. Easy verification makes it so now we can work on multiple things at the same time, try lots of things. As we saw this morning, look at different variations.

With a parallel process, we have the ability now to try things that we would never have tried before. Let AI help with those bookends, the task creation, and then the merge and test part, and context. Keep using MD files or links to documentation to getting started documents.

The more context, the better. And then we tell people to just throw everything in there. Jules and other agents are pretty good at actually sorting out which context is important. So more context is better at this point. But maybe that's just for the Gemini models, which I should have mentioned.

Jules is powered by Gemini 2.5 Pro. Quick shout out. Thank you, Team Jules. Couldn't have done any of this without you. If you have any questions, you can DM me. I'm Rustin Banks, RustinB on X. Thanks, everybody.