On this page
"We use AI to write code" tells you almost nothing about whether that makes a team more productive or just moves risk somewhere less visible. The difference comes down to the review rules wrapped around the tool, not the tool itself.
Where AI assistance actually helps
The clearest wins from AI-assisted coding show up in well-bounded, well-specified work: generating a first draft of a test suite from existing code, scaffolding a new API endpoint that follows an established pattern in the codebase, drafting documentation for a function whose behaviour is already settled, and summarising a large diff during code review so a human reviewer knows where to focus. In each case, a person is checking output against a concrete, verifiable standard — the tests pass, the documentation matches the actual function signature, the summary matches the actual diff.
Where it needs the tightest review
The riskiest use of AI-assisted coding is generating logic for cases that are hard to specify precisely — edge-case handling, concurrency, security-sensitive code paths (authentication, authorization, cryptography, input sanitisation). These are exactly the areas where a plausible-looking but subtly wrong suggestion is hardest to catch by eye, and where the cost of a wrong answer is highest. Our rule is simple: AI-generated code touching these areas gets the same review depth as if a junior engineer had written it for the first time — regardless of how confident the suggestion looks.
The three checks every AI-assisted change goes through
The same tests and scans as any other code. AI-generated code runs through the same automated test suite, static analysis, dependency scanning and security checks as code a person typed from scratch. It does not get a shortcut because a tool produced it.
A named engineer reviews and takes responsibility. Every AI-assisted pull request has a human reviewer who is accountable for it, exactly as they would be for a colleague's work. "The AI suggested it" is not a valid answer to "why does this code do that."
Provenance and licensing checks where relevant. For suggestions that could plausibly reproduce existing third-party code, we check for licensing conflicts before merging, using tools designed for that purpose rather than relying on visual inspection.
What we don't do
We do not let AI tools merge code, approve pull requests, or push directly to production branches. We do not enter client-confidential code or data into AI tools whose terms would allow that input to be used for training, unless the client has explicitly agreed to it in writing. And we do not use AI-generated test results as a substitute for exploratory testing by a person who understands what the system is actually supposed to do for its users.
The honest measure of whether it's working
The metric that matters is not "how much code did AI generate" — that number is easy to inflate and says nothing about quality. The metric we track is whether AI-assisted work passes review and testing at the same rate as work written without it, and whether the time engineers spend reviewing AI output is meaningfully less than the time they would have spent writing it themselves. When those two numbers hold up, the tool is earning its place. When they don't, using it faster just means finding the mistakes later.
Put it to work
AI-Powered Software Development