Skip to main content

Factory over Assistant - Why Dev Tooling UX Is Shifting

· 3 min read
Calvin Cheng
Calvin Cheng
Shape what gets built and the value it creates.

The "assistant" model -sitting in a sidebar, watching an agent work, ping-ponging back and forth -optimizes for the wrong thing. As models become capable of autonomous work for 45 minutes or more, the human becomes the bottleneck. The future of agent tooling isn't a better sidebar. It's a factory: spawn multiple agents, let them run, check in periodically.

The Assistant Model's Limits​

In the assistant model, you work one-on-one with an agent. You watch it type, you correct it, you refine the prompt. The feedback loop is you. That works when the agent needs constant steering. It fails when the agent can run for long stretches on its own.

The limitations are structural:

  1. One agent at a time. You can only effectively run one agent when you're watching it. Your attention is the rate limiter.
  2. Human as crutch. You become the feedback loop when you should be setting up automated loops -tests, builds, linters.
  3. Wrong optimization. Sidebar UX optimizes for watching. It doesn't optimize for spawning, monitoring, and orchestrating.
  4. Model mismatch. Slower, less capable models need more hand-holding. Better models work better autonomously. Optimizing for the former holds back the latter.

The Factory Mindset​

In the factory model:

  • You spawn multiple agents to work on different tasks in parallel.
  • You check in periodically -30, 60 minutes later -rather than watching every step.
  • You focus on setting up automated feedback loops so agents can self-correct.
  • You spend your time on orchestration and review, not real-time micromanagement.

The shift isn't just technical. It's a reallocation of human effort: less time watching, more time configuring, delegating, and integrating.

What Changes in the UX​

Dashboards over sidebars. When you're running multiple agents, you need a control plane -status, logs, summaries. The sidebar is a single-agent view. The factory needs a fleet view.

Notifications over streaming. For background agents, you don't need to watch the stream. You need to know when something completes, fails, or needs approval. Push notifications, Slack hooks, email digests.

Review workflows over edit workflows. The primary interaction shifts from "edit this while I watch" to "show me what you did so I can review." That implies diff UIs, intent summaries, and batch approval flows.

Async by default. The factory assumes you're not waiting. You spawn, you leave, you come back. The product has to support that cadence -saved state, resumable sessions, clear handoff points.

The "Last 20%" Principle​

AMP (Sourcegraph) has argued that for frontier developers, only 20% of work needs to happen in the editor. The rest can be delegated to agents. The goal is to push that to 10%, or 1%. The editor becomes the place for final integration and refinement, not the place where all work happens.

That suggests a different topology for dev tools: not an IDE with an agent sidebar, but an orchestration layer with the IDE as one of many surfaces. The assistant was the first draft. The factory is the next.

When the Factory Doesn't Fit​

Exploratory work, tasks requiring deep domain knowledge, and quick iterations where interactive feedback is faster -these still favor the assistant model. The spectrum of control applies: sometimes you need to watch; sometimes you need to spawn and step away. The best tools will support both, but the center of gravity is shifting toward the factory.