Approach validation, or proving the route before you drive it

There's a step between writing the spec and generating the code that most people skip, and skipping it is how you end up three hours into an implementation before realizing the whole approach was wrong. The step is approach validation: deciding how you're going to solve it, on paper, before the model writes a line.

The spec says what must be true. It doesn't say how to get there, and usually there are several hows. Store it in a database or a flat file. Poll or subscribe. Build the agent or make one good model call. Approach validation is laying those options side by side, naming the trade-offs, and picking one with a reason you could defend. It's a decision tree, and it costs minutes.

Why validate the approach separately from the spec?

Because changing your mind on a decision tree is free and changing it in code is not. Once the model has generated a real implementation of the wrong approach, you're not editing a choice anymore, you're unwinding a build, and the sunk cost starts arguing for keeping something you should throw away. Naming the approaches first, when they're all still just words, is the cheapest possible place to be wrong. You get to reject three bad routes for the price of a sentence each.

What it looks like in practice

Three lines, often. "Option A: X, fast but doesn't scale past N. Option B: Y, slower to build, handles the growth. Option C: Z, simplest, but loses the audit trail. Going with B because the growth is the actual requirement." That's it. You've now got a chosen route, a recorded reason, and two rejected alternatives you won't accidentally relitigate at 2am. Hand that to the model along with the spec and it builds the route you actually chose instead of the first one that occurred to it.

The takeaway: between the spec and the code, name the approaches and pick one on purpose, because a wrong route is cheap to reject on paper and expensive to unwind in a build.