Building Jules for Work That Outlasts the Prompt

A new tool for the craft

Jed Borovik was working on Google Search when people began telling him they would discourage college students from studying computer science. He had watched artists respond to Stable Diffusion with both alarm about appropriation and excitement about making better art. He chose to approach programming through that second possibility, experimenting with coding agents before joining Google Labs and Jules, an agent designed to do coding work in its own computing environment.

His attachment to programming began in New York’s hackathon scene, including HackNY events that alternated between NYU and Columbia. He later worked on news and freshness in Search. By this Latent Space conversation, recorded at GitHub Universe, Jules was partnering with GitHub on Agent HQ. The underlying product question was how to build for agents capable of increasingly complex, sustained work.

Borovik describes Google Labs as a product organization for work the rest of Google is not well positioned to build. Close collaboration with DeepMind lets teams work across the interface, infrastructure, model, and training loop. Google already had developer tools in Cider, its internal integrated development environment (IDE); Labs offered a way to connect model development with a new product experience.

An agent with its own computer

An agent working for hours—or potentially days—needs somewhere to operate independently of the developer’s local workspace. Jules has its own virtual machine (VM), a separate computing environment for that work. The architecture anticipates longer, more capable execution; those durations are a design target, not a reliability guarantee.

Independent infrastructure also supports ambient operation: software can trigger the agent when an event occurs. Borovik describes a user invoking Jules through its application programming interface (API) to update a website, then automatically merging its pull requests with a GitHub Action. The example shows how the pieces connect, though its tests, review gates, and success rate are unspecified.

Developers also need access from their existing workflows. The Jules command-line interface (CLI) had launched a couple of weeks before recording, allowing local interaction with the agent. Integration with Gemini CLI was expected by publication time, but was still a forthcoming release in the conversation.

Better models change the harness

Early Gemini models required complex agent scaffolding—the orchestration around the model that coordinates its work. As models improved, the Jules team simplified that scaffolding. Some of the earlier structure had compensated for tasks the model struggled to handle itself.

The team experimented with separate subagents for code edits, subproblems, integration actions, and review, without going as far as simulated organizations with product-manager personas. Simpler orchestration was easier to maintain and improve through machine learning. The harness remained sophisticated; better models changed which complexity was useful.

Code retrieval illustrates the tradeoff. One approach divides code into chunks and uses embeddings to search those chunks by meaning. Maintaining those embeddings and choosing useful boundaries proved difficult. The interviewer argues that a chunk can contain everything needed for one query while excluding context needed for another, and suggests grep as an alternative. Its proposed scaling advantage remains a conjecture.

The shared recommendation is to make semantic search one tool available to the agent, alongside grep and other file tools. Retrieval need not depend exclusively on fixed chunks. For the Jules team, this remained active research rather than a settled replacement algorithm.

The product was maturing alongside the harness. The reception to Jules’ May announcement at Google I/O marked a turning point in its development into a full product. Building something lasting had been the goal from the outset; the launch response gave that ambition momentum.

Where practitioners compare notes

AI Engineer Code provides a setting for comparing these changing techniques. Speaking as the event’s content organizer, the interviewer argues that AI engineers need gathering places like those in JavaScript, cloud native, and data engineering. An industry-neutral conference lets competing companies share work, recruit, and earn attention beyond their own events.

The organizer places the greatest value on the hallway track—informal conversations with speakers and peers. Talks are filmed for free release on YouTube; attending creates opportunities to discuss the work directly. The practical advice is to: - Publish your work or interests beforehand so people have something specific to discuss. - Explain what you do, what you can help with, and where you need help. - Arrive with a purpose while leaving time and energy for unexpected connections.

Focused summits on coding, datasets, and reinforcement learning are intended to bring together peers who could themselves be speakers, including founders and enterprise buyers. New York adds a particular connection to finance. Smaller meetings can narrow the discussion further—to code review agents, voice, or AI in biology. The previous New York summit reportedly attracted roughly 13–15 independently organized side events, and organizers leave evenings open for these gatherings.

The interviewer extends this preference for specificity to startups: choose a customer and domain, then consider building the complete agent product instead of defaulting to a framework. They perceive faster recurring-revenue growth and better margins among agent companies, but offer that as a business judgment without comparative financial data.

The session that lasted 30 days

A retention limit exposed an unexpected use pattern. Jules stored some session data for 30 days, after which the session locked. Users complained when they reached that limit: the team had assumed nobody would maintain a single track of work in one session for so long. The surprise was a month of continuity, not a month of unattended execution.

