ต้องช้าลงเพื่อให้เร็วขึ้น

• แนวปฏิบัติที่สวนทางสัญชาตญาณที่สุดในยุค AI คือ การรู้ว่าเมื่อไรควรชะลอความเร็ว และยิ่งการลงมือทำมีต้นทุนต่ำลงเท่าไร การตัดสินใจก่อนลงมือทำก็ยิ่งสำคัญมากขึ้น
• นำกรอบแนวคิด System 1 (การจับคู่รูปแบบอย่างรวดเร็ว) และ System 2 (การคิดเชิงวิเคราะห์อย่างช้าๆ) ของ Daniel Kahneman มาปรับใช้กับการพัฒนาซอฟต์แวร์ในยุค AI
• ข้อกำหนดที่ผิดหรือสมมติฐานด้านการออกแบบที่คลาดเคลื่อนจะถูก AI แพร่กระจายได้เร็วขึ้นยิ่งกว่าเดิม ทำให้ความคุ้มค่าของขั้นตอนที่ช้าก่อนการลงมือทำยิ่งสูงขึ้น
• สามารถใช้ AI ไม่ใช่แค่เพื่อเร่งการลงมือทำ แต่ยังใช้เร่งขั้นตอนการไตร่ตรองอย่าง การทบทวนล่วงหน้า, pre-mortem, และการสำรวจ edge case ได้ด้วย
• หากจะรับมือกับวัฒนธรรมแรงกดดันเรื่องความเร็วแบบใหม่จากคำว่า "ก็ใช้ AI สิ?" ก็จำเป็นต้องมีกลยุทธ์ที่ทำให้ขั้นตอนที่ช้าถูกมองเห็นอย่างชัดเจนและกำหนดกรอบเวลาไว้

---

ความเร็วของการคิดสองแบบ

• นำสองโหมดการคิดจากหนังสือ Thinking, Fast and Slow ของ Daniel Kahneman มาเทียบกับการพัฒนาในยุค AI
  • System 1: การคิดที่รวดเร็ว อัตโนมัติ และอาศัยการจับคู่รูปแบบ
  • System 2: การคิดที่ช้า มีเจตนา และเชิงวิเคราะห์
• Andrej Karpathy ในบทสนทนากับ Dwarkesh Patel เปรียบ LLM ว่าเป็น ผีหรือจินน์ เป็นผลกลั่นทางสถิติของข้อความมนุษย์ ที่เมื่อป้อนคำเข้าไปก็จับคู่รูปแบบและสร้างคำออกมา จึงเป็นสิ่งที่มีลักษณะเป็น System 1 โดยเนื้อแท้
• AI โดดเด่นมากกับ การจับคู่รูปแบบอย่างรวดเร็ว ในระดับมหาศาล แต่การตัดสินว่าเราควรสร้างอะไร ทำไมมันถึงสำคัญ และเรากำลังแก้ปัญหาที่ถูกต้องหรือไม่ ยังเป็นพื้นที่ของ วิจารณญาณมนุษย์
• แก่นสำคัญที่สวนทางสัญชาตญาณคือ AI ไม่ได้ทำให้ขั้นตอนที่ช้าสำคัญน้อยลง แต่กลับทำให้มัน สำคัญมากขึ้น
  • เมื่อการลงมือทำเร็วขึ้นและถูกลง จุดคานงัดก็ย้ายไปอยู่ที่ การตัดสินใจ ก่อนการลงมือทำ
• ข้อกำหนดที่ผิด ปัญหาที่เข้าใจคลาดเคลื่อน หรือสมมติฐานการออกแบบที่บกพร่อง จะถูกส่งต่อไปยังทุกสิ่งที่ AI สร้าง และตอนนี้มัน แพร่กระจายได้เร็วขึ้น
  • ยิ่ง System 1 ทรงพลังขึ้นเท่าไร ต้นทุนของการทำ System 2 ผิดพลาด ก็ยิ่งสูงขึ้นเท่านั้น

ภาพลวงตาของความเร็ว

• มีมุกเก่าในวงการวิชาการว่า "งานที่ทำในห้องสมุดไม่กี่ชั่วโมง กลับใช้เวลาหลายสัปดาห์ในห้องแล็บ" และในเวอร์ชันซอฟต์แวร์คือ "การเขียนโค้ดหลายสัปดาห์ช่วยประหยัดเวลาวางแผนไม่กี่ชั่วโมง"
  • ประเด็นสำคัญคือความจริงมักตรงกันข้าม — ถ้าเริ่มต้นอย่างรีบเร่ง ก็จะเจอข้อผิดพลาดพื้นฐานภายหลังและต้องตามมาด้วยการแก้งานที่เจ็บปวด
