AI ไม่ได้ทำให้คนคนหนึ่งชา แต่ทำให้ทั้งองค์กรชา: ความย้อนแย้งของระบบอัตโนมัติที่วงการการบิน·การแพทย์เจอก่อน

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

• AI ไม่ใช่ abstraction ที่ซ่อนงานระดับล่างไว้ แต่เป็นตัวแทนเชิงความน่าจะเป็นที่เข้ามานั่งแทนที่งานนั้น abstraction แบบเดิมอย่าง React·ORM ยังพอให้เราปีนลงบันไดไปตรวจเหตุและผลได้เมื่อจำเป็น แต่เหนือ AI นั้นไม่มีบันไดให้ลงไปตั้งแต่แรก
• แนวคิดหลักคือ cognitive ownership หรือ "สถานะที่สามารถอธิบายเส้นทางเชิงตรรกะได้ตั้งแต่ต้นจนจบว่า ทำไมโค้ดนี้จึงต้องถูกเขียนแบบนี้" ประเด็นไม่ได้อยู่ที่โค้ดผ่านมือใครบ้าง แต่อยู่ที่เหตุและผลนั้นอยู่ในหัวของใคร
• AI ไม่ได้ทำให้ฝีมือเท่าเทียมกัน แต่มันทำให้ "ความดูน่าเชื่อ" เท่าเทียมกัน จุดต่ำสุดของการกระจายคุณภาพโค้ดสูงขึ้นก็จริง แต่ไม่ได้แปลว่าฝีมือสูงขึ้น และยิ่งโมเดลดีขึ้นเท่าไร ความจริงที่ว่าเหตุและผลข้างในว่างเปล่าก็ยิ่งมองไม่เห็นมากขึ้นเท่านั้น
• ต้นทุนการสร้างเข้าใกล้ 0 แต่ต้นทุนการตรวจสอบยังเท่าเดิม แรงกดดันทางเศรษฐกิจที่ทำให้คนซึ่งใช้เวลา 1 ชั่วโมงตรวจโค้ดที่ถูกสร้างใน 1 วินาที กลายเป็นคนที่ช้าที่สุดในตัวชี้วัดขององค์กร ทำให้การยอมรับอย่างวิพากษ์วิจารณ์ไม่อาจยืนหยัดได้ด้วยเจตจำนงเพียงอย่างเดียว
• ยกตัวอย่างบรรทัดฐานจากการบิน·ประสาทวิทยา·การแพทย์ที่ผ่านเรื่องนี้มาก่อน เช่น ความย้อนแย้งของระบบอัตโนมัติ (Bainbridge, 1983), Air France เที่ยวบิน 447, การฝ่อของ hippocampus ในผู้ที่พึ่งพา GPS, และการลดลงของ sensitivity ใน CAD สำหรับแมมโมแกรม
• ข้อเสนอไม่ได้อยู่ที่ความตั้งใจของปัจเจก แต่ต้องเป็นโครงสร้างของทีม เสนอให้บันทึกความไร้ประสิทธิภาพของ ownership นี้ในบัญชีไม่ใช่ในฐานะ "ศีลธรรม" แต่ในฐานะ "ค่าเบี้ยประกัน"

สรุปแบบละเอียด

AI ไม่ใช่ abstraction แต่เป็นตัวแทน

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

การทำให้ความดูน่าเชื่อเท่าเทียมกัน

• จากการสังเกตหน้างานในฐานะผู้สัมภาษณ์และผู้รีวิว PR ชื่อตัวแปรดูสะอาด โครงสร้างก็ดูน่าเชื่อ แต่พอแกะดูจะพบฟังก์ชันซ้ำ ๆ การแยกความรับผิดชอบไม่ชัด และ side effect กองรวมกัน
• หลักฐานที่ซื่อตรงที่สุดคือวินาทีที่คำถามว่า "ตรงนี้ทำไมถึงทำแบบนี้ครับ/คะ?" แล้วตอบไม่ออก นั่นคือสัญญาณตรงไปตรงมาของโค้ดที่ภายนอกดูปกติแต่ข้างในไม่มีเหตุและผลรองรับ

อาการชาลามในระดับองค์กร

• เมื่อก่อนเหตุและผลถูกเก็บกระจายไว้ผ่าน ownership สองชั้นคือผู้เขียนกับผู้รีวิว แต่เมื่อทั้งการเขียนและการตรวจกลายเป็น AI ก็จะเกิดสถานะที่เหตุและผลของ PR นั้นไม่อยู่ในหัวของใครในทีมเลย
• "ให้ AI review bot สรุป แล้วมนุษย์ไล่ดูคร่าว ๆ พร้อมกด LGTM" ดูเหมือนการตรวจสอบ แต่จริง ๆ แล้วเป็นเพียงผลผลิตไร้เหตุและผลอีกชิ้นหนึ่ง หลักการที่ว่า "โค้ดที่ฉันสร้าง ฉันเป็นคนดูแล" จึงพังทลาย

รสนิยมเติบโตได้เฉพาะในความขัดข้อง

• เป็นการโต้แย้งวาทกรรมที่ว่า "ให้ AI ลงมือ implement ส่วนมนุษย์มีหน้าที่แค่ taste" เพราะ taste ไม่ได้เติบโตจากการอ่านโค้ดดี ๆ เยอะ ๆ แต่เติบโตจากประสบการณ์ที่ของที่เราเขียนพัง แล้วเราต้องคลำตามเหตุและผลตรงนั้นด้วยตัวเอง
• อ้างอิงอุปมาเรื่องค้อนของ Heidegger (แก่นแท้ของเครื่องมือจะเผยออกมาก็ต่อเมื่อมันเสีย) และ practical wisdom ของ Aristotle AI ไม่ได้ลบแค่ความขัดข้อง แต่ลบ "ประสบการณ์ของการเผชิญความขัดข้อง" ไปด้วย จนปิดโรงตีเหล็กที่ใช้หล่อหลอม taste

ตำแหน่งที่สายการฝึกแบบลูกมือขาดหายไป

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

ทางแก้ต้องเป็นโครงสร้างของทีม

• กำหนดเป็นกฎรีวิวว่า "โค้ดที่อธิบายเหตุและผลไม่ได้ จะไม่ merge" เปลี่ยนความหมายของ LGTM จากการอนุมัติทั่วไป ให้กลายเป็นคำประกาศรับช่วงว่า "ฉันสามารถอธิบายโค้ดนี้ได้" พร้อมทำ spot check แบบสุ่ม

นำเช็กลิสต์มาใช้

• พัฒนาความสามารถระดับทีมในการที่มนุษย์ยังถือการออกแบบไว้ แล้วค่อยส่งต่อให้ AI ลงมือทำ โดยระบุข้อจำกัดและ edge case ให้เป็นสเปกอย่างชัดเจน
• เลือกจุดยุทธศาสตร์ที่ห้ามปล่อยมือเด็ดขาด (core domain), เปลี่ยนความไร้ประสิทธิภาพให้เป็นเส้นทางการเรียนรู้แบบตั้งใจ, วัดไม่ใช่แค่ความเร็วแต่รวม ownership ด้วย แต่ต้องระวังกฎของ Goodhart จึงควรใช้เป็นเพียงแผงหน้าปัด ไม่ใช่ KPI

วิกฤตของผู้นำ: คนที่อนุมัติโดยตรวจสอบไม่ได้นั้น สุดท้ายอาจเป็นตัวฉันเอง

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