I like the parts nobody demos.

My favorite problems are where software meets something that won’t cooperate: a Bluetooth adapter that drops mid-session, a CAN bus that only talks in fragments, a spreadsheet export that changes its columns without telling anyone. That’s where the interesting engineering is, and it’s where most systems quietly break.

Case in point: my car. I drive a 2013 Genesis Coupe 2.0T, and off-the-shelf scanners won’t show the signals I actually care about. So I wrote ob2, a scan tool that talks to the car over a cheap Bluetooth OBD-II dongle, reassembles the multi-frame CAN messages, and decodes the Hyundai-specific readings for boost, oil temp, fuel trims, and misfires, streamed live to a browser. I built most of it against an emulator that throws the same failures real adapters do, so I wasn’t debugging in a parking lot.

I also run a small fleet of AI agents on a home server, on systemd timers. One reviews code for security issues, one researches dependency updates, and one watches production errors in Sentry and pushes my phone when something real breaks.

I write code every day, and more and more of that is directing agents rather than typing. I built a pipeline that takes a one-line brief, writes a plan, works it in an isolated git worktree, and hands back a branch for review. The model isn’t the hard part; the guardrails are: scoped permissions, checks that actually typecheck and build, and agents that never get near production data.

At work I lead a team of four developers. The short version is on the home page. The long version is better over coffee.