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.
Getting the definition work done
I split the work into seven phases. Give a process person a fun side project and the fun side project quickly grows a process. At the end of each one, Claude had to stop for a formal review before I’d approve anything else. The reviews covered architecture, security, data, the interface, testing, and deployment. One turned up 11 findings. Another came back with five Priority items, seven Should-fix items, and six Nice-to-haves. Claude cleared the important ones and reran the tests before I signed off. The automated suite eventually passed more than 1,100 tests. And then I’d open the application and find something else.
That became the rhythm of the whole project. Claude built the phase, ran the tests, reviewed the architecture, and fixed whatever the review surfaced. Then I’d start using it and hit another problem.
The stock provider is a good example. It passed its own automated tests. The display renderer passed its tests too. But the prices never showed up on the board, because one step in the publishing path didn’t recognize the new provider type. Nothing was broken in any way the tests could see, which is a special kind of maddening.
A few of the defects were properly technical. An Avalonia threading bug crashed the Display App when a new message interrupted an animation at exactly the wrong moment. Most were more ordinary. The date-and-time provider proudly showed UTC instead of local time. Switching display profiles updated the database but left the board unchanged. And depending on how each app was launched, the Control App and Display App could end up reading from different data folders.
The one that got me was a weather provider you could enable without giving it a location. It would then fail every single time it tried to refresh, exactly as I had built it to. After spending far too long hunting for the empty field, long enough to reconsider a couple of life choices, I asked Claude, “That was a lot of work to find a simple user-entry error. How can we prevent this from happening again?”
It suggested validating provider settings the moment they’re saved or enabled, rather than waiting for a refresh to fail, and then it went and checked the other providers for the same gap. Finding what’s broken is the one thing I’m reliably good at, so I tried to aim it better. After that, I stopped asking only for the fix and started asking what rule, test, or design change would keep the same kind of problem from showing up somewhere else.
Some of the early decisions held up well, and I am claiming full credit for them. Keeping the Display App separate from the database and the content providers was one. When I added stock and market data later, Claude could feed it through the existing manifest instead of pulling the display apart and rebuilding it.
The requirements weren’t always right, though. One called for built-in display-profile presets. It sounded useful when I wrote it into the spec, but once it existed a preset did exactly what a custom profile already did, so I cut it instead of keeping it around just because it had been approved. A bigger change ran the other way: moving messages, queues, providers, themes, and other settings underneath each display profile. That one meant stopping, going back to the original structure, and rebuilding the parts it touched.
A few prompts changed how I worked with Claude
One of the more useful prompts I wrote had nothing to do with a feature: “Do we have any issues or bugs that might appear after the Display App has been running for hours or days, such as caches filling, counters growing, or background processes overlapping?” A developer would probably have asked that in half the words. Mine rambled, but it turned up four tables that were quietly growing and a timer that was overlapping itself, and both had already survived two formal architecture reviews.
So I followed it up: “Write the design, coding, and review instructions needed to prevent this class of problem elsewhere in the application. Add them to the appropriate project documents so future work is checked against them.” Claude added rules for data retention, pruning, timer overlap, and long-running processes to the development instructions and the review process.
I also learned that Claude will sometimes read a question as a signal to start coding. Ask “Can we do this?” and you might get changed code back when you only wanted to talk through an idea.
Two phrases became routine: “Do not do any work yet,” and “Do not make any updates yet.”
For anything large, I stopped letting a long planning conversation slide straight into implementation. I’d close the planning out with, “Do not make any updates yet. Create a work plan with logical checkpoints. Tell me whether the work should begin in a new session and, if so, give me the complete prompt needed to start it.” Then the next session could open with the decisions, constraints, checkpoints, and completion criteria already settled.
And when Claude handed me a few reasonable options, I’d make it commit: “Do not update anything yet. Which option would you recommend? Consider the user experience, supportability, future enhancements, benefits, and tradeoffs.” I still made the call, but Claude had to weigh the choices instead of leaving me a list to sort out.
What I’m taking from it
The project documents gave Claude boundaries, and they made it easier to see when the implementation had drifted from a decision we’d already made.
The reviews and the automated tests caught a lot of defects. They still didn’t save me from using the whole application, start to finish, myself. And when something did break, the more useful question usually wasn’t how to fix it. It was why the process let it through, and what had to change so it would get caught earlier next time.
The code has a habit of running ahead of everything else. The installer fell behind after a few development cycles, and the change log and known-limitations docs keep needing to catch up after a round of troubleshooting. Claude is good about flagging when a deliverable has gone stale, but someone still has to go rebuild or update it.
The application does what I set out to build, a fun and cheap flip-board display, and I’ve started poking at enhancements like color, emojis, and more animation. Claude is writing most of the software at this point. Keeping the product honest is still on me, which is roughly the amount of trouble I was hoping to get into. More to come.
