Cognitive Surrender: วันที่คำตอบของ Agent กลายเป็นความเห็นของเราโดยไม่รู้ตัว

คำว่า "ยอมจำนน" ฟังดูเกินจริงไปหน่อยสำหรับคนที่แค่กด approve PR ครับ

ผมเองก็คิดแบบนั้นตอนเห็นชื่อบทความ Cognitive Surrender ของ Addy Osmani ครั้งแรก นึกภาพคนที่เลิกคิดไปเลยและให้ AI สั่งทุกอย่าง ซึ่งไม่น่าใช่ผม เพราะผมยังอ่านงาน ยังถามกลับ และยังเป็นคนกดปุ่มสุดท้ายเอง

แต่พออ่านจบ ภาพที่ผมเห็นกลับไม่ใช่คนที่เลิกคิดเลยครับ มันคือคนที่ทำงานเก่งตามปกติ ส่งงานตรงเวลา งานออกมาดี และไม่ทันสังเกตว่าส่วนที่เป็นการตัดสินใจของตัวเองในงานนั้นเหลือน้อยลงทุกที

ผมเป็นทั้ง developer, PM และ PO ที่ Mulberrysoft ดูแลทีม junior และใช้ Claude, Codex กับ agent อื่น ๆ แทบทุกวัน โพสต์ก่อนหน้า ผมเขียนเรื่องการให้ agent ทำงานแทนโดยไม่ให้มันคิดแทนไปแล้ว โพสต์นี้จึงอยากซูมเข้าไปที่จุดเดียว คือการเปลี่ยนผ่านที่เกิดขึ้นเงียบ ๆ ระหว่างการฝากงานกับการยกความคิดให้ไปเลย

จุดยืนของผมมีอยู่ว่า การฝากงานเป็นเรื่องดี แต่ความเป็นเจ้าของการตัดสินใจเป็นสิ่งที่ฝากไม่ได้

สองคำที่ดูคล้ายกัน แต่ไกลกันมาก

Addy หยิบกรอบคิดนี้มาจากงานของ Steven Shaw และ Gideon Nave จาก Wharton ซึ่งแยกสองอย่างออกจากกันครับ

Cognitive offloading คือการส่งงานให้เครื่องมือ แต่เรายังเป็นเจ้าของคำตอบอยู่ เครื่องคิดเลข search engine และ GPS อยู่ในกลุ่มนี้ เราฝาก "วิธีทำ" ไป แต่ยังตัดสินเองว่าผลที่ได้ใช้ได้ไหม GPS บอกให้เลี้ยวลงคลอง เราก็ยังไม่เลี้ยว

Cognitive surrender คือจุดที่เราเลิกสร้างคำตอบเองไปเลย output ของ AI กลายเป็น output ของเราแบบเงียบ ๆ และเราไม่รู้สึกด้วยซ้ำว่ายังมีอะไรเหลือให้ตรวจ

ในหัวผม ระหว่างสองคำนี้ยังมีอีกจุดหนึ่งที่ผมเรียกว่า deferral หรือ "เชื่อตามไปก่อน" ซึ่งเป็นการตีความของผมเองนะครับ ไม่ได้มาจากบทความของ Addy เป็นจุดที่เรายังอ่านอยู่ แต่รับคำตอบแรกเป็นค่าตั้งต้น และจะค้านก็ต่อเมื่อเห็นอะไรผิดชัด ๆ ผมเพิ่มจุดนี้เข้ามาเพราะคิดว่าคนส่วนใหญ่ไม่ได้กระโดดจากฝั่งหนึ่งไปอีกฝั่งในวันเดียว แต่ค่อย ๆ ไหลผ่านตรงกลางนี้ไป

ถ้าวางเป็นเส้นเดียว ผมแยกทั้งสามจุดด้วยคำถามง่าย ๆ ว่า ตอนนี้ใครเป็นคนตัดสิน offloading คือเราตัดสินหลังเห็นผล deferral คือเราตัดสินเฉพาะตอนมีอะไรสะดุดตา ส่วน surrender คือไม่มีการตัดสินเกิดขึ้นเลย มีแค่การส่งต่อ

ตัวเลขที่ทำให้ผมเงียบไปพักหนึ่ง

ตามที่ Addy สรุปไว้ งานวิจัยชิ้นนี้ (Thinking - Fast, Slow, and Artificial) ทดลองสามครั้งกับผู้เข้าร่วม 1,372 คน และพบว่าแค่มี AI ให้ใช้ก็เพียงพอให้คนเริ่มยอมจำนนแล้ว ในรอบที่ AI ตอบผิด ผู้เข้าร่วมรับคำตอบผิดนั้นไปถึง 73% ของจำนวนครั้ง และความมั่นใจของพวกเขาสูงขึ้นเมื่อมี AI อยู่ด้วย ทั้งที่คำตอบครึ่งหนึ่งถูกตั้งใจให้ผิด

