What an AI coding assistant actually costs a team
The seat price is the smallest number in the calculation. Review load, onboarding drag and the code nobody understands are where the real spend shows up.
By Jonas Lindqvist
Every engineering organization has now run the same experiment: buy a coding assistant, hand it to the team, and see what happens to velocity. The seat price makes it look like an easy decision — a few tens of dollars a month against a salary is a rounding error.
Then the second-order costs arrive, and they are not on the invoice.
Key takeaways
- Seat cost is typically under 5% of the total cost of adoption.
- Review load is the real expense: more code, produced faster, still needs a human to approve it.
- The teams that come out ahead changed their review process first, not their tooling.
The visible cost
Per-seat pricing for coding assistants has settled into a band of roughly $20–60 a month, with enterprise tiers adding audit logging, policy controls and a promise not to train on your code. For a team of thirty, that is somewhere between $7,000 and $22,000 a year.
Against fully-loaded engineering salaries, this is noise. If the tool delivers even a 2% productivity gain it has paid for itself several times over, which is the entire pitch and is not wrong.
The problem is that "productivity" is being measured at the wrong point in the pipeline.
Where the cost actually lands
Review load. An assistant increases the rate at which code is produced. It does not increase the rate at which code is reviewed, and review was already the bottleneck in most teams. The result is a queue that gets longer, reviewers who skim rather than read, and a slow decline in the quality of the approval — which is the control that was catching the problems.
This is the single largest cost and it is invisible on any dashboard that measures commits or pull requests.
Code nobody understands. Generated code that works is not the same as generated code that a team can maintain. Where an assistant produces something correct in an idiom the team does not use, the cost arrives eighteen months later when it needs changing and nobody knows why it was written that way.
Onboarding drag, in the opposite direction from expected. Assistants help experienced engineers most — they know what to ask for and can tell when the answer is wrong. Junior engineers get plausible code they cannot evaluate, and the learning that used to come from struggling through a problem does not happen. Several teams report this as their most consequential effect, and it takes a year to become visible.
What the successful adoptions did differently
The pattern among teams that got a real return is consistent, and it is not about the tool.
They fixed review before scaling usage. Smaller pull requests, enforced. A hard limit on the size of a reviewable change does more to preserve quality under increased output than any policy about where code came from.
They were explicit about where it is not used. Security-sensitive paths, anything touching money or authentication, and migrations. Not because the output is necessarily worse there, but because those are the places where a plausible-looking error is expensive and review fatigue is most dangerous.
They measured cycle time end to end, from first commit to deployed, rather than counting output. Teams that measure output see a large improvement. Teams that measure delivery frequently see nothing, because the work moved from writing into reviewing rather than disappearing.
They kept juniors writing code by hand for longer on the things they were still learning. This is unpopular and appears to slow people down. It is the difference between a team of engineers and a team of reviewers.
The honest arithmetic
For a thirty-person team, one plausible year:
| Line | Cost |
|---|---|
| Seats, enterprise tier | ~$18,000 |
| Additional review time (est. 2h/engineer/week) | ~$250,000 |
| Rework from insufficiently reviewed changes | Highly variable |
| Time saved on boilerplate, tests, scaffolding | Large, and real |
The last row is genuinely large — this is not an argument that assistants do not work. It is an argument that the second row exists, is roughly ten times the first, and appears in no vendor's ROI calculator.
Whether the fourth row exceeds the second is a real question with a real answer, and it depends almost entirely on how a team reviews.
The part that is genuinely settled
Three things are no longer in dispute:
- Boilerplate, tests and scaffolding are a clear win. Work that is tedious, well-specified and easily verified is exactly what these tools are good at.
- Unfamiliar languages and codebases benefit disproportionately. An engineer competent in one stack becomes useful in another far faster.
- They are poor at deciding what to build. Every serious failure reported involves a tool executing a bad plan quickly rather than producing bad code.
What to do about it
- Cap pull request size before increasing adoption, not after.
- Track cycle time to production, and treat output metrics as diagnostics rather than results.
- Name the paths where assistants are not used, and write it down.
- Protect junior engineers' hand-written practice on the fundamentals they are still acquiring.
- Budget review time as a real cost, because it is the largest one and it lands on your most experienced people.