Google puts Jules where developers actually work: terminal, CI, and the PR queue

Google is moving Jules out of the browser and into the parts of the stack that decide whether work actually ships. The company has launched a Jules CLI and a public API, so its coding agent can run from the terminal, plug into CI/CD, and connect to chat tools such as Slack.

That changes where Jules fits.

For the last two years, most AI coding products fought over the editor. Autocomplete, inline edits, chat sidebars, diff suggestions. Useful, sometimes very useful, but still built around a person sitting there driving. Jules is aimed at a different job: take a scoped task, propose a plan, get approval, do the work, and come back with a pull request.

That’s a better place to compete.

Jules and Gemini CLI have different jobs

Google says Jules and Gemini CLI both run on Gemini 2.5 Pro, but it’s framing them for different kinds of work.

Jules is for bounded tasks with limited back-and-forth. You give it a target such as “upgrade FastAPI, fix breaking changes, update tests,” it drafts a plan, you approve it, and it runs. Gemini CLI is positioned as the conversational tool for exploratory work, debugging, and iterative coding.

That split tracks with where these systems usually fall apart.

Chat-first coding tools work reasonably well when the problem is fuzzy and a human wants to steer each step. Agent-style systems do better when the task is boxed in with clear constraints and validation. Upgrade this library. Fix lint failures in these files. Add tests for this module. Open a PR, run checks, stop if something goes wrong.

The bigger question is operational. Can the agent run where your tooling already lives? Can it work outside a chat tab? Can you audit what it did? The CLI and API are Google’s answer to that.

Why the terminal matters

A terminal-native agent feels different from a browser assistant for a reason.

From the terminal, Jules can sit next to the tools that already define done for most engineering teams: git, test runners, linters, package managers, build scripts, secret scanners, and branch protection rules. That matters because coding agents are only useful in production workflows when they can deal with artifacts and failure modes, not just source text.

The loop is straightforward:

1. Jules gets task context such as repo state, file diffs, tests, and constraints.
2. It generates a plan with files to change, checks to run, and success criteria.
3. A developer approves or edits the plan.
4. Jules executes in a scoped workspace, usually on a branch.
5. It runs validation and prepares a pull request with diffs and a summary.
6. If it gets stuck, it asks a narrow question instead of guessing past the problem.

That approval gate matters. It’s what makes this usable inside a controlled engineering process instead of a code-generation demo.

For teams already using GitHub Actions, GitLab CI, Jenkins, Buildkite, or internal runners, the CLI and API create obvious attachment points. A flaky test label could trigger a Jules task. A dependency alert could spawn an upgrade branch. A Slack command could kick off a refactor job against a specific service.

That’s the appeal.

A spec-to-PR product

The AI coding market has moved fast. The old demo was a model autocompleting a function. The newer one is an agent opening a PR that passes tests.

That’s where Jules sits.

A plan-and-execute agent is basically a change-management layer wrapped around an LLM. The model matters, but the product value comes from everything around it: scoping, tool access, validation, logs, retries, permissions, PR generation, and human approval.

Google seems to get that. The public API matters as much as the CLI because it makes Jules something teams can build around. Internal triggers, wrappers, custom portals, approval flows. If you’re on a platform engineering team, that’s the useful part. You probably don’t need another chat window. You need something that can take a ticket-shaped task, work inside existing guardrails, and hand back a PR.

What to watch

The caveat is that agent-style workflows still depend on permission design, evaluation, fallback paths, and human review. A demo can look autonomous while the production version still needs tight boundaries, logging, and clear ownership when the system gets something wrong.