Factory in Practice: Code Reviews, Tests & Tech Debt Cleanup

👁 112 reads

Factory delivers the most value to teams where important development work sits in the queue because there’s always something more urgent: code reviews, tests, minor bug fixes, cleanup in old code. We’ve collected the use cases where Droid agents take the most work off your team’s plate.

For how to install Droid and set up code review, see our Factory tutorial.

Where to Start with Your Team

The safest first step is automatic pull request review. It doesn’t change any code, only adds comments, so your team can evaluate the agent’s work quality without risk. After two weeks, you’ll see whether the comments are on target. The second step is minor bugs from your backlog, assigned one at a time and reviewed like a colleague’s changes. Only then move to larger tasks in specification mode.

It’s important that the whole team knows the rules: who assigns tasks to the agent, who reviews its changes, and which areas of code the agent doesn’t touch without approval.

Automatic Review of Every Pull Request

The simplest implementation and often the most noticeable impact. Droid reviews every pull request before a human sees it, commenting on specific lines. It focuses on errors, not style. The human reviewer gets a change where obvious problems have already been caught, and can focus on logic and architecture.

Review Before Submitting

A command to review local changes lets you check code before anyone else sees it. Fewer rounds of corrections in the pull request means faster merging and less context switching between tasks.

Fixing Minor Bugs

Every project has a list of small bugs that no one has time to fix. You describe the bug, Droid finds the cause and proposes a fix, which you review like any other change. The backlog shrinks without taking time away from new features.

Tests for Code That Has None

Older modules often lack tests, so any change in them is risky. Droid writes tests for existing code, and you verify they test what really matters. After a few weeks, changes in old code stop being a lottery.

Migrations and Larger Changes with a Plan

Library updates, database structure changes, moving to a new language version. Specification mode first examines the project and presents a plan, and the team approves it before the first change. Factory’s documentation recommends this mode specifically for migrations and security-sensitive changes.

Tasks in Scripts and CI

When some work with Droid proves itself, you can run it without an interactive window, for example in a CI pipeline. Repeatable tasks like review or generating a change report happen automatically with every deployment.

Working in Your Favorite Editor

Droid works in VS Code, Cursor, Windsurf, JetBrains editors, and Zed. Your team doesn’t have to change tools, and in VS Code the agent sees the open file and errors from the editor.

Example: A Week with Technical Debt

A team of four developers has thirty minor bugs on the list and a payment module without tests. On Monday they enable automatic pull request review. Each developer assigns Droid two minor bugs daily and reviews the fixes. On Wednesday they plan payment module tests in specification mode, and on Friday they merge them after review. The bug list drops by half without canceling work on the new feature.

The key is that the team didn’t cancel work on the new feature. The agent took over tasks that were waiting in the queue anyway, and people handled reviewing its changes, which takes less time than writing fixes yourself. One rule is worth enforcing: every agent change has an owner on the team who reviewed and approved it. This way no one loses knowledge of what changed in the code.

What to Watch Out For

• Review every agent change like a human’s change.
• Automatic review won’t replace a reviewer for architectural decisions.
• Increase the agent’s autonomy gradually as you learn how it handles the project.

How to Check If It’s Worth It

Measure what actually hurts your team. Time from pull request opening to merge, because automatic review should shorten it. Number of bugs on the backlog at the start and after a month. Test coverage in modules that had no tests.

If after a month none of these numbers have moved, the problem usually isn’t the tool, but that no one has time to review the agent’s changes. Then it’s worth designating a fixed time each week to review what it prepared.

It’s also worth recording which types of tasks the agent performs best. After a month the team knows what to assign immediately and what’s better to do yourself, and stops wasting time trying to hand the agent tasks that require knowledge outside the code, like agreements with the client.

// read moreFactory and Droid Step by Step: Install to Auto Code ReviewGuidesReplit in Practice: Learning to Code, Prototypes & Business ToolsGuidesWarp in Practice: Commands, Error Diagnosis, Git and DockerGuides