Jules runs coding tasks asynchronously in the cloud, allowing developers to work on several tasks or variations at once.
2
Parallel development only works well when tasks have clear success criteria and the agent can run tests or other checks.
3
AI should help create tasks before coding starts and handle testing, reviews, and merges after agents finish.
Summary
Rustin Banks describes Jules, Google's asynchronous coding agent, as a way to move from serial development toward parallel work. Jules runs in its own cloud VM, can clone a repository, execute commands, run tests, and integrate with GitHub. Banks shows two forms of parallelism: working on unrelated backlog items at the same time, and asking several agents to produce different versions of one solution. His demo uses a conference schedule site, where agents add tests, a calendar link, Gemini summaries, accessibility fixes, and Lighthouse improvements. The workflow depends on clear verification. Prompts should state what success looks like, provide useful context, and tell the agent when to stop. Banks also argues that developers need help at both ends of the process, from turning backlogs into tasks to reviewing, testing, and merging the results. He is candid that parallel work creates merge problems, including an unfinished "octopus merge" in the demo.
Jules moves routine coding work into asynchronous cloud tasks
Banks introduces Jules as an asynchronous coding agent that runs in the background. It is meant to handle tasks developers do not want to do themselves, such as updating an SDK or making changes while the developer works from a phone. He says Jules launched publicly at Google I/O and produced 40,000 public commits in its first two weeks. The aim is to leave developers more time for the parts of coding that require judgment and design. Jules runs remotely rather than inside the IDE, so it is not limited by a developer's laptop and can remain connected across devices.
Parallel development needs help at the task and merge stages
Developers usually work serially: they take one task from a queue, finish it, and move to the next. Banks says this workflow changes when several agents work at once, because humans would otherwise spend their time writing tasks, reviewing pull requests, and resolving merge conflicts. He expects AI to help turn bug reports and backlogs into tasks before coding begins. At the other end, critic agents and merging agents can check the results and bring changes together. Without support at both ends, parallel execution would create too much coordination work.
Agents support both multitasking and trying several versions
Banks describes two patterns that have appeared in Jules usage. The expected pattern is multitasking, where separate backlog items run at the same time and are later tested and merged. The second pattern is multiple variations of one task. A developer can ask different agents to solve a complex problem in different ways, then compare the results. For a React drag-and-drop feature, he gives examples such as trying React Beautiful Drag and Drop, DND Kit, or a test-first implementation. The developer or the agents can test the alternatives and select one.
A useful parallel task has an easy way to verify success
After the demo, Banks states that the central requirement for parallel work is a clear definition of success. Developers should decide before starting how they will verify the result, since reviewing every pull request manually defeats the purpose. They should also make an explicit agreement with the agent, using instructions such as "don't stop until you see this" or "don't stop until this works." Tests, coverage, accessibility checks, and Lighthouse scores give agents concrete ways to determine whether their changes are acceptable.
The Jules prompt combines a brief, context, and a stopping condition
Banks explains the structure he uses when prompting Jules. He starts with a short description of the task, says how the agent will know it got the task right, and adds useful context. He then appends a broad approach and changes that final instruction when the task is more complex. His example asks an agent to log a number from a web page every day, gives the expected value, and says not to stop until the value matches. He can clone the task and ask another agent to use Playwright instead of Puppeteer.
More repository context can help agents choose the right information
Banks recommends keeping context in Markdown files, links to documentation, and getting-started documents. He tells users to put in everything they have because Jules and similar agents can often sort out which parts matter. He qualifies that advice by saying it may apply especially to Gemini models. Jules is powered by Gemini 2.5 Pro. The recommendation is practical: give the agent the repository conventions, instructions, and relevant background instead of assuming it will infer them from a small task description.
"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.""04:19
Who should watch
You are considering coding agents that run outside your IDE and need a concrete model for assigning them work.
Your team wants to run several implementation attempts at once but is worried about testing, reviews, and merge conflicts.
You build front-end or full-stack products and want agents to handle neglected work such as accessibility audits, security audits, and test coverage.
