The interesting question is not whether AI can write code. It is which parts of the delivery process are expensive, repetitive and tolerant of a review step — because those are the parts where AI changes the economics today.
Figure 01 — where AI earns its place
Where it works well
Code archaeology
Understanding an unfamiliar subsystem is one of the largest hidden costs in software delivery. Retrieval over a repository, its history and its issue tracker turns “which of these six services owns invoice numbering” from a half-day of asking around into a query.
Low risk, because the output is a starting point that gets verified immediately by reading the code.
Test generation for existing behaviour
Generating characterisation tests for legacy code is close to an ideal use case. The correctness bar is “does this compile and describe current behaviour”, the feedback loop is a test run, and the alternative is that nobody writes the tests at all.
First-pass review
Not as a gate — as a filter. Null-handling, missing error paths, inconsistent naming, forgotten migration steps. It catches the mechanical class of issue, so human reviewers spend attention on design and domain correctness, which is where they are actually irreplaceable.
Incident context assembly
During an incident, minutes go into gathering context: recent deploys, related alerts, similar past incidents, which dashboards matter. Assembling that automatically shortens time to diagnosis without asking the model to make any decision.
Documentation that stays current
Changelogs, API reference updates, runbook drafts derived from actual configuration. Documentation decays because updating it is unrewarding work — precisely the profile that automation suits.
Figure 02 — the delivery loop AI actually touches
Where it goes wrong
- Volume without review. More generated code with the same review capacity means the bottleneck simply moves, and the throughput gain is imaginary.
- Architectural decisions. Models produce plausible, conventional architecture. Plausible and conventional is often wrong for your specific constraints, and the failure is invisible until much later.
- Anything security-sensitive without a specialist. Generated auth, crypto and permission logic is confidently structured and frequently subtly wrong.
- Unmeasured adoption. If you cannot say whether cycle time, defect rate or review latency changed, you have bought a feeling.
How to introduce it without disruption
Figure 03 — adopt on evidence, not enthusiasm
- Pick one measurable bottleneck. Review latency, or test coverage on a legacy module, or incident diagnosis time.
- Baseline it first. Two to four weeks of data before anything changes.
- Keep the human decision point. Draft-first workflows, with approval where consequences are real.
- Track cost per unit of work. Model spend is trivially easy to lose track of and belongs on the same page as the benefit.
- Re-measure, then decide. Expand what moved the number; drop what did not.
The uncomfortable part
AI amplifies whatever process it lands in. A team with clear ownership, good tests and fast feedback gets meaningfully faster. A team without those gets more code, produced faster, that nobody fully understands — and the resulting maintenance burden arrives about two quarters later.
Fix the process first. Then accelerate it.