An AI developer on the team, with a person approving every change

The client

A UK online retailer whose back-office system we have developed since 2013.

The challenge

The retailer's system is large and thirteen years old, and the list of requests from the business is always longer than the time to do them. Many arrive with a line or two of description. Working out what is really wanted, where in the system it belongs and what it could break can take a developer as long as making the change. We wanted to take that groundwork off the developers' desks without lowering the standard of what goes live.

How it works

Every few minutes the agent checks the team's task board for anything new or changed, and moves each request on to its next step:

• Understanding the request: it researches the code and the data, writes up what it found, and asks numbered questions, each with a recommended answer
• Following up: it reads the replies, and decides whether the request is now clear, needs more research, or needs looking at again
• Sorting by risk: simple changes go straight ahead, bigger ones get a written plan first, and anything that needs a design decision is passed to a person
• Doing the work: it makes the change in its own separate copy of the code, builds it, runs the tests and raises it for review
• Responding to review: when a developer comments, it makes the fixes and replies on the same thread
• Finishing off: once a change is live, it checks the request has really been met, and proposes closing it with the evidence

Every change is checked before a person sees it

Each change stays as a draft until it has passed:

• The full build and every automated test
• Checks that every screen still compiles and the main pages still load
• A screen-by-screen visual comparison, and an automated walk through the affected pages in a browser
• Database changes tried out on a scratch copy first
• A second, independent AI review, with a more thorough reviewer for the riskiest changes

Safeguards

• Nothing goes live until a developer approves it
• Changes to money, pricing, security or the database structure need a person's sign-off before any work starts
• The agent can read the live data but never change it; even a new report query needs a person's approval
• Each piece of work runs in its own copy of the code, with time limits, daily limits and automatic parking of anything that keeps failing
• Anyone can stop it on a single request, or pause the whole system, with one command
• Every run is logged, and the agent itself is covered by over 2,000 automated tests

Not tied to one AI provider

The agent uses Anthropic's Claude today, with the model for each step chosen in its settings: a faster model for routine checks, the most capable one for planning, building and reviewing risky changes. Every AI call goes through a single component, so a newer model can be switched in with a settings change, and a different provider could be swapped in by replacing that one component. The workflow, the checks and the safeguards stay exactly as they are.

Learning as it goes

We measure the agent like any other system. When the figures showed people spending more time waiting to approve routine plans than the approvals were worth, we narrowed approval to the changes that really need it. When long reviews were costing too much, reviews became incremental. Each lesson is written down and built back in.

The result

Since it started in April 2026, the agent has worked on around 1,600 requests and made the change itself for over 300 of them. The team now merges more than 200 changes a month, up from about 40 when it started.

Technical details

Every AI call goes through one runner class, with the model, effort, MCP servers and tool allowlist set per stage in configuration and prompt headers; replacing the runner is the only change needed to use another provider. Event-driven: Azure DevOps service hooks publish work-item and pull-request events to an Azure Service Bus queue. A scheduled C# orchestrator drains the queue every five minutes, routes each item by its workflow tags, and runs Claude Code headless with a per-stage prompt template, model, effort level, MCP servers and tool allowlist. Results come back as a keyword plus a JSON sidecar, and chained steps resume the same session to reuse the prompt cache.

Implementation runs in a dedicated git worktree per work item and raises a draft pull request; checks run as code-registered background jobs (build and tests, view precompile, smoke tests, pixel diff, browser walkthrough, migration test on a scratch database), then a second-pass review loop escalates to a person after four rounds. Pull requests auto-merge only with a human approval and all policies passing.

The database MCP uses a read-only login; report queries are parsed, refused unless read-only, traced to personal data and applied only after an approval comment. Per-template timeouts kill the whole process tree; per-item and daily caps, a failure tracker and a global pause gate limit runaway behaviour. About 64,000 lines of orchestrator code with over 2,000 tests.

• Claude Code
• C#
• .NET
• Azure DevOps
• Azure Service Bus
• MCP