Juggler Puts Coding Agents in a GUI

Juggler is an open-source GUI coding agent from the longtime C++ developer behind JUCE, Tracktion, and Cmajor. It deals with the awkward part of agentic coding that terminal-first tools often hide: tool calls, branching sessions, raw context, and approvals. The answer to “what is the best ai tool for code review” is boring but useful: choose the workflow that leaves the clearest evidence trail, not the prettiest model demo. Juggler is interesting because it treats the agent session as something you inspect, edit, and branch instead of something you scroll past.

As of July 2026, the repository had 262 GitHub stars, was mainly JavaScript, and used the AGPL-3.0 license. That is early-project territory, not “standard toolchain” territory. But the idea landed on Hacker News because many developers like coding agents and still dislike the experience of watching them work through a narrow chat transcript.

Use the GUI to see the agent’s moves

Juggler’s pitch is simple: make the coding agent visible. It is a proper graphical workbench, not a CLI with nicer colors. Tool calls, approvals, item properties, nested sub-threads, and raw context are laid out in a Finder-style Miller column view.

That matters because code review ai often fails in a very ordinary way. The model may produce a plausible diff, but the reviewer cannot quickly answer: what files did it read, what did it assume, which tool call changed the behavior, and where did the session fork?

Juggler’s answer is to make those objects first-class. The session is stored as a Yjs document, not as a flat transcript. You can create sub-threads, drill down, backtrack, compare, and edit context.

The trap is assuming visibility equals safety. It does not. A visible bad edit is still a bad edit. But visibility gives a reviewer something concrete to challenge before the patch becomes “the agent said so.”

Treat the session tree as the review surface

A coding-agent session tree is a structured record of prompts, context, tool calls, branches, and outputs that can be inspected without replaying a chat log. That is the core design move in Juggler.

Imagine a real repo task: “replace the legacy billing webhook parser with a typed event dispatcher.” In a doom-scroll transcript, the agent’s path gets buried. In a tree, you can keep one branch where the agent edits only tests, another where it drafts the dispatcher, and a third where it tries the migration script.

That is a nicer review surface than a single final diff. You can ask why the agent chose src/billing/webhooks.ts, whether it read the old retry job, and where it introduced a new dependency.

Claude Code, Anthropic’s coding agent, can already fit into this style if you keep the terminal workflow strict. For example, a reviewer can require a short handoff note before merge:

Agent handoff receipt

Task: Replace legacy billing webhook parser.
Files read: src/billing/*, test/billing/*, docs/webhooks.md
Files changed: src/billing/dispatcher.ts, test/billing/dispatcher.test.ts
Commands run: npm test -- billing, npm run typecheck
Open questions: Stripe retry semantics still need product confirmation.
Reviewer focus: event ordering, idempotency, migration safety.

Juggler’s bet is that this receipt should not be an afterthought. It should be visible while the agent is still working.

Notice the objection: another agent can mean another island

The Hacker News reaction was warm, but not uncritical. Developers liked the clean UI and the visible context model. They also raised the obvious problem: many already use Claude, Anysphere’s AI code editor, Zed, Claude Code, Codex, OpenCode, or their own terminal agents.

The strongest objection was ecosystem friction. If you have already written plugins or built habits around another agent loop, a new GUI may be attractive and still too expensive to switch into. One commenter wanted ACP-style support because rewriting existing plugins would be a blocker.

That objection is fair. Juggler says its context items, slash commands, loop strategies, and UIs are JavaScript extensions you can inspect, fork, or replace. That is promising, but extensibility only helps if it meets developers where their current tools already are.

There was also a smaller but revealing debate around “No Electron.” Juggler’s GUI direction is part of the point, but implementation choices can become a distraction if the app feels heavier or stranger than the CLI it wants to replace.

The lesson is not “GUI beats terminal.” It is closer to: the interface should match the risk of the task. For fast local edits, a terminal agent may be enough. For a tangled refactor, a tree you can inspect may be worth the extra surface area.

Try Juggler when code review needs visibility

Juggler is worth trying when your review pain is not “the model is too weak,” but “I cannot tell what the agent actually did.” That is the practical version of “what is the best ai tool for code review”: the best tool is the one that makes review cheaper, sharper, and less dependent on trust.

Use it on a task with branches. A dependency upgrade, parser rewrite, or test-generation pass is a better experiment than “fix one typo.” You want a task where context, tool calls, and alternate paths actually matter.

It is overkill if you only want autocomplete, one-shot explanations, or quick command-line edits. It may also be too early if you need a stable enterprise support channel, a mature plugin ecosystem, or deep compatibility with an existing agent protocol.

For Claude Code users, the interesting comparison is not just Juggler versus the terminal. It is whether the GUI makes your existing review conventions easier to enforce. If your repo already has concise CLAUDE.md guidance, slash commands for common tasks, and hook boundaries for risky operations, Juggler gives you a different way to inspect the same class of work.

A simple Claude Code hook boundary can still be useful beside a GUI agent:

Hook boundary for agent edits

Allow without approval:
- Read files under src/, test/, docs/
- Run npm test, npm run typecheck, npm run lint

Require approval:
- Edit package.json or lockfiles
- Run database migrations
- Change CI, deploy, auth, billing, or permissions code
- Execute networked commands outside approved package registries

That kind of boundary belongs in the broader practice of agentic coding governance, but the point here is smaller. Juggler makes the agent’s path easier to see; hooks and review notes make the allowed path easier to enforce.

For a neighboring read on the same project, see Juggler Makes Coding Agents Visible.

Copyable fit table for a safe Juggler experiment

Use this table before giving Juggler a real refactor. Keep the experiment small enough to throw away.

A good first test is a branch named juggler-visible-refactor. Ask the agent to make a small change, preserve one alternate branch, and leave a handoff receipt. Then review the session tree before reviewing the diff.

Try one visible branch next

Pick one medium-risk refactor and run it through Juggler on a throwaway branch. If the session tree makes review faster or catches a bad assumption earlier, the GUI earned another test.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Practical starter checklist

- [ ] Name the Claude Code artifact first: a hook boundary, an MCP permission note, a slash-command workflow, a Claude skill outline, a review checklist, or a concise CLAUDE.md note when repository memory is the topic.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• What should teams know about ai code review?

  Start by writing down one visible team rule for Claude Code, not a loose preference. That is the practical core of ai code review. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Claude Code artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a hook checklist, MCP permission rule, slash-command workflow, skill outline, or concise CLAUDE.md note. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Claude Code teams deciding which hook, skill, MCP boundary, slash-command workflow, review habit, or repository-memory convention to standardize next around “Juggler Puts Coding Agents in a GUI.”
• Best first artifact: turn the named fix into a hook checklist, skill note, MCP permission note, review receipt, or concise CLAUDE.md convention when repository memory is the real topic before the next automated run.
• Best comparison angle: compare the workflow against the current Claude Code handoff, hook behavior, and MCP scope; keep the path that leaves the shortest auditable trail.

Further reading

• juggler — source
• Claude — Agent
• OpenAI Developers — Codex quickstart
• developers.google.com: fundamentals creating helpful content

Where to go next

Start from the related training topic and make the first exercise prove scope, verification, and ownership in the PR body.