Skip to content

How we use AI. Controls, not claims.

AI policyUpdated 9 November 2026

Full text

On this page · 8 sections

The short version

We use AI tools to build software. They sit inside a process that catches their mistakes: a written spec, small batches, automated tests and review of every change. Your technical lead is accountable for what ships, whichever tool helped write it.

We do not claim AI makes delivery faster. The evidence does not support that as a blanket claim, so you will not find it on this site or in a proposal.

Where we use AI

  • Drafting and refactoring code, inside a change small enough to review in full.
  • Drafting automated tests, which are then run and read like any other test.
  • Reading and summarising documentation and unfamiliar code.
  • Drafting documentation and handover notes, which are checked against the running system.

We do not use AI to decide what to build. The spec does that, and you sign it off in writing before any code is written. See how we work and the spec.

The controls

Each control below applies to AI-assisted work and to everything else.

  • A written spec first. The problem, scope and acceptance criteria exist on paper before a model is asked to write a line.
  • Small batches. Work moves in two-week sprints, and each change is kept small enough to read in full. Large generated changes are split or rejected.
  • Automated tests. Behaviour is pinned by automated end-to-end tests that run on every change. The tests are written from the spec, so generated code is checked against what you asked for, not against itself.
  • Review of every change. Nothing reaches your Friday link without review, whether or not an AI tool helped write it.
  • One accountable lead. Your technical lead answers for what ships. “The tool wrote it” is never an answer.

Client data

  • Credentials, API keys and production data never go into an AI tool.
  • Personal data does not go into prompts. Tests use synthetic data.
  • Your source code and documents go only into tools whose terms say they do not train on our inputs.
  • If your contract or security requirements rule out AI tools on your code, tell us before the spec is agreed. We switch them off for your project, and the spec records it.

How we handle your data more broadly is on the security and privacy page.

Output and ownership

Code written with AI tools is delivered under the same IP assignment as all other code, into repositories and cloud accounts you own from the first commit. See ownership.

AI features we build for you

Some projects put AI inside the product: language-model features, retrieval over your documents, automation. The same controls apply. The spec names the model providers and where your data goes, and you approve both before work starts.

What we do not claim

We make no speed claim, and the research is why. In 2024, DORA’s annual study estimated that each 25% rise in AI adoption was associated with a 1.5% fall in delivery throughput and a 7.2% fall in delivery stability (Google Cloud, 2024 DORA report).

In 2025, with about 5,000 respondents and 90% of them using AI, throughput had turned positive but delivery instability was still associated with AI use. The study’s conclusion is that AI is an amplifier of the strengths and weaknesses a team already has, and it names working in small batches among the capabilities that decide which one you get (Google, DORA 2025; InfoQ summary).

That is the reason for the controls above. A spec, small batches, tests and review are the practices the research points to. We publish them, not a promise of speed.

Review of this policy

This policy is dated and we update the date whenever its content changes. If you want to know how it applies to your project, contact us before the spec is agreed.