Main idea

A complete specification is a fiction: even a well-written one leaves silent zones — edge cases, error messages, implicit behaviors, security rules, timeouts, micro-interactions, fallback decisions. Those zones have always been filled by the developer at coding time, without anyone calling it a product decision.

Handing part of the code to an agent removes that silent filling. The expected behavior has to be stated, the edge cases settled, the acceptance criteria written and the output verified, because the machine shares neither the team's habits nor the memory of past trade-offs. What used to be absorbed into the implementation comes to the surface and becomes an object to frame.

The change is therefore not that these decisions appear: they already existed. It is that they stop being invisible, and that it becomes impossible to pretend they are a matter of execution alone.

Why it matters

This turns an apparently extra writing burden into a useful revelation: time spent making a behavior explicit for an agent is time spent on a trade-off that used to be made without a trace.

And it shifts the debate about developers' product responsibility: they aren't starting to decide, they were already deciding — delegating to a machine merely makes it visible and open to discussion.

Nuances and limits

Making things explicit has a cost, and it isn't always worth paying: on a trivial behavior, writing out what a developer would have settled in three seconds consumes more than it returns.

And the agent also fills silences, in its own way: with no instruction, it produces a default decision that has every appearance of a choice. The risk then moves from the unsaid to the unreviewed.

Open questions

• Which silent zones deserve to be written once and for all as team rules, rather than settled feature by feature?