Bad Software Comes From Bad Organizations

Here's a hard-won lesson a lot of my friends have learned over the years: bad software comes from bad organizations. The good news is that the organization here is entirely in our control. Right now Flatbed has a loosey-goosey process, so in this lesson I formalize it. The spec gets divided into sprints. Every sprint starts with the PM figuring out what we're doing, the product designer weighs in, and tests get written up front by someone who isn't the builder. That's not me going TDD on you, it's just a great checklist.

I ran this on Opus. I don't need the frontier model to write a process doc; if I wanted to think more expansively I'd reach for Fable. Here's what I dictated:

I want to have an orchestration.md document that defines our development process. The way I want to do things is I want to one-shot this application over a series of sprints. Each sprint is designed to be a step. Each sprint should have its own branch, and each sprint should start with a spec phase.

What are we going to get done? The product designer should weigh in. Tests should be written by a dedicated tester that is not the developer, and then we should have a fan-out at some point where builders can go or developers can go. Each agent can go and build things in parallel, if possible, for that sprint.

Each sprint should do commits along the way so that we know what's going on as far as a story goes. If we can fan out across sprints and do things in parallel, hooray. Otherwise, let's not trip over ourselves. But I want to be able to orchestrate this so that when we get to the end of a sprint, a review goes off for code quality that goes along the lines of security and performance, to make sure that what we're building doesn't suck. I don't want to push crap.

The mandate here is to be as scalable as possible, and that goes for performance as well as being able to add features and things later on. So document this in an orchestration.md and ensure that it is followed when we do the development process. So put it in CLAUDE.md. This is a hard gate. Did I miss anything? Tell me if there's anything else I need to think about.

What comes back is Agile-light: a kickoff, a spec check, a delight pass, contracts, the works (sorry if I'm triggering you, but nobody has to do a stand-up). Claude asks me eight questions, and I answer them. The biggest one: I don't want to approve every sprint, so an orchestrator agent kicks everything off. I'm skipping my full answers on screen because they're responses, not a prompt you can reuse; you'll have your own. Then I remember what we learned last time and add one more line:

Do not start development until I tell you to.

And here's the part I want to drive home. If the build that comes out of this isn't what I want, what did I lose? Lunch. It's a git reset, change what needs changing, and run it again while I go play Elden Ring. Throwing away a sprint used to be painful. It's a whole new day.