AI-Native Building

Using AI to fundamentally change the build loop. Not building AI features — using AI as leverage to move from idea to proof faster than ever.

The through-line #

Before any of the companies on this page, there was Seventy-Nine Lines — my personal label for building and shipping software since the earliest days of the Apple ecosystem. Dashboard widgets on Mac OS X. One of the first iPhone apps distributed through Installer.app on iOS 1, before the App Store existed. PegJump and Dashbuster in the App Store on day one, July 2008. PegJump went on to millions of downloads, hit the top 3 in the App Store charts, and is still live today.

That thread — building things, shipping them, learning from what happens — has run underneath every job on this site. It’s the reason I went to Mellmo, the reason I could architect platform systems at ServiceNow, the reason I saw the surface expansion opportunity at Heap, and the reason I could operate as a founder at Starlifter. I’ve always been building on the side, and the side projects have always made the main work better.

The work #

Right now I’m deep in what I think is the most important shift since mobile: AI-native software development. Not “add an AI chatbot to your app.” The real change — using AI to compress the entire cycle from idea to prototype to proof to iteration.

I’m building actively. Multiple projects, fast iteration, real shipping. Using Claude, Cursor, and modern tooling not as novelties but as core infrastructure for how I work. The results are dramatic: work that used to take weeks happens in days. Ambiguity that used to require a team to resolve can be explored by one person with good judgment and the right tools.

What this looks like in practice #

I rebuilt my entire multi-site publishing infrastructure — Hugo sites, Vercel deployments, media pipelines, content migration from legacy platforms — in days, not weeks. Not because the work was trivial, but because AI-native workflows collapse the iteration loop. The bottleneck shifts from “can I build this?” to “should I build this?” — and that’s a question that favors experience over headcount.

I’m also building in public at Dabble or Die, where the work is visible. Not polished case studies after the fact — the actual messy, iterative process of building things and figuring out what works. Hardware projects, software projects, infrastructure, experiments. Proof that this isn’t theoretical.

Why it matters #

The leverage frontier moved. For the first time in my career, the bottleneck isn’t access to engineering capacity — it’s taste, judgment, and the ability to see connective tissue between opportunities. Those are exactly the things I’ve spent 15+ years developing.

Every platform shift I’ve worked through — the iPhone, the iPad, enterprise mobile, connected devices, and now AI — has the same shape. A new capability emerges, it changes the economics of building, and the people who see it early and build for it natively are the ones who create disproportionate value. I’ve been on the right side of that pattern four times now. I intend to be on the right side of this one too.

This isn’t nostalgia for coding. It’s a strategic response to a real shift. The people who will matter most in the next phase aren’t the ones managing teams of 50. They’re the ones who can see the wedge, move fast, and ship with high craft — amplified by AI. That’s the game I want to play.