Google Jules and the Asynchronous Coding Agent in a Cloud VM
Google Jules treated coding as delegable asynchronous work: it cloned a repository into a short-lived cloud VM, formed a plan, edited and tested code, and returned changes for review.
Jules was introduced as a worker for delegated coding tasks
Google first previewed Jules in late 2024 as an experimental code agent built around Gemini and integrated with GitHub. The product was deliberately described as something developers could assign work to rather than watch continuously: it would form a multi-step plan, modify files, and prepare a pull request while the developer focused elsewhere.[1] That interaction model was a break from autocomplete and chat-based pair programming. The important unit was no longer a suggestion or a conversational turn but a task with a beginning, an execution environment, intermediate work, and a reviewable result. Jules therefore helped make “asynchronous coding agent” a concrete product category rather than only a research aspiration.
Asynchrony changed the developer’s role from typist to delegator
With Jules, the developer could hand off a bounded repository task and return later. That makes task definition, environment setup, observability, and review more important because the agent is operating without continuous correction.[1]
The 2025 public beta made autonomy the center of the product
At Google I/O in May 2025, Jules entered public beta. Google distinguished it from a copilot or completion tool by emphasizing autonomous repository work: reading code, understanding intent, creating plans, fixing bugs, writing tests, and handling tasks in parallel.[2] The choice of GitHub as the surrounding workflow mattered. Jules did not invent a separate code-hosting world; it attached agent execution to repositories, branches, issues, diffs, and pull requests that teams already understood. That made the agent legible as a software collaborator even when its internal model behavior remained probabilistic.
A plan created a checkpoint before code was written
Jules generates a plan before implementation, giving the developer an opportunity to review assumptions and direction. That planning step is a small but important control point in an otherwise asynchronous workflow.[2]
Each task ran inside a short-lived development environment
Jules’s cloud architecture turned environment management into part of agent design. The documentation describes each task running inside a secure, short-lived Ubuntu virtual machine where the agent can clone the repository, install dependencies, and run tests.[4] This matters historically because coding agents need more than language-model access to source text. They need compilers, package managers, test runners, network rules, credentials, and a reproducible environment in which actions have observable consequences. A disposable VM limits persistence and gives the agent an execution surface that is isolated from the developer’s laptop.
The VM made tool use testable and disposable
A short-lived environment lets an agent execute real commands and validate changes while containing the work to a session. It also exposes a new source of failure: if dependencies or setup scripts do not reproduce correctly, the coding agent may fail before it reaches the code problem.[4]
Leaving beta showed that the experiment had become a continuing service
In August 2025 Google took Jules out of beta and reported more than 140,000 publicly shared code improvements during the beta period.[3] The release also moved planning to Gemini 2.5 Pro and introduced plan tiers. Vendor-reported usage should not be treated as an independent quality benchmark, but it shows that asynchronous coding had found enough demand for Google to turn the experiment into a maintained product. More importantly, the launch preserved the delegation model rather than collapsing Jules back into an IDE sidebar. The agent’s identity remained tied to completing tasks remotely and returning artifacts for human review.
GitHub issues made the repository itself an agent queue
Jules later allowed a GitHub issue labeled “jules” to start a task, further reducing the distance between project management and execution. The repository could now contain both the description of work and the trigger that delegated it. This pattern is broader than Jules: once agents can be invoked from issues, tickets, or chat systems, the backlog becomes an executable queue. The operational challenge shifts toward deciding which tasks are sufficiently specified, what permissions the agent receives, and how its proposed changes are reviewed before merge. The agent can remove interaction cost without removing accountability.
The API turned asynchronous coding into infrastructure
In October 2025 Google introduced a Jules API for creating sessions programmatically and connecting the agent to tools such as Slack, Linear, Jira, CI/CD systems, and custom workflows.[5] That was a significant architectural step. A human no longer had to start every job from the Jules interface. Other systems could schedule or trigger software-engineering work, making the coding agent part of automation around the repository. This pattern foreshadowed the idea of fleets of agents handling maintenance, bug fixing, upgrades, and feature tasks as background processes rather than as one developer’s interactive session.
The agent became callable by other software
An API makes the coding agent composable. Once a session can be created by another service, developers must think about rate limits, credentials, policy, auditability, and failure handling in the same way they would for any other production automation.[5]
Asynchronous agents did not eliminate the need for review
Jules’s workflow remained organized around plans, diffs, tests, branches, and pull requests. Those artifacts are important precisely because the agent works without constant supervision. Asynchrony creates leverage by allowing many tasks to run while a developer is occupied elsewhere, but it also delays feedback: a mistaken assumption can survive for minutes or hours before a person notices. The historical contribution is therefore not “AI writes code alone.” It is a new division of labor in which a human scopes and reviews work while a cloud worker performs the mechanical exploration and implementation between those checkpoints.
Why Jules belongs in the history of vibe coding
Jules belongs in this history because it helped move AI coding from a synchronous conversation toward delegated background work. Google’s design combined repository access, a planning checkpoint, a disposable cloud VM, execution tools, test feedback, GitHub integration, and eventually a programmatic API.[1][4] Together those elements made the agent resemble a remote software worker more than an autocomplete feature. The lasting idea is the asynchronous task boundary: describe work clearly enough to hand it off, let an agent operate in a controlled environment, and evaluate the returned branch or pull request. That model has become one of the defining alternatives to continuous prompt-and-edit “vibe coding.”
Works Cited
- 01Google Developers Blog — The Next Chapter of the Gemini Era for Developers developers.googleblog.com
- 02
- 03Google — Jules Is Now Available for Everyone blog.google
- 04Jules Documentation — Environment Setup jules.google
- 05Jules Documentation — Introducing the Jules API jules.google
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead