What the contract leaves out

It’s tempting to think I could get better results from coding agents with a stronger product definition. More detail, clearer constraints, better acceptance criteria.

But an implementation can satisfy the contract while tying together decisions that ought to remain independent. The requested feature becomes the shape of the code.

I’ve spent time trying to teach agents to build from discrete, composable parts. Under sustained automation, those seams still seem to dissolve. Each addition finds somewhere to fit; the whole becomes harder to take apart.

That’s the part I’m struggling with. A specification describes what must work. It doesn’t necessarily describe what I should be able to change without understanding or disturbing everything else. Writing down that principle hasn’t been enough to preserve it as the work progresses.

If I have to keep identifying and defending those boundaries, how much of the design have I actually delegated?