AI SDLC with Claude Code: redesign the pipeline

TL;DR

An AI SDLC is not the old pipeline with a coding assistant bolted on. Three stages change shape: specification becomes the expensive part, review becomes the bottleneck, and capacity planning moves from seats to tokens per minute. Redesign those three and the rest of the pipeline holds. Skip the review redesign and throughput gets worse, not better.

Which SDLC stages actually change?

Three stages change: specification, review and capacity planning. Implementation gets faster, which is the part everyone measures, and that speed is exactly what overloads the two stages on either side of it. Build, test and deploy are largely unaffected, because they were already automated.

The mechanism is simple. If implementation time drops by half and review capacity stays fixed, the queue in front of review doubles. Teams that report no productivity gain after rolling out Claude Code almost always have this shape: more pull requests, the same number of reviewers, longer lead time overall.

What each stage needs:

Stage	What changes	What to redesign
Specification	Becomes the binding constraint on output quality	Write acceptance criteria and verification targets into the ticket
Implementation	Faster, more parallel, more throwaway work	Nothing, this is the part that works
Review	Becomes the bottleneck	Split review into mechanical and judgement passes
Test	Mostly unchanged	Add tests Claude cannot see while writing the code
Capacity	Moves from seats to tokens per minute	Model organisation-level rate limits, not headcount
Cost reporting	Moves from licences to consumption	Per-user attribution in your own stack

Why is review the stage that decides the outcome?

Review decides the outcome because it is the only stage where a human still has to understand every line, and understanding does not get faster. The redesign that works is to split review into a mechanical pass that tooling owns and a judgement pass that a person owns, then fund the second properly.

The mechanical pass belongs in hooks and CI, not in a reviewer’s head. Anthropic documents a PreToolUse hook pattern for exactly this shape of work: instead of Claude reading a 10,000-line log to find errors, the hook greps for ERROR and returns only the matching lines, cutting context from tens of thousands of tokens to hundreds. The same pattern applies to review gates. Anything a script can check should fail before a person looks.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "~/.claude/hooks/filter-test-output.sh" }
        ]
      }
    ]
  }
}

The judgement pass needs two changes. First, give the reviewer the specification, not just the diff, because the question is whether the code does the agreed thing rather than whether it compiles. Second, require tests the model could not see while writing the implementation, because a model that writes both the code and its tests will make them agree.

Four rules we apply to generated code in review, in order of how much they catch:

1. Reject any change whose ticket has no verification target. The reviewer cannot judge correctness without one, and neither could the model.
2. Read the test for what it does not assert. Generated tests tend to cover the happy path thoroughly and the boundary not at all.
3. Check every external call for error handling, since this is where generated code is weakest.
4. Treat a large diff as a specification failure, not a review problem. Send it back to be split.

Our Claude Code security guide covers the permission and sandbox controls that bound what the implementation stage can touch in the first place.

What does the pipeline need beyond a laptop install?

A pipeline needs four things a laptop install does not: policy delivered centrally, per-user cost attribution, rate limits modelled at the organisation level, and a route that matches your data residency commitment. All four have concrete mechanisms, and three of them are easy to get wrong.

Policy delivered centrally. Managed settings are the delivery mechanism, through server-managed settings, an MDM policy, managed-settings.json or a policy helper. One setting is specifically worth deploying early: modelPricing makes every cost figure Claude Code shows a developer reflect your contracted rates rather than list price. It requires Claude Code v2.1.242 or later and changes what is reported, not what Anthropic charges. Without it, developers see list prices and your finance team sees contract prices, and nobody trusts either number.

Per-user cost attribution. This depends entirely on the route, and the trap is sharp. On Amazon Bedrock, Google Cloud and Microsoft Foundry, Claude Code does not send metrics back to Anthropic, so the Anthropic analytics dashboards and the Claude Code Analytics API do not cover that usage at all. OpenTelemetry export works on every setup and is the only option that streams per-user token and cost metrics into your own observability stack in near real time. If you are on a cloud route and expect Anthropic’s dashboards to show you anything, they will not. Our Claude Code telemetry guide sets out the OpenTelemetry metrics and how to ship them.