ส่วนที่ผมว่าน่ากลัวไม่ใช่เลข 73 ครับ แต่คือสองอย่างนี้เกิดขึ้นพร้อมกัน เราผิดบ่อยขึ้น และมั่นใจขึ้นในเวลาเดียวกัน ถ้าผิดแล้วรู้สึกไม่มั่นใจ อย่างน้อยเราก็ยังมีสัญญาณเตือน แต่กรณีนี้สัญญาณนั้นหายไป

ต้องบอกตามตรงว่าผมอ่านตัวเลขเหล่านี้ผ่านบทความของ Addy ไม่ได้ลงไปอ่าน paper ฉบับเต็ม จึงไม่ขอตีความไกลกว่านี้ และก็รู้ตัวดีว่าการเอาสรุปของคนอื่นมาเล่าต่อในโพสต์เรื่องนี้ค่อนข้างย้อนแย้ง ใครอยากเช็กจึงกดลิงก์ด้านบนได้เลยครับ

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

ทำไมมันถึงมองไม่เห็น

ถ้าการยอมจำนนทำให้งานพังทันที เราคงเลิกทำไปนานแล้วครับ แต่มันไม่พัง

ลองนึกถึงรอบที่เราไม่ได้ตรวจแล้วงานออกมาถูก รอบนั้นไม่มีอะไรเกิดขึ้น ไม่มี incident ไม่มีใครทัก สิ่งที่สมองได้รับคือบทเรียนสั้น ๆ ว่า ไม่ตรวจก็ไม่เป็นไร พอรอบถัดไปมาถึงตอนกำลังรีบ การข้ามจึงง่ายขึ้นอีกนิด การข้ามแต่ละครั้งเลยฝึกให้เกิดการข้ามครั้งต่อไป และเป็นการฝึกที่ได้รางวัลทุกรอบ เพราะเราได้เวลาคืนมาทันที

ส่วนราคาที่ต้องจ่ายมาทีหลัง และมักไม่ได้มาในรูปที่เราจะโยงกลับไปหาการข้ามครั้งนั้นได้ มันอาจมาเป็นบั๊กอีกสามเดือนข้างหน้าในโมดูลที่ไม่มีใครในทีมอธิบายได้ หรือมาเป็นวันที่ agent แก้ปัญหาหนึ่งไม่ได้ แล้วเราพบว่าตัวเองก็ไม่รู้จะเริ่มตรงไหนเหมือนกัน

อีกเหตุผลคืองานที่ผิดกับงานที่ถูกหน้าตาเหมือนกันครับ คนเขียนโค้ดไม่มั่นใจมักทิ้งร่องรอยไว้ให้เราเห็น ทั้งชื่อตัวแปรแปลก ๆ คอมเมนต์ลังเล หรือคำถามใน PR แต่งานจาก agent ขัดเงามาเท่ากันทุกส่วน ความเรียบร้อยจึงเลิกเป็นตัวบอกคุณภาพ แต่สมองเรายังใช้มันเป็นตัวบอกอยู่

หน้าตาในงานประจำวัน

เรื่องนี้ไม่ได้เกิดกับการตัดสินใจใหญ่โตครับ มันเกิดในงานธรรมดาที่สุด และผมก็อยู่ในทุกข้อด้านล่างนี้ไม่มากก็น้อย

PR ที่ "ดูโอเค" Addy ยกตัวอย่างการ approve PR ใหญ่จาก agent เพราะ test เขียว ซึ่งตรงกับผมมาก พอ diff ยาวเกินจะอ่านไหวในรอบเดียว สายตาก็จะเริ่มกวาดหารูปแบบที่คุ้น เห็นโครงสร้างสวยก็ไปต่อ สิ่งที่ผมทำจริงในตอนนั้นคือการตรวจว่าโค้ด ดูเหมือน โค้ดที่ดี ไม่ใช่ตรวจว่ามันทำสิ่งที่ถูกต้อง

Spec ที่ agent เติมให้ มุมนี้ผมเจอในฐานะ PM ครับ ผมโยนไอเดียไปสองบรรทัด ได้ spec กลับมาครบทั้ง user story, acceptance criteria และ edge case อ่านแล้วรู้สึกว่างานคืบหน้าไปเยอะ แต่ในเอกสารหน้านั้นมีการตัดสินใจเชิงผลิตภัณฑ์ซ่อนอยู่หลายข้อที่ผมไม่ได้เป็นคนตัดสิน และพอส่งต่อให้ทีม เอกสารก็มีชื่อผมอยู่ คนอ่านย่อมเข้าใจว่าผมคิดเรื่องนั้นมาแล้ว

