What Is Google Jules? How the Coding Agent Works

What Is Google Jules?

Google Jules is an asynchronous coding agent that works on a selected GitHub repository inside a cloud virtual machine. It can plan a bounded task, modify files, run discrete commands and tests, and return changes as a branch or pull request for review.

It is not an employee, a correctness guarantee, or a reason to remove repository controls.

The execution flow

The current Jules getting-started guide begins with a Google account and GitHub authorization. The user selects a repository and starting branch, writes a task, optionally configures the environment, and asks Jules for a plan.

Jules then works in a task-specific VM.

flowchart LR
    A["User and GitHub authorization"] --> B["Repository and branch"]
    B --> C["Task prompt"]
    C --> D["Fresh cloud VM"]
    D --> E["Setup and repository instructions"]
    E --> F["Plan and feedback"]
    F --> G["Code and tests"]
    G --> H["Diff and summary"]
    H --> I["Branch or pull request"]
    I --> J["Independent review and merge"]

The user can leave while the task runs and return when Jules needs feedback or finishes.

Repository access comes first

Jules needs source access to reason about a repository. Its GitHub application can be limited to selected repositories.

Current repository documentation says Jules can access only repositories explicitly authorized through GitHub and explains how to change that access later.

Granting access can expose code, configuration, documentation, tests, fixtures, history, and accidentally committed credentials. Select the smallest set of repositories needed. Review the GitHub application permissions and remove access when the workflow no longer needs it.

Google says Jules does not train on private repository content in the current FAQ. That is a data-use statement, not a claim that repository execution has no security risk.

Every task has its own VM

Jules runs each task in a short-lived Ubuntu virtual machine. The current environment guide lists common language runtimes, compilers, package tools, Docker, Git, and other developer utilities.

The VM clones the repository, installs dependencies, runs setup, and executes the task. A repository can provide a setup script and create a snapshot for later tasks.

Task isolation prevents one agent process from editing another task's live filesystem. It does not prevent two returned changes from conflicting semantically.

The VM has internet access. Treat dependency installers, build scripts, downloaded tools, web content, and external services as part of the threat surface.

Repository instructions reduce guesswork

Jules looks for AGENTS.md at the repository root and can use README guidance. The file can describe build commands, tests, directory boundaries, conventions, generated files, and acceptance expectations.

Instructions should be durable repository knowledge, not a container for credentials or private customer data.

Keep the file current. A stale instruction can make an agent consistently wrong with high confidence.

The task prompt still matters. Name the outcome, constraints, non-goals, acceptance tests, files or interfaces in scope, and conditions that should stop the work.

The plan is a control point

Jules presents a plan with intended steps and assumptions. The user can ask for revisions before or during execution.

Current plan-review documentation says a web plan may auto-approve after a timer. The API requires the caller to set requirePlanApproval: true when explicit approval is needed. Otherwise the current sessions API auto-approves.

Read the plan for scope, not elegance. Confirm that it addresses the actual requirement, preserves important interfaces, names the right tests, avoids unrelated cleanup, and does not need secrets or migrations the task did not authorize.

Completion returns an artifact, not a verdict

The current code review guide says Jules presents a full diff and a summary with changed files, runtime, line counts, branch, and commit information. The user can request corrections and publish a branch or pull request.

Jules can also respond to pull-request feedback and automatically try to fix certain CI failures on its own pull requests.

Those features help close a loop. They do not make the loop independent.

The same agent can misunderstand a requirement, implement it, write a test that encodes the misunderstanding, and repair CI until the test passes. An independent reviewer must compare the behavior with an independently stated acceptance criterion.

Parallel tasks are isolated but related

Jules supports multiple simultaneous tasks. Current limits vary by plan and change over time, so recheck the official plan page rather than preserving a number in an evergreen guide.

Every task has a separate VM and change set. They still share the repository's architecture and future base branch.

Two agents can both be locally correct and jointly incompatible. One may rename an interface while another adds a caller. One may update a dependency while another relies on the older behavior.

Use stable task boundaries, explicit contracts, integration order, protected branches, and a concurrency limit based on review capacity.

Secrets need explicit handling

Jules supports repository-level environment variables that a user can enable for a task. The current environment-variable announcement says enabled values remain available for the task's duration.

Use synthetic data and test credentials. Grant minimum scope. Avoid production databases, customer records, payment systems, deployment keys, and broad cloud permissions.

Review logs, generated artifacts, new configuration, and error messages for leakage. Rotate a credential when its path or exposure is uncertain.

The Jules API uses a separate API key. Google's current authentication guide says to keep it out of source control and recommends an environment variable.

API automation changes the default

The Jules REST API can create sessions, inspect activities, send messages, approve plans, and retrieve outputs. A session can also use an automation mode that creates a pull request.

Programmatic access is useful for repetitive work and queues. It makes it easier to start many tasks without a person seeing the plan.

Require plan approval for consequential tasks. Log the source repository, branch, prompt, plan, identity, output, and pull request. Never use automatic pull-request creation as automatic merge permission.

Work that fits

Jules fits tasks that can be described and tested without continuous steering. Focused documentation, missing tests, a contained bug, a dependency update, or a feature behind a stable interface can be good candidates.

An IDE assistant may fit better when the developer is exploring architecture, discovering the requirement while reading code, debugging a production incident, or making a change whose meaning depends on rapid judgment.

The strongest workflow uses both. Explore interactively, extract a bounded task, delegate execution, and return to independent review.

The developer's role changes

Jules reduces the need to type every implementation step. It increases the importance of selecting the repository, describing the work, reviewing the plan, constraining the environment, challenging the tests, and deciding whether the result belongs in the product.

The agent does not remove review. It moves review.

Read the [[Google Jules Product Profile]], [[Asynchronous Coding Agents vs IDE Assistants]], and [[How to Review an AI-Generated Pull Request]] next.

AI assisted with research organization and drafting. Dalton Anderson remains responsible for the analysis and publication decision.