Two years ago the question was whether AI coding tools were worth using. That argument is over: they are, and almost every working engineer uses them. The interesting question now is narrower and more useful — which parts of delivery actually get faster, and what happens to the parts that do not?
Here is what we see across the lifecycle, and what we have changed in our own process as a result.
Where the gains are real
Understanding code you did not write
This is the biggest and least discussed win. Dropping an unfamiliar service into a model and asking what it does, where the entry points are and what looks risky turns a two-day archaeology exercise into an afternoon. For anyone inheriting a legacy estate — which is most modernisation work — this alone changes project economics.
The first draft of anything
Scaffolding, boilerplate, data-transformation glue, the fortieth CRUD endpoint, a migration script, a regex nobody wants to write. These are low-risk, high-volume tasks with obvious correctness criteria. AI drafts them in seconds and a senior engineer verifies them in minutes.
Tests
Generating test cases from an implementation is fast and genuinely useful — with one caveat we come back to below. Coverage of edge cases that a tired human would skip at 5pm on a Thursday goes up measurably.
Requirements and estimation
Feeding a specification into a model and asking it to list ambiguities, missing cases and contradictions is one of the cheapest quality interventions available. It finds the questions you should have asked the client before you quoted.
Where it quietly costs you
Review load moves, it does not disappear
If generation is ten times faster and review is not, review becomes the bottleneck — and a reviewer facing a large, plausible-looking diff reviews it less carefully than a small one. Teams that measure only "lines merged" look fast and accumulate defects. The honest metric is still cycle time to working, deployed software.
Tests written from the implementation
A test generated from the code tests what the code does, not what it should do. It will cheerfully lock in a bug as expected behaviour. Generated tests are good at coverage and bad at intent, which is why specification-level tests still need to be written by somebody who understands the requirement.
Confident wrong answers in unfamiliar territory
Model output is most dangerous exactly where your team is least able to check it: an unfamiliar framework, an obscure cloud service, a cryptography question. The risk is not that the answer is wrong; it is that it is wrong and fluent.
What has to change in the process
- Review becomes the governing constraint. Cap change sizes, require the author to explain what the change does in their own words, and fund review time as real work rather than something to fit around delivery.
- Separate intent from implementation. Write the specification-level tests first, by hand. Generate the rest.
- Keep humans at the decisions that reach furthest. Architecture, data modelling, security boundaries and anything touching money or personal data get human authorship and human sign-off.
- Measure the thing you actually want. Time to deployed, defect escape rate, change failure rate. Not tokens, not merged lines, not tool adoption.
- Write down the tool policy. Which tools, on which accounts, with training disabled, and which codebases are off-limits. Clients will ask, and the answer should already exist.
The honest summary
AI has not removed the need for senior engineers; it has raised the value of them. It produces a great deal of plausible code quickly, and the scarce skill is now judging that code — knowing which parts of a system deserve suspicion, which trade-off matters in six months, and when the fastest answer is the wrong one.
That is why we run every AI-assisted output through senior review before it ships, at every phase of the lifecycle rather than as a gate at the end. It is also why we have not reduced the seniority of our teams in response to AI, and do not plan to.
If you want to see what that looks like applied to a real backlog, our software development and AI development practices both run on this model.
