Build Everything

Claude is changing how I write software dramatically.

My biggest worry, as someone who's been writing software for a long time, is that I will be so blinded by my hard earned intuition on complexity that I will subconsciously be less ambitious than the moment calls for – that some treacherous part of my mind stubbornly knows it's too hard.

When I was 25 I thought it was a given that I would just never stop learning. Back then the risk, from what I could see of middle aged developers, was clownishly bungling your way into some obvious technological cul-de-sac. The intervening 15 years have tested it at times, but I had not considered that the raw intuition itself might end up the problem.

#Combinations and permutations

For the last few years, new companies were really the only time I got to try out new architectural patterns. They become concrete so quickly, and updating them becomes an exercise in changing the wheels on a moving car. Plus, there's always stuff that seems more important.

One of the slightly unintentional effects for me has been the ability to experiment with a variety different architecture and deployment patterns.

For a specific example, one of the projects I'm working on at the moment, rockstar.ninja (saving and sharing Claude Code sessions), has a macOS taskbar application. I've never written one of these before, and it's been my first experience working with Apple's notarization system.

The backend server and CLI are written in Go, so I've just been cross-compiling for Linux and deploying the system using rsync over SSH. This is not too far from how we used to deploy boards.ie in 2008. Even the git repo for this one is just on one of my home servers.

For another project, bewitch.dev (a terminal-based system monitor for Linux), I've gotten to build out the apt repo and multi-architecture build system that I always wanted to have when I started building command-line tools.

This blog itself is something of a continuous project. I started frontend development again in 2024 after our company pivoted, and my blog has been a way for me to explore the space without worrying too much about making mistakes. It started as a Next.js / Supabase project, quickly became an Astro-based project instead, and recently I've been replacing Astro entirely, as it was never quite the right fit.

#I can move through phases more quickly

Discovering what you're building as you're building it is par for the course in software development.

The essential element of all of this is that, thanks to LLMs, it's been possible to iterate rapidly. That rapidity has enabled these projects to reach a level of quality (build automation, tests, documentation) that would otherwise have been hugely time consuming to produce.

It is allowing me to start a variety of different projects, integrating architectural and agentic lessons from each one into each other, combining or discarding approaches and trialling new ones.

Certainly, it has sometimes enabled me to go off on ill-advised tangents, over-engineering some corner of the system before I quite understand it. That is not new though– the difference is that now the cost to correct those missteps has also reduced significantly.

#It's easier to be more ambitious

Being able to iterate faster and correct mistakes faster means I get to consider projects and possibilities that would have been out of reach before.

As a result, I am trying to build everything.

Everything I can think of, every project that has ever sat on the back burner. Any number of ideas for new software, features or fixes might pop into my head a day. If I reckon I have the spare usage to tackle them, they get tackled. I can't even tackle them all with LLMs, but I am sure starting to make a dent.

It's the only way I can think of, in 2026, to try and crack a hole in that calcified intuition and start finding out where the edges are again.