Fabric did more than add an AI coding assistant. It built a new TypeScript monorepo as the foundation for the workflow, stored business and architecture context with the code, and connected planning, tracking, implementation, review, and security into one controlled system.
An engineer who joined Fabric through Remotely proved the approach on one slow-moving cataloging project. Early adopters refined it, and Fabric then standardized the workflow across engineering.
At steady state, completed work per engineer per week rose from 2.3 items to 7.7. Median time from request to completion fell from 4.9 days to 1.4 days.
About Fabric
Fabric builds merchandising and analytics for AI shopping, so brands and retailers show up accurately wherever shoppers decide what to buy. This story focuses on how Fabric changed the way its own engineering team plans, builds, reviews, and ships software.
Faster coding was not enough
Fabric's existing setup made coordination difficult. The codebase mixed Python and TypeScript, so changes could require separate front-end and back-end work. A mismatch as small as one system expecting a number while another sent text could create rework or a bug.
Tracking was manual too. Engineers had to create tasks, update their status, and close them when the code was complete. In practice, the backlog grew, older work became stale, and project information could drift away from the code it described.
There was also a deeper limitation. AI can write code quickly, but speed becomes a liability when the system lacks the company's business rules, architecture decisions, and security requirements. Without that context, an agent can produce code that looks plausible while conflicting with an earlier decision or solving the wrong problem.
An engineer working inside Fabric saw an opportunity to improve speed and traceability together while preserving human judgment over product, architecture, security, and release decisions.
Fabric rebuilt the foundation and workflow together
Fabric adapted AWS's AI-Driven Development Life Cycle, or AI-DLC, around Claude Code. AI helps create and execute a detailed plan; people provide business context, answer questions, and approve consequential decisions.
The team paired that process with a new TypeScript monorepo. The front end, back end, database definitions, APIs, and access rules could work from shared structures. When one structure changed, automated checks could catch parts of the product that no longer matched before the code was committed.
That foundation made Claude Code more useful because the system became easier to understand as a whole. It also reduced the handoffs that previously occurred between different languages and separate parts of the product.
Why Remotely: enough context to redesign the system
The engineer was already part of Fabric's team through Remotely when the initiative began. Working inside the company provided enough product and engineering context to recognize that the constraint was larger than any one task.
Remotely connected Fabric with the engineer. The engineer designed the first workflow, selected the technical foundation, documented Fabric's business rules, proved the approach on real work, and helped the team scale it.
From one real project to an engineering-wide workflow
The approach began independently, not as a company-wide mandate. When a cataloging project was taking substantial time, the engineer applied the new technical foundation and workflow, completed a working version over a weekend, and demonstrated it the following Monday.
The CEO, product manager, responsible engineer, and other team members reviewed the result. A small group began using and refining the workflow.
Within roughly two weeks, broader engineering support had formed and the team began using the new foundation more widely. Fabric had followed a clear sequence: prove the approach on real work, learn with early adopters, then standardize it.
The codebase became a shared memory
Fabric treated documentation as part of the product. Business rules, future direction, and important architecture decisions lived with the code and changed with it.
Claude Code could compare a proposed feature with those records and flag a conflict before implementation. Engineers gained the same shared reference, instead of depending on context held only by the most senior people.
Claude turns an approved idea into visible, tracked work
Fabric connected Claude Code with Linear, its project-management system, and Slack through the Model Context Protocol (MCP), a standard way for Claude to work with other tools.
When an engineer starts a feature, the workflow follows a repeatable path:
- Define the intent. The engineer explains the feature and its business purpose.
- Build and approve the plan. Claude reads the relevant rules and architecture decisions, asks questions, and proposes the flow. The engineer approves the important choices.
- Create and implement tracked work. Claude creates the Linear project and tasks, then works through them one at a time.
- Run required checks. Code-quality, security, type, and dependency checks run before merge.
- Route human review. The system identifies an eligible reviewer familiar with the changed areas. Another person must approve the change.
- Keep the record current. Claude updates and closes the Linear tasks as work progresses.
Speed did not remove the human gate
Claude Code performs routine work without becoming the final decision maker. Engineers approve the plan, and a qualified reviewer must approve every merge.
For product features that use AI, Fabric also records model requests, tool calls, responses, and failures. Engineers can investigate what happened instead of dismissing unexpected behavior as an unpredictable AI-generated result.
Together, these controls preserved human review and traceability as delivery accelerated.
Fabric measured the change in completed work, not lines of code
Fabric compared two periods in Linear: the previous team's strongest comparison period, January through April 2026, and the new AI-DLC workflow's steady state, July through September 2026.
The analysis counted completed work items and distinct engineers assigned during each period. Unlike lines of code, this reflects units of work the team finished and tracked.
The internal analysis found:
- 3.4× as many delivered items per engineer per week. The rate rose from 2.3 to 7.7.
- 71% shorter median lead time. The typical time from request to completion fell from 4.9 days to 1.4 days.
- 69% less canceled work. Canceled items fell from 10.6% of work to 3.3%.
- 259 stale items reduced to one. Open items with no activity for more than 30 days fell from 259 to one.
The team-level comparison tells the same story from another angle. The old team sustained 66 delivered items per week with 13 to 24 engineers active in a given month. The new team sustained 60 per week with two to four active engineers in a given month. That is about 91% of the weekly output with about 21% of the people.
Fabric changed several things at once: Claude Code, a new technical foundation, shared documentation, automated tracking, review gates, and a smaller team. The results describe that combined change.
Faster delivery shifted attention from reaction to direction
Before the change, the team often felt it was catching up with bugs, broken demonstrations, and unclear behavior. After the rollout, the engineer reported a calmer development environment with more room to focus on product and business value.
Speed created a new challenge: priorities and roadmaps now had to keep pace. Fabric is exploring more objective updates from Linear so team meetings can focus on decisions and blockers.
The team is also extending controlled parallel work. Isolated working copies let one engineer run separate Claude Code sessions without mixing their changes—for example, continuing a large feature while another session investigates an urgent problem in the pre-release environment.
A Fabric teammate created this worktree capability. The engineer interviewed for this story described how it changed the experience of working with Claude:
"You can ask Claude to start a job or a feature or something in a new work tree. So this work tree will be isolated in your computer and anything that Claude changes is going to be there. So if you want to work in 5 different things unrelated, you can just open sessions ... It's very cool because now I feel that I'm empowered by not just one of me, like several instances." — Victor Rodrigues, Principal Engineer, Fabric.
The goal is not maximum code generation. It is a system that moves faster because the plan is explicit, the context is shared, the work is visible, and people still control the decisions that matter.
Key results
- 3.4× more completed work per engineer per week, from 2.3 items to 7.7, comparing January–April 2026 with July–September 2026
- 71% shorter median lead time, from 4.9 days to 1.4 days over the same periods
- Open items idle for more than 30 days fell from 259 to 1 over the same periods