• ในวิศวกรรมซอฟต์แวร์มีสัญชาตญาณที่ชัดเจนว่า ควรจับความผิดพลาดให้ได้เร็วที่สุดเท่าที่จะทำได้ โดยเฉพาะในขั้น ข้อกำหนดหรือการออกแบบ
  • แผนภาพแบบกล่องแก้ได้ง่าย ข้อกำหนดที่เข้าใจผิดแก้ยากกว่า และสถาปัตยกรรมการ deploy ที่บกพร่องในระดับรากฐานอาจถึงขั้นต้อง เขียนใหม่
• ปัญหาของ AI คือมันสามารถ สร้าง technical debt ได้เร็วกว่าที่เคย
  • หากการตัดสินใจก่อนลงมือทำมีข้อบกพร่อง AI ก็จะนำข้อบกพร่องนั้นไปทำต่ออย่างซื่อสัตย์ในรูปแบบที่ ดูเหมือนโค้ดฟีเจอร์ที่สมบูรณ์
  • มันสามารถสร้างโค้ดหลายพันบรรทัดจากข้อกำหนดที่เข้าใจผิด และพร้อมสร้างโซลูชันที่งดงามให้กับปัญหาที่ผิดได้อย่างเต็มใจ
• ภาพลวงตาของความเร็ว คือภาวะที่รู้สึกเหมือนกำลังก้าวหน้า แต่จริงๆ แล้วกำลังขุดหลุมให้ลึกขึ้น
• คำตอบไม่ใช่การละทิ้งความเร็ว แต่คือการ จัดวางมันอย่างมีเจตนา — ความเร็วของ AI ควรถูกใช้ก็ต่อเมื่อยืนยันทิศทางที่ถูกต้องแล้วเท่านั้น

ช่วงเวลาที่ความช้าสร้างผลลัพธ์

• จุดที่ความช้าอย่างมีเจตนาสร้างผลลัพธ์ได้ดีนั้นแทบไม่เปลี่ยน
  • ข้อกำหนดมีต้นทุนการเปลี่ยนต่ำเมื่อยังเป็นเพียงคำในเอกสาร และมีต้นทุนสูงเมื่อกลายเป็นโค้ดที่ deploy แล้วและให้บริการผู้ใช้จริง
  • การตัดสินใจด้านการออกแบบแก้ไขได้ง่ายในแผนภาพ แต่ยากมากในระบบ production
  • AI ไม่ได้เปลี่ยนฟิสิกส์พื้นฐานนี้ แต่เพิ่ม คานงัด เมื่อทำสิ่งเหล่านี้ได้อย่างถูกต้อง
• Thinking First protocol: จุดที่จับความผิดพลาดได้ถูกที่สุดคือการลงทุนเวลาเพื่อทำให้ชัดว่าจริงๆ แล้วเราต้องการอะไร ก่อนจะส่งงานให้ AI
• มีความย้อนแย้งที่น่าสนใจคือ AI ไม่ได้ใช้แค่เร่งการลงมือทำ แต่ยังใช้ เร่งการไตร่ตรองเองได้ด้วย
  • ทำข้อกำหนดให้ชัดก่อนเขียนโค้ด: ใช้เวลา 10 นาทีเขียนปัญหาที่ต้องการแก้ เกณฑ์ความสำเร็จ และข้อจำกัด แล้วให้ AI ช่วยทบทวนสิ่งที่เขียนก่อนเริ่ม generate
  • ทำ pre-mortem: ก่อนสรุปแบบออกแบบ ให้ถาม AI ว่า "อะไรอาจผิดพลาดได้บ้างกับแนวทางนี้?" เพื่อดึงความเสี่ยงที่อาจมองข้ามออกมา
  • กลับด้านปัญหา (Invert): ถาม AI ว่า "อะไรจะทำให้โปรเจกต์นี้ล้มเหลว?" เพื่อเปิดเผยสมมติฐานที่ซ่อนอยู่
  • สร้าง prototype ที่พร้อมทิ้ง: ใช้ AI ทำในไม่กี่ชั่วโมงแล้วนำไปให้ผู้มีส่วนได้ส่วนเสียดู เพื่อตรวจสอบความเข้าใจก่อนลงทุน — ใช้ความเร็วเพื่อลงทุนให้กับความช้า
  • สร้างเครื่องมือภายในแบบง่ายๆ: ก่อนใช้ต้นทุนกับผลิตภัณฑ์จริง ให้ใช้ AI ทำเวอร์ชันหยาบๆ ก่อน เพื่อดูว่าอะไรจำเป็นจริงและอะไรไม่จำเป็น
  • ดึง edge case ออกมาตั้งแต่เนิ่นๆ: ก่อนเริ่ม implement ให้ AI สร้าง edge case และ failure mode ของแบบออกแบบเพื่อจัดการตั้งแต่ระดับแผนภาพ

แรงต้านทางวัฒนธรรมรูปแบบใหม่