Coding puts pressure on context—the files, command outputs, and conversation history available to the model. Commands can produce large outputs, while prolonged sessions accumulate many turns. Jules’ specific compression implementation remains undisclosed; the team describes using standard techniques while researching additional approaches.

Three context-management patterns come up: - Subagents perform bounded work in separate contexts and return without importing their entire working histories. - Summarization condenses accumulated context. - External notes preserve information outside the immediate conversation. Subagents make reliable information transfer especially important: the main agent still needs the relevant findings. No method emerges as the winner, and the preferred approach can change as models improve.

The Jules team describes two-way collaboration with DeepMind on model capabilities. Its research agenda reaches beyond code generation to browser interaction, computer use, and multimodal input such as images. These are parts of a broader ambition for intelligent agents, rather than a list of shipped Jules features.

Continuity through tickets and pull requests

The Jules perspective on collaboration extends to competing agent companies: improving software engineering can benefit them collectively. A shared product vision needs to explain how developers interact with models, divide work between local and cloud environments, and move between them. Making that future concrete could also make the tools less intimidating, especially for engineers managing difficult codebases.

For handoffs, the interviewer proposes the ticket or pull request as the shared artifact. A cloud agent could summarize completed work and remaining context in a Linear ticket, GitHub pull request, or Slack message. Another agent could continue from that record without receiving the full conversation history, much as a colleague picks up work from a handoff.

This proposed workflow addresses an emerging interface pattern: coding tools appear to be converging on IDE, CLI, and cloud surfaces. Useful continuity between those environments matters even when the interaction moves to a different tool.

What remains for the engineer

Adoption still looked uneven from inside the Jules team. Conversations with companies revealed less AI use among software engineers than expected. The optimistic case for continued hiring rests on elastic demand: cheaper software production could make more projects worth funding and encourage further investment in engineers.

The speakers connect this argument to Jevons paradox, where greater efficiency can encourage enough additional consumption to expand total demand. They propose that software resembles electricity, whose consumption can grow as it becomes cheaper, more than food, whose consumption has practical limits. This is an explicitly optimistic economic hypothesis, not a measured employment outcome.

The interviewer proposes delegating commoditized tasks to asynchronous agents while reserving human attention for strategic, novel, or high-risk work requiring deep understanding of the codebase. Their criticism of careless vibe coding is that enjoyment can become permission to produce poor code and leave cleanup to others. Agentic coding is offered as a candidate name for a more trustworthy practice, though the desired approach would retain the joy while adding care, craft, and reliability.

Specify, iterate, verify

A thoughtful product requirements document (PRD) can serve as a strong prompt by explaining the desired result. But requiring exhaustive specifications before the agent starts risks recreating waterfall development: planning everything in advance, then handing it over for implementation.

The interviewer favors interactive planning, an approach they say Cognition has supported from the start: 1. Start a task with the intent you can currently express. 2. Inspect the agent’s response for misunderstandings or missing requirements. 3. Correct the intent and iterate. Feedback helps users discover what they want as the work develops.

As agents improve, two responsibilities remain: specifying the result and verifying that the output matches it. Briefly clicking around an application without engaging with the code or meaningfully checking behavior can leave verification incomplete.

Jules runs an existing repository test suite without requiring a new test for every requested change. The argument for this choice is engineer control over the output: tests can help demonstrate correctness, but introducing them into a repository that does not use them should be a deliberate decision. Verification remains necessary even when a particular testing policy is optional.

Show the bug, demonstrate the fix

Multimodal input offers ways to express intent beyond text. For a visual website bug, pointing to a picture can be easier than describing everything in words. Jules supported image uploads at the time of recording. Video was a requested extension: elements appearing and disappearing can be difficult to capture in screenshots. The response expressed interest without committing to video support.

Computer use adds a corresponding execution requirement: the agent’s environment must render a user interface or browser and let the agent interact with it. Precision, speed, and affordable cost must work together. One appealing future workflow would open an interactive demo of completed work, let the developer watch the agent operate it, and allow the developer to take over. That remained a proposed direction rather than an established Jules capability.

The closing invitation welcomes unusual coding-agent workflows and accounts from engineers who tried the tools and rejected them. The Jules representative also invites conversations about building these systems, noting that the team was hiring at the time of recording. Both inventive uses and reasons for abandoning the tools are feedback worth hearing.