Catching mistakes before a person has to

The client

Our own way of working, refined across our recent projects: a schools product of our own, a large retailer's back office, and the modernisation of a 13-year-old system.

The challenge

Developer time is the most expensive part of building software, and the costliest way to spend it is finding mistakes a machine could have found. With AI now doing much of the typing, the question is no longer how fast code can be written, but how few errors reach the person checking it. So at every stage, from writing the requirements to running the live system, we build automatic checks that catch problems first, and the developer only looks at what genuinely needs a human decision.

Every project is bespoke, so the process is too

There is no one-size-fits-all pipeline. A schools product handling children's data gets checks against education law and data-protection rules. A thirteen-year-old business system gets proof that nothing changed as it was modernised. A small website gets a lighter set. We choose the checks that pay for themselves on each project, and add more as the project grows.

Before any code is written

Every feature starts as a written specification with numbered acceptance criteria, each tracked from "designed" through to "proven by a test"
AI reviewers check draft specifications against the relevant rules and our design principles, so gaps are fixed on paper rather than in code
An AI agent researches each new request, asks numbered questions with a recommended answer for each, and sorts the work by risk before anyone starts
Larger or riskier changes get a written plan, and a person signs it off before any work begins

While the code is written

Several sets of automated code-quality rules run on every build, and the warnings that matter stop it
Around 130 "house rule" checks enforce what matters for a specific product, such as keeping each customer's data separate, keeping personal details out of the logs and protecting every AI prompt against manipulation
When the same kind of problem is flagged three times, it becomes a permanent automatic rule instead of something to remember to look for
AI agents work in their own separate copies of the code, so they never get in each other's way or a developer's

Before a change is accepted

Thousands of automated tests, from single calculations up to full journeys through the system in a real browser
Mutation testing, which deliberately plants bugs to prove the tests would catch them
Screen-by-screen visual comparisons, automated walks through the affected pages, and database changes tried on a scratch copy first
Independent AI reviews from several providers; when they disagree, that's the most useful signal of all
Fixes written test-first: a failing test proves the bug, then the fix makes it pass, so the same bug can't quietly return
Only then does the change reach a developer, and nothing goes live without their approval

Proving nothing changed

When we modernise a system, the old and new versions are compiled and compared, every page is screenshotted and compared, and the full test suite must pass on both. The conversion can be re-run from scratch at any time, so ongoing work never has to stop for it.

Accessibility, security and privacy

Pages scanned automatically against the WCAG 2.1 AA accessibility standard, plus keyboard-only checks that scanners miss
Security rules, checks for vulnerable components and scans for accidentally committed passwords as part of the normal test run
Checks that what can be exported about a person and what can be erased always cover the same data, as UK GDPR requires

Release and running

Deployments upload only what has changed. Health checks, error reporting and records of every background job show problems before users report them. Once a change is live, the AI agent checks the original request has really been met, and proposes closing it with the evidence.

The result

The developer's time goes on decisions, such as whether a feature is right for the people using it, not on hunting for mistakes a machine could find. On our schools product, a full review by around 25 AI reviewers working in parallel found 376 issues; after a week of test-first fixing, the same review found about 58, mostly minor. On the retailer's system, the team went from merging about 40 changes a month to more than 200.

Technical details

Schools product: .NET 10 with Blazor Server and MongoDB. xUnit, bUnit, NSubstitute, EphemeralMongo, Verify snapshot and FsCheck property tests; Playwright with axe-core in the browser; k6 for load; Stryker.NET mutation testing run incrementally (score up from 3.6% to over 70%). Seven Roslyn analyser packs (Roslynator, SonarAnalyzer, Meziantou, SecurityCodeScan, AsyncFixer, VS Threading, BannedApiAnalyzers) with 22 banned APIs; house rules as reflection and source-scanning tests; architecture boundary tests; gitleaks. Cross-model review rotates Claude with GPT and Gemini through a small in-house CLI, with a findings tracker that promotes recurring findings to rules.

Retailer: an event-driven orchestrator runs Claude Code per stage in its own git worktree; pull requests stay drafts until build, tests, view precompile, smoke tests, pixel diff, a browser walkthrough and a migration test on a scratch database pass, followed by a second-pass AI review loop. Modernisation: a VB.NET-to-C# harness decompiles both builds with ILSpy and diffs them, with page-by-page pixel comparison.