Rate limits at the organisation level. Rate limits apply per organisation, not per developer, and Anthropic’s recommended per-user allocations fall as the team grows, because concurrency does not scale linearly:

Team size	TPM per user	RPM per user
1 to 5 users	200k to 300k	5 to 7
5 to 20 users	100k to 150k	2.5 to 3.5
20 to 50 users	50k to 75k	1.25 to 1.75
50 to 100 users	25k to 35k	0.62 to 0.87
100 to 500 users	15k to 20k	0.37 to 0.47
500 or more users	10k to 15k	0.25 to 0.35

Anthropic’s own worked example: 200 users at 20,000 TPM each is 4 million total TPM. Request the capacity before the rollout, and request extra for training sessions, where concurrency spikes in a way normal work does not.

A route that matches the residency commitment. For organisations that must route inference through their own cloud provider, the Claude apps gateway is the supported pattern. It is a self-hosted single Linux binary in front of Bedrock, Claude Platform on AWS, Google Cloud or Microsoft Foundry, with SSO sign-in, per-group model access and OTLP telemetry carrying token counts, model, user identity and latency by default. Its requirements are specific: Claude Code v2.1.195 or later on both the server and every developer machine, an OIDC identity provider (SAML and LDAP are not supported), PostgreSQL 11 or later, and a hostname that resolves only to private addresses. Boot is fail-closed, so a bad config or an unreachable identity provider stops the gateway rather than degrading it.

One gateway limitation belongs in the pipeline design from day one: there is no service-token flow for unattended pipelines. Gateway sign-in always runs the browser device flow, so a CI job with no developer to approve it cannot authenticate. Configure CI against the cloud provider directly and keep the gateway settings off CI runners. Our LiteLLM EU gateway guide covers the alternative proxy route and what it does and does not give you.

What does the redesigned pipeline cost?

Budget three consumption lines: per-developer token spend, the cost of parallelism, and the review capacity you have to fund. The first two have published figures. The third is the one most plans leave out, and it is usually the largest.

Anthropic’s cost page reports around 13 USD per developer per active day and 150 to 250 USD per developer per month across enterprise deployments, staying below 30 USD per active day for 90 percent of users. For a 40-developer organisation that is roughly 72,000 to 120,000 USD per year.

Parallelism is where budgets break. Agent teams use approximately 7 times more tokens than standard sessions when teammates run in plan mode, because each teammate maintains its own context window and runs as a separate instance. They are disabled by default and need CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. Leave them off until a team has a reason, then watch the attribution.

The cost levers that actually move the number, in order:

Lever	Effect	Where it lives
Model choice	Sonnet versus Opus is a 2x difference on input and output	/model, subagent config, managed settings
Clearing between tasks	Avoids re-sending stale context on every request	/clear, developer habit
Prompt caching	Cache hits cost a fraction of base input	Automatic, but broken by changing tool definitions
Hooks that preprocess	Cuts tens of thousands of tokens to hundreds	PreToolUse hooks
Keeping CLAUDE.md small	It loads at session start regardless of relevance	Under 200 lines
Effort level	Thinking tokens bill as output	/effort, MAX_THINKING_TOKENS

Review capacity is the line to argue about. If implementation throughput rises and you fund no additional review, lead time gets worse. Our position: budget one additional reviewer day per week per five developers in the first quarter, then measure and adjust. That is our recommendation rather than a sourced benchmark, and it is cheaper than the alternative of discovering the queue in production.

For measurement, the analytics dashboard reports pull requests created in Code, weekly active members, adoption level and estimated time saved, with CSV export and a daily refresh. Pair it with /insights, which analyses up to 200 previously unseen local sessions per run and reports friction points such as misunderstood requests and buggy code rather than token counts. The friction report is the more useful input to a process redesign.

Run it yourself or outsource?

