Waku Is a Native Coding-Agent App

Waku is an independent Show HN project described as “I built a native app for coding agents with Rust and GPUI.” It is a desktop app for working with coding agents, built around the idea that supervising agent work deserves a real native interface, not only a terminal buffer or browser tab. The takeaway is simple: the interesting part is not that Waku is native; it is that native UI may make agent activity easier to inspect while it is happening.

A native coding-agent app is a desktop interface that runs or supervises coding agents without making chat the only control surface. For Claude Code, Anthropic’s coding agent, and for agentic coding more broadly, that matters when one developer is watching several edits, tool calls, and approvals at once.

See why native mattered on Hacker News

The Hacker News reaction landed on a good question: what value does a native app add when developers already have terminals, editors, and web chats?

That is the right objection. A thin wrapper around an agent is not very interesting. A fast workspace that can show multiple agents, their diffs, their tool calls, and their approval points in one place is much more interesting.

Waku’s technical bet is also part of the story. It uses Rust and GPUI, Zed Industries’ Rust UI framework behind the Zed editor. That choice signals a priority: low-latency panes, native windowing, and a UI that should stay responsive while work is happening.

The trap is assuming “native” automatically means “better.” Native helps only if it removes a real supervision cost. If the app still makes you reconstruct what happened from chat messages, it has not solved the hard part.

A small example makes this concrete. Imagine an agent fixing apps/web/src/checkout/DiscountCode.tsx after a failing Playwright test. The useful UI is not a prettier prompt box. It is a live trail: the failing test, the files opened, the diff made, the command rerun, and the exact moment the agent asked to write or execute something risky.

Watch the agent, not the chat

The most compelling view for a coding-agent app is a timeline.

Chat is a poor audit log. It mixes intent, status, reasoning summaries, file changes, and permission requests into one stream. That works for a single short task. It gets noisy when an agent reads ten files, edits three, runs tests twice, and then asks to touch a migration.

A timeline should separate the important events:

• files read
• commands run
• diffs proposed
• approvals requested
• tests passed or failed
• human interruptions

That is the product-shaped opening Waku points at. The agent’s work becomes observable as a sequence of operations, not a transcript you have to replay in your head.

The trap is collecting every event without making any of it legible. A wall of tool calls is just terminal spam with better spacing. The useful version groups events around the thing the developer cares about: “why did this diff happen, and what evidence supports it?”

For a Claude Code workflow, this is where a slash command can stay simple. A developer might use /fix-checkout-test to ask for one bounded repair, then watch the agent’s activity in the surrounding app. The command is the intent. The native timeline is the receipt.

Use Waku when terminal friction is the bottleneck

Waku is worth trying when your pain is supervision, not model quality.

If you are already comfortable running one coding agent in a terminal, and you mostly do short edits, a native app may be overkill. The terminal is still excellent for direct, local, interruptible work. Adding another surface can slow you down if it does not replace something annoying.

The fit gets better when you run longer tasks or compare several agent attempts. For example, one agent can try the minimal bug fix, another can write the regression test first, and a third can inspect the type boundary. In that world, the hard part is not prompting. It is keeping the attempts separate and choosing the clean diff.

This is also where developer productivity claims need discipline. “The app feels fast” is nice. “I can reject a bad migration in 20 seconds because I saw the exact command and diff that caused it” is useful.

The adjacent question is covered well by Does AI Coding Feel Like Leadership?: the more autonomous agents get, the more the developer’s job looks like setting constraints, reading evidence, and deciding when to intervene.

Keep Claude Code boundaries boring

If you try Waku next to Claude Code, keep the safety boundary dull on purpose.

A native interface should make approval easier to understand, not easier to skip. Let the agent read freely in a throwaway branch. Make writes visible. Keep shell commands constrained. Never let a new UI be the reason a destructive command becomes casual.

Here is a lightweight Claude Code hook boundary you can copy into a repo note before experimenting. It is not a full security policy. It is a reminder of what should require human attention.

# .claude/agent-ui-boundary.md

Safe to inspect without stopping:
- Read source files
- Search with grep/ripgrep
- List project files
- Open existing tests and docs

Pause for a human before:
- Running migrations
- Editing lockfiles
- Changing CI, deploy, or auth code
- Writing outside the repo root
- Running commands with network access
- Deleting files or rewriting history

Evidence expected before accepting a diff:
- The failing command or test name
- The files changed
- The final diff
- The command used to verify the fix

This is the small practical connection to the related training topic: code review guardrails are more useful when the tool shows the evidence at the moment you need it.

The trap is turning the first experiment into a policy debate. Do one bounded task. Watch what the app makes easier. Write down the one friction it removed and the one new risk it introduced.

Try Waku safely in one hour

Use a small repo and a real bug. The goal is not to benchmark all coding agents. The goal is to learn whether a native agent app improves your ability to supervise work.

A good first task is boring: “Fix the failing checkout applies discount code test without changing the API contract.” Boring tasks reveal UI value quickly because you already know what a clean path should look like.

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

• How should teams start with Claude Code?

  Start by writing down one visible team rule for Claude Code, not a loose preference. 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 “Waku Is a Native Coding-Agent App.”
• 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

• I built a native app for coding agents with Rust and GPUI — source
• Claude — Agent
• OWASP — Top 10 for Large Language Model Applications
• 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.