What Happened When Google Jules Built a Go Backend

What Happened When Jules Built a Go Backend

Google Jules built the skeleton of a small Go backend in Dalton Anderson's live E107 experiment, returned repository changes for review, and supported a working local demonstration after Dalton increased a timeout. The experiment showed that asynchronous coding agents can perform bounded repository work. It did not prove that the code was secure, maintainable, correct for insurance use, or ready for production.

That boundary is the real story.

The source is a dated demonstration

The preserved E107 source is an SRT subtitle transcript. It captures the spoken sequence but can misrecognize names, commands, punctuation, and technical details. The private repository, recording, exact diff, pull request, test logs, and runtime configuration were not available for this editorial review.

The public page therefore describes Dalton's recorded experience without reproducing private code, repository names, prompts, credentials, or insurance decision logic.

Current product behavior comes from the Jules documentation, not the old interface described in the episode.

The task was a skeleton, not a finished system

Dalton asked Jules to work inside a Go project using a hexagonal architecture. His goal was to keep the entry point small and separate domain behavior from adapters and infrastructure.

The demo application accepted a short incident description and returned a category, urgency, injury flag, and fraud probability. Dalton tried several invented examples during the recording.

Those outputs were illustrative software behavior. They were not claims decisions, fraud determinations, coverage opinions, medical assessments, or evidence that the classification design was appropriate.

An AI-generated prototype can make a workflow tangible. It cannot establish the policy, data, calibration, legal authority, or expert review required for a consequential insurance system.

Jules changed the control loop

An IDE assistant usually works while the developer remains in the editor. The developer sees suggestions, adjusts the request, and changes direction quickly.

Jules accepted a repository task and worked elsewhere. Dalton could leave the session and experiment with Google Flow while the coding task continued.

flowchart LR
    A["Dalton defines repository task"] --> B["Jules prepares plan"]
    B --> C["Task runs in cloud VM"]
    C --> D["Code, build, and tests"]
    D --> E["Returned changes"]
    E --> F["Dalton reviews and runs locally"]
    F --> G["Timeout correction"]
    G --> H["Working demonstration"]
    H --> I["Unresolved quality and security review"]

The waiting time did not disappear. It became available for other work. The review also did not disappear. It moved to the plan, returned diff, local behavior, and integration decision.

The plan was the first review surface

Dalton gave Jules a structural direction and then approved a proposed plan. The current web workflow still includes plan review, according to the official guide.

Plan review matters because a large diff is expensive to unwind. The reviewer can catch a misunderstood boundary, unnecessary dependency, risky migration, missing test, or wrong layer before implementation spreads the decision across many files.

The plan is not a guarantee. Current Jules documentation says web plans can eventually auto-approve on a timer. The API also auto-approves unless requirePlanApproval is explicitly enabled in the session request.

Teams should treat plan approval as a deliberate policy, not assume it from the interface.

Jules worked inside a separate environment

Dalton described Jules cloning the repository into a virtual machine, updating the code, running tests, and returning the result.

That matches current environment documentation. Jules uses a short-lived Ubuntu VM with common languages and developer tools. Each task keeps its own environment, logs, and changes.

Isolation protects the developer's active workspace from direct edits. It does not make repository contents, dependency installers, setup scripts, network access, or environment variables harmless.

Google's Jules FAQ says the VM has internet access and should be treated with the same caution as public or shared compute. It warns users not to commit credentials and to review third-party packages and commands.

The first local run exposed a timeout

The generated application did not immediately produce the live result Dalton expected. He traced the failure to a ten-second timeout around an AI request and increased it to sixty seconds.

The local demonstration then returned results for his sample inputs.

That is a useful debugging outcome. It is not proof that sixty seconds is the correct production timeout. A production decision would consider the provider's latency distribution, retry behavior, cancellation, concurrency, user feedback, cost, rate limits, idempotency, and failure policy.

The failure also illustrates why a passing agent-run build is incomplete evidence. The important behavior appeared only when the application talked to an external model under local runtime conditions.

The output looked architecturally plausible

Dalton inspected the entry point and liked that it remained short. He used the size of main.go as a rough smell test for separation of concerns.

That can prompt useful questions. It cannot replace architecture review.

A small entry point can still wire incorrect dependencies, hide global state, ignore errors, expose secrets, or connect the wrong implementation. A large entry point can be justified in a small one-file tool.

The reviewer needs to trace actual responsibilities, dependency direction, error handling, data ownership, and test seams rather than score the architecture by line count.

The repository interface created friction

Dalton says he clicked a recommended repository accidentally and could not immediately find the removal path in the early interface.

Current documentation now says Jules can access only repositories authorized through the GitHub application and explains how to change access in GitHub settings.

The episode's observation remains valuable because repository authorization deserves friction in the right place. Adding a private codebase should be explicit. Removing access should be discoverable. The interface should distinguish enrolling a repository from merely selecting it for a task.

The secret question remained unresolved

The most important security moment was not a visible failure. The local application could use an API credential, and Dalton was uncertain how that credential had become available.

The public package does not infer an explanation. The repository and environment were not inspected, and no credential is reproduced.

Current Jules supports repository-level environment variables that can be enabled for a task. That current feature does not explain the historical demo.

An unexplained working secret should trigger an inventory. Identify the source, owner, scope, process access, logs, artifacts, rotation path, and whether the task needed it. Convenience is not the correct interpretation until the path is known.

Flow filled the asynchronous gap

While Jules worked, Dalton experimented with Google Flow and generated several short video clips. Flow is an AI filmmaking tool, not a competing coding surface.

The side experiment demonstrates the behavioral appeal of asynchronous agents. A user can start one bounded task and move to another.

It also hints at a new failure mode. Starting more work is easier than reviewing what returns. The limiting resource becomes attention, task design, and integration rather than model output.

What the demo established

The subtitles support a narrow conclusion. Dalton gave Jules a bounded repository task, reviewed a plan and changes, ran the result locally, corrected a timeout, and obtained a convincing prototype demonstration.

The demo did not independently establish the exact test coverage, code quality, dependency safety, secret isolation, model reliability, insurance validity, production readiness, or superiority over another tool.

That is not a weakness in the story. It is the reason the story is useful.

The coding agent made implementation cheaper. It made specification and verification more important.

Read [[What Is Google Jules|What Is Google Jules?]], [[How to Review an AI-Generated Pull Request]], and [[How to Run Parallel Coding Agents Without Losing Control]] next.

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