@duggan — ai

Build Everything

2026-03-14T15:35:26.000Z

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.

Changelog:

Mar 16, 2026, 9:31 PM — Correct tense.

Cognitive debt in AI coding

2026-02-15T10:25:18.000Z

Parachuting into an unfamiliar codebase, where the original author is long gone, is an experience that will be familiar to a lot of developers.

People writing with AI assistants have been encountering this in a new form.

Simon Willison wrote a brief post about it recently, concluding:

I no longer have a firm mental model of what they can do and how they work, which means each additional feature becomes harder to reason about, eventually leading me to lose the ability to make confident decisions about where to go next.

— Simon Willisonsimonwillison.net

Interestingly, this has been my experience in the large codebases of every company I've ever joined. Even with reasonably good documentation, it can be difficult to get to grips with any sufficiently large codebase – say, over a million lines.

This can also be true of smaller systems. If you're new to programming, you will be learning what works best as you go, and so your codebase will change as you learn. Even an experienced developer can make plenty of design mistakes in a domain they are unfamiliar with.

Working with large, successful systems are the circumstances under which code review skills are built. Something true in one part of the system may not hold in another. Experienced developers have their own methods to build understanding, like creating or adding to test suites, extracting microservices, and cultivating the patience, persistence, and humility to read the code.

What's new, though, is experienced developers needing these skills in their own personal projects.

Systems like Claude Code now have an integrated MEMORY.md that they can use for projects in order to persist comprehension across sessions. I am using it and CLAUDE.md religiously in order to build persistent knowledge of the system into each project – but it's early days.

Coding assistants are taking people from idea to working system much faster than before. They are reaching the points at which design and testing become valuable much more rapidly. Not only that, but it's also possible to turn many ideas that might have remained pleasant daydreams into reality, and dreams brought into reality can sometimes turn out to be nonsense.

This may even tie into at least some of the sense of burnout that people have been reporting. It can be comforting and intrinsically rewarding to tinker away on a codebase, but if you're building a business, or at least software for other people, code is just part of it.

It can be quite disheartening to realise that customers won't just appear out of thin air. Building for yourself is fun, but building for nobody is pointless. Claude Code isn't talking to your customers. It's not being thoughtful about the problem. It doesn't have a strong sense of aesthetics.

It doesn't know that what you don't build can be as important as what you do build.

All sorts of people, developers included, are finding out that coding is not software engineering, and that software projects are not startups. This is not new information, but it can take a long time for it to sink in. If people are able to get to that lesson faster, then it's a good thing.

There is currently no comments system. If you'd like to share an opinion either with me or about this post, please feel free to do so with me either via email (ross@duggan.ie) on Mastodon (@duggan@mastodon.ie) or even on Hacker News.

I built a terminal monitoring app and custom firmware for a desktop clock with Claude

2026-02-07T16:17:21.000Z

The way that I've used AI for coding has changed drastically over the last year.

In fact, the rate at which it is changing is probably the most drastic element of it – I can't recall any time since my first year of college, twenty years ago, that I've experienced such a rapid evolution in my own ability to do stuff.

This week I have written a fully self-contained system monitoring daemon and terminal UI, based on the Charm toolkit and using DuckDB. It archives metrics to parquet, shows ECC status, SMART health, temperature, sparklines, historical charts, and even has an alerts system.

bewitch comes in one colour: hot pink.

I am passingly familiar with Go, but this is a project that's been in the back of my head for a while, and would have been a monumental undertaking. It already works well enough, and I'm using it for a handful of servers.

Also this week, I built custom firmware to show Stripe subscription metrics for the Ulanzi TC001. I've linked to a good overview below if you're not familiar with it – basically a cheap and hackable desktop clock.

Blakadder’s Smarthome Shenanigans

Ulanzi Desktop Pixel Clock TC001 Review

As I was trawling AliExpress in search for a decent but cheap photography light I found Ulanzi, a Chinese brand specialized in making video and photography equipment. Browsing their product list something peculiar jumped out in the recommended tab. A desktop pixel clock targeted to YouTubers, the Ulanzi TC001, priced at 59.99$. After various sales and coupons the price dropped down to a very affordable 43$ and that made me click the buy button.

blakadder.com

This is the kind of project I have dreamed about putting together, but I've never found the time required to become familiar with firmware development outside of a few Arduino demos many years ago.

Most of these project ideas go to a list of ideas that I look at and go, "some day, if I have the time." – I rarely have the time. This blog was one such project, and I sat on it for ten years!