• "ก็ใช้ AI สิ?" คือรูปแบบใหม่ของ แรงกดดันด้านความเร็ว และอันตรายเป็นพิเศษเพราะมันทำให้สับสนระหว่างภาพลักษณ์ของ productivity กับ throughput ที่แท้จริง
  • AI อาจ generate โค้ดได้ในไม่กี่วินาที แต่การ generate โค้ดกับการ แก้ปัญหาที่ถูกต้อง ไม่ใช่เรื่องเดียวกัน
• กลยุทธ์รับมือ:
  • แชร์ให้ชัดว่าตอนนี้อยู่ในขั้นตอนไหน: หากอยู่ในช่วงช้า ให้บอกว่าเรากำลังทำข้อกำหนดให้ชัด กำลังคิดเรื่อง edge case หรือกำลังยืนยันว่าแก้ปัญหาถูกจุด
  • ดึงผู้มีส่วนได้ส่วนเสียเข้ามามีส่วนร่วม: ต้นทุนของการรับ input จากผู้มีส่วนได้ส่วนเสียตอนนี้ยังต่ำ แต่จะสูงมากในภายหลัง
  • แชร์กระบวนการทำงาน: ทำให้ ผลลัพธ์จากขั้นตอนที่ช้า มองเห็นได้ เช่น เอกสารข้อกำหนด ภาพร่างการออกแบบ หรือผลจาก pre-mortem เพื่อพิสูจน์ว่างานกำลังเดินหน้า
  • กำหนด timebox ให้ขั้นตอนช้า: เช่น "ใช้เวลา 2 วันทำข้อกำหนดให้ชัดก่อนเริ่มเขียนโค้ด" เพื่อให้ความช้าอย่างมีเจตนาดูเป็นสิ่งที่ มีแผน ไม่ใช่เปิดปลาย
  • แชร์สิ่งที่เรียนรู้: อัปเดตสั้นๆ ถึง edge case ที่ค้นพบหรือสมมติฐานที่พิสูจน์แล้วว่าไม่ถูกต้อง เพื่อเปลี่ยนขั้นตอนช้าให้เป็น กระแสคุณค่าที่มองเห็นได้
  • สาธิต quick win: ทำ prototype ที่พร้อมทิ้งหรือ mockup ตั้งแต่เนิ่นๆ เพื่อแสดงว่าเคลื่อนไหวได้เร็ว และสร้าง ความเชื่อมั่น ต่อการทำงานที่ช้าและรอบคอบ
• คล้ายกับแนวคิด Hill Chart ในวิธีการ Shape Up ของ Basecamp
  • ช่วงขึ้นเขา: ขั้นตอนช้า ที่ความไม่แน่นอนสูงและยังต้องค้นหาว่างานคืออะไร
  • ช่วงลงเขา: ขั้นตอนเร็ว ที่เส้นทางชัดเจนและเหลือเพียงการลงมือทำ
• นี่ไม่ใช่ข้ออ้างของความล่าช้า แต่เป็นคำอธิบายว่า งานที่ดีเกิดขึ้นจริงอย่างไร — ในระยะยาว ทีมที่ส่งมอบได้เร็วที่สุดมักเป็นทีมที่รู้จักชะลอความเร็วในจังหวะที่เหมาะสม

วิธีนำไปปฏิบัติ

• ก่อนเริ่มงานถัดไปที่มี AI ช่วย ลองทำสิ่งต่อไปนี้:
  • ใช้เวลา 10 นาทีเขียนปัญหาที่แท้จริงที่ต้องการแก้ พร้อมนิยามว่าความสำเร็จหน้าตาเป็นอย่างไร และอะไรอยู่นอกขอบเขต
  • ให้ AI ทำ pre-mortem กับแนวทางที่เลือก ก่อนเริ่มลงมือสร้าง
  • หากงานมีขนาดค่อนข้างใหญ่ ให้ สร้าง prototype ที่พร้อมทิ้งก่อน เพื่อตรวจสอบทิศทาง

บทสรุป

• ความเร็วกับความช้าไม่ใช่สิ่งตรงข้าม แต่เป็น เครื่องมือสำหรับคนละช่วงของงาน
• AI มีประสิทธิภาพกับทั้งสองด้าน: การลงมือทำอย่างรวดเร็ว เมื่อทิศทางชัดเจน และ การไตร่ตรองที่เร่งได้ เมื่อยังไม่ชัด
• ทักษะสำคัญคือการรู้ว่าตอนนี้เราอยู่ในช่วงไหน และ ใช้จังหวะที่เหมาะสม

[dankim0124]

มีคำพูดอยู่ว่า ช้าๆ แต่เร็ว

[hungryman]

เป็นคำที่สมัยเรียนปริญญาโทได้ยินจากอาจารย์บ่อยมาก
ไม่ได้ยินมานานแล้ว PTSD กลับมาเลย

[dankim0124]

ผมได้ยินมาในกองทัพ

[findnamo]

ฉันเคยอ่านเจอในโน้ตเพลง
allegro non troppo (เร็ว แต่ไม่เร่งรีบเกินไป)