The recent honest data on AI-assisted coding is uncomfortable. Throughput goes up. Bug rates also go up — somewhere between 1.5× and 2×, depending on the study you trust, with the worst gap on security-relevant defects. The dominant industry pitch (“Cursor doubled my velocity”) and the dominant industry data (“Cursor doubled your bug rate too”) agree on more than people admit.
The mistake is to argue about whether the tradeoff is real. It’s real. The interesting question is: in your context, is it worth it?
When the trade is good
Three rough categories where the bug-rate hit is acceptable:
- Code that’s easy to test. Pure functions, well-typed pipelines, anything with a thick golden-data test. The agent can be sloppy because the test is the canary.
- Code with low blast radius. Internal scripts. CI scripts. One-off data wrangling. The cost of a defect is your hour, not your customer’s data.
- Code that’s about to be rewritten anyway. Prototypes. Throwaway POCs. Spike branches.
When the trade is bad
Three categories where it isn’t:
- Auth, billing, payments. Anything where a defect maps directly onto user money or user trust. The 1.7× bug-rate hit is not negotiable here. Slow down.
- Concurrency, distributed-system edges. The model is fluent at writing the happy path. It is bad at the race condition that hits 1 in 10,000 calls.
- Migrations and schema changes. A subtly wrong DDL costs you a recovery window. The agent will produce one that looks right.
What to do
Stop pitching AI-assisted coding as universally faster. It is conditionally faster, and the condition is that you have the test coverage, the review discipline, and the rollback path for the parts where it’s also buggier.
Then it’s a real tool. Without those, it’s a debt instrument.