สรุปที่แทนการอ่านของจริง agent บอกว่าเจอสาเหตุใน log แล้ว แก้เรียบร้อย ผมอ่านสรุปแล้วปิดงาน โดยไม่ได้เปิด log สักบรรทัด ข้อนี้อันตรายเพราะสรุปอ่านเหมือนข้อเท็จจริง ทั้งที่มันคือการตีความชั้นหนึ่ง

แก้ error ที่ไม่เข้าใจ ข้อนี้ก็อยู่ในรายการของ Addy เช่นกัน error หายไปแล้ว งานเดินต่อได้ แต่ถ้าถามว่ามันเกิดจากอะไร เราตอบไม่ได้ สิ่งที่เราได้จึงเป็นอาการที่หายไป ไม่ใช่ความเข้าใจที่เพิ่มขึ้น

สัญญาณว่าเราเลื่อนไปแล้ว

ผมลองรวบรวมสัญญาณไว้เช็กตัวเองครับ ส่วนนี้เป็นรายการของผมเอง ซึ่งเรียบเรียงจากตัวอย่างของ Addy ผสมกับสิ่งที่เจอในงาน

สัญญาณแรกคือ ตอบ "ทำไม" ไม่ได้โดยไม่กลับไปถาม agent ถ้าเพื่อนร่วมทีมถามถึงเหตุผลของ design ที่เราเพิ่งเสนอ แล้วเราอยากเปิดหน้าต่างแชตก่อนตอบ นั่นคือเราถือข้อสรุปอยู่ แต่ไม่ได้ถือเหตุผล

สัญญาณที่สองคือ ความมั่นใจมาจากน้ำเสียงของคำตอบ ลองถามตัวเองว่าที่รู้สึกว่าถูกนั้นมาจากไหน ถ้าไม่มีอะไรนอกจาก "มันอธิบายได้ดี" ความมั่นใจนั้นก็ยังไม่มีหลักฐานรองรับ

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

สัญญาณที่สี่คือ รู้สึกอึดอัดกับงานที่ต้องคิดเองตั้งแต่ต้น เมื่อก่อนเรานั่งไล่บั๊กได้เป็นชั่วโมง แต่ตอนนี้ผ่านไปสิบนาทีก็เริ่มอยากโยนให้ agent นี่คือสัญญาณที่บอกเรื่องทักษะมากกว่าเรื่องงานชิ้นนั้น

สัญญาณสุดท้ายคือ เราตรวจน้อยลงตอนเหนื่อย แต่ส่งงานเท่าเดิม Addy พูดถึงความเหนื่อยไว้ด้วย และผมว่าจริงมาก ช่วงห้าโมงเย็นของวันที่ประชุมทั้งวันคือช่วงที่ผมกด approve ง่ายที่สุด ซึ่งก็เป็นช่วงที่ไม่ควรทำแบบนั้นที่สุดเช่นกัน

นิสัยที่จะดึงตัวเองกลับมา

ผมไม่คิดว่าทางแก้คือการตรวจทุกบรรทัดครับ เราทำแบบนั้นไม่ไหว และถ้าทำก็เสียประโยชน์ของ agent ไปหมด เป้าหมายของผมคือการรู้ว่างานไหนต้องการเรา แล้วอยู่กับงานนั้นจริง ๆ

คิดคำตอบไว้ก่อนเห็นคำตอบ ก่อนส่งงานให้ agent หรือก่อนเปิดอ่านผลลัพธ์ ผมจะเขียนสั้น ๆ ว่าคาดว่าจะเห็นอะไร จะผิดก็ไม่เป็นไร แค่นี้ผมก็มีอะไรไว้เทียบ และการอ่านของผมจะเปลี่ยนจากการรับสารเป็นการเปรียบเทียบทันที

รับชื่อตัวเองก่อนกดส่ง ทุกอย่างที่ออกไปในชื่อผมคืองานของผม ไม่ว่าใครจะเป็นคนพิมพ์ ผมตั้งใจเลิกใช้ประโยค "agent บอกว่า" เป็นคำตอบสุดท้าย พูดได้ว่ามันเป็นจุดเริ่มต้น แต่ถ้าจะส่งต่อ ผมต้องพูดได้ว่า "ผมเช็กแล้วว่า..." ตามด้วยสิ่งที่เช็กจริง

สุ่มตรวจแบบที่เลือกจุดเอง เมื่อตรวจทั้งหมดไม่ได้ ผมก็จะเลือกตรวจให้ลึกในจุดที่ผิดแล้วเจ็บที่สุด เช่น สิทธิ์การเข้าถึง เงิน หรือข้อมูลลูกค้า แล้วสุ่มเปิดของจริงเทียบกับสรุปอีกสักหนึ่งหรือสองจุด เช่น คลิกตามไปดูบรรทัดใน log ที่สรุปอ้างถึง ถ้าจุดที่สุ่มมาไม่ตรงกับสรุป ผมถือว่าต้องอ่านทั้งหมดใหม่

