Set Up an Autonomous Developer That Fits Your Workflow

A coding agent that produces work nobody reviews is not an autonomous developer. It is a faster way to generate diffs that pile up outside the process you already trust.

The usual demo skips the part you actually need. An agent is pointed at a goal, it edits files, and a finished branch appears. What it does not show is where the ticket came from, who decided the change was safe enough to attempt, which checks ran before a human looked at it, and how the result lands back in the same repository and review step the rest of the work flows through. Strip those out and the agent is not part of the development process. It is a side channel that happens to write code.

The fix is not a smarter agent. It is an operating model that wires the agent into the issue tracker, repository, and review step you already have, with explicit gates between intake and merge.

An autonomous developer is a pipeline, not a prompt

Treat the autonomous developer as a workflow with named stages, not a single open-ended session. Each stage has an owner, an input, and a verification criterion that decides whether work advances or stops.

The shape that fits an existing development process looks like this:

Stage	What happens	Verification criterion
Ticket intake	A ticket from your issue tracker becomes a task with its description, labels, and linked context attached	The task has a concrete acceptance condition, not just a title
Planning	The agent reads the repo and writes a work spec: files it expects to touch, approach, test plan, open questions	The spec is reviewable on its own, before any code is written
Risk scoring	The plan is scored on blast radius, novelty, sensitivity, and reversibility	A score above the threshold routes to human approval before execution
Execution	The agent runs on a connected worker against your actual repository, following the spec	Work stays inside the files and scope the plan declared
Verification	Project checks run: build, tests, formatter, linters, and any review checklist for non-compiler concerns	All declared checks pass, or the failure becomes an inbox item
Approval	A human reviews the diff, the checks, and the plan together	The reviewer can see what changed and why without reopening a transcript
Merge	The approved change goes back through your normal review step and into the repository	The merge follows the same path a human pull request would

The agent only owns execution and the first draft of planning and verification. Intake, the approval gate, and merge stay where they already are. That is what makes it fit a workflow instead of replacing one.

The planning step is what makes the rest reviewable

Most agent failures are not bad code. They are work that was never scoped, so nobody could tell whether the result was right before it existed.

A planning step fixes that by forcing a work spec before execution. The spec is the artifact a reviewer reads first, and it is cheap to reject. A good one states:

• The acceptance condition pulled from the ticket
• The files and modules the change is expected to touch
• The approach, in enough detail that a reviewer can disagree with it
• The test plan, including what counts as passing
• Open questions the agent could not resolve from the repo alone

Rejecting a plan costs a paragraph of feedback. Rejecting a finished branch costs a full review and a rerun. Putting the cheap gate first is the whole point. It also gives the reviewer something to compare against later: a diff that wanders outside the files the plan declared is a signal on its own.

Score risk so the gate is proportional

Not every ticket deserves the same scrutiny. A typo fix in a README and a change to an authentication path should not pass through the same approval. Risk scoring is how the pipeline decides where a human must look before execution, instead of forcing approval on everything or trusting everything.

Score each plan on four dimensions:

Dimension	Low risk	High risk
Blast radius	One file, isolated module	Shared utilities, config, many call sites
Novelty	A pattern the codebase already uses	A new dependency, new approach, unfamiliar area
Sensitivity	Internal tooling, docs, tests	Auth, payments, data handling, customer-facing output
Reversibility	Trivial to revert, no migration	Schema changes, data migrations, released artifacts

A change that is low on all four can run and surface its result for review. A change that is high on any one of them routes to human approval before the agent writes code, because the cheapest moment to catch a bad approach is before it exists. The threshold is yours to set. The discipline is that the score is explicit and recorded, not a feeling the reviewer has after the fact.

Verification is more than the test suite passing

For code, the compiler and the test suite carry real weight, and they should be wired in as gates that block on failure. But "the build is green" is not the same as "this change is correct." A passing suite says the agent did not break what was already covered. It says nothing about whether the change matches intent, or about the parts of the work no test exercises.

That is why the verification stage mixes automatic and human checks:

• Build, tests, formatter, and linters run as automatic gates that block on failure
• A review checklist covers what tests cannot: does the diff match the plan, is the scope what the ticket asked for, are there obvious gaps
• A failed check does not vanish into a log or a notification. It becomes a unit of work a human is routed to, with the failure and the context attached

The pipeline does not need every check to be automatic. It needs every gate to be explicit and every failure to land somewhere a person will see it.

Where Task Machine fits

This pipeline is the kind of work Task Machine is built to run. The autonomous developer is set up as a deterministic workflow with the same stages above: branch and approval nodes, verifiers, retries on failure, and step-level logs you can read after the fact. The planning and risk-scoring stages gate approval, so high-risk changes stop for a human before execution rather than after.

You work that pipeline through three surfaces. Chat is where you direct the work and fan a goal or a batch of tickets into tasks. The inbox is where the gates come back to you: a plan to approve, a high-risk change to look at, a failed verification to resolve. Tasks is where you dig into one piece of work, read its step log, and steer it when the diff drifts from the plan. Chat to direct, inbox to approve, tasks to dig in.

Autonomy is a level you set, not a switch you flip. A low-risk, well-covered change can run to a reviewable result without stopping. A sensitive one stops at the plan. Budgets cap what a run can spend before it pauses for you, so an agent in a retry loop does not quietly burn through tokens. Connectors wire the pipeline to the issue tracker and repository you already use, so intake and merge happen where your work already lives rather than in a separate tool.

The honest limitation

Two things are worth stating plainly.

First, human review does not go away. The pipeline moves the human to the highest-leverage moments — approving a plan, gating a risky change, resolving a failed check — but a coding agent that merges without a human reading the result is not what this describes. If your goal is to remove review entirely, this is the wrong model.

Second, the agent runs on a machine you connect — through Codex, Claude Code, Opencode, Pi, OpenClaw, or Hermes. The worker lives on hardware you provide and keep reachable, so setup means connecting a machine and leaving it on. The upside is that the agent runs where your repository and tools already are, in the real environment rather than a copy of it.

That tradeoff is also the point. An agent that runs against your real repository, on a worker you control, gated by your tracker and your review step, is one you can actually fold into how you ship. An agent that runs somewhere you cannot see, producing branches nobody scoped, is the thing you were trying to avoid.

If you want to set up an autonomous developer that fits the process you already run, join the private beta on the waitlist.