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

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

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

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

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

AI Text-to-Speech Tools Advance at Breakneck Speed, Enhancing Training Development

It’s remarkable how rapidly AI-powered text-to-speech technology has advanced over the past six months.

The current level of technology is so advanced that it can produce spoken words from a written script that sound almost natural, making it difficult for some listeners to discern the difference. Some high-end models can accurately generate speech in numerous languages, while also allowing for the manipulation of attributes such as intonation, inflection, intensity, and pauses. My Chinese colleagues have even confirmed the quality of a Chinese-language training video I produced using a text-to-speech tool that doesn’t support attribute management. Moreover, it’s possible to combine multiple languages seamlessly within a single script, transitioning from spoken Chinese to spoken English and back again.

These tools will be game-changing for training developers who produce content in multiple languages, as a single text-based script can be written in one language, translated into other languages, and then rendered by the AI text-to-speech tool. Below are two samples I produced from the same script, one in English and the other in Chinese. (Note – these videos were produced as tests. They have not been cleaned up for actual rollout to learners.)

English Language Version:

English Language Test

Chinese Language Version:

Chinese Version Test

In addition to examining the specific tool utilized to generate these examples, I have also explored several other tools, such as Amazon Poly, Speechify, Descript, and Google Cloud Text to Speech.

continue Reading