Three Roles, One Tool: How Tech Leads, Engineers, and PMs Use Fabriq

TL;DR. AI coding tools are usually designed for a single user. Fabriq is designed for a team — and different team roles interact with it differently. The tech lead governs via dimension rules and confirmation gates. The engineer focuses inside a bounded feature worktree with minimal context switching. The PM traces features from kickoff artifacts to shipped outcomes. This post maps each role's needs to Fabriq's capabilities.

Why roles matter in AI-assisted development#

Most AI coding tools are optimized for a single persona: the solo developer in a chat interface. They assume one person, one agent, one context.

Teams don't work that way.

In any software team, three distinct roles have different relationships to AI-generated code:

• Tech leads are accountable for what lands in the repo — quality, security, consistency, auditability.
• Engineers are responsible for producing working code — efficiency, flow, minimal friction.
• Product managers are accountable for outcomes — did the shipped feature produce the expected business result?

Fabriq's workspace shell serves all three. Not by giving them different tools, but by letting the same workspace surface different views appropriate to each role.

The tech lead: governance by architecture#

The problem#

"I can't review everything the AI does, but I'm accountable for everything it ships."

A tech lead can't sit next to every engineer and review every AI agent turn. But without guardrails, AI-generated code accumulates quality debt silently. Two problems dominate:

1. Dimension breaches. An agent working on a feature accidentally modifies workspace-level documentation or shared configuration. The result is hard-to-trace drift.
2. Unreviewed mutations. The agent deletes a file, upgrades a dependency, or changes a shared utility — and nobody notices until CI breaks.

How Fabriq helps#

By enforcing the workspace/feature boundary at the architecture level, not the process level.

// The tech lead doesn't write a policy document.
// They maintain a dimension rules file:
const DIMENSION_RULES = {
  "feature": {
    writeBlocklist: [/^cdr\./, /^repos\.(add|remove|sync)$/],
    // Feature-dimension agents can never write to workspace-level
    // cognitive artifacts or repository management operations
  },
  "workspace": {
    requireConfirmation: true,
    // All workspace-dimension writes require explicit user confirmation
  }
};

The tech lead's job shifts from "review every PR for governance compliance" to "define the dimension rules once and verify they're correct." The shell enforces them at runtime.

Auditability is built in. Every state change is in .dapei/audit/. The tech lead can query:

• "Which features modified shared utilities?"
• "How many agent turns needed human confirmation this sprint?"
• "What workspace knowledge was updated via CMR?"

The tech lead's typical view#

The Workspace Dashboard is the tech lead's primary surface — showing all features in flight, their current stage, pending confirmations, and recent audit entries. No need to context-switch into individual feature worktrees.

The engineer: focused flow#

The problem#

"I want to use AI to move faster, but I don't want to fight the tool to do my work."

Engineers face a tension: AI agents are most powerful when they have broad context, but broad context means the agent can affect unrelated parts of the system. Two complaints are common:

1. Context overhead. "The agent changed a utility file I didn't ask it to touch, and now I have to review changes I didn't expect."
2. Interruptions from confirmation prompts. "Every other agent action needs a click. I can't stay in flow."

How Fabriq helps#

By bounding the agent's context to the feature worktree.

When the engineer opens a feature in Fabriq, the agent operates inside features/admin-order-search/. It can read workspace assets (docs, repo code) but can only write to the feature directory. The boundary is enforced by the dimension rules — no trust-me flags, no .gitignore hacks.

Within that boundary, the agent has freedom. The confirmation gates are:

• Write operations to the feature worktree — auto-approved (the agent can write code freely inside the feature)
• Read operations on the workspace — auto-approved (the agent can read whatever it needs)
• Write operations outside the feature worktree — blocked (the agent simply can't do this)
• Dependency changes, configuration changes, destructive operations — explicit confirmation (still surface in the UI)

The result: the engineer gets flow within the feature boundary and protection beyond it. No context switching for routine operations. No surprises from unexpected agent behavior.

The engineer's typical view#

The Feature Workbench is the engineer's cockpit — showing the current stage, task progress, recent agent actions, and pending confirmation prompts. The workbench organizes everything related to one feature in one place.

The product manager: traceability from intent to outcome#

The problem#

"We shipped the feature. Did it work? Why did we build it this way?"

PMs consume the artifacts of development — PRs, demos, release notes — but they rarely have direct access to the decision-making process. When a feature underperforms, the postmortem depends on reconstructing what happened from git commits and Slack messages.

How Fabriq helps#

By making the feature's artifact trail the source of truth.

Every feature in Fabriq produces six artifact layers:

The PM doesn't need to read code or dig through git history. They read the feature's docs directory, which captures the entire decision chain from kickoff to closure.

Feature History is the PM's long-term view. Months after a feature ships, the PM can open docs/feature-history/ and answer:

• "What was the expected outcome of the Admin Order Search feature?"
• "Did the design change during implementation? Why?"
• "What knowledge did we capture from building this?"

The PM's typical view#

The Workspace Knowledge view and Feature History index are the PM's primary surfaces — showing the accumulated product knowledge, closed features, and their documented outcomes.

How the three roles interact#

Fabriq's design creates a healthy feedback loop between the three roles:

PM defines the "why" (expectation document)
        │
        ▼
Tech lead defines the "how safe" (dimension rules)
        │
        ▼
Engineer does the "what" (implementation inside worktree)
        │
        ▼
Feature closes → knowledge promoted back to workspace
        │
        ▼
PM reads the outcome → informs next feature's "why"

Each role's work feeds the next. The artifacts produced by one are consumed by another. The workspace becomes the shared context that connects them — replacing Slack threads, Notion docs, and tribal knowledge with a single, versioned, auditable source of truth.

Summary#

A tool that only serves one role will fail in a team context. Fabriq is built for all three — not by being three different products, but by surfacing the right view of the same workspace for each role's needs.

Fabriq is designed for teams. Download it and see how it fits your team's workflow, or read the workspace spec for the full directory contract.