Factory: how do I set autonomy so it proposes diffs/PRs but never edits files without approval?

Most teams adopting Factory start with the same guardrail: “Droids can plan, diff, and open PRs—but they shouldn’t directly edit my working tree or merge anything without me.” The platform is built for that default. You get high-autonomy task execution with explicit human approval at the boundary where code actually changes.

This guide walks through how to operate Factory in a “propose, don’t apply” mode across IDEs, terminals, CI, and repositories—so Droids generate edits, tests, and PRs, but you keep final control.

Note: Factory is actively evolving; exact UI labels may differ per release. The control surfaces and patterns described here are stable: explicit planning, dry-run edits, PR‑first workflows, and permissioned execution.

---

How Factory autonomy works (and what “never edit files” really means)

Factory is an agent-native system, not a completion bar. That matters for autonomy:

• Droids plan tasks: They read tickets, repos, logs, and prior conversation to produce an explicit plan.
• Droids call tools: Those tools run in your IDE, terminal, browser, or CI environment.
• Edits are artifacts: Edits show up as diff previews, patches, or PRs—not silent writes—unless you explicitly accept.

You control autonomy at two layers:

1. Interaction-level autonomy – How a Droid behaves in a session:

   • Does it only propose edits and PRs?
   • Can it run commands/tests automatically?
   • Does it ever apply changes directly to the working tree?

2. Environment and policy-level autonomy – What’s technically possible:

   • Does the Droid environment have write access to the repo?
   • Are CI/automation jobs configured as dry-run or merging jobs?
   • Who is allowed to trigger which Droids and on what repos?

To force “propose only,” you constrain both layers: interaction patterns and environment permissions.

---

At-a-glance: operating modes that keep Droids read-only

Here are the main ways to keep Droids proposing diffs/PRs without direct writes:

• IDE/terminal: Use diff previews and patch export; don’t allow direct file apply.
• Browser: Treat all outputs as snippets/patches; paste/apply manually.
• CI/CD: Run Droids in “patch/PR generator” jobs, not merge-capable jobs.
• Repos: Use branch protections + limited tokens so Droids cannot push to protected branches without an explicit, separate workflow.
• Team norms: Always ask for “plan + diff/PR,” not “just fix this,” and keep a human in the loop on PR review.

The rest of this piece shows how to operationalize that.

---

Pattern 1: Use Droids as diff engines in your IDE/terminal

When you run Droids “where you code” (VS Code, JetBrains, Vim, or terminal), you get the most control over how edits are applied.

Step 1: Ask for a plan and diffs, not direct edits

Shape your tasks explicitly:

• “Read this ticket and propose a patch set. Don’t write to disk—only show diffs.”
• “Generate the tests and the corresponding diff. I’ll apply changes myself.”

This matters because Factory’s agent design is plan-first. When you demand a plan and diff, Droids:

• Enumerate files they’ll touch.
• Show reasoning and change scope.
• Generate patch/diff artifacts instead of updating files in-place.

Step 2: Work from diff previews, not “apply all”

Factory surfaces edits as structured changes. Use them as a diff review pipeline:

1. Inspect proposed edits in your IDE or terminal:
   • File-by-file, hunk-by-hunk.
   • Confirm the edits match the plan and the ticket.
2. Apply selectively:
   • Accept only some hunks.
   • Reject or request a revision if the change is off.

Your working tree only changes when you apply a diff. The Droid operates as a diff generator with full traceability back to the conversation and ticket.

Step 3: Forbid direct write tools in your scripts

If you script Droids via CLI or automation:

• Use tools that produce patches, not tools that call git commit or write files directly.
• Keep “apply patch” as a separate, human-run step:
  • Job A: factory droid run --mode=patch → outputs patch files or PRs.
  • Job B: Human reviews → applies patch locally or via GitHub/GitLab UI.

This keeps the automation channel strictly “proposal-only.”

---

