Idea principal

Una especificación completa es una ficción: incluso bien escrita, deja zonas mudas — casos límite, mensajes de error, comportamientos implícitos, reglas de seguridad, tiempos de expiración, microinteracciones, decisiones de repliegue. Esas zonas siempre las ha rellenado el desarrollador en el momento de programar, sin que nadie llamara a eso una decisión de producto.

Confiar una parte del código a un agente elimina ese relleno silencioso. Hay que decir el comportamiento esperado, resolver los casos límite, escribir los criterios de aceptación y verificar la salida, porque la máquina no comparte ni la costumbre del equipo ni la memoria de los arbitrajes pasados. Lo que se absorbía en la implementación sale a la superficie y se convierte en un objeto que hay que encuadrar.

El cambio no es, por tanto, que esas decisiones aparezcan: ya existían. Es que dejan de ser invisibles, y que se vuelve imposible pretender que son mera ejecución.

Por qué es importante

Esto transforma una carga de escritura aparentemente añadida en una revelación útil: el tiempo dedicado a explicitar un comportamiento para un agente es tiempo dedicado a un arbitraje que antes se tomaba sin dejar rastro.

Y desplaza el debate sobre la responsabilidad de producto de los desarrolladores: no empiezan a decidir, ya decidían — la delegación a una máquina solo lo vuelve visible y discutible.

Matices y límites

Explicitar tiene un coste, y no siempre es rentable: sobre un comportamiento trivial, escribir lo que un desarrollador habría resuelto en tres segundos consume más de lo que aporta.

Y el agente también rellena los silencios, a su manera: sin instrucción, produce una decisión por defecto que tiene todas las apariencias de una elección. El riesgo se desplaza entonces de lo no dicho a lo no releído.

Preguntas abiertas

• ¿Qué zonas mudas merecen escribirse de una vez por todas como reglas de equipo, en lugar de resolverse en cada funcionalidad?