20 Years in the Trenches: From Banking Code to AI Agents

20 Years in the Trenches: From Banking Code to AI Agents

I started writing code in 2005. Not in a garage with a startup dream — in a bank, where "move fast" meant deploying quarterly and "break things" meant losing millions.

Twenty-one years later, I'm building AI agents that reason, plan, and execute autonomously. The journey between those two points wasn't a straight line. It was a series of controlled explosions.

The Banking Years (2005–2012)

Seven years in banking taught me one thing: systems that fail cost real money. Not theoretical money. Not VC money. Money that someone's pension depends on.

I learned to build for fault tolerance before it was trendy. Every line of code carried weight. Every deployment was a commitment. You don't unlearn that.

Banking gave me discipline. It also gave me a deep skepticism of anything labeled "revolutionary." I've seen too many "game-changing" architectures that couldn't survive a Monday morning traffic spike.

Humanitarian Tech (2012–2018)

Then I went where most engineers don't: humanitarian operations.

Imagine building systems where the users are field workers in disaster zones, connectivity is intermittent at best, and the data you process determines whether food reaches 10,000 people or 100,000.

This is where I learned about constraints as architecture. When your network drops every 30 minutes, you design differently. When your users speak five languages and have limited tech literacy, you simplify differently. When the stakes are measured in human lives, you QA differently.

Humanitarian tech taught me that the best technology is invisible. It works. It doesn't ask for attention. It just does its job while the real work happens.

eCommerce & Operations (2018–2022)

eCommerce seems simple until you're handling inventory across multiple warehouses, processing thousands of orders a day, and your payment integration fails at 2 AM on Black Friday.

This phase taught me operational thinking. Not just building software — building systems that run operations. The difference is enormous.

An engineer builds a feature. An operations-minded engineer builds a feature that degrades gracefully, reports its own failures, and doesn't wake anyone up at 3 AM unless it actually matters.

The AI Pivot (2022–Now)

When I saw what was happening with large language models, I didn't see a shiny new toy. I saw a force multiplier for everything I'd built over 17 years.

Banking discipline + humanitarian constraints + operational thinking = the perfect foundation for production AI.

Here's what most people get wrong about AI engineering: it's not about the model. It's about the system around the model.

Anyone can call an API and get a response. The hard part is:

• Grounding outputs in real data (RAG)
• Building agents that don't hallucinate themselves into oblivion
• Creating fallback chains when the model gets it wrong
• Observing, measuring, and improving — not just deploying and praying

That's what I do now. I build AI systems that work in production. Not demos. Not proof-of-concepts. Systems that handle real data, real users, and real consequences.

What 20 Years Actually Teaches You

Here's the thing nobody tells you about a long career: the domains change, the principles don't.

• Build for failure, not just success
• Constraints are design inputs, not obstacles
• If it can't degrade gracefully, it's not production-ready
• The best architecture is the one nobody notices

These principles hold whether you're processing bank transactions, coordinating disaster relief, or deploying AI agents.

What I'm Building Now

Today I'm focused on Cortex (YabashaOS) — an AI operating system that brings structure to agent workflows. Alongside that: FinTrack for financial intelligence, AutomotiveAI for the automotive sector, and Jopal for document management.

Twenty years of banking, humanitarian work, eCommerce, and operations — all converging into AI systems that actually ship.

If you're building AI and wondering why your demo works but your production system doesn't, maybe you need someone who's spent two decades learning that the hard way.

That's what I bring to the table. Not just AI knowledge. Systems thinking forged in the trenches.

---

What's the one principle from your career that carried you through every domain change? I'd genuinely like to know.