I started my career as an intern in accounts payable at a large pharmaceutical company. I hated the work. Data entry, no thinking required. I excelled at it, but I was bored. So I started automating things.
It started with formulas in Excel. Then VBA macros. Then a SQL server. Then I taught myself Visual Basic one summer and built tools that eliminated my own job. Those tools became part of our controls — the processes the company relied on to operate correctly. Eventually, an audit flagged them. The response was basically: yeah, that kid in the corner cubicle did all of this. No one else knew how it worked. It was a huge operational risk.
So I worked with IT to rebuild my tools in the corporate-approved system. I could do that because I was the only one who understood what the tools actually did — not just the code, but the problem they were solving. That moved me into a different role.
Not because I could code. Because I understood.
Finding what others miss
At a large insurance company, after the 2008 financial collapse, we were looking for risk everywhere. We had all the pieces. We just weren’t putting them together.
We kept getting questions about our excess exposure — how much of our claims liability was above our deductibles. The answers existed in the data. We had our policies. We had our claims. But the two systems weren’t connected. When I put them together, I found the problem: policies were broken and not being followed. Claims that should have been captured for excess weren’t.
The company had already taken billions in reserve charges from adverse development on these excess lines. I built a process that matched what our third-party administrator reported as excess against what we actually had on our books — same client, same line of business, same loss. Where there should have been an excess claim but wasn’t, or where the numbers didn’t match, that was the gap. The reporting showed exactly where we continued to be at risk.
The data was there the whole time. The understanding wasn’t.
Building the environment
The pattern evolved again. Same problem, different scale. The company had all the pieces — acquired businesses, existing systems, new tools — but they weren’t connected. People were working in isolation, on their own systems, with their own processes. The technology wasn’t the blocker. The fragmentation was.
My job became building the environment where that fragmentation couldn’t survive. The right tools, the right systems, the right technology stack — so the company could operate as one system instead of many.
Sometimes that meant pushing an acquired company off their email system, not because I cared about email, but because staying on their own systems kept them isolated from ours. Sometimes it meant pushing back on a decision during a system rollout that felt right in the moment but was leading us away from the one-company model we were building. Sometimes it meant using a system upgrade as the moment to pull disconnected processes into alignment — not because the upgrade required it, but because the upgrade was when change was possible.
The building changed. The understanding stayed the same: find where the pieces aren’t connecting, and fix the environment so they can.
Directing instead of building
The technology changed. My role changed. The approach didn’t.
Now no one is building the tools — we direct AI agents that build them. I write this site, I manage my knowledge system, I prototype solutions — all through an AI that executes my direction. But the value is the same: understand the problem and the technology deeply enough to know when the AI is going off course and how to redirect it.
This site is the clearest example I have. I directed an AI agent to build it. When the layout was technically correct but the spacing felt wrong, I didn’t adjust the CSS myself — I described what was off and why, and had the agent fix it. When the article structure was clean but the thesis was buried, I redirected. The AI built. I directed. The same pattern I’ve been describing — just with a different builder.
The building got easier. The understanding got more important.
When anyone can generate a solution, the advantage shifts to the person who can evaluate it — who can see that the solution solves the wrong problem, or that the problem was defined incorrectly, or that the tool is optimizing for the wrong thing. Not the people who can code. Not the people who can prompt. The people who understand what technology can do, and what it needs to do.
What happens without it
The audit that flagged my tools wasn’t really about the tools. It was about what happens when understanding lives in one person and that person moves on. The tools were fine. The operational risk was that no one else understood the problem they were solving.
That’s the risk with AI, too. Not that the AI gets it wrong — that the person directing it can’t tell when it’s wrong. A technically correct solution to the wrong problem is worse than no solution at all, because it looks like progress.
Excel to VBA to SQL to AI agents. The tools have changed completely over twenty-five years. The approach hasn’t. Find the problem. Understand the technology deeply enough to direct the solution. The building changes. The understanding doesn’t.