I am a web developer. Fifteen years of CMS work, mostly WordPress, Drupal, and Sitecore, with the PHP and JavaScript that holds those together. Swift was never on that list. AppKit and SwiftUI were not either. And yet a good chunk of what I have built in the last year is native macOS software written in exactly those tools. The reason is Claude Code.
This page collects everything I have built and written about building with Claude Code in one place. If you want to know how I actually work with an AI coding tool, not the demo-day version but the real one with specs, dead ends, and the occasional self-inflicted disaster, this is the index for that.
How I actually use it
I do not treat Claude Code as a vending machine where you drop in a prompt and collect a finished app. I treat it as a collaborator that needs a clear brief and a tight feedback loop. Every project of any size starts with a project.md file: a written spec of what the thing needs to do, broken into features. I keep that file updated as the work moves, so Claude has the history and the current target in one place instead of relying on a conversation that scrolls away.
From there it is iteration. I describe a feature, review what comes back, run it, and report what actually happened. The clearer I am about the goal and the constraints, the better the output. That is not so different from briefing a junior developer, except the loop is measured in seconds and I am the one responsible for catching the mistakes before they ship. Knowing what good code looks like still matters. Claude writes faster than I can, but I am the one who decides whether what it wrote is right.
What this unlocked is reach. I had clear pictures in my head of small tools I wanted, things that did not exist in quite the shape I needed, and the only thing standing between me and them was a language I did not know. That barrier is mostly gone now. I can describe a native macOS app precisely enough, and between my judgment about how software should behave and Claude handling the Swift, the app gets built.
What this says about how I work
I think the way a developer adopts a tool like this says more than the tool does. I did not wait for permission or for the workflow to be perfect. I had a problem, I reached for the best available way to solve it, and I learned the workflow by doing it on real projects. When the official Claude Code VS Code extension had defaults that did not match how I work, I did not file a feature request and wait. I built a companion extension that patches it. When my shell startup was slow and Claude Code kept losing track of my Node version, I profiled it and fixed it. That instinct, find the route or build it, is the same one I have brought to every CMS migration and client problem in my career.
It also keeps me honest. Not everything here is a polished release. Some of it is proof of concept. And one of these write-ups is the night I let an LLM refactor my dotfiles without watching closely enough and booted straight into Recovery Mode. I left that one in on purpose. Working with these tools well means knowing exactly where they will hurt you, and the only way to learn that is to get hurt once and write it down.
Apps I have built
Real, working software built with Claude Code as the collaborator. Two of these are native macOS apps written in Swift, a language I do not know, driven entirely by a clear spec and a tight review loop.
-
Building The Daily Feed News Reader with Claude Code
The macOS News app gave me anxiety. So I built my own RSS reader in Swift, a language I don't know, using Claude Code. Here's how that went.
-
Building a macOS Image Viewer with Claude Code
I don't know Swift. I built a native macOS photo gallery with Claude Code anyway, and now I actually enjoy browsing my photo library.
-
Building a WordPress Exit Intent Popup Plugin with Claude
A proof of concept born from a request at Seismic, and my first real attempt at building a plugin with Claude as a collaborator.
Customizing the tooling
Using a tool heavily means sanding down the parts that do not fit. These are the times I changed Claude Code and its environment to match how I work instead of the other way around.
-
Patching the Claude Code VS Code Extension
The official Claude Code extension had five behaviors that added friction to my workflow. Rather than waiting, I built a companion extension that patches it in-place.
-
Speeding Up Zsh Startup: Fixing compinit, NVM, and Claude Code PATH Issues
My terminal was taking over a second to show a prompt. One profiling command later, the culprit was obvious: compinit running three times. Here is what I found, how I fixed it, and how I made Claude Code stop losing track of Node.
Lessons learned the hard way
The honest part. What happens when you hand an LLM too much trust and not enough supervision, and what I took away from it.
-
My Very Fun, Super Duper Evening
What happens when you let an LLM refactor your dotfiles without checking the output closely enough. Spoiler: you boot into Recovery Mode.
Want to get in touch? Connect on LinkedIn or send an email .