Run the redesign yourself. It touches your ticket format, your review culture and your definition of done, and none of that can be delivered from outside. Bring in help for the platform layer: gateway deployment, OpenTelemetry pipeline, rate limit modelling and managed settings rollout, which are specialist, finite and well documented.

What the work takes, as our estimate rather than a sourced benchmark:

Workstream	Effort	Owner
Managed settings design and rollout	5 to 10 days	Platform engineering
OpenTelemetry pipeline and dashboards	10 to 15 days	Observability team
Claude apps gateway deployment	10 to 20 days	Platform plus identity
Rate limit model and capacity request	2 days	Platform engineering
Ticket format and verification targets	5 days, then ongoing	Engineering management
Review redesign and reviewer training	10 days, then ongoing	Tech leads

Our view: the gateway is the single piece most worth outsourcing, because its requirements are precise, its failure modes are fail-closed, and a team doing it for the first time will spend a fortnight on identity provider configuration that a practised operator does in two days. The review redesign is the piece least worth outsourcing, because an external party cannot change how your tech leads review code.

What to demand from anyone selling an SDLC redesign:

1. A review redesign, not only a tooling rollout. A proposal with no review capacity line has not understood the problem.
2. Per-user attribution working on your actual route, verified, including the cloud-route gap in Anthropic’s own dashboards.
3. The capacity request filed and granted before the rollout, with the TPM arithmetic shown.
4. modelPricing deployed so developer-visible figures match your contract.
5. A documented CI authentication path that does not depend on the gateway.

Our Claude Code on Bedrock setup guide covers the EU residency route in detail, and Claude Code pricing for teams compares the billing routes.

For teams still choosing between two coding agents, Codex vs Claude Code: deployment and EU processing lists the verifiable differences.

FAQ

What is an AI SDLC?

An AI SDLC is a software development lifecycle redesigned around a coding agent rather than one that adds an assistant to an existing pipeline. In practice three stages change: specification carries more weight, review becomes the bottleneck, and capacity planning shifts from seats to tokens per minute at the organisation level.

What does Claude Code cost per developer in a pipeline?

Around 13 USD per developer per active day and 150 to 250 USD per developer per month across enterprise deployments, staying below 30 USD per active day for 90 percent of users. Agent teams change the picture sharply, using roughly 7 times more tokens than standard sessions when teammates run in plan mode.

Why does review become the bottleneck?

Because implementation speeds up and review does not. Understanding a diff still takes a person the same time it always did, so a fixed number of reviewers in front of a faster implementation stage produces a longer queue and worse lead time. Split review into a mechanical pass owned by hooks and CI and a judgement pass owned by a person.

Claude apps gateway vs an LLM gateway: which do we need?

Use the Claude apps gateway when you must route inference through your own cloud provider and want SSO sign-in, per-group model access and OTLP telemetry from a supported component. Use a general LLM gateway such as LiteLLM when you need one proxy across several model vendors. The Claude apps gateway has no service-token flow, so CI authenticates against the provider directly either way.

How do we get per-user cost reporting on Bedrock?

Through OpenTelemetry export, a Claude apps gateway, or an LLM gateway that tracks spend per key. On Bedrock, Google Cloud and Microsoft Foundry, Claude Code sends no metrics back to Anthropic, so the Anthropic analytics dashboards and the Claude Code Analytics API do not cover that usage.

What rate limits should we request?

Model them per user and multiply. Anthropic recommends 50,000 to 75,000 TPM per user for 20 to 50 users, falling to 15,000 to 20,000 for 100 to 500 users, because concurrency drops as teams grow. Their worked example is 200 users at 20,000 TPM each, or 4 million total TPM. Request extra capacity for training sessions.

Sources

1. Claude Code: Manage costs effectively (28 October 2026)
2. Claude Code: Claude apps gateway (28 October 2026)
3. Anthropic Support: Usage analytics for Team and Enterprise plans (28 October 2026)
4. Anthropic: Model and feature pricing (28 October 2026)
5. Anthropic Support: What is the Enterprise plan (28 October 2026)