Spec the invariants, vibe the rest

There's a failure mode on the other side of all this, and it's the one that bites people right after specs finally click for them. They start speccing everything. Every variable name, every internal step, the exact shape of the implementation. And now they've handcuffed the one collaborator that's genuinely good at implementation, and they're getting slower, worse output while feeling more disciplined. Over-speccing is real, and it's a trap.

The line I've settled on is this: spec the invariants, vibe the rest. Pin the things that must be true, the properties, the interface, the failures that matter. Then hand the model the freedom to decide how. The how is exactly the half it's better and faster at than you are. Your job is the fence, not the footprints inside it.

How do you know how much is enough?

Here's the test. If you can't name what breaks when a given line drifts, that line doesn't belong in the spec yet. A spec is a set of things that would count as failure if violated. If a detail could change and nothing you care about would break, it's implementation, and implementation is the model's to own. Enough spec is the point where someone who's never seen the problem couldn't build the wrong thing without violating something you wrote down. One inch past that, you're speccing the how, and the how was never yours to hold.

Why over-speccing feels productive and isn't

Because writing feels like control, and control feels like progress. But every implementation detail you pin is a constraint the model now has to route around instead of optimize through, and you've traded its strongest capability for a false sense of authorship. The discipline isn't writing more. It's writing the right lines and deliberately leaving the rest open. Restraint is the skill.

The takeaway: pin what breaks if it drifts and leave the rest to the model, because the invariants are yours to hold and the implementation is its to own. Spec the fence, vibe the field.