The short answer
Typing was not the constraint on most teams. Deciding what to build, understanding existing code, reviewing changes and coordinating were. Assistance helps the first and third of those and can make review worse if volume rises.
Measure whether work reaches production faster, not whether more code is produced.
Where it genuinely helps
- Writing tests for code that has none
- Boilerplate and repetitive transformations
- Understanding unfamiliar code quickly
- Mechanical migrations across many files
- First drafts of documentation
- Explaining an error nobody has seen before
The first is the most valuable in most codebases. Test coverage is the thing teams know they should have and never prioritise, and this lowers the cost of it substantially.
Where it does not
| Task | Why it does not help much |
|---|---|
| Deciding what to build | Needs product context |
| Architecture decisions | Needs system and business knowledge |
| Debugging subtle production issues | Needs the surrounding context |
| Anything requiring your domain rules | Not in the training data |
| Judgement about acceptable risk | Not a code question |
Watch the review bottleneck
Producing more code faster moves the constraint to review. A team that doubles output and does not increase review capacity ends up with a queue, and the queue is where the delay now lives.
Measure lead time from starting work to it running in production. If that has not improved, the extra output is sitting somewhere rather than reaching users.
Quality rules that matter
- The person who submits the code is responsible for it, regardless of how it was written.
- Generated code goes through the same review as anything else.
- Never accept code you cannot explain.
- Check dependencies it introduces, including licences.
- Be careful what context you send to an external service.
The third is the one to hold firmly. Code that works and is not understood is a maintenance problem that arrives later and costs more than the time it saved.