AI Won't Kill Engineers. Bad Engineers Will Kill AI.

In 2023, we had an incident that cost Stripe roughly $340k in engineering hours, customer credits, and one genuinely embarrassing postmortem. The root cause wasn't a bad algorithm or a race condition. It was a senior engineer who copy-pasted Claude-generated Postgres migration code, skimmed it, and ran it on a table with 90 million rows. No lock timeout. No batching. Full table lock for 47 minutes. PagerDuty went off at 2am in six timezones.

The AI wrote syntactically perfect code. The human stopped thinking.

Here's the thing nobody wants to say out loud

AI coding tools are a massive IQ amplifier. That's the problem. If you were already good, you're now scary good. If you were mediocre, you now ship mediocre code 4x faster. If you were dangerous, you're a force multiplier for production fires.

We ran an internal analysis after that incident. Engineers who used Copilot and GitHub's code review suggestions without deeply understanding the underlying system had a 2.3x higher rate of P1 incidents in Q3 2023 compared to engineers who treated AI output as a first draft requiring real scrutiny. That number should terrify your VP of Engineering. It terrified ours.

The vibe coding trap

Don't do this: open Cursor, describe a feature in plain English, accept the diff, open a PR. I've seen this kill production. Not metaphorically. Actual downtime.

The issue is that LLMs are world-class at pattern matching and genuinely terrible at understanding YOUR system's invariants. GPT-4 doesn't know that your payment service has a soft dependency on a Redis key that gets set by a cron job that runs at 3am. It doesn't know your Kafka consumer group can't handle rebalancing during peak traffic. It doesn't know any of the 40,000 lines of tribal knowledge your team accumulated over five years of incidents.

It knows what code looks like. That's different from knowing what your code needs to do.

What's actually changing (and it's not what you think)

The skill gap is inverting. Fast.

For the last decade, the bottleneck was implementation speed. Could you write the code quickly enough? Now that's nearly solved. The new bottleneck is system understanding. Can you read AI-generated code and immediately spot the three assumptions it made that don't hold in your environment? Can you write a prompt precise enough that the output is actually correct? Can you review a 200-line diff in 8 minutes and catch the subtle bug on line 147?

That's a different skill. Most teams aren't training for it.

What I actually do now

I treat AI output the way I treated offshore code contributions in 2015. Assume good faith. Assume competence. Verify everything before it touches main.

Specifically: I use Claude for drafting, Copilot for autocomplete, and I've added a mandatory checklist to our Linear ticket template for any AI-assisted PR. Does this code understand our data model? Did the author test the failure path? Does this touch anything that talks to Stripe's payment processing pipeline?

Sounds slow. It's not. It's 30 seconds that's saved us from at least two incidents I can trace directly.

The engineers who'll win the next decade aren't the ones who use AI the most. They're the ones who know exactly when not to trust it.

Your job isn't to write code anymore. It's to be the last line of defense between an extremely confident language model and your production database.

Act like it.