AWTRIX3 is the go-to firmware for customizing the Ulanzi TC001, but customization requires running a process on another machine and sending data over the network to the device. I wanted something I could bundle up and send to my other cofounders. So, again, I leaned on Claude Code to create custom firmware in Rust that communicates with the Stripe API, providing a subscriber count, MRR, and notification for new subscribers. It runs a wifi access point that you can connect to and configure, after which it connects to the wifi and communicates with Stripe via their API.

Ironically, given how long generative AI has been threatening art, I ended up having to do a lot of the actual pixel art for the device by hand. Precise pixel art is one area chat models remain mysteriously terrible at.

The Stripe subscription firmware shown here configured with a demo sandbox to test everything out.

I have never written a line of Rust, but I know it is a relatively unforgiving language, and the ESP32 is a less forgiving environment than most I've developed for, with 8MB of flash storage and something like 160KB of RAM.

These are two projects that would have remained on the back burner forever, requiring activation energy that I just don't have to spare. They were both written over the course of a few days, here and there, between other work, and recovering from a cold.

#A year ago

When I was writing the engine that powers this blog in December 2024, I would upload a few files at a time through the Claude or OpenAI web UIs, try to get them to reshape them into something that seemed close enough to what I wanted, and then iterate on that work myself.

This was slow, but the project of putting together a custom editor using Lexical was daunting enough that I would not have attempted it otherwise. At that point I had only about six months of modern frontend development experience and my reach exceeded my grasp^[1].

Then the startup I was working for ran out of runway, we shut down the company, I spent a couple of months learning Japanese, and then went bumming around Japan for a few months with my partner Ash.

Fast forward to August 2025, I'm starting a new company, and coding assistants are starting to generate a good bit of heat on Hacker News.

One of the first things I did after getting back was try to make some headway on my cofounder's MVP, and it seemed like a perfect opportunity to try out Claude Code. I had it write a few helper scripts, add logging, and act as a glorified find-replace in a few areas. For this tedious work it was quite useful, despite frequently giving up or failing the tasks.

I had it write the first draft of a feature that we needed, and iterated on it myself, getting Claude to throw in some fixes here and there.

