The bug that cost $0 and taught me everything AI never will

I walked into IBM India straight out of college, trained in Bangalore, and landed in Pune — in the Ozone building, one of those glassy IBM campuses that still felt slightly unreal to someone getting used to being called an employee instead of a student.

I didn't know yet what "corporate" even meant. I was still figuring out how to read a room in a meeting, how to ask a question without sounding like I didn't belong.

My first real assignment was supporting BSkyB's CRM application — mostly keeping things running, learning how a production system actually breathes. Then I got pulled onto something bigger: a portal migration for Sprint, built on IBM WebSphere and Apache Struts.

PASS in column G

Testing back then didn't look like CI pipelines or automated suites. "Unit testing" meant a massive Excel spreadsheet — hundreds of rows, each one a test case you walked through by hand, typing PASS in column G, then emailing the file to QA like a chain letter and waiting.

Working alongside a senior developer, my task was a "Change Password" portlet. Small feature, sensitive purpose — it was only meant to appear for specific customer account types. We wrote the code, wired up the Struts actions, and filled out our spreadsheet.

Every row said PASS. QA signed off. UAT signed off. Green lights everywhere.

Then we shipped it.

Release night

No crashes. No 500 errors flooding the logs. WebSphere hummed along fine, metrics all green — the kind of calm that makes you relax a little too early.

Then someone noticed: every logged-in customer, regardless of account type, could see the Change Password portlet on their screen.

We hadn't broken anything. We'd just forgotten to check who shouldn't see it.

Nobody had written a test case for "what happens when the wrong person looks." Not dev, not QA, not UAT — because it wasn't in anyone's spreadsheet, and because it wasn't a scenario anyone had thought to write down.

We patched it fast. No data was compromised, and no real damage was done. But sitting in that Pune office, barely a year into my career, watching a senior engineer calmly walk through what we'd missed — that stuck with me for good.

The code was correct. The thinking behind it wasn't.

Why this still matters when AI writes code

I hear a version of the same question a lot now: if a model can scaffold a backend service in thirty seconds, does experience even matter anymore?

Every time, I think about that portlet.

Give an AI a spec today and it will write you clean, syntactically perfect code. And it will ship the exact same bug we shipped back then — because it only knows what you told it to worry about.

It doesn't know that "certain account types" is doing a lot of quiet, dangerous work in that sentence unless you spell out which ones, and which ones must absolutely never see this screen.

Nobody prompts for the failure mode they haven't imagined yet.

If you're early in your career

Learning to generate code is the easy part now — genuinely, it's a commodity skill. What isn't a commodity is knowing how systems actually fail once real, messy humans start hitting them in ways nobody designed for.

That instinct doesn't come from a tutorial or a well-crafted prompt. It comes from being on call the night something you shipped breaks in a way no one predicted, and sitting with "why didn't we catch this" instead of just "how do we fix it."

I was barely a year in when I learned that lesson. Go get it on purpose — ask to be on call, ask what broke last quarter, and find out why.

If you're the senior dev in the room

A feature isn't done when it works for the happy path. It's done when it correctly refuses to do the thing in every case it shouldn't.

When something breaks in production, the useful question was never "who missed this?" — it's "what assumption did our design, our requirements, or our testing let slide through unquestioned?"

Harder conversation. But it's the only one that actually prevents the next incident.

Keeping sharp in the age of AI

A few things that have kept me sharp as AI tools got good enough to matter in my day-to-day:

• I use AI to write the boilerplate, and spend the time I save reading the diff line by line, not skimming it. Speed is worthless if you stop checking.
• I still ask "who is not supposed to be able to do this?" out loud in every design review, model-assisted or not. Two-second question, saved me more than once.
• I treat every AI-generated PR the way I'd treat one from a smart junior engineer I don't fully trust yet — fast, helpful, occasionally confidently wrong about something it had no way of knowing.
• I keep collecting production war stories, mine and other people's, because those are the training data no model has: the actual weird ways things break at 2 a.m. in a system with real traffic and real history.

Code generation is a commodity now. Judgment about what could go wrong, and the humility to keep asking "what am I not seeing," never will be.