อ่าน diff เหมือน junior เขียน อันนี้ได้มาจาก Addy ตรง ๆ และเข้ากับชีวิตผมพอดี เวลารีวิวงานน้องในทีม ผมจะถามว่าทำไมทำแบบนี้ และเคสนี้คิดไว้หรือยัง โดยไม่ได้ดูถูกเขาเลย แต่พอเป็นงาน agent ที่อ่านแล้วดูมั่นใจกว่า ผมกลับเกรงใจมันไปเอง ซึ่งไม่มีเหตุผลอะไรรองรับเลย

ลดขนาดงานให้เท่าที่เข้าใจได้ Addy เขียนประโยคหนึ่งที่ผมอยากแปะไว้หน้าจอ คือ "The unit of review is the unit of comprehension" ถ้า PR ใหญ่เกินกว่าจะเข้าใจในรอบเดียว ปัญหาไม่ใช่ว่าเรารีวิวไม่เก่ง แต่คืองานก้อนนั้นใหญ่เกินไป ผมจะขอให้ agent แบ่งเป็นก้อนเล็กลง แม้ต้องเสียเวลาเพิ่มนิดหน่อยก็ตาม

เขียนโค้ดเองบ้างทุกสัปดาห์ Addy แนะนำเรื่องนี้เช่นกัน ส่วนผมจะเลือกงานเล็ก ๆ สักชิ้น แล้วปิด agent ทำเองจนจบ ไม่ใช่เพราะเชื่อว่าการเขียนมือดีกว่า แต่เพราะเป็นวิธีเดียวที่ผมนึกออกในการเช็กว่าทักษะยังอยู่ ส่วนทีม junior ข้อนี้ยิ่งสำคัญกว่าผมอีก เพราะน้อง ๆ ยังอยู่ในช่วงสร้างสัญชาตญาณว่าอะไรน่าสงสัย ถ้าข้ามช่วงนี้ไป ก็จะไม่มีอะไรไว้ calibrate กับคำตอบของ agent

ถามคำถามสุดท้ายว่า "ผมจะปกป้องสิ่งนี้ได้ไหม" ก่อนส่งงานที่สำคัญ ผมจะนึกภาพว่าต้องอธิบายการตัดสินใจนี้ต่อหน้าคนที่เก่งเรื่องนี้ที่สุดในห้อง โดยไม่เปิดหน้าจอ ถ้าปกป้องได้ จะใช้ agent ช่วยมากแค่ไหนก็ไม่มีปัญหา ถ้าปกป้องไม่ได้ งานนั้นยังไม่ใช่ของผม ถึงแม้ว่าจะมีชื่อผมอยู่บน commit ก็ตาม

ท้ายที่สุด

ผมยังจะใช้ agent ทุกวันครับ และน่าจะมากขึ้นเรื่อย ๆ การส่งงานที่น่าเบื่อออกไปแล้วเอาเวลามาคิดเรื่องที่ยากกว่า เป็นข้อเสนอที่ดีมากจริง ๆ และ agent ก็ทำให้งานเร็วขึ้นจริง ๆ

แต่ข้อเสนอนั้นจะดีได้ก็ต่อเมื่อเวลาที่ได้คืนมาถูกเอาไปคิดจริง ถ้าเวลานั้นหมดไปกับการสั่งงานชิ้นถัดไปเร็วขึ้น แล้วเราค่อย ๆ เลิกคิดในทุกชิ้น เราก็จะได้งานมากขึ้นด้วยทักษะที่น้อยลง และสิ่งที่น่ากลัวคือในวันแรก ๆ ตัวเลขทุกอย่างจะยังดูดีอยู่

การยอมจำนนไม่ได้มาพร้อมการตัดสินใจครั้งใหญ่ครับ ไม่มีวันไหนที่เราตื่นมาแล้วบอกตัวเองว่าจะเลิกคิด มันเกิดจากการข้ามเล็ก ๆ ที่สมเหตุสมผลทุกครั้ง ทางกลับก็น่าจะเล็กเหมือนกัน

ดังนั้นงานชิ้นถัดไปที่ agent ส่งกลับมา ก่อนกด approve ผมจะถามตัวเองแค่ว่า ถ้ามีคนถามว่าทำไมถึงเป็นแบบนี้ ผมตอบได้เองไหม

ถ้าตอบได้ นั่นคือการใช้เครื่องมือครับ ถ้าตอบไม่ได้ ก็ยังมีเวลาอ่านอีกรอบก่อนจะกดปุ่ม