Butterfly Brands revisited
I've revisited Butterfly Brands, one of my earliest pieces, using AI. The original turned familiar brand logos into butterfly wings. This time, I've reimagined them as lifelike pinned specimens.
I've revisited Butterfly Brands, one of my earliest pieces, using AI. The original turned familiar brand logos into butterfly wings. This time, I've reimagined them as lifelike pinned specimens.
Coding agents make it possible to do lots of work in parallel. I always have several (often many tens of) agents working at once, especially when working in Saggar. They might be working across many repositories, or in the same codebase. They write code, run the tests, and commit... then BAM!
I don't think the terminal is going to die.
I think it's finally going to become usable.
Nobody writes machine code anymore. For a good reason - it's inefficient to write. Luckily, we don't need to, because somebody already wrote it for us.
A lot of new AI coding tools are built around the same idea: start a thread, keep feeding it work, and let it run forever. You can see the assumption hardening into product features: Claude Code lets you name sessions, find and resume them by name, branch them, and export their transcripts. Cursor has editable chat titles, stored history, Markdown exports, and a way to pull old chats into the current one.
I gave a talk at Write The Docs London a few weeks back, to a room full of technical writers. The pitch: most people's relationship with AI stops at the chat box, and for docs work that's leaving a lot on the table.
Spec-driven development means treating a written specification as the source of truth: define the intended behavior first, then implement and validate the code against it.
I find the principle intuitive and exciting, but it has the same problem we've always had with documentation: drift.

used to be fairly extreme about separation of concerns in my React code. A smart component file for logic. A dumb component file for rendering. A styled-components file for styles. An index file to tie them together. Four files per component, minimum.
It made each individual file very readable. You could generally fit one on a screen. If you needed to understand the render logic, you opened one file. If you needed the business logic, you opened another. The mental overhead of jumping between co-located files was low.
In 1528, the Welser banking family of Augsburg struck a deal with Emperor Charles V: in exchange for debts the Emperor couldn't repay, they'd receive the Province of Venezuela to colonise and exploit. They called it Klein-Venedig, Little Venice. It lasted eighteen years, and it's one of the most instructive failures in colonial history.
Claude Code's skills system is genuinely impressive. You can package domain expertise, best practices, and specialised workflows into reusable modules that extend what Claude can do. The architecture is elegant. The potential is huge.
There's just one problem: Claude barely uses them.