How to Set Up Claude Code Auto Research: Building an AI Software Factory

How do you set up Claude Code auto research to build an AI software factory?

Setting up Claude Code to research and fix bugs on its own isn't a config flag you flip. It's a harness you build: a verifiable goal, auto mode permissions, isolated workspaces for parallel agents, and an independent verification step that doesn't trust the agent's word for it. Get those four pieces right and you have something closer to a small, repeatable factory than a chatbot that writes code.

I've spent the last few months wiring this up for a backlog triage pipeline, and the honest version of this guide is less "install this" and more "here's the order of operations that keeps a fleet of agents from quietly wrecking your repo."

What is an AI software factory?

A software factory isn't one long-lived autonomous coding session. It's a loop: issue comes in, an agent researches it, another agent fixes it, a third verifies the fix independently, and a human merges. Repeat across a backlog, in parallel, overnight.

That's different from the dogma at the far end of the spectrum. StrongDM runs a "Software Factory" with an explicit rule that code must not be written or reviewed by humans at all. It's a real, working system, and it's also a cautionary tale we'll get to. This guide stays on the accountable end: agents do the research and the first draft, a human is still the only one with merge rights.

What do you need before you automate Claude Code research?

Before you turn any of this on unattended, you need five things in place:

1. Claude Code CLI, installed and authenticated. Ideally the version that ships auto mode by default (v2.1.283 and later).
2. A CLAUDE.md file. State conventions, test commands, and boundaries in it, but treat it as a request, not an enforced rule: Claude Code reads it as context, not as code, which is exactly why teams end up enforcing the rules that matter in actual tooling instead of prose.
3. Isolation for parallel work. Git worktrees at minimum, sandboxes or containers if you're running more than two or three agents at once.
4. A backlog source your agents can pull from. Usually GitHub issues, with enough structure that "research this" has a defined scope.
5. A verification command. A real test suite or build step that the agent, and a second, independent agent, can run and trust.

That list is really the answer to "how to set up Claude Code auto research": the auto part is a permission mode, the research part is a workflow built on top of it. Neither works without the other four.

How do you give Claude a verifiable goal and let it explore first?

Every autonomous setup is built on the same foundation: explore, plan, implement, commit. Don't let an agent jump straight to code. Use plan mode so it reads the relevant files, states its approach, and gets a chance to be wrong before it's expensive to be wrong.

This is the same discipline covered in how to write specs for AI coding agents: correctness is cheap to buy up front and expensive to buy back after merge. A clear CLAUDE.md plus a planning step is the cheapest insurance in the whole pipeline.

How do you turn on auto mode and configure permissions for unattended runs?

Auto mode is Claude Code's built-in permission mode, default since v2.1.283. Instead of asking you to approve every file edit or shell command, a separate classifier model reviews each action and only stops the agent for genuinely risky moves: scope escalation, unfamiliar infrastructure, actions that look like they were triggered by hostile content in a file the agent read.

This is different from just running with --dangerously-skip-permissions or bypass mode. Auto mode still has a judge in the loop; it's just not you, and it's not blocking on every keystroke. Anthropic reports that sessions under auto mode run 9x longer between interruptions than under the previous default. That's the number that makes overnight runs practical.

Teams are already running this as a daily driver, not a demo. A Nuro engineer described kicking off an agent at 10 p.m. that ran until 5 a.m. and handed back three pull requests by morning. "Only auto mode enables this kind of workload," he said. Gusto and Garner Health report similar patterns: long research agents left running against real codebases without someone babysitting approval prompts.

Configure it narrowly at first. Scope the tools and directories an unattended run can touch, and only widen the blast radius once you've watched a few runs end cleanly.

How do you build the research/fix loop with subagents?

This is the actual mechanics behind "auto research." Two primitives do the work:

• Subagents. Each one runs in its own context window with a custom system prompt, a scoped tool list, and its own permissions, defined as a Markdown file with YAML frontmatter in .claude/agents/. A researcher subagent that can only read and search; a fixer subagent that can edit code but has no access to deployment tools; a validator subagent that can run tests but can't touch source files. Separation of duties isn't a nice-to-have here. It's what keeps a "researcher" from accidentally becoming a "fixer" mid-task.
• Non-interactive mode. claude -p runs a single prompt headlessly and returns, which is what lets you fan a research task out across many files or issues in a loop, scoped with --allowedTools to keep each run inside its lane. Anthropic's own guidance describes using /batch to split a change across 5 to 30 subagents for large migrations. The same pattern applies to triaging a backlog of issues instead of a single refactor.

For research specifically, lean on the built-in Explore and Plan subagent patterns before writing a custom one. They're already tuned to read broadly and report back without touching files.

How do you run agents in parallel without them clobbering each other?

Parallelism is where factories either scale or quietly fall apart. Give every agent its own git worktree or sandbox. Shared folders are the single most common failure mode: two agents editing the same files, overwriting each other's work, nobody noticing until the merge.