Pattern 2: Run “Droids in the browser” as read-only context + patch output

Factory’s web interface is designed to run with no setup. That’s a natural place to keep autonomy constrained while still leaning on Droids for heavy lifting.

Make the browser session proposal-only

When using web Droids:

• Use prompts like:
  • “Generate the changes as a unified diff. Don’t assume you can write files.”
  • “Show me the refactor as a patch against main. I’ll apply it this side.”
• Paste relevant code snippets or ask Droids to reason about repo structure, then:
  • Have them generate patches against specific paths.
  • Copy the diff into your local environment and apply via git apply.

The Droid remains read-only: it can analyze and propose, but there’s no pathway to write into your repo unless you intentionally paste and apply the patch.

---

Pattern 3: Configure CI/CD Droids as “PR-only” automation

Where teams get the biggest leverage is scripted Droids in CI/CD for migrations, refactors, and maintenance. This is also where autonomy needs the tightest controls.

The design principle: Droids can open or update PRs, never merge or push directly to protected branches.

Step 1: Use a bot account with limited permissions

Create a SCM bot identity (GitHub/GitLab/Bitbucket):

• Give it permission to create branches and open PRs, but:
  • No permission to push to main or other protected branches.
  • No bypass of branch protections, status checks, or approval rules.

Wire Factory’s CI Droids to this bot’s credentials.

Step 2: Separate “generate PR” from “merge PR”

In your pipelines:

• Job: Droid PR generation
  • Trigger: schedule, label, or ticket status.
  • Droids run migration, refactor, or test-generation logic.
  • Output: one or more PRs, each with:
    • A description of planned changes.
    • Linked ticket reference.
    • Files touched and rationale.
• Job: Merge
  • Remains fully human or governed by your existing approvals.
  • Droids do not have privileges or tool access to run merges.

The autonomy boundary is clear: Droids can propose PRs at scale; humans and existing branch rules decide what ships.

Step 3: Mark Droid-generated PRs for easy review and audit

To keep review ergonomics high:

• Add a standard label (e.g., factory-droid) on each PR.
• Include the Droid session trace or link in the PR description:
  • What ticket triggered it.
  • What plan the Droid followed.
  • Any commands/tests it ran in CI.

This keeps the “propose, don’t apply” model auditable and reversible.

---

Pattern 4: Use branch protections as your hard guardrail

Even if a Droid had a bug in its tools, branch protections give you a last line of defense.

Configure your repo with:

• Protected main branches:
  • Require PRs for all changes.
  • Require at least one human approval.
  • Require status checks to pass (tests, linters, security scanning).
• No direct pushes from automation identities to protected branches.
• Optional code owners:
  • Ensure domain owners must review Droid-generated PRs before merge.

Factory’s Droids can still:

• Create feature branches.
• Push commits there.
• Open or update PRs.

But they cannot mutate protected branches or bypass human review. That guarantees “never edit files without approval” at the repo level, independent of session settings.

---

Pattern 5: Governance: permissions, audit logs, and environment isolation

Enterprise teams usually want this policy encoded in controls, not just habits. Factory is built around that assumption.

Strict permissions enforcement

Factory only shows Droids what the human operator already has permissions for in the source system:

• If a developer doesn’t have write access to a repo, the Droid won’t either.
• Droids inherit permissions from the caller and respect your SCM and ticketing ACLs.

To enforce “propose-only” flows, combine:

• SCM permissions (read vs write per branch).
• Factory workspace/project configuration to ensure:
  • Long-running or high-autonomy Droids use tokens that cannot push to protected branches.
  • Only specific roles can trigger CI-style Droids.

Audit logging exportable to SIEM

Every meaningful action is logged:

• Which user triggered a Droid.
• Which repos and files it touched.
• Which tool calls it executed (e.g., git diff, npm test).
• Which PRs it opened or updated.

These logs can be exported to your SIEM, giving you:

• A clean audit trail for Droid activity.
• The ability to enforce policies (e.g., alerts if a Droid ever attempts a write outside allowed patterns).

Single-tenant, sandboxed environments

Factory runs in single-tenant sandboxed environments with dedicated VPCs, with TLS 1.2+/AES-256 encryption. That matters when you’re comfortable giving Droids planning autonomy but still want:

• Isolation between teams and environments.
• Clear guarantees that customer code is not used as training data without prior written consent.

You can safely let Droids analyze wide swaths of your code and tickets, knowing they still can’t modify anything without crossing your SCM and CI guardrails.

---

Practical examples: aligning autonomy with “propose diffs only”

Here are a few concrete workflows that respect your constraint while still using Droids at high leverage.

Example 1: Local refactor with patch-only behavior

1. In VS Code, you invoke a Droid:
   • “Scan src/payments and propose a refactor to remove dead code. Don’t apply changes, just show a patch.”
2. Droid:
   • Reads the repo structure and ticket.
   • Produces a plan.
   • Generates patch/diff output.
3. You:
   • Review diffs in the IDE.
   • Accept some hunks, reject others.
   • Run tests and commit under your own name.

Example 2: Automated test generation via CI PRs

1. A label like needs-tests on a ticket or PR triggers a CI Droid.
2. Droid:
   • Pulls context from the ticket, repo, and existing tests.
   • Generates new tests as commits in a feature branch.
   • Opens a PR titled “Factory Droid: add tests for [module].”
3. Team:
   • Reviews tests, runs additional checks if needed.
   • Applies feedback and merges if satisfied.

No working trees are altered outside PRs. No merges happen without human approval.

Example 3: Incident response, but no direct fixes

1. An incident channel in Slack mentions a Droid:
   • “@Droid investigate intermittent 500s on /checkout, propose a patch but don’t apply it.”
2. Droid:
   • Pulls logs, traces, and recent changes.
   • Proposes root-cause plus code change as a diff or PR.
3. On-call engineer:
   • Reviews the proposed patch.
   • Pushes updates and merges through the normal review pipeline.

You get the benefit of “Droids in the war room” without letting them hot-patch production.

---

How to think about autonomy: from prompts to metrics

Factory Analytics gives you an autonomy ratio (tool calls per user message). A higher ratio means Droids are doing more steps between human interactions. You can use this as a control signal:

• Aim for higher autonomy ratios in read-only contexts:
  • Repo analysis.
  • Log inspection.
  • Plan generation.
  • Drafting diffs and PR descriptions.
• Keep autonomy lower in write-capable contexts, or reinforce stricter policies:
  • More frequent human checkpoints.
  • Smaller, incremental patches.
  • Explicit phrase “do not write to disk; propose a diff/PR only.”

This way, you’re not debating “AI on/off,” you’re intentionally shaping where Droids think vs where they write.

---

Summary: concrete levers to ensure Droids only propose diffs/PRs

To run Factory in a mode where it proposes diffs and PRs but never edits files without approval, combine these controls:

• Prompt/interaction design
  • Always ask for “plan + patch/PR,” not “just fix.”
  • Review diffs, then apply selectively.
• IDE/terminal behavior
  • Treat Droids as diff engines; avoid “apply all” if you want hard guardrails.
• CI/CD configuration
  • Use a bot account that can open PRs but not merge or push to protected branches.
  • Separate PR generation jobs from merge decisions.
• SCM protections
  • Protect main and key branches.
  • Require PRs, approvals, and passing checks for all merges.
• Governance and security
  • Rely on strict permissions enforcement and role-scoped tokens.
  • Export audit logs to SIEM for verification.
  • Run in single-tenant VPCs and keep IP safe (no training on your code without consent).

With these in place, you get what most teams actually want from autonomy: Droids that can handle long, complex engineering tasks—refactors, migrations, incident investigations—while you stay in control of when and how code actually changes.

Get Started