Why AI Coding Agents Need a Control Panel, Not Another Chat Box

TL;DR. Every modern IDE gives you a chat box with an AI agent. Almost none give you a shell that respects the boundary between you and the agent. Fabriq exists to make three questions answerable by default: where is the agent allowed to write, what is it about to change, and why did this end up in the repo? This post explains the problem we set out to solve and why a "control panel" mindset beats a "chat box" mindset.

---

The two eras of AI coding#

We've been through two eras of AI-assisted development. Each one solved a real problem — and each one introduced a new kind of friction.

Era 1: The autocomplete. GitHub Copilot, Tabnine, Codeium — you write a comment or a function signature, and the AI suggests the next few lines. Low risk, low reward. You're still writing most of the code, but you get occasional bursts of productivity. The blast radius of a bad suggestion is a few lines you can delete.

Era 2: The agent. Cursor's agent mode, Claude Code, OpenCode's ACP — you describe a feature in natural language, and the AI edits multiple files, runs terminal commands, installs packages, and produces a working change. High reward, high risk. The blast radius of a bad agent turn can be half your codebase.

Era 2 is where the industry is now. And it's where the problems start.

The three unanswerable questions#

When you work with an AI coding agent in a standard IDE, three questions are surprisingly hard to answer:

1. Where is the agent allowed to write?#

Your repository has long-lived assets (documentation, architecture specs, shared configuration) and short-lived working branches where the actual feature work happens. These are fundamentally different kinds of state with different update cadences and different review requirements.

But in every IDE today, they live on the same filesystem with the same permissions. The agent can accidentally — or "accidentally" — overwrite a workspace-level spec while implementing a feature. Most teams discover this when their CI breaks or their documentation silently diverges from reality.

2. What is the agent about to change?#

When you ask an agent to "refactor the checkout flow," it may edit 12 files across 3 directories. In a chat-based interface, you see the result after the fact — a diff review, if you're lucky. You never see the proposal before it happens.

Destructive operations — file deletion, credential changes, dependency swaps — happen silently and instantly. There's no moment where the system says "I'm about to delete this file and replace it with something new. Approve?"

3. Why did this end up in the repo?#

Git blame tells you who changed a line and when. It doesn't tell you why. The commit message says "implement checkout validation" but doesn't say which business rule motivated the change, which threat model the validation addresses, or which source document the implementation derived from.

When code rots — and all code rots — you're left with the source file and no context. The knowledge that produced the change is gone.

What "chat box" gets wrong#

The chat metaphor dominates AI coding tools because it's familiar. You talk to a language model; it talks back. Natural.

But a chat box is a terrible interface for control. A chat box is:

• Ephemeral. Yesterday's conversation is gone. The decisions made in that conversation are invisible.
• Unstructured. There's no distinction between "I'm exploring an idea" and "I'm about to change production code."
• Non-deterministic. The same prompt can produce different results at different times. You can't audit what happened.
• Blind to boundaries. A chat box doesn't know which files are safe to edit and which aren't.

What "control panel" means#

A control panel, unlike a chat box, has:

Dimension-aware routing. The system knows which "surface" the agent is operating on. Workspace assets (docs, specs, contracts) live on one side. Feature worktrees (branches, experiments, feature code) live on another. The agent can't cross boundaries without explicit human approval.

Confirmation before mutation. Every state-changing operation — file write, package install, credential change — surfaces as an explicit proposal before it executes. You see the target, the payload, and the expected effect. Nothing touches disk until you say so.

Audit trail by default. Every decision leaves evidence. The artifact that enters the repo carries sources[] — links back to the specific files, lines, and business rules that produced it. Six months later, you can answer "why is this code here?" without spelunking through Slack history.

Reversible operations. Nothing in software is truly irreversible — but some reversals are harder than others. A control panel makes reversal a first-class operation, not a postmortem.

How Fabriq answers the three questions#

Fabriq is a desktop workspace shell that embodies this control-panel philosophy. The architecture is deliberately minimal:

┌─────────────────────────────────────────────────────┐
│                   Fabriq Desktop                     │
│                                                      │
│  Workspace Browser  ◄── Two dimensions ──►  Feature  │
│  (docs / specs /    │   with boundary       Workbench│
│   assets)           │   enforcement         (worktree)│
└─────────────────────┬────────────────────────────────┘
                      │ Typed IPC + confirmation gates
                      │
┌─────────────────────▼────────────────────────────────┐
│  Agent — OpenCode / Claude Code                       │
│  (proposes; never performs without confirmation)      │
└───────────────────────────────────────────────────────┘

When you ask an agent to implement a feature in Fabriq:

1. Dimension boundary. The agent operates inside an isolated feature worktree. It can read workspace assets but can only write to the feature. The shell enforces this — no configuration, no trust-me flags.

2. Confirmation gates. Every capability call that mutates state surfaces in the workbench UI. You review the payload and approve or reject. The agent never silently mutates disk.

3. Evidence trail. When the feature closes, the engine proposes structured knowledge updates — behaviors, state machines, business rules — each with sources[] linking back to the code that inspired them. You approve each proposal individually. The workspace is updated only after human confirmation.

The bet#

We believe the next bottleneck in AI-assisted development isn't model capability — it's trust infrastructure. Models will continue to improve, producing more sophisticated changes faster. The limiting factor will be the human's ability to understand, review, and confidently approve those changes.

Fabriq is our bet that the solution is architectural, not behavioral. Not "train humans to review faster" but "build a shell that makes every change legible before it happens."

A chat box is for conversation. A workshop is for building things that last.

---

Fabriq is open source (MIT) and available on macOS, Windows, and Linux. Download the latest release or browse the code on GitHub.