AI Engineer World's Fair 2025
Your Coding Agent Just Got Cloned And Your Brain Isn't Ready
Read the talk
Your Coding Agent Just Got Cloned, and Your Workflow Has to Change
Rustin Banks uses Jules to improve a conference schedule app, showing how parallel coding depends on clear tests, competing approaches, and a plan for merging the results.
From a talk by Rustin Banks
Before you start: Familiarity with Git branches, pull requests, and automated tests will help you follow the demonstration.
From a closet bulletin board to background coding
Rustin Banks’s first compiler was Borland C++ 3.1, ordered through AOL Classifieds. He recalls it arriving on ten five-and-a-half-inch floppy disks. He later hosted a bulletin board on salvaged computers in his parents’ closet, so the text interfaces of early AI assistants felt immediately familiar. By the time ChatGPT 3.5 appeared, he wanted to devote his career to AI coding. Watching its slow output again, he marvels at how recently that had been state of the art.
At Google Labs, Banks became a product manager for Jules, an asynchronous coding agent that works in the background while other tasks proceed. This talk takes place shortly after its May 2025 public-beta launch at Google I/O. The beta was free with usage limits in supported Gemini regions. Banks recalls a launch interruption: Josh called while demonstrating other Google Labs products, the team temporarily shut Jules down, and then brought it back.
The intended division of labor is straightforward: let the agent handle the laundry so developers can concentrate on the art of coding. Updating Firebase SDK usage is one example; managing development from a phone is another. Banks reports 40,000 public commits in the two weeks after launch. Those examples make background coding tangible: work can continue without keeping the developer at a laptop, supervising each edit.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Parallel execution needs help at both ends
Most developers have a serial default: take a task from the queue, work on it, then take the next one. Running agents concurrently changes that middle step, but it can leave a person preparing tasks all morning and reviewing pull requests or resolving merges all afternoon. More execution capacity only helps if task preparation and integration can keep up.
At the beginning of the workflow, AI can help turn backlogs and bug reports into actionable tasks. At the end, Banks anticipates critic agents and merging agents helping assess and assemble the results. He presents that integration assistance as help on the way, rather than a finished capability demonstrated here. Its purpose is to prevent parallel coding from becoming an exhausting task-writing and review job.
Remote agents make concurrent execution practical because their work is not bounded by the developer’s laptop. Each can operate in a cloud environment, remain connected, and accept interaction from another device. Banks describes this as agents as a service, with effectively unbounded scaling as the architectural aspiration; the launched service still has the usage limits described above. Moving execution away from the IDE changes where work can happen, but does not remove the need to coordinate its results.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Do more tasks, or try more approaches
The expected use of parallel agents is multitasking: assign ten backlog items, run them together, then merge and test the changes. A second pattern emerged from users: give several agents the same goal with different approaches. Banks points to Solomon from Dagger requesting three versions of a website earlier at the conference. Instead of committing to one implementation before seeing it, the developer gets alternatives to inspect.
| Pattern | Agent assignments | What happens afterward |
|---|---|---|
| Multiple tasks | Different backlog items | Merge and test the combined changes |
| Multiple variations | Different approaches to one task | Test candidates and choose |
For variations, either the user or agents can evaluate the candidates. The distinction matters because alternatives are not necessarily changes to combine: some are experiments to discard after comparison.
Consider adding drag and drop to a React app. Banks proposes separate agents using react-beautiful-dnd, using dnd kit, or taking a test-first approach. Each can work asynchronously, then return an implementation for evaluation. The first library belongs to the historical example: its repository was archived on August 18, 2025, after this talk. The enduring technique is to vary the approach while keeping the desired behavior fixed.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A conference schedule with room to improve
The demonstration starts with the conference schedule. Its horizontal scrollbar gives Banks an immediate usability complaint, but the organizers have also published the schedule as JSON. That feed lets other developers build their own interfaces. Pallav’s version adds favorites and bookmarks, and Banks already uses it to keep track of sessions.
Banks asks Pallav for permission to clone the project for the Jules demo. Pallav agrees and reports that he has just fixed a bug with Jules from his phone while sitting in a session. With an existing app to work on, Banks opens Linear to organize the changes.
The first task is to establish a way to tell whether subsequent agent changes work. Banks starts competing test-suite tasks using Jest and Playwright, proposing test coverage as the selection criterion. This uses the variations pattern before moving on to independent improvements: first choose a verification foundation, then let more tasks build on it.
The proposed work then expands:
- Features: add a Google Calendar link for a session and an AI summary when a user clicks its description.
- Neglected maintenance: use agents for accessibility and security audits, work that often remains on the backlog despite its importance.
- Selected demo tasks: run an accessibility audit, fix issues, and improve Lighthouse scores alongside the feature work.
Security is an example of useful backlog work here, not a demonstrated audit result. Banks chooses a front-end project because the changes are easy to show, while noting that the same workflow can apply to back-end development.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Give the agent a testable foundation
Inside Jules, the Jest task proceeds through a concrete execution sequence:
- Connect the repository. Jules accesses the project through its GitHub integration and proposes a plan.
- Review the plan. Banks checks the proposed calendar, search, and session test targets, then approves the work.
- Execute remotely. Jules has its own cloud VM with the entire codebase cloned into it. It can run project commands, including tests, rather than merely suggest edits.
That last step supplies the feedback loop needed for later feature work: the agent can observe a failure and change its implementation.
Banks fast-forwards through test creation. Alongside the Jest tests, Jules updates the README with instructions for running them. Those instructions become reusable context: a later task can read the repository and discover how to check its own changes.
Banks estimates roughly 80% test coverage for the Jest candidate. He suggests comparing it with Playwright, but does not show a comparative result or establish a winner on that basis. A useful comparison would need the same file scope and reporting method: Jest distinguishes statement, branch, function, and line coverage, while Playwright’s documented coverage API collects browser JavaScript and CSS usage in Chromium. A percentage alone does not establish which suite better verifies the app.
The Jest pull request is then merged into main. This is the dependency boundary in the demo: the shared test foundation lands before Banks requests the calendar feature, so subsequent work can use it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Let test failures drive the next edit
The calendar-button task does not pass its tests on the first attempt. Jules makes changes and runs them again; this time they pass. Banks can now review the code with evidence from the test run. He also mentions eventual inspection in a Jules browser, but that is prospective in this demonstration. The working mechanism here is the edit–test–repair loop inside the agent’s execution environment.
Next comes a Gemini-generated summary opened from a session description. Banks switches to an emulated mobile view to illustrate how the work could be managed from a phone, then shows interaction with the accessibility audit and fixes. He acknowledges visible console errors and says Jules will fix them; their resolution is not shown at this point. Remote access makes the tasks available on another screen size, while the actual coding work remains in the cloud.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A working feature is not yet a combined release
The parallel tasks leave a larger integration job. Banks says he ran out of time to finish the combined merge, naming an octopus merge and joking that Jules’s squid identity should make it a natural helper. Git’s octopus strategy can merge more than two heads, but refuses complex merges requiring manual resolution. It does not automatically solve conflicting edits from concurrent agents.
Instead, Banks checks the calendar feature locally. He refreshes localhost, finds the new button, clicks it for his own talk, and adds the session to Google Calendar. That verifies the visible user path for this feature without implying that all the parallel work has been integrated.
Merging the remaining changes into main so conference attendees can use them is still a next step. Banks estimates about an hour for the demonstrated work and management of the parallel process. His account includes the calendar feature, test suite, accessibility work, and Lighthouse improvement, but gives no numerical Lighthouse result; the combined merge and public deployment remain unfinished in the demonstration.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keep the success criterion fixed
Define how you will verify success before starting the agents. Otherwise, parallel execution simply produces more pull requests to inspect. Banks recommends making an explicit agreement with the agent: continue until a specified result is observed or a behavior works. A robust merge-and-test process must still assemble the output afterward, even as better assistance for that work develops.
His prompt structure separates the goal from the implementation choice:
- Give a brief overview of the task.
- State how the agent will know it got the result right.
- Supply helpful context.
- End with a broad approach.
For a complex task, he changes that last line across two or three variants. The goal and its acceptance condition stay stable, making the approaches easier to compare.
His example is a task that reads a number from a webpage each day. Today’s known value is X, so the agent should extract the number, log it to the console, and keep working until the output matches X. A small JavaScript check can express that observable condition:
javascript
function verifyExtractedNumber(actual, expected) {
console.log(actual);
if (String(actual).trim() !== String(expected).trim()) {
throw new Error(`Expected ${expected}, received ${actual}`);
}
}
Here actual must come from the extraction, while expected is supplied independently from today’s known value. The check makes a mismatch visible; the agent still has to repair the extraction and rerun it.
Banks supplies the search query as context, asks one task to use Puppeteer, and clones it with the final approach changed to Playwright. In a reusable prompt, that separation looks like this:
Task: Read the number from the target webpage each day.
Success: Today's known value is X. Log the extracted value to
the console and keep working until it matches X.
Context: [the search query that locates the target webpage]
Approach: Use Puppeteer.
The second candidate changes only the approach line to Use Playwright. Both candidates must satisfy the same observable outcome, so the experiment compares ways of solving the problem rather than different definitions of done.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make experimentation affordable to verify
Banks closes by encouraging an abundance mindset: with easy verification, developers can try alternatives that a serial workflow would never make time for. The useful expansion is not merely a larger task count. It is the ability to inspect several plausible solutions before deciding which one deserves to become part of the product.
That freedom still depends on the surrounding workflow. Use AI to help create tasks and to support the merge-and-test work afterward. Keep context in Markdown files, documentation links, and getting-started guides so agents can discover how the project works. The earlier README update is a concrete example of turning one completed task into guidance for the next.
Banks recommends supplying extensive context and letting agents identify the relevant parts, then qualifies that advice as perhaps especially applicable to Gemini models. He identifies Gemini 2.5 Pro as the model powering Jules at the time. The final design choice is therefore to make both the task and its environment legible: give agents enough information to act, and a clear result against which to check their work.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
The conference schedule links its public JSON data and community interfaces, including Pallav's list and bookmarking app.
The React list drag-and-drop library from Banks's variation example; its repository is now archived.
Current documentation for building drag, drop, sorting, and reordering interactions.
Configure coverage collection, included files, reporting, and minimum thresholds for Jest tests.
Collect JavaScript and CSS usage through Playwright's Chromium coverage API.
Git's reference explains multi-head merges and the octopus strategy's conflict-resolution limits.
Browser automation documentation for the tool Banks proposes as an alternative to Playwright.
Further reading
Google's launch account explains Jules's cloud execution, parallel tasks, Gemini 2.5 Pro foundation, and free-beta conditions.
Updates since the talk
Current instructions for connecting GitHub, preparing a task, approving a plan, and supplying repository instructions.
Read the complete timestamped transcript
- 0:00
[upbeat music] Hi, everyone.
- 0:15
I'm Rustin. I'm a product manager with Google Labs, and really thrilled to be here and get to speak to you today. This is really like a, a dream come true.
- 0:25
So I'm an engineer at heart. This is my first compiler, Borland C++ 3.1. It came in the mail on 10 five-and-a-half inch floppy disks. I ordered it from AOL Classifieds.
- 0:37
It was amazing. This is my bulletin board, yeah, that I hosted out of my parents' closet and 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.
- 0:53
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 that we-- that how slow this is, and this used to be state-of-the-art only two years ago?
- 1:10
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 wanna do in parallel in the background.
- 1:26
And we launched this just two weeks ago at I/O to everyone, everywhere, all at once, for free,
- 1:37
while Josh was up on the stage trying to demo other Google Labs products. [laughs] And so he called us, and we said, "Oh, we gotta shut it down so that we can demo other products," and, and luckily, we got it up and going.
- 1:49
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 wanna solve. We want to do the laundry, so to say, so that you can focus on the art of coding.
- 2:03
So the next time Firebase updates their SDK, Jules can do that for you, or if you just wanna develop from your phone, Jules can do that for you. So in the last two weeks, we've had forty thousand public commits, and we're super excited what we can bring to the open source world.
- 2:19
So, but as developers, we're meant to think serially. We take a task from the queue, we work on it, we go onto the next one. That's our default workflow.
- 2:30
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.
- 2:44
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
- 3:01
day, that's not gonna 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, uh, 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
- 3:24
make it so that this tr-- this parallel workflow that we've envisioned can really come together and not drive us crazy.
- 3:33
Remote agents are uniquely suited for this. Agents inside of our IDE are always gonna 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.
- 3:51
We've seen two types of parallelism emerging. This is the type that we expected, which is multitasking. Oh, I'm just-- I have ten different things on my backlog. Let's do them all at once, and then we'll merge them together and test them.
- 4:08
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.
- 4:22
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.
- 4:38
And we can have the agents test and choose the best ones, or the user can, can test and choose.
- 4:45
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.
- 4:55
Maybe try it using this library, uh, the React beautiful, beautiful drag and drop, or maybe use dnd-kit, or maybe try it using the test first." And in this parallel asynchronous environment, you can just spin up multiple agents at the same time.
- 5:11
They can try it, they can easily come back together, choose the best one, and you're off to the races. Okay. Demo time.
- 5:21
So exit out of this. For a demo, I'm going to use the conference schedule website. And
- 5:32
Swix, for all his skills, as you can see, has probably not spent a lot of time designing the, the schedule website, as you can see there. Anytime there's a horizontal scroll, scroll bar, uh, we, we know that's a problem.
- 5:46
But luckily, they knew that, and they said, "We're just gonna publish the JSON feed, and we'll let, we'll let hackers hack. Uh, engineers do what we do, and let's build from it."
- 5:56
So Pahlav, who is here, built this amazing, uh, conference site where you can favorite things, you can bookmark things, and, uh, this is what I use to keep track of my, my sessions for the conference.
- 6:09
And so I messaged him, I said, "Hey, can I u- can I use, phone this and use this for, as an example for Jules?" And Pallav said, "Oh yeah, sure.
- 6:18
Actually, I was sitting in my last session on my phone, and I fixed a bud- a bug using Jules." So I thought that was perfect. So this is how I would start something like this, is I would go into linear, and I would say, "Okay, first thing we need to do," we just heard Scott talk about it,
- 6:34
is I want to add a way to know if this parallel agent is gonna do a bunch of things at the same time, that it's getting it right. So first we're gonna add in some tests, and then I'm gonna actually, I'm gonna kick this one off while I'm thinking about it.
- 6:50
And then, using that idea of multiple variations, I'm gonna say, "Add it with Jest, and add it with, 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.
- 7:04
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."
- 7:14
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 t- 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.
- 7:31
So we're gonna 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, it's a better visual representation, but we've seen all these, all these apply to the back end as well.
- 7:50
Okay, so here's Jules. We a- told it to add, add tests in a Jest framework. It connects to my GitHub, all my GitHub repos, and, uh, it's gonna give me a plan.
- 8:02
That looks about right. I can see it's gonna test the calendar, the search relay, the session. That sounds great. I can approve the plan. So Google, so Jules now has its own VM in the cloud.
- 8:13
It's cloned my whole, whole code base. It can run all the commands that I can run, and un- 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 things right.
- 8:26
So I'm gonna fast-forward a little bit here. And so this is adding, uh, Jest tests. You can see all the, the things it's, or all the components it's, it's added to the tests.
- 8:39
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."
- 8:47
And let's see how it did on test coverage.
- 8:52
Okay, 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, the one we like the best.
- 9:06
We merge that into main, and now we're, we're off to the races. So that, again, it's automatically integrated into GitHub. We merge that into, into main, and now we can start saying, "Okay, now I want a calendar link."
- 9:20
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.
- 9:29
It makes some changes. Now the tests pa- 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.
- 9:42
Similarly, for, uh, 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.
- 9:54
So this is making accessibility audit, fixing any issues from my phone. Uh, never mind the console errors. Jules is going to fix those. And then I can go back.
- 10:07
I can... 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.
- 10:18
So surely Jules, as a squid, should help with the Oc- Octopus merge. But let's just pull our, check out our add to calendar button.
- 10:28
Go back to this. Localhost. Refresh. And now I have a calendar button. Let's test it. Okay, let's add this to my calendar to make sure I know to come to my own talk, and there it's on, it's on my calendar.
- 10:45
I could then now, again, pull this back into the main branch, and now everybody at the conference has the ability to add, add sessions to their Goo- 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,
- 11:06
and managing the, the parallel process in the back end.
- 11:11
Okay. So, in fair- 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 gonna easily verify that this works?"
- 11:28
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 robu- robust merge and test framework at the end to put everything back together, and help is coming.
- 11:45
This is how I prompt for Jules. I give it a brief overview of the task. I tell it when it will know when it, it got right, any helpful context, and then I'll, 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
- 12:02
the task. So for example, if I need to log this number from this webpage 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."
- 12:14
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 t- task because I can, it's in the cloud, and I'll say, "Use Playwright."
- 12:30
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.
- 12:41
As we saw this morning, look at different variations. We can, with a parallel process, we can, we have the ability now to try things that we would never have tried before.
- 12:52
Let AI help with those bookends, the task creation, and then the merge and, and test part, and context. Keep using MD files or links to documentation to getting started do- documents.
- 13:03
The more context, the better. And then we tell people, "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, uh, the Gemini models, which I should have mentioned, Jules is powered by Gemini 2.5 Pro.
- 13:24
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, [REDACTED:username] on X. Thanks, everybody. [upbeat music]