Idea principale

Una specifica completa è una finzione: anche ben scritta, lascia zone mute — casi limite, messaggi di errore, comportamenti impliciti, regole di sicurezza, timeout, micro-interazioni, decisioni di fallback. Quelle zone sono sempre state riempite dallo sviluppatore al momento di scrivere il codice, senza che nessuno la chiamasse decisione di prodotto.

Affidare una parte del codice a un agente elimina questo riempimento silenzioso. Bisogna dichiarare il comportamento atteso, decidere sui casi limite, scrivere i criteri di accettazione e verificare l'output, perché la macchina non condivide né le abitudini del team né la memoria delle scelte passate. Ciò che veniva assorbito nell'implementazione riemerge in superficie e diventa qualcosa da definire.

Il cambiamento, quindi, non è che queste decisioni compaiano: esistevano già. È che smettono di essere invisibili, e diventa impossibile sostenere che appartengano alla sola esecuzione.

Perché è importante

Trasforma un carico di scrittura in apparenza aggiuntivo in una rivelazione utile: il tempo speso a esplicitare un comportamento per un agente è tempo speso su una scelta che prima si faceva senza lasciare traccia.

E sposta il dibattito sulla responsabilità di prodotto degli sviluppatori: non cominciano a decidere, decidevano già — la delega a una macchina rende solo la cosa visibile e discutibile.

Sfumature e limiti

Esplicitare ha un costo, e non sempre ripaga: su un comportamento banale, scrivere ciò che uno sviluppatore avrebbe deciso in tre secondi costa più di quanto renda.

E anche l'agente riempie i silenzi, a modo suo: senza istruzioni produce una decisione di default che ha tutta l'aria di una scelta. Il rischio si sposta allora dal non detto al non riletto.

Domande aperte

• Quali zone mute meritano di essere scritte una volta per tutte come regole di team, invece di essere decise funzionalità per funzionalità?