The code worked. I ran it locally. The unit tests passed. Claude wrote 80% of it and I wrote the rest. We reviewed it as a team. We shipped on a Friday afternoon.
By Friday evening, our error rate had tripled.
The feature
We were building a bulk price-update API for car listings. Dealers needed to update prices on 50â200 listings in a single request. The old flow required one API call per listing. Painful. We were fixing it.
I asked Claude to generate the bulk update logic. It produced clean, readable code with proper error handling. Each listing update wrapped in a transaction, errors collected and returned, successful updates committed. Exactly what I asked for.
What I didnât ask for â and didnât think to ask for â was what happens at scale.
What went wrong
The AI-generated code opened a database connection per listing in the loop.
for listing_id in listing_ids:
with db.transaction():
update_listing(listing_id, new_price)
For 50 listings: 50 connections opened, 50 transactions, 50 connections closed. Our connection pool had a ceiling of 20. At peak load, with multiple dealers running bulk updates simultaneously, we exhausted the pool in seconds.
The rest of the system â which shared that pool â started timing out. Authentication checks. Inventory reads. Everything.
Error rate tripled because the problem wasnât in bulk update at all. It was in every other API call that couldnât get a connection.
The feature that caused the outage didnât fail. Everything else did. This is the hardest class of production bug to anticipate â the feature looks fine, the blast radius is somewhere youâre not looking.
Why we missed it
The code was correct. It did exactly what was specified. Every listing updated, errors surfaced, rollbacks worked. If you reviewed it for functional correctness, it passed.
What we didnât review for:
- Connection pool behavior under concurrent load
- What happens when 10 dealers all run bulk update at the same time
- The second-order effects on shared infrastructure
AI doesnât model your production environment. It models the problem you described. Those are different things.
The fix
We rewrote to batch the updates into a single transaction with a single connection:
with db.transaction() as conn:
for listing_id in listing_ids:
update_listing_with_conn(conn, listing_id, new_price)
One connection. One transaction. Atomic across all listings. And we added a max_batch_size guard to reject requests over 100 listings with a clear error message.
What Iâd do differently
Iâd add âconnection pool implicationsâ to my AI code review checklist. And Iâd load test any feature that touches shared infrastructure before shipping â not after.
The AI wrote exactly what I asked for. I just didnât ask the right questions.
AI generates code that solves the stated problem. It doesnât model your production topology, your connection pool limits, or your concurrent load profile. That context is yours to bring â and yours to verify.