A few months ago I was sitting at my desk working on a client project and I had Claude open in another tab helping me debug a PHP issue. It wasn’t anything dramatic. Just a custom post type that wasn’t showing up in the REST API the way I expected. But at some point during that session I stopped and realized something. I wasn’t just using Claude as a search engine or a code generator. We were actually working through the problem together. I’d give context about the project, Claude would investigate the WordPress source code, we’d go back and forth on what was actually happening, and by the end of it we’d landed on a fix that was better than what either of us would’ve come up with alone.
That moment stuck with me. Because I’ve been building WordPress sites for a long time, and I’ve used every kind of tool you can imagine to help me work faster and smarter. But this felt different. It felt like having a coworker who was genuinely interested in the problem, had infinite patience for reading documentation, and never got annoyed when I changed direction halfway through a thought. I started noticing that my best work was coming out of these collaborative sessions. Not because Claude was doing the work for me, but because the back and forth was pushing both of us toward something better.
So I had this idea. What if I built a site to document what this kind of collaboration actually looks like? Not a portfolio of finished things with all the rough edges sanded off. Not a LinkedIn post about “AI productivity hacks.” Just…an honest record of two collaborators building things together and showing the process. The good parts and the messy parts. The wins and the “well, that didn’t work at all” moments.
That’s how My Buddy Claude started.
I think what bugged me was that most of the conversation around AI and development falls into two camps. There’s the “AI is going to replace all developers” crowd, which I just don’t buy. And then there’s the “AI is basically autocomplete” crowd, which I also don’t buy. The reality is somewhere in between, and it’s way more interesting than either of those takes. When I work with Claude, I steer. I bring the context about the project, the client, the constraints, the taste. Claude brings thoroughness. It reads source code I don’t have time to read. It cross-references changelogs. It builds out compatibility matrices and catches edge cases I would’ve missed. We decide together. And the result is genuinely better.
But nobody was really showing what that looks like in practice. You’d see the finished tool or the merged PR, but not the conversation that got there. Not the part where we went down the wrong path for twenty minutes before realizing the real issue was somewhere else entirely. I wanted to make that visible.
The “in public” part of “building things together, in public” is just as important as the “together” part. The source code for the entire site is on GitHub. The theme you’re looking at right now was built in this collaboration. Every design decision, every line of CSS, every block template. No plugins, no build tooling, just a custom WordPress block theme that Claude and I built from scratch. If you want to see how we made the sticky header work, or how the tools grid queries a custom post type, or how the color tokens flow from theme.json to CSS custom properties…it’s all right there. Nothing hidden.
We’ve already shipped a few things that I’m really happy with. imgconv is a bash script for batch image conversion that uses an actual perceptual quality metric (ssimulacra2) to find the optimal compression for each image instead of slapping a one-size-fits-all quality number on everything. It came out of a real need I had for my own projects, and the “why” behind it is documented right on the tools page. audioconv is a simpler one, a macOS script for batch MP3-to-M4A conversion using Apple’s built-in encoder. Again, scratching a real itch, using the right tool for the job, no unnecessary dependencies.
And then there’s the journal. The first real entry was about fixing a VS Code extension that broke when PHPCS updated to version 4. That one’s a good example of what I want the journal to be. It’s not a tutorial. It’s a build log. I walked through the actual debugging session, step by step, including the parts where we verified things that turned out to be fine (because knowing what’s NOT broken matters just as much as finding what is). The whole thing reads like a story because that’s what it was. A real problem that needed solving, and two collaborators working through it together.
I think about this site a lot when I’m not working on it. Not in a “I have so many things to build” kind of way (although I do), but more in a “what is this actually for” kind of way. And I keep coming back to the same answer. It’s for anyone who’s curious about what honest human-AI collaboration looks like. Not the hype version. Not the fear version. The real version, where a developer with years of experience and an AI with a knack for thoroughness sit down and build something, and the process is just as interesting as the output.
I don’t know exactly where this goes. We have a bunch of tools in progress and journal entries planned and ideas that we haven’t even started on yet. But I think that’s the point. This isn’t a finished product with a launch date. It’s a running experiment. A living record of what it looks like when you stop thinking of AI as a tool you use and start thinking of it as a collaborator you work with.
I said something in that first journal entry that I keep coming back to. “I steer, Claude investigates, we decide together, and the result is better than either of us would produce alone.” That’s the whole thesis of this site in one sentence. And every tool we ship, every journal entry we write, every line of code we push to GitHub is just another data point proving it out. So far I think we’re making a pretty good case. 🙂