กับดักที่พบบ่อย: ระบุทางแก้ ไม่ใช่ระบุปัญหา

ความล้มเหลวรูปแบบหนึ่งควรถูกพูดถึงแยกออกมา เพราะมันตกหลุมได้ง่ายมาก เมื่อคุณนั่งลงเพื่อเขียนสเปก สิ่งที่ยั่วยวนใจคือการอธิบาย ทางแก้ ที่คุณจินตนาการไว้แล้ว — "แถบด้านข้างที่มีแท็บ" "หน้าต่างป๊อปอัปที่โผล่ขึ้นมา" "ตาราง Postgres" แต่สเปกที่เต็มไปด้วยทางแก้กลับล็อกการตัดสินใจที่คุณยังไม่ได้พิสูจน์ว่าคุ้มค่าไว้อย่างเงียบ ๆ

ลองเปรียบเทียบสองประโยคนี้:

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.

ประโยคแรกได้เลือกแถบด้านข้าง ส่วนที่พับเก็บได้ และเลย์เอาต์ไปแล้ว — ก่อนที่ใครจะยืนยันด้วยซ้ำว่านั่นคือการตัดสินใจที่ถูกต้อง ประโยคที่สองระบุ งานที่ต้องทำให้สำเร็จ และปล่อยให้ AI (และตัวคุณ) เป็นอิสระในการหาทางแก้ที่ง่ายที่สุดที่ตอบโจทย์นั้น ซึ่งอาจเป็นแค่ปุ่มกรองสามปุ่มก็ได้ อธิบายผลลัพธ์ที่คุณต้องการ ปล่อยให้วิธีการยังคงต่อรองได้นานที่สุดเท่าที่จะทำได้ ทางแก้เปลี่ยนแปลงได้ง่ายในสเปก แต่แพงเมื่อต้องเปลี่ยนในโค้ด