Your Coding Agent Just Got Cloned And Your Brain Isn't Ready

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.

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.

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.

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.

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.

Inside Jules, the Jest task proceeds through a concrete execution sequence:

1. Connect the repository. Jules accesses the project through its GitHub integration and proposes a plan.
2. Review the plan. Banks checks the proposed calendar, search, and session test targets, then approves the work.
3. 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.

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.

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.

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:

1. Give a brief overview of the task.
2. State how the agent will know it got the result right.
3. Supply helpful context.
4. 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:

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.

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.