The Tuesday morning train to Boston: the bug no specification warned me about

It was 2012, and I made a decision that looked a little wild on paper: I joined a consulting firm as a traveling consultant.

Up until then, my career had been cozy and predictable. I wrote Java code in familiar offices, took tickets from senior devs, and stayed inside safe boundaries. But I wanted more. I wanted shorter projects, faster cycles, and the chance to sit across the table from some of the sharpest engineers in the industry.

I got exactly what I asked for — along with a crash course in what it actually means to take full ownership of a system.

The old architect in Dayton

My very first flight landed in Dayton, Ohio. The job was to build a corporate intranet portal alongside another consultant.

That was where I met him: an Enterprise Architect who was nearing the end of his career, fiercely proud of his craft, and passionately obsessed with running the absolute latest version of IBM WebSphere Portal.

He didn't just give me tasks to check off. He pulled up a chair and walked me through why he designed things the way he did. We'd spend long evenings dissecting application server mechanics, arguing over technical trade-offs, and eventually chatting about life — trading stories about American habits and Indian culture over dinner.

He didn't just teach me portal configuration. He taught me to be relentlessly curious about what happens under the hood when code actually runs.

A 3-month-old baby and the Boston train

Then came the next call: a financial client in downtown Boston.

This project wasn't a team effort. I was the sole developer on the ground for a back-office application used to manage employee records — handling critical Insert, Update, and Delete operations for internal staff data.

The personal stakes were massive. Back home in St. Louis, I had left behind my three-month-old baby boy.

If you've ever boarded a Monday morning flight away from an infant, you know that specific, heavy ache in your chest. You are pulled in two directions at once — the fierce love for your child, and the quiet, stubborn drive to pursue the career dream you've worked so hard for.

I remember navigating the freezing Boston subway system alone, juggling pumping schedules in quiet corners, and walking straight into client boardrooms with cold hands and a determined mind. It made me tough. It made me outspoken (sometimes a little too direct, as my colleagues might tell you with a laugh!).

Technically, it was a trial by fire — my first time building a massive enterprise system in Spring from scratch. But the hardest part wasn't writing the code. It was navigating the people sitting in the room with me.

The collision: when "Delete" doesn't mean Delete

The Business Analyst wanted a simple, frictionless UI for back-office admins. When an admin clicked "Delete Employee," the record was supposed to disappear instantly so the screen looked clean.

The Enterprise Architect cared about audit trails, financial compliance, and legal retention. In his world, a financial application never permanently wipes a record from the database — it marks the record status as "Inactive" (a soft delete).

Neither of them talked directly to each other; they both talked through me.

I built the backend service to perform the soft delete: updating the employee status flag to "Inactive" in the database. I tested my code, verified the database updated cleanly, and felt pretty good about myself.

Then came UAT (User Acceptance Testing) week — and the storm hit.

During a live demo with client stakeholders, the Analyst clicked "Delete" on a test employee record. The screen refreshed... and the employee was still sitting right there at the top of the list, looking back at us.

Silence fell over the room. The Analyst turned to me, giving me the look: "The developer's delete button doesn't work."

My heart dropped into my stomach. I was thousands of miles from home, exhausted, and standing alone in front of client leadership. It would have been easy to get defensive, but I took a deep breath, opened my laptop, and pulled up the logs.

The bug wasn't a broken Spring bean or bad syntax. It was a classic clash of human assumptions.

The Architect had instructed me to update the record status to "Inactive." But the Analyst's UI search query was written as SELECT * FROM EMPLOYEES — without filtering out WHERE status != 'INACTIVE'.

The database had done exactly what the Architect wanted. But the UI had displayed exactly what the Analyst hadn't thought to exclude!

The Analyst thought I couldn't write a basic database update. The Architect thought the Analyst was trying to destroy compliant audit logs. And neither requirement document had ever bothered to spell out what "Delete" actually meant end-to-end.

I sat down with both of them in a small conference room. I didn't point fingers. I drew the data flow on the whiteboard, showed them where our English words had tripped us up, and proposed a simple fix: update the search queries to filter out inactive records while keeping the audit trail safe in the database.

We patched the service, deployed the update, and the demo passed cleanly the next morning.

Lessons learned: what AI can never beat

Looking back from 2026, I ask myself: what does a stressful afternoon in a Boston boardroom in 2012 have to do with the AI tools we use today?

Everything.

Today, if I type a prompt into an AI tool saying "Write a Spring service to delete an employee record," it will write a clean repository.deleteById(id) or a soft-delete update in three seconds. And it will ship that exact same disconnect.

Why? Because an AI only knows what you explicitly tell it to care about.

Here is what that Boston chapter taught me:

1. AI doesn't know your enterprise's unwritten rules. An AI model doesn't know if "Delete" in your specific bank means DELETE FROM table or SET active = false — unless a human who understands compliance tells it.
2. AI cannot reconcile human ambiguity. An AI tool cannot sit in a conference room, notice that an Analyst and an Architect mean two completely different things by the same word, and calm the room down when a demo stumbles.
3. Friction is where judgment is born. The instinct to step up under pressure, own a problem that wasn't strictly your fault, and bridge the gap between human business needs and system architecture isn't something you can prompt. It's a muscle you build by being in the fire.

The real breakthrough

When that consulting chapter ended, I moved on to my next company. In my interview, the hiring manager didn't just see a programmer who knew Java and Spring. He saw someone who had stood in front of clients, managed real-world pressure, and learned how to translate messy human expectations into resilient software.

That experience paved the direct path to my first official role as a Tech Lead.

AI can write our syntax now, and it does it brilliantly. But the courage to carry responsibility, the soft skills to navigate human misunderstandings, and the judgment to ask "What do we actually mean by this requirement?" — those are the human experiences AI will never beat.