Actually, it now reminds me of the accounts recorded by the engineers using the first computer being built at Princeton in the 1940s (from Turing's Cathedral, by George Dyson).

Essentially, the ENIAC often produced incorrect calculations, overheated and shut down during jobs, and was generally a hassle to work with. Despite all that, it was still better than doing it by hand, turning what would be months of human calculation into mere weeks of computer assisted work.

#December 2025

By December, I had written one major piece of functionality with Claude Code. Arguably I would have done a better job doing it by myself, maybe in a similar timeframe if I had been really dialled in and had no distractions.

All of my experience was with Sonnet at this point, and while it was useful and sometimes surprisingly good, it wasn't a huge accelerant. If pushed, I'd have said something like 1.5x, maybe. My €22/month usage plan was enough to help me write helper scripts and break ground on new features though, which was already worth it.

At the end of November though, Opus 4.5 had been released, and some time in December I decided to give it a try. It didn't seem massively different at first, but I was still working with it like it was Sonnet – giving it small tasks, writing scripts, etc. It absolutely burned usage though, and until Opus I had never run into a limit before my usage counter reset. I literally didn't even realise there was a limit.

It wasn't until I started asking it to implement features that I found it was making far fewer mistakes, and was in fact producing relatively good first passes.

In October I had begun adding Github Copilot to some pull requests, and it had found a few issues. This was great, even if it came with some mistakes and noise. When you're a team of one and a half developers, an extra set of eyes is absolutely worth the trouble.

Eventually the Co-authored-by: Copilot notes start showing up more frequently in the commit logs, and I found it useful enough to pay for the basic subscription once my free tier limits ran out.

By the end of December, I was hitting my Claude Code limits constantly. I started using "extra usage" which lets you spend a little more to get to the end of whatever was being worked on when the included limits were reached.

I experimented with using GPT-5 and Opus via the Copilot extension included with VSCode. Once I run through the limits there, I start going through extra usage on that.

The point at which Copilot started being very useful.

Using Copilot, I built the first application that I have not read line-by-line, a VAT invoice generator. I needed to generate mock invoices to do some basic interactive testing of the OCR flow for Manano. As long as it generated something that looked plausible, it was fine, but I found that with GPT-5 doing the bulk of the actual coding, I was able to freewheel on ideas about design and local-first software.

I wanted it to be like Tiddlywiki, where it could be used as a file on the desktop as easily as something at a URL. I wanted it to be WYSIWYG rather than a set of dull forms to fill out. And having a bunch of visually distinctive templates to make sure a variety of visual styles would work.

#Christmas break, structured prompts

Over the Christmas period, while Ash was visiting her family, I had the opportunity to get stuck into the feature idea backlog for my blog. This felt like a good testing ground for the coding assistants, as it was a bit cobbled together, had gone through a few architectural lurches, but I had written enough of the codebase myself to evaluate the results.

Also, being a blog, the stakes were low. Every time I'd have some idea for the blog I'd jot it down in Apple Notes. Here was what I had built up:

duggan.ie features/bugs

Saving/updating published posts
When a post has been published, any subsequent updates should include an optional reason for the update.
If a post is published, hitting save or using the save shortcut (Cmd+S) should pop up a dialog with a textbox to describe the reason for the change. This should be plaintext only, no special formatting.
It should still be possible to change without including a reason. In that case, the update should not change the updated_at marker.
The “save” target should move to the dialog box, so that hitting Cmd+S again will save the post.

Changelog
Include the post updates in published posts.
It should be implemented as a collapsed summary + details element at the bottom of the post.
It should also be included in the Atom feed.

Feedback system for shared drafts

Goal: Create a feedback system for shared links.
Context:
Shared links are designed to be shared with a single person. The URLs are deliberately obfuscated and they have configurable expiry, after which they return 404.
The editor is built using Lexical, and stores the lexical node data in the post_revisions table, with a posts table to hold the rendered html and reference to the currently fresh post_revisions record.

Implementation details:
Implement the feedback system as a Lexical plugin.
The shared links can use a Lexical editor with our feedback system plugin.
Other than using the feedback system, the shared link editor should be read-only – the user should just be making notes, not editing the text directly.
Each shared link will likely need to make a copy of the main editor node data on creation.

Open questions:
How best to handle when the main editor updates the post data. Should the shared links be updated? Should the user get a note/bar at the top of the screen saying something like “the author has updated the draft, would you like to refresh?” etc.

Opengraph integration for links
When pasting a link into the editor, it should give me the option to include it as nicely formatted block with OpenGraph data (image, title, content, etc) like Notion.

Video/image loading skeleton
Context: images and videos can be dragged and dropped into the editor, and are displayed inline.
Goal: While the images are uploading, there should be a loading skeleton in place to show that it is being processed.

Enhanced video/image resizing controls
Context: image and video resizing in the editor is very basic
Goal: enhance the resize functionality so that arbitrary resizing is supported.
Additional support: helpful resize controls, like “original”, “full width”, etc., should be included

Light / Dark mode
Initial change to light mode seems to result in a white screen
Continue button flashes when changing, sometimes on loadMake tags distinctive

Tag management area
Include emoji / stickers / SVG images as part of the tags
Should be able to specify a colour for each tag using a colour wheel, etc.
V2
More comprehensive emoji selector (with keyword search)

Post list
Add a new post status: archived
The post list navigation should be broken out by published vs draft vs archived in the left navigation.

It was quite a decent chunk of work in my book.

These notes were originally just for my own reference, but you'll notice that at some point I started editing the notes with a basic structure for Claude Code that I felt was clearer.

I thought I'd make good headway on a few of them, but over the Christmas break I steamrolled every one of them, iterated on a few, and even added some extras once I ran out.

I started out just about coming up short on Claude limits, having to wait 30 minutes or so before starting again. But by the end of this process I was smashing through those limits really quickly, and had to start getting more targeted and careful about what I wanted to work on.

Eventually though, I was paying extra usage on both Copilot and Claude Code, still cheaper than springing for a higher usage plan, but chafing at the limits.

#The Yegge Inflection Point

This month, I finally sprung for Claude Code Max – though only 5x, not yet the 20x. It's just too powerful an upgrade on my capabilities as a developer to pass up. Other people can wait to see where it goes and look back on this period with sagacity and the wisdom of hindsight.

I am still using Claude Code interactively in VSCode, I haven't gotten to the stage where I never read the code that's being produced, though maybe I'll get there, too. Steve Yegge is there with a few other people, and they are probably living in a version of the future, but it's not the only version of the future.

There are lots of different kinds of software. Not all of it will be amenable to this style of development.

For a 20 year old aspiring software developer in college, I have no idea how they are going to get to their version of mastery^[2]. I suspect it will be very different to mine, and will take a very different route. I think it will be daunting, but I hope exciting. Nobody starts off knowing how everything works.

For me, it's exciting. If at the end of the day all I end up with is a bunch of completed side projects, it will have been money well spent.

Changelog:

Feb 8, 2026, 11:21 PM — Fixed formatting in notes.

Notes:

...to paraphrase Robert Browning.
For want of a slightly less pretentious term. Basically I just mean skilled and experienced enough to be useful at their craft. Being able to dive deep, take responsibility, adapt and learn on the fly.