Factory and Droid Step by Step: Install to Auto Code Review

👁 113 reads

Factory’s Droid agents work in your terminal, editor, and GitHub: they read projects, propose changes, write code, and review pull requests. This tutorial walks you through from installation to automated code review, following Factory’s official documentation.

Before You Start: Prepare Your Project

Droid works on your repository, so a few things are worth having in order before your first task. A clean state in version control, so you can see each agent change separately and easily revert it. Working tests and commands to run them, because an agent that can check its own work makes fewer mistakes. A short project description in a file in your repository: how to run it, where the key modules are, what the team conventions are.

If your project has areas the agent shouldn’t touch, such as production configuration, state that explicitly in your guidelines.

Step 1: Installation

You install Droid with a single command. On macOS and Linux it’s a command that downloads the installer from the Factory site, on Windows a PowerShell command, and if you have Node.js, you can install it via npm. You need a Factory account to use it, and on first run you log in through your browser.

Then you navigate to your project directory and launch Droid with the droid command.

Step 2: First Task

The official guide shows how Droid reads your project, proposes changes, and waits for your approval before changing anything in your files. Small tasks work best to start: explain the project structure, find where login is handled, add validation to this form.

Step 3: Specification Mode for Larger Changes

For bigger tasks, use specification mode. Droid first examines the project and plans, then writes code. The documentation recommends it for architectural changes, migrations, security-sensitive work, and any task where you want to see the plan before files are edited. You enable it with Shift + Tab at the command line.

After the plan is proposed, you can approve each change manually, give Droid more autonomy, or continue refining the plan.

Step 4: Autonomy Level

Regardless of mode, you set how autonomously Droid can operate. The Ctrl + L shortcut cycles through levels from disabled to high. Start with low until you know how Droid handles your project.

Step 5: Editor Integration

Droid works in any editor’s terminal, and in VS Code and editors from that family it can install an extension that passes it the open file, selection, and editor errors, showing changes in the native diff view. Check integration status with the /ide command. For JetBrains and Zed, the documentation describes separate connections.

Step 6: Code Review Before Pushing

The /review command checks local changes before you push them. It’s a good habit before every pull request: Droid looks for obvious errors before anyone on your team sees them.

Step 7: Automated Review in GitHub

The /install-code-review command sets up automatic pull request review in GitHub or GitLab. Droid analyzes changes and adds comments on specific lines. It focuses on errors and skips style and minor optimizations. You add your own review rules for the repository in a guidelines file in Factory’s configuration directory.

Example: First Day on a Team

You install Droid, ask it to explain the project structure and point out three areas that change most frequently. Then in specification mode you plan a small feature, approve the plan and each change manually. Before pushing you run /review, and at the end of the day you set up automatic review for the whole repository.

This kind of first day has another advantage: it teaches the team how to read the agent’s work. After a few tasks, you can see where Droid is strong, for example in repetitive changes across many files, and where it needs more detailed instructions, for example with business logic. These observations are worth recording in project guidelines, because each new person on the team will then start from their predecessors’ experience, not from zero.

Common Mistakes

• High autonomy at the start, before you know the agent.
• Large tasks without specification mode.
• Treating automated review as a replacement for human review.

Google · Your sourcesQuantslant higher in your Google - one clickAdd to preferred sources →

How to Evaluate the First Week

After a week, count two things. How many tasks Droid completed so you accepted the change without corrections, and how many required your intervention. With a well-prepared project, the first number grows quickly. Also check comments from automated review: did they point to real errors, or mostly noise. If noise dominates, add review guidelines for your repository so the agent knows what to focus on and what to skip.

Only when results are good should you increase the agent’s autonomy level.

If you’re working solo rather than on a team, the same principles work at smaller scale: assign the agent tasks you can quickly verify, and review every change before merging, even if no one else will see it.