Project Jules used to tell your AI what to do. Jitro tells it what you want. That gap — between task execution and outcome ownership — is the entire bet Google is making with its next-generation coding agent.
The Problem With Every Coding Agent Right Now
Every major AI coding tool today, GitHub Copilot, Cursor, Windsurf, OpenAI's Codex — operates on the same underlying model: you define the work, the agent does it. You write the prompt, you review the output, you write the next prompt. The developer is still the scheduler, the project manager, and the QA team. The AI is a very fast, very capable executor.
That's genuinely useful. But it hits a ceiling. When your goal is "reduce memory leaks in the backend by 20%" or "get our accessibility score to 100%," you don't want to translate that into ten sequential prompts across a week. You want to hand it off. No current tool actually lets you do that.
How Project Jitro Actually Works
Google is internally developing Project Jitro as an autonomous AI system that moves beyond prompt-based coding to independently execute high-level development goals. It's built on Jules, Google's existing asynchronous coding agent — but the architecture is meaningfully different.
Rather than asking developers to manually instruct an agent on what to build or fix, Jules V2 appears designed around high-level goal-setting — KPI-driven development, where the agent autonomously identifies what needs to change in a codebase to move a metric in the right direction.
The workspace model is the critical piece. A dedicated workspace for the agent suggests Google envisions Jitro as a persistent collaborator rather than a one-shot tool. Early signals point to a workspace where developers can list goals, track insights, and configure tool integrations — a layer of continuity that current coding agents don't offer.
From leaked tooling definitions, the Jitro workspace API exposes operations like: list goals, create a goal after helping articulate it clearly, list insights, get update history for an insight, and list configured tool integrations including MCP remote servers and API connections. That last item is significant — Jitro integrates through Model Context Protocol (MCP) remote servers and various API connections to ensure it has the context it needs.
Transparency is baked in by design. When you set a goal in the Jitro workspace, the AI doesn't just operate silently — it surfaces its reasoning process, explaining why it chose a specific library or restructured a database table. You stay in control by approving the general direction, while the AI handles the execution.
What Engineering Teams Are Actually Going to Use This For
The use cases where this model genuinely wins are the ones that are currently painful in proportion to their importance: reducing error rates becomes the objective instead of debugging individual functions; improving test coverage becomes the target instead of writing test cases manually across multiple files; increasing conversions becomes the priority instead of adjusting isolated page elements without strategy alignment.
The primary beneficiaries would be engineering teams managing large codebases where incremental improvements compound — performance optimization, test coverage, accessibility compliance.
Jules V1 already demonstrated that the asynchronous model works. During the beta, thousands of developers tackled tens of thousands of tasks, resulting in over 140,000 code improvements shared publicly. Jules is now out of beta and available across free and paid tiers, integrated into Google AI Pro and Ultra subscriptions. Jitro inherits that async foundation and extends it to goals that span sessions, not just tasks.
Why This Is a Bigger Deal Than It Looks
The shift from prompt-driven to goal-driven AI isn't a UX improvement — it's a change in the unit of work. Right now, developer productivity is measured by how good your prompts are. Jitro changes that to how clearly you can define outcomes.
Routine tasks like debugging, writing boilerplate code, or running tests may increasingly be handled by AI systems. As a result, developers may shift toward higher-level responsibilities — guiding AI systems, reviewing outputs, and aligning technical work with business goals.
This marks a departure from the task-level paradigm seen across competitors like GitHub Copilot, Cursor, and even OpenAI's Codex agent, all of which still rely on developers defining specific work items. If Jitro ships as described, it resets what the category baseline looks like. Every competitor will be asked why their tool still needs a prompt for every action.
The MCP integration angle is also worth watching closely. A goal-oriented coding agent that natively connects to MCP remote servers can reach across your entire toolchain — CI/CD, monitoring, issue trackers — rather than reasoning only over local files. That's a different class of tool.
The honest caveat: the risk is that autonomous goal-pursuing agents introduce unpredictable changes, and trust will be the key barrier to adoption. None of the UI is visible yet, so the full scope remains unclear. There's a real question about what "approve the direction" actually looks like in practice when the agent is making dozens of decisions across a large codebase.
Availability and Access
Project Jitro is still pre-launch. The upcoming experience is expected to launch under a waitlist, with Google I/O 2026 on May 19 as the likely announcement moment alongside broader Gemini ecosystem updates. The Jules team has published a waitlist page with messaging that reads: "Manually prompting your agents is so… 2025."
Current Jules users on Google AI Pro and Ultra are the most likely early access recipients. No public timeline beyond "2026" has been confirmed.
The line between "AI that helps you code" and "AI that owns a development objective" is the line Jitro is trying to cross. Whether it lands or not at I/O, the framing alone forces every other coding tool to answer the same question: how long until your users stop writing prompts?
Follow for more coverage on MCP, agentic AI, and AI infrastructure.
Top comments (1)
Woahhh, loved it!