Factory turns coding requests into reviewable Droid work

Factory builds Droid, a software-development agent that works with repositories, terminals and development tools. Its appeal is the continuity between an interactive coding session and repeatable work run in a background environment or automation. The buying decision is therefore about more than code completion: a team needs to decide which work it can delegate, what the agent may execute and how a reviewer accepts the result.

01 / ProductDroid connects repository context to executable work

The CLI quickstart introduces Droid inside an existing code project. It can inspect the repository, map relevant files, propose changes and show a diff. The current public website is factory.com; the earlier factory.ai address redirects there, while the product documentation and application retain factory.ai subdomains.

Factory also documents Droid Exec, a non-interactive interface for scripts and CI. That changes the operating setting: an interactive engineer can answer a question, while an automated job needs a bounded instruction and a machine-readable completion condition. The same software agent can participate in both, but a successful terminal conversation is not sufficient specification for unattended work.

The product separates interaction mode from autonomy level. Spec Mode plans before implementation; autonomy determines which actions can run without repeated approval. Off, Low, Medium and High progressively permit broader work, subject to other policies and safeguards. Understanding that distinction helps teams avoid treating a planning mode as a universal security boundary.

02 / AudienceBest suited to teams that can define a reviewable change

A useful initial audience is a team maintaining several services with similar maintenance work: replacing a deprecated library call, improving a test fixture or adding structured logging. These tasks have recognizable completion evidence. The agent can inspect implementation details, but an engineer still decides whether the change preserves the service’s contract.

Factory is less straightforward for a repository with unreliable setup commands, missing tests and undocumented environment dependencies. An agent may spend most of its time discovering how to run the project. That work can still be useful, but it should be treated as repository preparation rather than evidence of immediate development throughput.

The Cursor blueprint offers an editor-centered comparison when the developer wants continuous assistance while writing code. The Cognition blueprint is relevant when delegated software tasks and remote execution are central. Compare them using the same accepted repository change, including review time and environment preparation, rather than the number of generated lines.

03 / WorkflowA proposed dependency-migration workflow

Imagine a team replacing a deprecated client-library method across a service. This is a proposed workflow, not a test performed for this article. Select a single repository and define the supported runtime, the old method, the replacement and the behavior that must remain stable. Prepare a branch and a fixture that exposes the old behavior before asking the agent to edit.

Start by asking Droid to find call sites and identify related tests. Review the plan for indirect uses, wrappers and generated files. A search result alone may miss dynamic access or a helper in another package; the agent’s proposed map should explain how the change propagates. This inspection phase is useful even if a human ultimately performs the edit.

Choose the execution policy for the task. Low autonomy allows file edits and lower-risk commands; Medium adds reversible development operations such as dependency installation and builds. The right level depends on the actual task and organization policy. Keeping a deployment command outside the approved scope makes the review boundary easier to understand.

Ask for the smallest migration that preserves behavior, together with the relevant validation. Review changed dependency and lockfile entries as well as application code. If the replacement changes error types, retries or pagination, those differences deserve explicit tests. A mechanically correct rename may still alter what downstream callers observe.

Once the interactive process is repeatable, evaluate Droid Exec for the same bounded task in CI. Its headless documentation describes non-interactive execution and output controls. Give the runner only the credentials and files required for the job, record the result as a proposed change, and require the existing merge checks before the patch enters the main branch.

Compare runs by accepted migration, not agent activity. Useful measures include unresolved call sites, behavioral regressions, time spent reviewing the diff and the number of interventions. Keep failed attempts because they reveal whether the obstacle is task ambiguity, model behavior or an environment issue. A clean final patch does not explain the cost of reaching it.

04 / PricingPlans combine access with different usage and organization controls

The Teams base charge matters. Illustratively, five seats at the displayed rate cost $260 per month before any additional charges or tax: $60 plus five times $40. This is arithmetic from the published components, not a vendor quote. Compare that shared-billing route with the administrative features the organization actually requires.

The pricing page lists SSO, SAML/SCIM, zero data retention and audit logging under Business, with more extensive controls and on-premise options under Enterprise. Do not assume a team billing plan includes every enterprise control. Likewise, the Plus and Max usage multiples do not promise a particular number of completed pull requests.

Model choice, context size and repeated attempts can change how quickly a rolling allowance is consumed. Budget using a representative mix of implementation, review and investigation tasks. Include the compute environment and engineer review effort; the subscription is one part of a functioning development process.

05 / DistinctionsA useful separation between planning, permission and execution

Factory’s control model makes three questions explicit: what should be done, what may run automatically and where it runs. That separation is valuable when a team wants the same task specification in a developer terminal and a controlled runner. It lets the organization adjust permissions without rewriting the business goal.

The data-flow guide distinguishes local file operations, model requests and telemetry. It says the agent loop runs where Droid is installed and that file contents can leave that machine as model context. A local CLI should therefore not be described as local-only inference. The chosen endpoint and deployment pattern determine where the reasoning request goes.

Another practical distinction is the ability to move a known procedure into headless execution. The value is consistency in how a task is requested and checked, rather than simply removing a human from the loop. A well-defined patch proposal can save repetitive setup while keeping acceptance in the existing engineering workflow.

06 / QuestionsThe important boundaries are repository-specific

Which commands can reach production systems? Package scripts can contain network writes or deployment actions despite harmless names. Review the runner’s credentials and network access alongside Droid’s policies. A command approval layer and an operating-system sandbox address different mechanisms; neither should be assumed to describe the entire environment.

Which model endpoint receives source code? Factory’s privacy documentation describes cloud-managed, hybrid and airgapped patterns, and states that custom endpoint guarantees depend on the configured systems. Confirm the actual contracted pattern, not merely that airgapped deployment exists somewhere in the product family.

What is the recovery path when the task stops halfway? Keep changes on a branch, preserve logs that explain validation failures and make the human handoff include unfinished work. A generated commit is an artifact to inspect, not proof that tests passed or the change was released. For larger tasks, make intermediate acceptance criteria explicit before expanding autonomy.

07 / DecisionAdopt around a repeatable engineering outcome

Factory is worth evaluating when a team can describe valuable repository work with observable completion criteria. Begin with a bounded migration or repair, then compare the accepted result with the existing workflow. Expand into background execution only when environment setup, permissions and validation are reproducible.