Number Six needed a website. Claude Code and I built three.

Update: After Dragon Con

I had a blast at Dragon Con.

The Number Six costume was as much fun as I’d hoped. People who recognized the character really recognized him. Several crossed crowded hotel lobbies to say hello, talk about The Prisoner, and ask for a picture.

The website was also a hit with people who found it. Some scanned the QR code on my button while we were talking. Others took a business card and looked at the site later. Once they were in, the browser apps gave them another way to play along.

Keeping the apps small paid off. They loaded reliably throughout the convention, even with thousands of people competing for cellular service and hotel Wi-Fi.

The best part was watching people use something Claude Code and I had built for this exact purpose. The site became part of the character and gave people another reason to join in.

I already have ideas for next year’s apps. I also have a new twist in mind: my other character costume may turn out to be Number Six in disguise. Apparently, escaping from the Village may require a change of wardrobe.

Be seeing you.


The expedition with my partner Claude continues, but this new project sent us on a side excursion into a virtual con twist, spy game apps, and one unusually persistent large white balloon.  If you haven’t been, Dragon Con is a fan convention that takes over downtown Atlanta every Labor Day weekend. It is a sprawling fan convention devoted to science fiction, fantasy, comics, gaming, and pop culture. Five hotels, tens of thousands of people, and a costume culture serious enough that some attendees plan for it the way others plan a 4 week vacation.

This year it runs September 3 through 7, and I’m going as Number Six from The Prisoner, the 1967 British series about a spy who resigns, wakes up in a cheerful seaside prison called the Village, and spends seventeen episodes refusing to explain himself. If you know the show, you know the blazer with the white piping. It’s an easy costume, and for once, being the old guy at the con fits in. You may also remember Rover, the giant white balloon that chases anyone who tries to leave. It’s less silly on screen than it sounds. Usually.

A simple costume alone didn’t feel like enough, so I built a little extension around a virtual spy app and game.  At the con, I’ll hand people a card designed to look like a Village document. It has a QR code pointing to the site, and I’ll wear a button with the same code for anyone who prefers to scan first and ask questions later.

continue reading

4 Things Claude Code Built for My Project That I Couldn’t Have Built

A split-flap is the flip board you’d find in an airport or train station, where each character sits on a rotor that clacks through the alphabet until it reaches the right letter. I’ve been building a software version and writing about it as I go: a Windows app that paints the board on a monitor or TV, plus a control app where you enter messages, connect data feeds, and schedule what appears.

You already know the setup if you’ve been following along. I’m not a developer. I know what the product should do, and Claude Code works out how to build it. By this third stretch of the project, the route had become familiar: I could describe the destination, and Claude Code would head into territory beyond my map. Four parts of the project made that especially clear.

I assumed this was the easy part. You spin some letters until they land. How hard can that be?

The animation turned into a physics problem

Rather than choose a rendering method based on a guess, Claude Code built what developers call a spike, a temporary test used to answer a technical question before committing to an approach. It created two working prototypes. One used Avalonia’s transform animation engine, while the other drew the flap geometry by hand on every frame. It then measured both versions on my machine at several scales.

continue reading

Claude Code Built the Software. I Still Had to Manage the Project.

When I last checked in, I’d handed a real software project over to Claude Code and kept the one job I’m actually qualified for: telling it what’s wrong. I can spec software all day. I just can’t write a line of code. I said I was amazed at how the whole thing was going. A few weeks later, I still am. I’ve also spent those weeks discovering every possible way an application can pass all of its tests and still be wrong.

It didn’t start with a one-paragraph prompt. It started with a package I’d built in ChatGPT first: a 40-page requirements spec plus architecture decisions, data schemas, test examples, development rules, and a milestone plan, close to 60 pages once you count everything. That is a lot of documentation for a little app that flips letters on a screen, which tells you something about the kind of person who volunteered for this. Claude took that and worked the project one phase at a time, writing code, running tests, reviewing what it had done, stopping to ask me for decisions, and fixing the things I ran into once I started using the application.

What came out of it is a working flip-board application in two parts. The Control App creates and schedules messages, pulls in sources like date & time, weather and stock quotes, and configures the board. The Display App reads those instructions and renders the animation. It’s built on C#, Avalonia, and SQLite, and it’s meant to run on both Windows and a Raspberry Pi. By now it has authentication, scheduling, content providers, diagnostics, backup and restore, secure API-key storage, and a stack of other administrative functions.

It works, though it isn’t finished. As previously noted, I’m not an engineer, but I’ve been around enough development projects to get myself into trouble. My job here was to define the product, test it, push back on decisions, and decide when something was good enough to accept. Some of that meant questioning an architecture choice. A lot more of it meant saying the text wasn’t centered, or the animation didn’t look mechanical enough.

continue reading

Enough to Be Dangerous: Getting a Project Ready for Claude Code Before Writing Any Code

I have never written production software. I have, however, spent years telling other people what’s wrong with theirs. So naturally, I decided to build an app.

Here’s my resume for the job. I know enough about requirements, product design, instructional design, and the ways software projects quietly fall apart to be genuinely dangerous, and nowhere near enough to be useful at a keyboard. That gap is where it gets interesting. I can tell you what a product should do, where the plan is thin, and which cheerful assumption is going to bite someone in month three. I cannot, on my own, build the thing and prove it works. I know just enough to get into trouble.

So I went looking for some, with ChatGPT and Claude Code as accomplices.

I wanted a project I actually found interesting, and one with nothing riding on it: not a product, not anything tied to my day job. Something fun to get my hands dirty with, where nobody would care if it never made a dime.

What I landed on was a digital split-flap display, the kind of mechanical arrival board that used to clatter away in train stations and airports. I’ve always wanted one. The physical versions cost about as much as a used car, which is a lot to pay for the pleasure of watching letters flip. So, not wanting to spend a lot of money on a novelty device, I decided to fake it and emulate the look and the movement of a flip board on a monitor or TV. The application needs to display messages, animate individual character tiles, manage content, support external data sources, and eventually run on both Windows and Raspberry Pi.

The idea was easy to explain. Turning it into a package an AI coding system could actually implement was the hard part, and where being dangerous started to matter.

I didn’t start by asking for code

My first real decision was to use ChatGPT for product definition and documentation before letting Claude Code write anything.

It’s tempting to describe an application in a paragraph, hand it to a coding model, and see what comes back. That’s fine for a small demo. It’s not a great way to build a tool with multiple applications, persistent data, authentication, configuration, API integrations, animation rules and rendering, installation requirements, and a roadmap.

continue reading