I like owning problems end to end.

I don't like stopping at the abstraction. If I'm using something — a framework, a system, a model — I want to understand it well enough that I could have built it myself. That's not a purity test, it's practical: you can't debug, extend, or trust something you don't actually understand.

That instinct is the thread through everything I've worked on. At an enterprise scale, it means understanding a system deeply enough to know exactly where a change is safe and where it isn't. At a startup, it means being comfortable owning a problem with no playbook, because someone has to figure out what "done" even looks like. Across client work, it means going deep enough into someone else's domain — healthcare compliance, fintech regulation — to build something that actually holds up.

More recently I've turned that same instinct toward AI. I use tools like Claude Code to move fast, but I treat them as leverage, not a replacement for understanding. I still work through the mechanics myself — training runs, architecture decisions, what actually happens inside the model — because that's the only way I trust what I've built.

I'm drawn to problems where the easy version isn't good enough. Where "mostly working" doesn't count, and the interesting part is making the whole thing actually hold together.