Una trampa común: especificar soluciones, no problemas

Vale la pena señalar por separado un modo de fallo, porque es muy fácil caer en él. Cuando te sientas a escribir una especificación, la tentación es describir la solución que ya te imaginaste — "una barra lateral con pestañas", "una ventana modal emergente", "una tabla de Postgres". Pero una especificación llena de soluciones bloquea silenciosamente decisiones que aún no te has ganado.

Compara estas dos líneas:

Bad:  Add a left sidebar with collapsible sections for each book status.
Good: Let me see my books grouped by status without losing the full list.

La primera frase ya ha elegido una barra lateral, secciones plegables y un diseño — antes de que nadie haya confirmado que esas son las decisiones correctas. La segunda enuncia el trabajo por hacer y deja a la IA (y a ti) en libertad de encontrar lo más simple que lo satisfaga, que podría ser simplemente tres botones de filtro. Describe el resultado que quieres; deja que la implementación siga siendo negociable el mayor tiempo posible. Las soluciones son baratas de cambiar en una especificación y costosas de cambiar en código.