I build fast, solve problems, and lead engineers.
Right now I'm building Merge Lantern, risk intelligence that tells small teams which pull requests need senior eyes before they merge.
I'm an Engineering Manager and Technical Architect. I turn ambitious roadmaps into shipped reality, broken and bloated systems into modern marvels, and chaotic sprints into calm, dependable releases — all without losing the human part along the way.
13 years in and I still love this stuff...the hard problems, the good teams, the moment it all clicks. Poke around; the rest of the site fills in the details.
AI made coding faster, and the common advice now is to cut process everywhere so all that extra code can flow through. But some of those steps were catching risky changes before they reached users. Here are the three questions I ask to tell the process worth cutting from the process worth keeping.
When review depth follows risk, the high risk work falls on the same two or three seniors every week. Here are three ways to spread that load without lowering the bar.
When an agent helped write a pull request, the first question most reviewers ask is who wrote it. I think the better first question is what it touches. Here's how I'd set review depth by risk, where authorship still fits, and why some changes may need very little review at all.