getting from Step 1 to Step 2 of AI coding adoption

Most engineers working with Claude Code settle at a stable equilibrium: one task, one agent, you read every line it produces. The agent writes; you approve or redirect. It works. Your output is faster than writing by hand, and you feel in control because you are — you are the gate on every transition.

The ceiling is also you.

At this mode of working, throughput is still linear. The agent accelerates each unit of work, but you are serializing the pipeline. Moving to ten parallel tasks on ten worktrees requires trusting a loop you have not built yet, and most engineers have not built it because no one has described what it should contain.

the framework: steps of AI adoption

Boris Cherny, principal engineer at Anthropic, published a "Steps of AI Adoption" ladder in July 2026. Step 1 is Assisted: AI helps with individual tasks, you read everything, you hold the context. Step 2 is Parallel/Orchestrator: "run more than one agent at once; a self-verification loop you trust; auto mode to avoid permission prompts; automate code review." At Step 2, the description reads: "agents on their own worktrees, Claude self-checks tests/build/lint/security, automated code and security review, you review final diffs."

That last phrase is the key shift. You review final diffs, not each intermediate step. The verification loop has taken over the intermediate checking. You sign off on intent, not process.

Most engineers stall between Step 1 and Step 2 not because they lack tooling, but because they have not built the verification loop that earns the trust to stop reading everything. That trust has to be earned through evidence, not assumed.

the four ingredients

Cherny's Step 1→2 recipe maps to four practices. None requires a specific tool; each can be assembled from Claude Code primitives. But they have to be assembled deliberately — they do not arrive automatically by "using AI more."

1. worktrees, not branches

Running multiple agents against the same working directory causes constant conflicts. The standard solution is git worktrees: each agent gets its own checkout at a dedicated path, operates independently, and its output merges back to main when done. Worktrees let parallelism scale past the natural two- or three-agent ceiling without the merge chaos that kills it.

The practical ceiling on parallel Claude Code agents without worktrees is low — agents step on each other's file writes, context bleeds between tasks, and you spend more time untangling conflicts than you save from the parallelism. Worktrees are the mechanical prerequisite for Step 2.

2. a self-verification loop

A verification loop is what earns the right to stop reading every line. The agent produces output; before that output reaches you, something checks it. The minimum viable version: the agent runs tests and build after writing code, and only surfaces the result when both pass.

This sounds obvious but most setups skip it. If you are using Claude Code in the terminal without structured hooks, the agent completes its task and stops — it does not run tests unless you ask it to at the end of every prompt. Building the loop means structuring the agent's prompt to include verification as a required phase, not an optional add-on.

A more complete version adds lint, type-checking, and a security scan. Cherny's Step 2 description lists all four. The more the loop catches, the less you need to read before approving.

3. auto mode

Claude Code's default behavior prompts for confirmation on tool uses that might be risky: file writes, shell commands, network calls. In interactive single-agent use, that is fine. With multiple agents running in parallel, the permission prompts are walls — each one stalls an agent and routes back to you, serializing the workflow you were trying to parallelize.

Moving to auto mode means configuring an allowlist of safe tool uses and denying risky ones by default. What belongs in the allowlist and what must stay on the denylist takes some deliberate design — the Claude Code production config post covers the patterns. The result is agents that run to the verification step without interrupting you.

4. automated code review

The final ingredient is an agent reviewing the agent's output before it reaches you. A human reviewer looking at ten parallel diffs becomes the new bottleneck; the loop you built to free you from file-by-file reading breaks down at the review gate if review is still manual.

An automated reviewer reads the diff from implementation and produces structured output: potential bugs, security issues, naming or architecture concerns. It does not approve the change — that is still the human's role — but it reduces the cognitive load of review to evaluating the reviewer's findings rather than cold-reading the diff from scratch. For anyone running multiple agents in parallel, automated review is what keeps throughput from collapsing at the approval step.

what "trust" actually means

Trust in the loop is evidence-based, not faith-based. You earn the right to stop reading every line by observing the loop catch failures: a test that would have shipped broken, a security flag the reviewer caught that you would have missed on a fast manual pass, a build failure that prevented a broken merge. Once you have seen the loop work across a dozen tasks, the question shifts from "should I check this?" to "did the loop check this?"

The failure mode is not missing something once. It is reading everything because you do not trust the loop, which means the parallelism does not buy you anything — you have multiplied the agents and multiplied your own review surface at the same time. Velocity at Step 2 requires building evidence that the loop works, which means watching what it catches, not just deploying it and hoping.

Context consistency is part of the same trust surface. With parallel agents on separate worktrees, a common failure is agents making contradictory decisions because they do not share context — one agent refactors a data model, another adds a feature that depends on the old shape. Keeping decisions consistent across parallel sessions is a separate problem from verification, but it has to be solved before the trust holds at scale.

the Step 2→3 horizon

Step 3 in the framework is Supervised autonomy: the agent is a manager-of-managers, you monitor via observability rather than reviewing each file. The jump from Step 2 to Step 3 is not a tooling upgrade — it is the trust built at Step 2 compounding into a larger autonomy radius.

You cannot reach Step 3 without Step 2 working first. A team that skips the verification loop and jumps straight to "run 50 agents" finds that each agent is a failure surface they have not instrumented. The cascade is fast and the rollback is expensive.

The engineers who seem to land at Step 3 quickly are the ones who built Step 2 most deliberately: the verification loop is tight, the allowlist is specific, the review agent is tuned, and they know exactly what the loop catches and what it does not. The autonomy radius expands from that foundation.

one way to assemble the loop

defract is built around the Step 1→2 recipe as a native property of the application. Tasks run on their own worktrees by default. Agents run through a gated lifecycle — story, design, architecture, implementation, review, release — and the review stage uses specialist reviewer agents before the diff reaches the developer. Auto mode is managed through an allow/deny configuration that ships with the app.

It is one approach to assembling the loop. The Claude Code orchestrator landscape has several others; the right pick depends on what you are willing to configure versus what you want the tool to impose. The recipe above applies regardless of which approach you take. Building the loop is the move; the tool is secondary.