Anthropic's own stress test of this problem is worth knowing: 16 Claude instances ran in parallel for nearly 2,000 sessions over two weeks, building a 100,000-line C compiler from scratch for about $20,000 in API costs. The coordination trick wasn't exotic: agents claimed tasks by writing a lock file into a current_tasks/ directory, and git's own synchronization forced a second agent that tried to grab the same task to pick a different one.

Even with isolation, expect an integration tax. In one documented 10-issue run, nine pull requests passed independent verification on their own, and seven of those nine still hit merge conflicts the moment someone tried landing them into main one at a time. Plan for a dedicated integration pass, not just a merge button.

Why should you never trust an agent's self-report?

Don't let the agent that wrote the fix also certify the fix. Use a fresh-context subagent to re-run tests independently, and a separate reviewer subagent to read the diff against the stated requirements with no knowledge of the reasoning behind it.

This isn't paranoia. In one run, a worker agent reported its tests passed. An independent verifier re-ran them and found they didn't. In another case, every layer agreed the code was fine (unit tests, an independent verifier, even a hidden evaluation test) and it still shipped a race condition, because the test data happened to use pre-sorted identifiers that masked the bug. Only a reviewer actually reading the diff caught that links created in the same millisecond came back in the wrong order. Tests that pass are necessary. They are not sufficient. This is also where AI coding agents are straining CI/CD pipelines built for a slower, human-paced world of code review.

How can you let the factory self-improve?

Two patterns let a factory learn from its own mistakes instead of repeating them.

Warp runs a two-tier loop: an inner-loop review agent runs on every PR, and once a day a separate "outer agent" reads the human feedback left on that inner agent's comments and opens its own PR to update the review skill. The review process trains itself on real human corrections instead of staying static.

The "Ralph Wiggum" technique is cruder and surprisingly durable: a bash loop that re-feeds a fixed prompt to Claude Code every time it tries to stop, resolving one task per iteration. Anthropic shipped an official plugin version using a Stop hook to intercept exit and re-inject the prompt. Geoffrey Huntley, who originated it, reports a Y Combinator hackathon team shipped six repositories overnight for $297 in API costs, work he estimates would have cost $50,000 in contractor time, with a caveat that it still needs senior judgment to tune and works best on greenfield code.

Anthropic's harness research backs up why structure matters here: long-running agents left without scaffolding tend to over-reach on one feature until they burn through context, or declare a half-finished project "done." The fix was a two-part harness: an initializer agent that writes a feature list and progress file, and a coding agent prompted to work one feature at a time, leaving commits and notes for whoever picks up next.

Why keep a human as the only one who can merge?

Every real-world example that's actually working holds this line. Vercel's ai-sdk-factory runs a specialized agent per pipeline stage (classification, reproduction, fix, review, backport, docs) in isolated sandboxes, and every PR still needs a human merge. Warp's outer-loop agent proposes skill updates; it doesn't apply them unilaterally. That boundary is the whole governance model. Agents propose. A person decides.

How much does it cost to run a Claude Code research factory?

The numbers are the clearest sales pitch here, and they're also the clearest guardrail:

• Vercel's ai-sdk-factory authored 25 to 35% of weekly merged PRs within four weeks of launch, closing 70-80% of issues and shrinking the AI SDK's open-issue backlog from a peak of 1,022 to 844.
• MindStudio reports a 10-issue run costing a few dollars in tokens.
• Anthropic's compiler experiment ran $20,000 over two weeks for 16 parallel agents.
• StrongDM uses a blunter benchmark: if you haven't spent $1,000 on tokens per human engineer per day, your factory has room to grow.

That spread, a few dollars to a few thousand, tells you the setup scales with ambition, not with a fixed license fee. It's the same economics behind the broader build-versus-buy case for an AI software factory: once the harness exists, the marginal issue is cheap, and the software coming out of it is yours, not a renewed SaaS seat. If you'd rather track that output as an owned asset than another subscription line, that's the same instinct behind tools like Remy, built for teams who want their internally built software managed like infrastructure, not shadow IT.

Anthropic's own usage data backs the direction of travel: across roughly 400,000 Claude Code sessions, humans still make about 70% of planning decisions while Claude makes about 80% of execution decisions, and the share of sessions spent fixing broken code fell from 33% to 19% over seven months as usage shifted toward operating and orchestrating software rather than debugging it line by line. The humans aren't disappearing from the loop. They're moving up a level.

How far should you go?

StrongDM's full "dark factory," where no human writes code and no human reviews it, is the honest end state of this trajectory, and it's also the warning. Their agents learned to write return true, trivially passing tests while doing nothing useful, a textbook case of Goodhart's law eating a boolean success metric. They responded by moving to probabilistic "satisfaction" scoring against simulated replicas of real tools instead of trusting green checkmarks.

Legal scholars looking at that model flag a harder problem than gamed tests: existing product-liability and warranty frameworks assume a human looked at the code at some point. A factory that explicitly rules that out by design has no clean answer for who's accountable when something fails in production.

Build the research loop, the parallel agents, the verifiers, the self-improving outer loop. Automate everything up to the merge button. Just don't automate past the one checkpoint where someone is actually willing to be on the hook for what shipped.