How we use AI internally, and where we deliberately don’t.

• Scaffolding and boilerplate — adapters, DTOs, repetitive mapping code
• Test generation against an existing specification, then reviewed and pruned by hand
• Large mechanical migrations — framework upgrades, API renames across hundreds of files
• Documentation drafts and runbook first passes
• Reading unfamiliar legacy code quickly, as a guide rather than an authority

• Security-sensitive logic — authentication, authorisation, cryptography, payment flows
• Anything that is the actual novel difficulty of the project
• Architecture decisions, which need someone accountable in a year’s time
• Any context where client data would leave your tenancy

• Every change is reviewed by a named engineer who takes ownership of it. "The tool wrote it" is not a defence at review.
• The same CI gates apply: tests, coverage thresholds, security scan, performance budget.
• No client code or data is submitted to any service that trains on inputs. Enterprise tenancy with training disabled, in writing.
• Dependency suggestions are checked against our approved list — AI-suggested packages are a known supply-chain vector.

It shows up as scope delivered per increment, not as a line item. We are happy to show you the difference in throughput on comparable work, and equally happy to say that on the genuinely hard parts of a project it changes very little.