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.
The QR code is the primary delivery system. Scan it and your phone receives a Village security alert, which Number Six promptly hijacks. He gives you a passphrase and a call sign, tells you to commit both to memory, then deletes the transmission in front of you, complete with screen wipes. The passphrase is THE BICYCLE HAS NO CHAIN. (IYKYK) Your mission, should you accept it: find me at the con and introduce yourself with the passphrase.
There’s also a trivia game disguised as a spy assessment and a Whack-A-Rover game people can play on the convention floor or while waiting in line. You do a lot of waiting at Dragon Con. Attendees have a lot of free time.
The site behind the code turned into three small apps styled like an old school green-screen computer terminal. The Village message is the main event, and everyone who scans the code starts there: the alert, the Number 6 takeover, the passphrase, and the fake deletion.
Anyone who wants to remain in the Village a little longer can take the Village Aptitude Assessment, a trivia game dressed up as paperwork a Village clerk might use to evaluate a new arrival. It judges you on two scales, field aptitude and Village familiarity, assigns a rank for each, and closes with one mildly disapproving summary. Nobody gets a score. Everybody gets a designation. Each round pulls 12 questions from a pool of 160.
Then there’s Whack-a-Rover, an arcade game where you finally get to take a swing at the balloon that spent the whole series bouncing after Number Six. Only the message app is needed for the costume bit to work. The other two exist because apparently I don’t know when to stop.
Just a reminder, I’m not an engineer. Readers of the flip-board posts already know the arrangement: I bring requirements, testing, and opinions, and Claude Code writes the software. This time I want to talk less about whether the arrangement works, because so far it has, and more about what a week of it actually looks like. My project notes read like a sitcom with a QA department.
Small on purpose
We had a significant constraint – network and cellular bandwidth. Dragon Con puts approximately 70,000 people within a few city blocks most of whom are on their phones and laptops regularly. So, we created three very small apps that live their own single file and runs in phone’s browser, so there’s nothing to download from an app store. We wanted to stay under 25 kilobytes, smaller than almost any photo on your phone. There’s no tracking, no analytics, no cookies, no email collection, and no calling out to other services behind the scenes.
The pages also have to keep working when the internet doesn’t. Thousands of phones fighting over hotel Wi-Fi and cellular is not an unusual emergency at Dragon Con. It’s practically the daily weather forecast.
For technical readers, the code lives on GitHub and Cloudflare publishes it. Claude Code and I work on a password-protected staging copy, and the public site changes only when I deliberately release a new version. Before anything goes live, a few automated checks make sure the files are small enough and the privacy rules still hold. Claude calls it the best build and publish setup that keeps me out of trouble.
There’s no privacy policy on the site because the site collects nothing. Anyone curious enough can look inside the files and confirm it.
As of this week, the three apps weigh in at 19,372, 9,658, and 23,811 bytes, all under their 25,000-byte limits. The quiz includes 160 trivia questions I generated and fact-checked myself. We also built a browser-based editor for quiz questions. At this scale, every new question adds roughly 70 bytes. I know exactly how much the Dragon Con apps weigh and after every update and the architectural review, Claude Code reports to me the size of the apps.
The apps fit only because the publishing process removes the code comments inserted by Claude Code. Leave those comments in and the quiz alone balloons to 165 percent of the app size limit. The documentation outweighs the software, which I’ve decided is a compliment to Claude. Claude wanted to keep the comments in the dev environment because it reads and uses them. So, the comments are automatically stripped out when the apps are published to production.
The mistakes were part of the fun
The collaboration ran across forty-seven working sessions and 159 saved changes in the first eight days. Claude is a very fast, very capable coworker who occasionally needs to be sat down and spoken to. Claude keeps a file of those occasions.
We spent two days answering the question, “How much room is there on an iPhone screen?” Claude produced three confident, precise, and wrong answers, including an elaborate theory about Safari making everything 11 percent larger than Chrome. The actual cause was my desktop Chrome, which had been quietly sitting at 89 percent zoom.
The investigation ended when I asked what other developers do in this situation. The answer was: put the page on an actual phone and look at it. Claude then made a one-click way for me to open the site on my phone over home Wi-Fi without publishing to production. A few hours with the real phone settled what two days of theories hadn’t. Somewhere along the way, Safari was cleared of all charges.
One night we spent hours tuning two little animations of Rover. We adjusted bounce heights, exit timing, and every other detail you can obsess over when a menacing balloon is involved. The next day I asked for the same animation somewhere else, and Claude cheerfully built a new one from scratch. Twice. While the previously finished versions were sitting in a folder it had created but not checked.
My feedback was direct. There’s now a standing rule to search the parts bin before building anything new, and Claude has to name the file it plans to reuse before it starts or state that it needs to build a new component.
One noted mishap came from a full review of the Whack-a-Rover game. Claude reported one of the game’s safety limits could never be reached. The limit is the cap on how many Rovers can be on the board at the same time. In the game only one Rover can be on the board at a time. Its evidence was a note in the project documentation saying the limit had never been reached and never would be.
When we finally measured a real round instead of trusting the note, the limit kicked in during the last ten seconds of every game. The review was supposed to catch exactly this kind of mistake, and Claude had written a note it used to dismiss the problem. We fixed the defect and updated Claude’s game requirements and instructions. The witness and the suspect and the solver were the same AI.
Then there was the test that graded itself. I asked Claude to “check the whole quiz,” which was not my finest prompt. It checked one item, reported “1 run, 1 passed, 0 failed,” and stopped. The result looked reassuring until I noticed the other 159 questions had never been checked. We added a rule telling Claude to stop and question me when a request can be read more than one way. Will it help? We’ll see.
My job showed up in the middle of building
The instruction file Claude works from has become an interesting artifact. It has grown to about nine thousand words and may be the most honest lessons-learned document I’ve ever helped produce. (I understand, that the most recent recommendations about the Claude.md file says to limit its size. I’m starting a new project and will trying implementing that strategy.)
Every rule carries the story of the mistake that paid for it, including the date and, often, a direct quote of me being annoyed. Each one says when it applies, what Claude must do, and what proof it must provide afterward.
The pattern was familiar from twenty years of writing training and process documentation for people: rules asking for visible proof tend to get followed. Rules saying only “don’t do this” tend to get skipped. Turns out, Claude follows this pattern too.
The file is stricter than most process documents I’ve written for humans. Claude keeps track of how much material it has opened during a working session. When the pile grows too large to hold reliably, it stops, writes a handoff for the next session, and tells me it’s time to end a session and start a new on. Work beyond that point tends to produce confident numbers and code that can go off the rails.
A new test isn’t considered finished until Claude deliberately breaks the feature and confirms the test fails. The complete round of testing now opens the apps the way a visitor would and walks through 94 checks. The latest run passed all 94 test scripts.
Claude uses rules and instructions to sort the work into chores and craft. A higher-capability model handles the craft: writing the specifications, making key decisions, and defining the code requirements. Once the work is clearly laid out, a less costly but still capable model handles the routine implementation. Claude stops at each handoff, I switch models, and we continue. This saves tokens by reserving the higher-end model for work that needs it. (Recent studies have shown this may not be the best practice. But, from my experience, it seems to be saving tokens. I will continue to watch this.)
This part of the project feels familiar to me. I’ve spent my career writing training and process material meant to change how people work. Claude reads the manual at the start of every session and takes it literally, so vague instructions fail fast and good ones tend to stick. I’ve never had feedback on my requirements and instructions this quickly.
What I’m taking from it
I’ve written in earlier articles about how quickly a fun side project develops rules. This one now has size limits, release checks, and a real deadline – Dragon Con.
Claude keeps reminding me to generate the final QR code and send the cards to the printer. It’s right to nag. Once the cards are printed, no amount of clever code can fix bad information on a printed card.
If you’re at Dragon Con this September and a man in a piped blazer hands you a card, or you spot a QR code where a convention badge ought to be, scan it and play along. Come find me.
Be seeing you.