Author: Jeff Stivers

Posted on

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
Posted on

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
Posted on

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
Posted on

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
Posted on

AI Voice-Over Tools Have Matured. The Workflow Still Matters.

When I first wrote about AI text-to-speech tools in early 2023, the technology was moving quickly enough to feel experimental from month to month. The core idea was simple: instructional designers and training teams could write a script, generate narration, and produce audio without booking studio time, hiring voice talent, or recording multiple takes.

AI voice-over is no longer just a stand-alone audio capability. It is becoming part of a broader training media workflow. The same platforms now help generate scripts, record screens, create captions, translate content, produce avatars, edit video, and package content for delivery. The question is no longer whether AI text-to-speech is good enough for internal training. Often, it is. The better question is how training teams should use these tools without creating a messy, expensive production process.

The most important lesson may be this: fewer tools are often better.

Training teams have always been tempted by tool sprawl. One application for script writing. Another for voice-over. Another for screen recording, editing, animation, or captions. Each tool may be useful on its own, but the total workflow can become harder to manage than the content itself.

Continue reading
Posted on

Good Training Starts with the Real Problem

When a new system or upgrade struggles to gain traction, one of the first things people say is, “We need more training.”

Sometimes they are right.   A team may need a clearer introduction to the system.  A new hire may need guided practice.  A manager may need better tools to coach the work.  A global rollout may need structured learning so people understand what is changing, why it matters, and how to use the system correctly.

But in many organizations, the request for training is also a signal.  It often means users are confused, support teams are hearing the same questions, managers are filling in gaps, or people are creating workarounds because the intended process is not clear enough.

In those cases, training may be part of the answer, but it is rarely the whole answer.   The better question is not simply, “What training do we need?” The better question is, “Where is adoption breaking down?”

This question changes the work.  It moves the discussion beyond courses and classes.  It brings workflow, product design, documentation, support readiness, manager communication, system usability, and knowledge access into the same conversation.  It also recognizes a reality many global organizations know well: people cannot adopt what they do not understand, cannot find, cannot trust, or cannot fit into the way they actually work.

continue reading
Posted on

Airline Pricing Introduction Video

Here’s an example of a training video I created using Vyond.

The video introduction: Have you ever wondered how airlines determine the prices of their flights? In this video, we look into the world of airline pricing and explore the various factors that influence fares. First, we look at the basics of airline pricing, including the different fare classes and the factors that determine their prices. We explain how airlines use complex strategies to calculate fares based on demand, competition, seasonality, and other factors.

continue reading
Posted on

Your Organization Already Has the Experts. They’re Just Not Teaching Yet.

When organizations struggle with training, they often start by looking outside the business. They look for a new learning platform, a new vendor, a new content library, or a new instructional approach to close the gap between what people are told to do and what they can actually do when the work gets complicated.

Formal training matters. Systems training matters. Job aids, videos, knowledge articles, onboarding paths, and structured curriculum all have a place. But after years of working in hospitality, travel technology, product environments, and learning organizations, I have become convinced a useful source of learning is already inside the operation.

It is the employee who has handled the same difficult guest situation dozens of times. It is the front desk manager who knows which system step causes new hires to stumble. It is the night auditor who understands not only what the checklist says, but why the sequence matters. It is the person everyone quietly goes to when the documentation is technically correct, but still not quite enough.

Organizations already have these experts. They just have not always built a practical way for those experts to teach.

Continue Reading