Target assistance at the delivery bottleneck

Learning objective

Identify high-value AI-assisted stages across planning, implementation, testing, review, and documentation, tiered by risk and measured against a baseline.

Core idea

Choose the workflow stage where assistance can shorten delivery without shifting more work into verification or incident response. Generating an implementation faster has little value when changes already spend most of their time awaiting review. An architect owns the complete path from request to accepted change, including the additional review that generated output creates.

Anthropic’s common workflows cover code exploration, refactoring, tests, pull requests, and documentation. Its analytics documentation recommends pairing Claude Code contribution measures with DORA metrics, sprint velocity, or other engineering KPIs, and comparing PRs and lines shipped with and without Claude Code. Turn that guidance into a workflow measurement plan: state the bottleneck, the proposed assistance, the acceptance check, and the result that would justify expansion. The workflow choices below are an example team policy, not product-defined risk tiers.

How it works

Compare complete stages

Inventory representative changes before choosing automation. Record elapsed time, active engineering time, review effort, and rework for each stage. Separate waiting from execution: reducing an hour of implementation does not remove a three-day approval queue. Include failed and abandoned assisted tasks so the comparison does not count only successful runs.

Use the same unit of work before and after adoption. Compare a routine validator fix with similar fixes, rather than comparing it with a cross-service migration. Record task size and risk alongside the measures. Otherwise, shifting easy work into the pilot can look like a productivity improvement even when the workflow itself is unchanged.

Give each stage an assignment and an acceptance owner:

These assignments follow documented Claude Code workflows. The table defines how this team accepts their outputs. It does not imply that a planning mode, a generated assertion, or a review response establishes correctness by itself. Planning effort belongs to 7.2.2; completion criteria belong to 7.2.3.

Tier the consequences, not the file extension

A useful pilot distinguishes advisory output, bounded source changes, and consequential changes. Advisory work might produce an explanation of an unfamiliar module without modifying it. Bounded changes might add a regression case using synthetic fixtures. Consequential work might change authorization, financial calculations, or release automation.

Assign each candidate a risk record containing the failure consequence, permitted side effects, verification method, and approving owner. A documentation edit is consequential if operators use it to recover a production database. A generated test can be harmful if it replaces a correct business expectation with the implementation’s mistake. “No production source changed” is therefore insufficient as a risk classification.

For advisory investigation, ask for cited source paths so the reviewer can check them. For implementation, the team supplies tests, linters, build commands, or fixture comparisons that Claude can execute and report. Anthropic’s best practices explicitly recommend these observable signals. Configure tool permissions for the assignment using the policy in 7.1.3; a risk label in a spreadsheet does not restrict tools.

Define success before collecting usage

Write down the primary delivery measure, a quality guardrail, the observation period, and the decision owner before the pilot starts. For a review bottleneck, useful project measures include time from PR opening to first substantive review, time to approval, and reviewer minutes per accepted change. Pair them with the fraction of releases needing a corrective hotfix or rollback, using a fixed team definition. For the cost side of the baseline, obtain per-user token counts and cost estimates through OpenTelemetry export or the organization’s spend report, which reports usage and estimated usage-credit spend per user and model.

The Claude Code Team and Enterprise analytics dashboard exposes lines of code accepted, suggestion accept rate, daily active users, and sessions. Accepted lines exclude rejected suggestions but do not track subsequent deletions. Those measures establish activity; they cannot establish whether the accepted implementation survived review or improved delivery. Keep them as context for interpreting the pilot.

If using GitHub contribution metrics, state their boundary: they are public beta on Claude for Teams and Enterprise, require GitHub integration, exclude Console API and third-party integration usage, and are unavailable with Zero Data Retention. A missing contribution count outside that coverage is not evidence of inactivity. The pilot’s delivery comparison should still come from its defined change and release records.

Key distinctions and trade-offs

Generation time versus delivery time: Faster drafting can increase total effort when reviewers must reject more speculative changes. Measure the accepted outcome and the work needed to reach it.

Activity versus effect: High accept rates can coexist with frequent rework. Low accepted-line counts can accompany valuable deletion, investigation, or review.

Low write access versus low consequence: A read-only explanation can still influence a consequential human decision. Check the advice against source before acting on it.

Start where verification is affordable and a real bottleneck exists. This may favor test-gap analysis or review preparation over feature implementation. Expand only when the measured benefit survives the quality and review-capacity constraints.

Architecture / decision scenario

A retail engineering group has six developers and two reviewers. Its baseline over eight weeks shows a median two hours of implementation, 18 hours waiting for first review, and a 4% corrective-release rate. Management proposes using Claude to double feature drafting. The alternative is assisted test-gap analysis and review preparation for routine checkout changes.

The architect selects the second option for a four-week pilot. Planning assistance produces dependency notes; implementation stays within agreed checkout paths; test generation proposes uncovered cases; fresh-context review produces candidate findings; documentation assistance updates examples for accepted changes. Each stage has the owner from the table. Payment and authorization changes stay in the consequential tier with specialist approval.

The pilot target is first review within ten hours, with no increase above the defined 4% quality guardrail and no increase in reviewer minutes per accepted change. These are scenario thresholds, not Anthropic recommendations. If implementation falls to one hour while review waiting rises to 24 hours, the architect rejects expansion despite higher accepted-line counts. The engineering manager owns staffing and rollout; the architect owns whether the assisted workflow addresses the measured constraint.

Common exam traps

• Selecting the stage that generates the most code rather than the stage delaying accepted delivery.
• Comparing easy pilot tasks with complex baseline changes.
• Treating generated tests as low risk without reviewing their assertions.
• Reporting accept rate as proof of quality or return on investment.
• Interpreting analytics outside their plan, integration, or retention coverage.

What to remember

Define a bounded assignment, risk tier, acceptance owner, and baseline for every assisted stage. Measure delivery and verification effort together. Usage explains adoption; an outcome comparison with a quality guardrail determines whether the workflow deserves expansion.

Knowledge check

References

• Anthropic, Common workflows
• Anthropic, Best practices for Claude Code
• Anthropic, Track team usage with analytics
• Anthropic, Choose a permission mode