Three Hours, Ten Sprints: Is This Vibe-Coded Trash?

This is one of my favourite moments in any project. The spec is written, the design's been explored, the skills are loaded, and now I get to kick off the build and go eat lunch. First I check the context: 17% used, which is too much for a build this big, so I clear it and start at 6%. The plan has ten sprints, from the skeleton through polish and launch. Then I dictate the prompt, which feels a bit like leaving a message for a loved one:

This is going to be a big build, and I trust you to build it. So let's kick off the first sprint, Sprint 00, and I'm going to go off to lunch. And when I come back, I want to see as complete a build as possible. Do all the things you need to do. I fully trust you. Make decisions for me. Do not deploy anything. Just for right now, what I want to see when I come back is a whole set of nice tests that are all passing in green, and I want to see an application that is utterly gorgeous. Have fun, execute all the sprints, make sure everything is complete, and I will talk to you later.

It wasn't fast. It ran about three hours, and it stopped halfway because a sprint failed review three times and it wanted to know what to do (it does that by default; if you don't want a review gate per sprint, do one at the end). But when it finished, Flatbed ran, and it's fun: "Carolyn holds the conch" (my wife, and the trophy that moves week to week), a solo run against your own ghost, an AI sportscaster calling the race, and an MCP server so we can load the list from Claude. The docs folder tells the whole story, sprint by sprint, with the decisions and a go-live checklist.

So is the code any good? I poke around in VS Code (it wrapped Math.random in its own class, seriously) and then ask Fable for the honest version:

I'm very concerned that this app is going to come off as vibe-coded garbage. I want to make sure that I have good solid tests, that things follow idiomatic React and SOLID principles and generally good coding. I want to make sure that I can change this. I'm not a Puritan. I know that there's always bending the rules. But if I ever decide to change something in this application, let's say in six months or a year, that it's not going to be a nightmare. Do a quick high-level review as if you're an architect of 20-plus years, understands databases and long-running application maintenance, and tell me the goods, the bads and the ugliest. Thank you.

The verdict: "unusually disciplined." A clean composition root, real layering, honest tests. The bads are real too: sprint tags in the comments instead of the why, tests organized by sprint instead of behaviour (that one's on me), and 6,000 lines of global CSS sitting next to Tailwind. Maybe a 30 to 40 minute refactor. Could I have written it this way myself? No. I'm not this rigorous or this consistent. That's the point of all the discipline up front: you end up with something you can stand behind, not vibed-out garbage.