I have a bad habit. I get excited about an idea, and it's half built before I stop to ask whether I'm building it right. Sometimes that works out. This is a post about a time it didn't, and the process I built afterward so it would happen a little less often.
The idea, for the record, was a multiplayer Songsterr: a guitar tab that scrolls in lockstep with a shared transport, so five people in five different rooms can follow the same beat. It was also an excuse to finally try spec-driven development, which had been showing up everywhere, including at work where folks I respect were singing the praises of GitHub's Spec Kit, so that's where I started.
Ten days and sixteen feature specs later, I had a mess.
What went wrong
Spec Kit gives you a pipeline (specify → plan → tasks → implement) plus an /analyze step to catch inconsistencies before they become bugs. The pipeline worked. The problem was upstream of it, and it was me: I hadn't decided which decisions needed locking down before I started generating artifacts. So the artifacts accumulated unevenly and drifted, from each other and from the code, at roughly the speed I was adding features.
