ตะวันตกได้ลืมวิธีสร้างสิ่งของไปแล้ว และตอนนี้ก็กำลังลืมวิธีเขียนโค้ด
(techtrenches.dev)- การล่มสลายของขีดความสามารถการผลิตด้านกลาโหม แสดงให้เห็นว่าเมื่อแรงงานฝีมือที่เกษียณไปแล้วและความรู้กระบวนการที่สูญหายไปขาดช่วง ต่อให้เกิดความต้องการในยามสงคราม ก็ไม่สามารถฟื้นการผลิตกลับมาได้อย่างรวดเร็ว
- กรณีการฟื้นการผลิต Stinger, กระสุน 155 มม. และ Fogbank แสดงให้เห็นว่า การปรับให้เหมาะกับต้นทุนและจุดล้มเหลวเพียงจุดเดียว ช่วยเพิ่มประสิทธิภาพในยามปกติ แต่ทำให้ความยืดหยุ่นของห่วงโซ่อุปทานและความเร็วในการฟื้นตัวอ่อนแอลงอย่างมาก
- ซอฟต์แวร์ก็กำลังเคลื่อนไปในเส้นทางที่พึ่งพาทางเลือกทดแทนที่ถูกกว่า จนทำให้ pipeline ของบุคลากร อ่อนแอลง และหลังการนำ AI มาใช้ การลดการจ้างระดับ junior กับการเกิด review bottleneck ก็กำลังรุนแรงขึ้นพร้อมกัน
- ทักษะความชำนาญไม่อาจสร้างขึ้นอย่างรวดเร็วได้ด้วยเงินเพียงอย่างเดียว และทั้งในอุตสาหกรรมกลาโหมกับซอฟต์แวร์ การ สั่งสมความรู้และความชำนาญ ต้องอาศัยประสบการณ์ภาคสนามหลายปีและความสามารถในการตรวจทาน
- หากคนระดับ junior ไม่ได้ผ่านความผิดพลาดในช่วงก่อร่างและการดีบัก ก็จะไม่เกิดการสะสมของ ความรู้ฝังลึก ทำให้ความเสี่ยงที่จะขาดแคลนวิศวกร senior และ institutional knowledge ในอนาคตยิ่งสูงขึ้น
เส้นขนานระหว่างการล่มสลายของศักยภาพการผลิตด้านกลาโหมกับการลดคนในสายงานซอฟต์แวร์
- Raytheon ต้องเรียกวิศวกรวัย 70 กลับมาช่วย ฟื้นการผลิต Stinger โดยอาศัยแบบกระดาษเก่าและอุปกรณ์ทดสอบที่เก็บอยู่ในโกดังเพื่อชุบชีวิตกระบวนการผลิตขึ้นมาใหม่
- หลังจาก Pentagon ไม่ได้สั่งซื้อ Stinger ใหม่มา 20 ปี ความต้องการก็พุ่งขึ้นอย่างรวดเร็วจากสงครามยูเครน แต่สายการผลิตถูกปิดไปแล้ว ชิ้นส่วนอิเล็กทรอนิกส์และ seeker ก็เลิกผลิตไปแล้ว และคำสั่งซื้อในเดือนพฤษภาคม 2022 จะส่งมอบได้ในปี 2026 เท่านั้น
- ความต้องการสูงจนในเวลาเพียง 10 เดือนของสงคราม ก็ใช้ปริมาณการผลิต Stinger เทียบเท่า 13 ปี ไปหมด ทำให้ช่องว่างด้านความรู้การผลิตที่หายไปแล้วและช่องว่างกำลังคนกลายเป็นคอขวดสำคัญ
- แก่นของอุปสรรคไม่ใช่แค่ปัญหาเรื่องงบประมาณ แต่เป็นโครงสร้างที่หลังจาก แรงงานฝีมือที่เกษียณแล้ว หายไป ก็ไม่มีคนทดแทนต่อเนื่องเข้ามา
ความเปราะบางของห่วงโซ่อุปทานที่ถูกเปิดโปงโดยความล้มเหลวในการเพิ่มการผลิตกระสุน
-
คำมั่นสัญญา 1 ล้านนัดกับกำลังการผลิตที่แท้จริง
- EU ให้คำมั่นในเดือนมีนาคม 2023 ว่าจะส่งมอบกระสุนปืนใหญ่ 1 ล้านนัดแก่ยูเครนภายใน 12 เดือน แต่กำลังการผลิตต่อปีของยุโรปมีเพียงราว 230,000 นัด ขณะที่ยูเครนใช้วันละ 5,000~7,000 นัด
- เมื่อถึงเส้นตาย ยุโรปส่งมอบได้เพียงประมาณครึ่งเดียว และจากการสืบสวนของ 11 สื่อใน 9 ประเทศ พบว่ากำลังการผลิตจริงมีเพียงประมาณ 1 ใน 3 ของตัวเลขทางการที่ EU อ้างไว้
- เวลาที่จะทำได้ครบ 1 ล้านนัดจึงเลื่อนไปเป็นเดือนธันวาคม 2024 ช้ากว่าคำมั่นเดิม 9 เดือน
-
โครงสร้างที่มีคอขวดหลายจุดซ้อนกันพร้อมกัน
- France หยุดการผลิตสารขับดันในประเทศตั้งแต่ปี 2007 และหยุดอยู่นาน 17 ปี
- แหล่งผลิต TNT หลักของยุโรปมีเพียงแห่งเดียวใน Poland และกระสุนสำรองของ Germany มีพอใช้แค่สองวัน
- โรงงานของ Nammo ใน Denmark ปิดไปในปี 2020 และต้องเริ่มเดินเครื่องใหม่แทบตั้งแต่ศูนย์
- อุตสาหกรรมกลาโหมยุโรปถูกปรับให้เหมาะกับ สินค้าปรับแต่งราคาแพงปริมาณน้อย และไม่ได้ออกแบบมาโดยตั้งสมมติฐานเรื่องการผลิตจำนวนมากหรือการรับมือวิกฤต
-
สหรัฐฯ ก็มีจุดอ่อนคล้ายกัน
- สหรัฐฯ เองก็พึ่งพาโรงงานแห่งเดียวใน Scranton และโรงงานบรรจุวัตถุระเบิดแห่งเดียวใน Iowa อีกทั้งขาดการผลิต TNT ภายในประเทศมาตั้งแต่ปี 1986
- แม้จะอัดฉีดเงินหลายพันล้านดอลลาร์ ปริมาณการผลิตก็ยังไปไม่ถึงแม้แต่ครึ่งของเป้าหมาย
การเพิ่มประสิทธิภาพด้านต้นทุนที่สร้างจุดล้มเหลวเพียงจุดเดียว
- ในปี 1993 Pentagon ส่งสัญญาณไปยัง CEO ของบริษัทกลาโหมว่า ถ้าไม่ควบรวมก็จะถูกคัดออก และหลังจากนั้นผู้รับเหมาด้านกลาโหมรายใหญ่ 51 รายก็เหลือเพียง 5 ราย
- ซัพพลายเออร์มิสไซล์ทางยุทธวิธีลดจาก 13 รายเหลือ 3 ราย อู่ต่อเรือลดจาก 8 รายเหลือ 2 ราย และแรงงานลดจาก 3.2 ล้านคนเหลือ 1.1 ล้านคน หรือลดลง 65%
- single point of failure เกิดขึ้นทั่วห่วงโซ่อุปทานกระสุน และการผลิตตัวกระสุน 155 มม. ก็ไปกระจุกอยู่ที่ผู้ผลิตรายเดียวใน Coachella, California
- ประจุขับดันก็พึ่งพาสถานที่แห่งเดียวใน Canada เช่นกัน การเพิ่มประสิทธิภาพแบบยึดต้นทุนต่ำสุดช่วยให้มีประสิทธิภาพในยามปกติ แต่แทบไม่เหลือพื้นที่เผื่อสำหรับการพุ่งขึ้นของอุปสงค์
เมื่อความรู้หายไป การฟื้นกลับมาก็ช้าลง
-
ความล้มเหลวในการฟื้น Fogbank
- Fogbank เป็นวัสดุลับที่ใช้ในหัวรบนิวเคลียร์ ผลิตตั้งแต่ปี 1975 ถึง 1989 แล้วสถานที่ผลิตก็ถูกปิดลง
- ในปี 2000 มีความพยายามจะผลิตมันอีกครั้งสำหรับโครงการยืดอายุการใช้งาน แต่คนส่วนใหญ่ที่มีความเชี่ยวชาญในการผลิตได้เกษียณ เสียชีวิต หรือออกจากหน่วยงานไปแล้ว และแทบไม่เหลือบันทึกใด ๆ
- ตาม ข้อมูลที่เกี่ยวข้องจาก GAO ต้องใช้เงินเพิ่มอีก 69 ล้านดอลลาร์และทำ reverse engineering อยู่หลายปี จึงจะได้ Fogbank ที่ผลิตได้กลับมาอีกครั้ง
-
ความรู้ฝังลึกที่ไม่ได้อยู่ในเอกสารคือปัจจัยตัดสิน
- Fogbank ที่ผลิตขึ้นใหม่มีความบริสุทธิ์สูงเกินไป และเพิ่งมาพบภายหลังว่า สิ่งเจือปนที่ไม่ได้ตั้งใจ ซึ่งมีอยู่ในล็อตดั้งเดิมกลับมีความสำคัญต่อการทำงานจริง
- ข้อมูลนี้ไม่ได้อยู่ในเอกสารใดเลย มีเพียงคนงานที่เคยผลิตดั้งเดิมเท่านั้นที่รู้ แต่คนเหล่านั้นเกษียณไปแล้ว
- เหตุผลที่แม้แต่วัสดุที่ตัวเองเคยสร้างยังสร้างซ้ำไม่ได้ ก็เพราะ ความรู้นั้นคงอยู่ในตัวคนเท่านั้น
ซอฟต์แวร์ก็กำลังเดินไปในเส้นทางเดียวกัน
-
ทางเลือกที่ถูกและเร็วกว่า กำลังทำให้ pipeline บุคลากรอ่อนแอลง
- รูปแบบการแทนที่ขีดความสามารถที่สร้างมาหลายสิบปีด้วยทางเลือกที่ถูกกว่า แล้วทำให้ pipeline ของกำลังคนมนุษย์อ่อนแอลง ก่อนจะพบในยามวิกฤตว่าความสามารถที่เคยตัดทิ้งไปกลับจำเป็นอีกครั้งนั้น กำลังเกิดขึ้นทั้งในกลาโหมและซอฟต์แวร์
- หากในกลาโหม ทางเลือกทดแทนนั้นคือ peace dividend ในซอฟต์แวร์ AI ก็กำลังเข้ามาอยู่ในตำแหน่งเดียวกัน
- ทั้ง การพังทลายของ pipeline บุคลากร และ วิกฤตความเข้าใจ ได้เริ่มปรากฏชัดแล้ว และกรณีของกลาโหมก็ชี้ให้เห็นด้วยว่าระยะเวลาการฟื้นฟูนั้นยาวนานเพียงใด
-
การฟื้นฟูต้องใช้เวลา มากกว่าเงิน
- การเพิ่มการผลิตอาวุธหลักใช้เวลา 3~5 ปีสำหรับระบบง่าย และ 5~10 ปีสำหรับระบบซับซ้อน
- Stinger ใช้เวลาอย่างน้อย 30 เดือนตั้งแต่สั่งซื้อจนส่งมอบ, Javelin ใช้เวลา 4 ปีครึ่งเพื่อเพิ่มกำลังการผลิตได้ไม่ถึงเท่าตัว, และกระสุน 155 มม. แม้ทุ่มเงิน 5 พันล้านดอลลาร์ก็ยังต่ำกว่าเป้าหมายในปีที่ 4
- แม้แต่ France ก็ยังใช้เวลา 17 ปีในการกลับมาผลิตสารขับดันอีกครั้ง และข้อจำกัดหลักอยู่ที่ ความรู้และความชำนาญ มากกว่าเงินทุน
- งานวิจัยของ RAND มองว่า 10% ของทักษะการออกแบบเรือดำน้ำยังต้องอาศัยประสบการณ์ภาคสนาม 10 ปีหลังจบ PhD และแรงงานฝีมือด้านกลาโหมเองก็ต้องฝึกงาน 2~4 ปี และต้องใช้ 5~8 ปีจึงจะมีขีดความสามารถระดับกำกับดูแล
-
เส้นโค้งการเติบโตในซอฟต์แวร์ก็ย่อไม่ได้
- นักพัฒนาระดับ junior ต้องใช้เวลา 3~5 ปีจึงจะไปถึง mid-level ที่มั่นคง, 5~8 ปีจึงถึง senior, และมากกว่า 10 ปีจึงจะไปถึงระดับ principal หรือ architect
- เวลานี้ไม่อาจย่นได้ด้วยการใช้เงินเพิ่ม และก็ดูยากที่จะบีบอัดได้ด้วย AI เช่นกัน
คอขวดและการอ่อนตัวของทักษะหลังการนำ AI มาใช้
-
คอขวดด้านการตรวจทานใหญ่กว่าความเร็วในการผลิต
- ใน การทดลองแบบสุ่มมีกลุ่มควบคุมของ METR เมื่อนักพัฒนาที่มีประสบการณ์ใช้เครื่องมือเขียนโค้ดด้วย AI งานโอเพนซอร์สจริงกลับใช้เวลานานขึ้น 19%
- ก่อนเริ่มทดลอง ผู้เข้าร่วมคาดว่า AI จะทำให้เร็วขึ้น 24% แต่ช่องว่างระหว่างความคาดหมายกับผลจริงสูงถึง 43 จุดเปอร์เซ็นต์
- ในการทดลองต่อเนื่อง สัดส่วนนักพัฒนาที่บอกว่าหากต้องทำงานโดยไม่มี AI ก็จะไม่เข้าร่วมก็มีไม่น้อย และดูเหมือนจะไม่ง่ายแล้วที่จะจินตนาการถึงการกลับไปทำงานแบบไม่มี AI
-
การลดการจ้างและการลดลงของการสมัครเรียนมหาวิทยาลัย
- Salesforce ระบุว่าจะไม่มีการจ้างวิศวกรซอฟต์แวร์เพิ่มในปี 2025
- จากการสำรวจของ LeadDev ผู้นำด้านวิศวกรรม 54% มองว่า AI copilots จะลดการจ้างระดับ junior ในระยะยาว
- การสำรวจของ CRA พบว่า 62% ของภาควิชาคอมพิวติ้งในมหาวิทยาลัยรายงานว่าจำนวนนักศึกษาลงทะเบียนลดลงในปีนี้
-
code review กลายเป็นข้อจำกัดหลัก
- AI สร้างโค้ดได้รวดเร็ว แต่การ review โดยมนุษย์ดำเนินไปช้า จึงเกิด review bottleneck
- เพื่อตอบสนองต่อเรื่องนี้ จึงเปลี่ยนมาไม่ให้ AI ตรวจทานโค้ดของ AI กันเอง และบังคับให้ใน pull request template ต้องใส่รายละเอียดการเปลี่ยนแปลง เหตุผลของการเปลี่ยนแปลง ประเภทของการเปลี่ยนแปลง และภาพหน้าจอก่อน-หลัง
- ยังมีการเพิ่มผู้ตรวจทานประจำแต่ละโปรเจกต์ เพื่อให้มีสายตามนุษย์มากขึ้นช่วยจับสิ่งที่โมเดลพลาดไป
ขีดความสามารถที่อาจขาดแคลนในอนาคต
-
สภาพแวดล้อมที่เทคโนโลยีอย่างเดียวไม่เพียงพออีกต่อไป
- ตอนนี้ความเชี่ยวชาญทางเทคนิคเพียงอย่างเดียวไม่พอแล้ว แต่ยังต้องมี วิจารณญาณและภาวะผู้นำ ที่พร้อมรับผิดชอบ อธิบาย trade-off และผลักข้อเสนอที่ผิดพลาดแต่เครื่องนำเสนออย่างมั่นใจออกไปได้
- ในการรับสมัครครั้งล่าสุด มีผู้สมัคร 2,253 คน ถูกปฏิเสธ 2,069 คน และรับเข้าทำงานเพียง 4 คน อัตราการเปลี่ยนผ่านอยู่ที่ 0.18%
- สิ่งนี้สะท้อนความจริงว่าตลาดแทบไม่มีคนที่มีทั้งทักษะเทคนิคและ วิจารณญาณในการระบุความผิดพลาดของ AI พร้อมกัน
-
การทำเอกสารอย่างเดียวไม่ได้หมายความว่าการถ่ายทอดความรู้เสร็จสิ้น
- มีการทำเอกสารอย่างกว้างขวาง ทั้ง Site Books, SDDs, รายงาน RVS และแม้แต่ boilerplate modules ที่มี coverage ครบถ้วน
- ตอนนี้มันยังใช้ได้ เพราะคนที่อ่านเอกสารเหล่านั้นยังมีความเชี่ยวชาญทางวิศวกรรมอยู่ แต่เมื่อความเชี่ยวชาญนั้นหายไป วิธีเดิมจะยังใช้ได้เหมือนเดิมหรือไม่ก็ยังไม่แน่นอน
- ไม่มีใครคาดเดาสมรรถนะของโมเดลในปี 2031 ได้ และก็ไม่แน่ชัดว่า AI จะดีพอจนสร้างปัญหาน้อยลงหรือไม่
-
วิกฤตมาโดยไม่แจ้งล่วงหน้า และ senior ก็สร้างขึ้นทันทีไม่ได้
- เช่นเดียวกับที่ไม่มีใครคาดคิดว่าในปี 2022 จะเกิดสงครามเต็มรูปแบบในยุโรป วิกฤตไม่ได้มาให้ตรงตามตารางเวลา
- อีก 5~10 ปีข้างหน้า จะต้องการวิศวกร senior ที่เข้าใจทั้งระบบ ดีบักปัญหา distributed outage ตอนตี 2 ได้ และแบกรับ institutional knowledge ที่อยู่นอก codebase ทั้งหมดไว้
- แต่คนแบบนั้นไม่ได้ถูกสร้างขึ้นอยู่ในตอนนี้ และเหล่า junior ที่ควรได้เรียนรู้ก็ไม่ได้ถูกจ้าง หรือกำลังสะสมสิ่งที่งานวิจัยจากทุน DoD เรียกว่า AI-mediated competence
- ความสามารถในการโยน prompt ให้ AI อาจยังคงอยู่ แต่ความสามารถในการชี้จุดที่ AI ผิดอาจไม่เติบโตขึ้นเลย
ความเสี่ยงที่โค้ดอาจกลายเป็น Fogbank
- หากเหล่า junior ข้ามขั้นตอนการดีบักและความผิดพลาดในช่วงก่อร่าง ความรู้ฝังลึก ก็จะไม่ถูกสะสม และเมื่อวิศวกรรุ่นปัจจุบันเกษียณ ความรู้นั้นก็จะไม่ถูกถ่ายโอนไปยัง AI
- ผลลัพธ์คือความรู้อาจหายไปอย่างสิ้นเชิง และนี่เชื่อมโยงกับโครงสร้างเดียวกับสิ่งที่เกิดขึ้นกับ Fogbank
- สงครามยูเครนคือช่วงเวลาที่ความล้มเหลวจากการปรับให้เหมาะที่สุดของอุตสาหกรรมกลาโหมถูกแปลงกลับมาเป็นต้นทุนจริง และ Stinger, Javelin, Fogbank รวมถึงกระสุนปืนใหญ่ 1 ล้านนัดที่ผลิตไม่ได้ ก็แสดงให้เห็นราคาที่ต้องจ่ายนั้น
- วิศวกรรมซอฟต์แวร์ก็กำลังเดิมพันกับการเพิ่มประสิทธิภาพแบบเดียวกัน และหาก AI ดีพอ การพนันนี้อาจถูกต้อง แต่ถ้าไม่ใช่ ใบแจ้งหนี้แบบเดียวกันก็อาจย้อนกลับมาได้
1 ความคิดเห็น
ความเห็นจาก Hacker News
ปัญหาที่แท้จริงไม่ใช่ AI เอง
แต่เป็นแนวทางการบริหารที่ทำให้คนและองค์กรไม่มีพื้นที่หายใจ เพราะมันไม่สร้าง กำไรทันที แล้วก็ยังเชื่อว่าพอถึงเวลาจำเป็น ความรู้นั้นจะยังคงอยู่
การลดต้นทุนระยะสั้นทำให้ลดการจ้าง junior และยังทำให้วิศวกรที่มีประสบการณ์ไม่มีเวลาสอน จนตัดขาด การถ่ายทอดความรู้โดยนัย
สุดท้ายสิ่งที่เหลือมีแค่เอกสารกับระบบอัตโนมัติ แต่เอกสารไม่ใช่ประสบการณ์หน้างาน และระบบอัตโนมัติก็แทนวิจารณญาณไม่ได้
พอคนที่เคยลงมือจัดการระบบจริงหายไป ความรู้โดยนัยก็หายออกจากองค์กร และสุดท้ายผลิตภาพก็ลดลง
ตอนนี้ AI ก็ถูกขายด้วยรูปแบบเดียวกัน และในหลายด้านมันดูใกล้เคียงกับ การลดจำนวนคน มากกว่าการเพิ่มผลิตภาพ
เป็นวิธีคิดคล้ายกับตอนที่ GE หมกมุ่นกับผลประกอบการรายไตรมาสและผลตอบแทนผู้ถือหุ้นจนทำให้ศักยภาพระยะยาวกลวงเปล่า
คนตัดสินใจที่อยู่ห่างจากงานวิศวกรรมจริงเชื่อว่าเครื่องมือ กระบวนการ และเอกสาร สามารถแทนความรู้โดยนัยได้ แต่ความจริงไม่ใช่แบบนั้น
ถ้ากำจัดคนและท่อส่งการเรียนรู้ออกไป ความรู้นั้นจะไม่คงอยู่ในองค์กร แต่จะหายไปเลย
ไม่มีเผื่อไว้สำหรับการทดลอง การซ่อม หรือการรับแรงกระแทกเลย และผมมองว่าระบบที่พังทุกวันนี้ 90% ก็พังเพราะไม่มี slack สำหรับรับแรงกระแทกระยะสั้น
โปรเจกต์สตาร์ตอัปต้องสร้างอะไรใหม่ตลอดอยู่แล้ว ฟีเจอร์ที่เพิ่มขึ้นจึงแปลเป็นคุณค่าได้ทันที แต่บริษัทอย่าง Visa, Salesforce, LinkedIn มักอยู่ในจุดที่มีทั้งผลิตภัณฑ์ ฟีเจอร์ และทรัพยากรเพียงพออยู่แล้ว
บริษัทแบบนี้มักอยู่ในสภาพที่พยายามฝืนหา “ตะปู” ให้เข้ากับค้อนชื่อ write more software
ถึงจะดูเหมือนมี wishlist กับระบบ A/B test มากมาย แต่ถ้าการเขียนซอฟต์แวร์เพิ่มทำเงินได้ชัดจริง ก็น่าจะทำกันไปแล้ว
การเติบโตจริงและดีมานด์ใหม่มักเกิดนอกบริษัทกลุ่มนี้มากกว่า และบริษัทที่ยังสร้างหรือซื้อซอฟต์แวร์ไม่เก่งอาจกลับเป็นฝ่ายคว้าโอกาสได้
และแกนสำคัญคือ fungibility
ทุนมนุษย์ไม่ใช่ของที่หยิบมาแพ็กใหม่ได้ง่าย ๆ แต่มันเป็นสิ่งมีชีวิต และท่อส่งคนเก่งกับทักษะ ถ้าขาดเมื่อไร ก็อาจหายไปตรงนั้นเลย
ความเสี่ยงของ AI coding ก็อยู่ตรงที่มันแค่ดึงทุนมนุษย์ที่มีอยู่มาใช้ แต่สร้างทุนมนุษย์ใหม่สำหรับอนาคตไม่ได้
ความรู้เกี่ยวกับระบบที่ผมดูแลอยู่จำนวนมาก ทำเป็นเอกสาร ได้ และในทางทฤษฎีคนใหม่ก็รับช่วงต่อจากเอกสารเหล่านั้นได้
แต่ปัญหาคือปริมาณเอกสารที่ต้องใช้มันมากเกินจริง
ต่อให้เป็นระบบเล็ก ๆ ผมก็คิดว่าต้องใช้เอกสาร A4 หลายหมื่นหน้า แบบแน่นเอี้ยด
คนรับงานใหม่ต้องเข้าใจเอกสารมหาศาลนั้นแทบทั้งหมดจนเกือบท่องได้ และบริษัทก็มักไม่อยากจ่ายทั้งต้นทุนการเขียนเอกสารหรือค่าเรียนรู้ของคนใหม่
จากประสบการณ์ผม มันเลยทำไม่ได้ในทางปฏิบัติ ไม่ใช่เพราะเป็นไปไม่ได้โดยหลักการ
เรากำลังค่อย ๆ ตัด เหตุผลที่จะคุยกับคนอื่น ออกไป
ทุกครั้งที่ถาม AI ก็เท่ากับการปฏิสัมพันธ์แบบมนุษย์กับเพื่อนร่วมงานหายไปหนึ่งครั้ง
นี่ไม่ใช่แค่เรื่องการเขียนโค้ด แต่ทำให้นึกถึงว่าการมี ChatGPT อยู่ในกระเป๋าตลอดเวลา กำลังแทนที่ปฏิสัมพันธ์ทางสังคมแบบไหนบ้าง
มนุษย์เป็นสิ่งมีชีวิตทางสังคมโดยเนื้อแท้ แต่เรากำลัง optimize การเข้าสังคมให้หายไปให้ได้มากที่สุด
ผมเองก็ไม่พ้นกระแสนี้ เพราะเดี๋ยวนี้ชอบใช้ Doordash มากกว่าโทรหาร้านอาหารเหมือนเมื่อก่อน
ในโลกอุดมคติ บริษัทควร optimize กำไรระยะสั้นถึงกลาง รัฐบาลควร optimize ประโยชน์ระยะยาว และบุคคลควร optimize ตลอดช่วงชีวิตของตัวเอง
ถ้าบริษัทลด slack และเดินเครื่องจนตึง รัฐบาลก็ควรรักษาพื้นที่เผื่อและการไหลเข้าของบุคลากรด้วยกฎระเบียบ เพื่อปกป้องขีดความสามารถของประเทศ
แต่ในตะวันตก ดูเหมือนกลุ่มล็อบบี้กับ MBA จะครอบงำบริษัท และลากรัฐบาลไปสู่การ optimize เอาแต่เงิน ด้วย
เหตุผลที่ผมยังเขียนโค้ดทุกวันโดยไม่ใช้ตัวช่วยเขียนโค้ด ก็เพราะเชื่อว่าต้องทำแบบนั้นถึงจะไม่ลืม สัมผัสของการลงมือเอง แม้ในเรื่องเล็กน้อย
เหตุผลหลักที่ไม่ใช้ AI คือเวลาอยู่หน้าจอ ผมไม่อยาก พึ่งพาอะไร ถ้าเลี่ยงได้
แน่นอนว่าไม่รวมเอกสาร หนังสือ หรือ Stack Overflow
ผมเห็นคนรอบตัวจำนวนมากพึ่ง AI แม้แต่งานจุกจิกในชีวิตประจำวันทั้งหมด ซึ่งสำหรับผมมันหมายถึงการลดความพยายามในการคิดลงอย่างรุนแรง และมันค่อนข้างน่ากลัว
การยกแรงงานทางความคิดนั้นให้ไปไม่ใช่เรื่องเล็ก
สำหรับผม พอยกมันให้ไปก็เหมือนกลายเป็นซอมบี้ที่ต้องพึ่งพิง และผมมองว่าความรู้เกิดจากการลองผิดลองถูกซ้ำ ๆ แทบทุกวัน
เทคโนโลยีแสดงให้เห็นมาโดยตลอดว่ามันสามารถผลักและชี้นำมนุษย์ได้ และการพึ่ง AI ก็ดูเหมือนรูปแบบสุดท้ายที่บริษัทจะรุกล้ำเข้าไปถึงความสามารถที่ละเอียดอ่อนที่สุดของมนุษย์ นั่นคือ พลังในการคิดและความอยากรู้อยากเห็น
ผมใช้เวลาส่วนใหญ่ไปกับความสับสนและความหงุดหงิด และหลังจากต่อสู้กับปัญหาเกือบ 7 ชั่วโมงก็ทำงานเสร็จ
แต่ความยากนั้นเองทำให้ช็อก จนผมกังวลว่าสมองตัวเองอาจจะฝ่อไปหน่อยเพราะไม่ได้ใช้
แล้วผมก็นึกขึ้นได้ว่าเดิมทีเวลาจะแก้ปัญหาใหม่ ผมก็ลำบากแบบนั้นอยู่แล้ว
ความรู้สึกของการปะทะกับปัญหาที่ไม่เคยเจอนั้นเดิมทีมันก็ยากระดับนั้นอยู่แล้ว แค่ผมไม่ชินกับความรู้สึกนั้นแล้ว
ถ้าชินกับความยาก มันจะดูเป็นเรื่องปกติ แต่ถ้าชินกับสภาวะที่ไร้ความยาก พอกลับมาเจออีกครั้งมันจะรู้สึกท่วมท้นและแปลกประหลาด
เพราะงั้นผมคิดว่าความสามารถในการทน ความไม่สบายและความยาก เป็นกล้ามเนื้อที่ต้องรักษาไว้
ที่มันกลายเป็นปัญหาจริง ๆ ก็มีแค่ตอนย้ายงานใหม่แล้วต้องเขียนโค้ดสัมภาษณ์บนแพลตฟอร์มที่ไม่มี syntax checking หรือ autocomplete เลย ซึ่งผมก็เลยฝึกในสภาพแวดล้อมแบบนั้นล่วงหน้า
ในงานจริง การพึ่ง autocomplete ด้าน syntax ไม่เคยเป็นปัญหาใหญ่ และสิ่งสำคัญคือ แนวคิดหลักของภาษา กับความเข้าใจ runtime
เช่นการเข้าใจว่า event loop ของ Node.js ทำงานอย่างไร และจะเขียนโปรแกรมแบบ asynchronous กับ event-driven อย่างไรให้ถูก
โค้ดที่ deploy ในช่วง 6 เดือนที่ผ่านมา แทบจะพูดได้ว่าผมแทบไม่ได้อ่านเองแม้แต่บรรทัดเดียว
แต่การทำงานแบบนั้นกลับเหนื่อยกว่ามาก
ตอนเขียนโค้ดด้วยมือตัวเอง กระบวนการแก้ปัญหามันเหมือนการต่อพัซเซิล พอแก้ได้ก็มี วงจรความพึงพอใจ กับรางวัลโดปามีน
ตอนนี้เวลาส่วนใหญ่ในแต่ละวัน ผมรู้สึกเหมือนเป็น เจ้าหน้าที่ QA มากกว่าเป็นคนแก้พัซเซิล และมันบั่นทอนมาก
ต่อให้ AI แก้ปัญหายากแทนให้ ความพึงพอใจจาก ตู้สล็อต LLM ก็ยังอ่อนกว่าการที่ผมแก้ได้เองมาก
อีก 2 วันที่เหลือจะไม่ใช้ตัวช่วยเขียนโค้ด และให้มันช่วยรีวิวหลังงานเสร็จเท่านั้น
ผมมองว่าวิธีนี้ดีต่อสุขภาพจิต และยังช่วยรักษาคมของฝีมือไว้ได้
ต่อให้เป็นภาษาที่เคยเก่งมาก ส่วนที่เป็นงานเชิงกลไกก็จะพร่ามัวเร็ว
เพราะงั้นงานแบบ LLM-assisted สำหรับผมคงเหมือนเอาน้ำยาฟอกขาวราดสมอง
ยิ่งใช้มาก ผมก็ยิ่งรู้สึกว่ามันไม่ดีต่อผม
ความสามารถในการจัดโครงสร้างสิ่งที่ต้องทำและแก้ปัญหายังโอเคอยู่ แต่ส่วน nuts and bolts ของงานจริงจะระเหยหายเร็วมาก
ประโยคที่ว่า เงินไม่ใช่ข้อจำกัด ความรู้ต่างหากที่เป็นข้อจำกัด ฟังดูประชดประชันดี
เพราะตัวบทความเองก็ มีสำนวนเหมือน AI เขียน มากจนอ่านยาก
จังหวะมันไม่เป็นธรรมชาติ สะดุดเป็นช่วง ๆ และเต็มไปด้วยลักษณะคำพูดแบบ LLM
ความสามารถในการเขียนเองก็เป็นทักษะที่เสื่อมถอยได้เหมือนกัน
ผมเข้าใจนะถ้าใช้ AI เพราะอยากให้ภาษาลื่น แต่ผมกลับรู้สึกว่า AI translation ยังดีกว่าข้อความที่ generate ขึ้นมา
ถ้าผู้เขียนไม่ได้สนใจถึงขั้นเขียนเอง ผมก็ไม่ค่อยเห็นเหตุผลว่าทำไมผมต้องอ่าน
สำหรับผม โค้ดกับร้อยแก้วไม่ได้ต่างกันในระดับแก่นสารขนาดนั้น
ทั้งสองอย่างประกอบด้วยคีย์เวิร์ด ไวยากรณ์ โครงสร้าง และการจัดวางที่มีความหมาย
ถ้าประโยคที่ AI สร้างขึ้นไม่มีความหมายหรืออ่านยาก ตามตรรกะเดียวกัน โค้ดที่ AI สร้าง ก็ควรอ่านยากและเชื่อถือยากเหมือนกัน
อยากให้เลิกใช้มาตรฐานสองชั้นสักที
ตรงกันข้าม มันยังดีกว่า บทความน้ำท่วมทุ่งจาก AI ที่บน HN มักปล่อยผ่านกันว่าโอเคอยู่บ่อย ๆ มาก
ดังนั้นลักษณะบางอย่างที่คนรู้สึกว่าเป็นสไตล์เฉพาะของ LLM จริง ๆ แล้วอาจเป็นสำนวนที่มนุษย์ใช้มาก่อน แล้วมนุษย์ก็เอากลับมาใช้ซ้ำผ่านมันอีกทอดหนึ่งก็ได้
ปกติผมเห็นบทความ AI ตามอันดับบนเว็บค้นหาวันละหลายชิ้นแล้วก็เลื่อนผ่านทันที แต่บทความนี้ดูต่างจากพวกนั้นพอสมควร
ผมไม่ค่อยเชื่อว่าบริษัทจะประเมิน ระดับประสบการณ์ ของนักพัฒนาได้แม่นจริง
การแบ่งเป็น junior, mid, senior, lead เป็นแค่ภาพลักษณ์ภายนอก ทั้งที่ความจริงมันเป็นความต่อเนื่องหลายแกนและบิดเบือนได้ง่ายตามเทคโนโลยีที่กำลังฮิต
ถ้าพูดแบบเคร่ง ๆ ผมคิดว่าต่อให้ไม่ได้ถูกบริษัทจ้าง ก็ยังอาจเป็นนักพัฒนาระดับ senior ได้
สุดท้ายสิ่งสำคัญคือความตั้งใจจะเรียนรู้และลงมือสร้างด้วยตัวเอง รวมถึงเวลาที่ลงทุนลงไป
ทุกวันนี้สิ่งที่บริษัทต้องการจริง ๆ ดูเหมือนจะไม่ใช่ความสามารถพัฒนาซอฟต์แวร์เท่าไร แต่เป็นประสบการณ์ในการหาทางเลี่ยง โครงสร้างองค์กรที่พัง กับระบบสื่อสารและงบประมาณที่งุ่มง่าม
แบบนั้นเรียกว่า senior หรือแค่เก่งการเมืององค์กร ผมก็ไม่แน่ใจ
และเวลาโครงการซอฟต์แวร์ล้มเหลวจนภาพลวงตาถูกกระชากออก รูปแบบนี้จะยิ่งเห็นชัด
แบบแรกคือคนที่พอได้รับปัญหามา ก็เรียนรู้สิ่งที่ต้องรู้เองได้ ขุดลึกในส่วนที่ไม่รู้ สร้างผลลัพธ์ที่มีความหมายได้ซ้ำ ๆ สื่อสารกับคนที่จำเป็น อัปเดตความคืบหน้า ช่วยทีมและขอความช่วยเหลือได้ และยังเติมเต็มส่วนที่ตกหล่นก่อนใคร
ที่เหลือก็คือที่เหลือ
ภายในไม่กี่ปีแรกของอาชีพก็มักเห็นแล้วว่าใครอยู่ฝั่งไหน และแทบเป็นไปไม่ได้เลยที่จะเปลี่ยนคนกลุ่มหลังให้เป็นคนกลุ่มแรก
เพราะงั้นต่อให้มีประสบการณ์ 30 ปีเป็น senior ก็ยังอาจอยู่กลุ่มหลังได้ และคนที่เพิ่งเรียนจบก็อาจอยู่กลุ่มแรกได้เหมือนกัน
แน่นอนว่ามีคนที่เก่งมากเรื่องการเมืององค์กร มนุษยสัมพันธ์ หรือการขายตัวเอง จนในสายตาผู้บริหารดูเหมือนอยู่กลุ่มแรก ทั้งที่จริงอยู่กลุ่มหลัง
แต่นั่นก็ไม่ใช่เรื่องความสามารถในการสร้างซอฟต์แวร์แล้ว
และถึงจะอยู่กลุ่มแรก ก็ยังอาจถูกประเมินต่ำหรือไม่ได้เลื่อนตำแหน่ง ความสัมพันธ์กับความสำเร็จในอาชีพจริง ๆ ก็ไม่ได้สูงขนาดนั้น
จะติดป้ายอะไรให้ตัวเองก็ทำได้ แต่มันก็แปลกอยู่หน่อย
ฟรีแลนซ์ถูกประเมินจากพอร์ตโฟลิโอ นักวิชาการด้านคอมพิวเตอร์จากงานวิจัย และผู้มีส่วนร่วมกับ OSS จากปริมาณและผลกระทบของ contribution
ไม่ว่าแบบไหน สุดท้ายก็แปรผันตามความพยายามที่ลงไปกับการเรียนรู้และการสร้าง
แต่ไม่ว่าจะถูกจ้างหรือไม่ ความเป็นมืออาชีพก็ไม่ได้ถูกกำหนดด้วยสิ่งที่เรียนจากหนังสือเพียงอย่างเดียว
เรื่องอย่าง การจัดการผู้มีส่วนได้ส่วนเสีย หรือการนำเสนอทางแก้ เป็นสิ่งที่อ่านอย่างเดียวเรียนไม่ค่อยได้ ต้องอาศัยการฝึกจริงและ feedback
วิศวกรระดับ senior ไม่ใช่แค่คนที่เขียนโค้ดเก่ง แต่คือคนที่ช่วยสร้างคุณค่าได้ด้วยตัวเองตลอดทั้ง SDLC และช่วยคนอื่นได้ด้วย และทักษะแบบนั้นน่าจะพัฒนาได้ง่ายกว่าใน สภาพแวดล้อมมืออาชีพ มากกว่าในโปรเจกต์สมัครเล่น
ซึ่งโดยมากก็ต้องใช้ทักษะทางสังคมและทักษะองค์กร ถึงจะไม่ชอบ แต่โลกมันก็หมุนแบบนั้น
พร้อมกันนั้นผมก็อยากไม่ต้องรู้เรื่องพวกนี้ให้มากที่สุด
ผมไม่อยากบิดหัวตัวเองให้เข้ารูปเพื่อใคร และการทำงานท่ามกลางปัญหาแบบนี้ก็เป็นความทรมานล้วน ๆ
มันคล้ายกับการถามว่าศัลยแพทย์ที่ไม่เคยถูกจ้างจะเป็น senior surgeon ได้ไหม
ถ้าไม่มีประสบการณ์ทำเป็นอาชีพจริงมาหลายปี ก็ยากจะเรียกว่า senior และสายนี้ก็เกือบจะพูดได้ว่า ประสบการณ์คือทุกอย่าง
หนังสืออย่างเดียวไม่พอจะทำให้ซึมซับความเข้าใจที่จำเป็น และมนุษย์ก็ไม่ได้ internalize ได้มากพอจากการอ่านหรือดูเฉย ๆ
ต้องลงมือทำจริงถึงจะเกิดการเรียนรู้จริง
คุณอาจเรียนข้อเท็จจริงและเทคนิคจากหนังสือได้ แต่การอ่านหนังสือเรื่องร้านอาหารมิชลินไม่ได้ทำให้กลายเป็น Michelin Chef ได้ทันที
AI code generator เหมือนโทรลล์
มันตอบอย่างมั่นใจ ดูเหมือนมีเหตุผล แต่บางส่วนผิด และสุดท้ายมนุษย์ก็ต้องมานั่งจับผิดมัน
มันไม่สนุกและไม่มี flow
ผมชอบแก้ข้อผิดพลาดที่คนอื่นทำไว้ และยิ่งชอบความรู้สึกแบบ เอาชนะ LLM
แทนที่จะเข้าสู่ภาวะลื่นไหลแบบเดิม ผมกลับโฟกัสได้นานกว่าเวลาเฝ้าจับตา LLM แบบไม่ลดละ
มันไม่มีตรรกะ มีแค่ การทำซ้ำของแพตเทิร์น แล้วผมก็ไม่เข้าใจว่าทำไมวิศวกรที่ฉลาดถึงยังหลงเชื่อมัน
มันค่อนข้างประชดดีที่ตัวบทความเองก็ดูเหมือนชัดพอสมควรว่ามี AI ช่วยเขียน
ผมไม่ได้จะวิจารณ์การใช้ AI ช่วยเขียน แต่พอเอามาวางข้างหัวข้อของบทความแล้ว มันชวนให้คิดเหมือนกัน
คนดูเหมือนจะใช้มันเพื่อ “ขัดเกลา” ข้อความ แต่ในความจริงสิ่งที่ยังไม่ได้เอาไปขัดอาจอ่านลื่นกว่าด้วยซ้ำ
ช่วงนี้สิ่งที่กวนใจผมมากเป็นพิเศษคือการเขียนประโยคแบบใช้จุดพร่ำเพรื่อแทนลูกน้ำ
My people lived the other side of this equation. Not the factory floor. The receiving end.มันเหมือนตั้งใจจะเพิ่มน้ำหนัก แต่ใช้แม้ในจุดที่ไม่จำเป็น จนให้ความรู้สึกเหมือนกำลังอ่านข้อความพากย์ตัวอย่างหนังแอ็กชัน
ไม่ใช่ว่ามีปัญหาเชิงจริยธรรมกับการใช้ AI นะ แต่ สไตล์แบบ LLM มันชวนระคายเคืองมาก
แถมคนยังใช้มันเพื่อเติมปริมาณข้อความและ filler ที่ไม่จำเป็นเข้าไปเรื่อย ๆ จนตอนนี้ต้องคอยลุยผ่านบทความแบบนั้นทีละหลายหน้า
ที่แย่กว่านั้นคือ ไม่มีวิธีง่าย ๆ ที่จะบอกได้ว่าข้อความนั้นอย่างน้อยยังอาศัย insight ใหม่จากมนุษย์อยู่ หรือเป็นแค่การสั่ง write me something about X แล้วให้มันสร้างทั้งหมด
ในระดับคุณภาพตอนนี้ ถ้าเป็นแบบหลัง จะบอกว่าแทบไม่มีค่าให้อ่านเลยก็คงไม่เกินจริง
สำหรับผมมันให้ความรู้สึกเหมือนนักบวชที่ด่าคนรักร่วมเพศ แล้วถูกจับได้ว่าขึ้นเตียงกับโสเภณีชาย
จะเสพโคเคนด้วยหรือไม่ก็แล้วแต่ แต่ยังไงก็ทิ้งรสขมไว้ในปากอยู่ดี
ในข้อความนี้ไม่ได้มีร่องรอย AI แบบจำเจที่คนชอบพูดถึงมากนัก และในมุมผม สิ่งที่ดูคล้าย LLM ก็มีแค่โครงสร้างประโยคสั้น ๆ หนักแน่น
แต่สไตล์แบบนั้นก็ถือเป็นรูปแบบการเขียนที่มีอำนาจพอสมควรในโลกภาษาอังกฤษมาตั้งแต่ Hemingway แล้ว
ผมชักรู้สึกว่าเมื่อก่อน ทางเลือกที่ถูกกว่าของ AI ไม่ใช่ AI แต่เป็น ทีมพัฒนาสัญญาจ้างระยะไกลจากยุโรปตะวันออก มากกว่า
ตั้งแต่แรกคนก็ไม่ได้มีมากพออยู่แล้ว
และแม้แต่ที่นี่ ทางตะวันออกของเส้นเมริเดียน 15 องศาตะวันออก ทุกคนก็โดนปลดเหมือนกัน
แผนจริง ๆ ดูเหมือนใกล้เคียงกับการ “ทำน้อยลงโดยรวม” ถ้าไม่ใช่เรื่อง AI และเหมือนทุกคนเอาแต่มองว่าใครจะเริ่มปลดก่อน
ผมทำงานพาร์ตไทม์อยู่ 6 เดือน และคนตัดสินใจก็บอกชัดว่าระยะยาวแบบนี้ดีกว่า
มันดีกว่าการถูกเลิกจ้างก็จริง แต่ผมอยู่กับชีวิตแบบนั้นต่อไปไม่ไหว
ผมเป็นคนประหยัดนะ แต่ก็ไม่ถึงขั้นนั้น
พวกเขาไม่อยากจ่ายเงินจริง ๆ โดยเฉพาะยิ่งไม่อยากจ่ายให้ คนอเมริกันและประกันสุขภาพ
มันรู้สึกแปลกที่บริษัทอเมริกันกำลังวิ่งบนเส้นทางเร็วในการผลักคนอเมริกันออกจากงาน แต่กลับแทบไม่มีอะไรหยุดยั้ง
ในฐานะคนยุโรป ผมก็เห็นนักพัฒนายุโรปตะวันออกแน่นอน แต่ไม่ได้มีอยู่ในทุกบริษัทที่ผมเคยทำงานด้วย
ตรงกันข้าม คนอินเดียมีอยู่เสมอ
เรื่องคุณภาพก็เป็นเรื่องเดิม ๆ ตลอด ผมจะไม่ลงรายละเอียด แต่คนที่พร้อมรับฟังคงรู้แล้วว่าผมกำลังจะสื่ออะไร
เมื่อมองจากวิชา Formal verification in software ที่ผมได้ยินครั้งแรกช่วงปลายยุค 80 ไปจนถึงวิชา Programming in Java ที่ผมฝากให้นักศึกษาปีแรกสอนตอนต้นยุค 2000 ก่อนลาออก ผมรู้สึกว่าความเข้มงวดทางวิชาการพังลงจากหน้าผา และถูกแทนที่ด้วย การจัดแนวเพื่อการจ้างงาน
สิ่งที่สอนเมื่อก่อนใกล้เคียงกับการสอนให้คิด แต่หลัง ๆ กลายเป็นการสอนให้ได้งานเงินดี
เพราะบริษัทไม่อยากฝึกพนักงานใหม่อีกต่อไป
ทั้งเงินเดือนผู้ฝึกหัดและต้นทุนของคนสอนล้วนต้องใช้เงิน พวกเขาเลยผลักค่าใช้จ่ายนั้นไปให้มหาวิทยาลัย นักศึกษา และภาครัฐ ผ่านการ บังคับใช้วุฒิการศึกษา
มันน่าแปลกที่คนจะมองว่าถ้าบังคับให้พนักงานจ่ายค่าฝึกเป็นเงื่อนไขการทำงาน มันมีกลิ่นตุ๋น แต่กลับยอมรับ ระบบ degree mill กันได้ง่ายเหลือเกิน
มนุษย์ไม่ได้สมบูรณ์แบบ
ตอนที่ผมไป ยูเครน ไม่กี่วันก่อนการรุกรานของรัสเซีย การท่องเที่ยวและโรงแรมในเคียฟถูกมาก และพอถามคนท้องถิ่นถึงความเป็นไปได้ของการรุกราน ทุกคนก็ตอบว่า มันจะไม่เกิดขึ้น
ปฏิกิริยาคือรัสเซียก็พูดก้าวร้าวแบบนี้เรื่อยมา แต่ไม่ทำจริงหรอก
การเตรียมพร้อมไม่พอ และผลก็คือสูญเสียดินแดนไป 20% ภายในไม่กี่วัน
หลังกลับออสเตรีย ผมก็ยังคิดไม่ตกว่าบางคนที่ผมเคยเจออาจตายไปแล้ว
หลังจากนั้นตอนเป็นผู้ประกอบการและวิศวกรอยู่ใน Dubai และ Saudi Arabia ผมก็ถามว่าถ้าโดรนโจมตีโครงสร้างพื้นฐานจะทำอย่างไร ซึ่งถ้าดูสงครามรัสเซียกับการโจมตีครั้งแรกของอิหร่าน ก็ควรคาดการณ์การโจมตีแบบนั้นได้แน่
แต่ผมก็ยังได้คำตอบอีกว่า มันจะไม่เกิดขึ้น
เพราะเตรียมพร้อมไม่ดี จึงเสียหายไปหลายหมื่นล้านดอลลาร์ ทั้งที่ถ้ายอมใช้เพียงหลายร้อยล้านดอลลาร์ตลอดหลายปี ก็น่าจะป้องกันได้
สุดท้ายปัญหาไม่ใช่ AI แต่คือ มนุษย์
ถ้าไม่เตรียมไว้ ป่านนี้ตัวแทนฝ่ายรัสเซียคงนั่งอยู่ในเคียฟแล้ว
การที่ยื้อ 2 สัปดาห์แรกไว้ได้ ทำให้สถานการณ์กลายเป็นสงครามยืดเยื้อ และสงครามดอนบัสก็ลากมายาว 8 ปี แล้ว
ผมไม่คิดว่าชาวยูเครนอยู่ในภาพลวงตาว่าคู่กรณีตรงหน้าไม่ใช่รัสเซีย
บางทีพอขุดลึกลงไปก็พบว่ามีเพื่อนที่ต้องได้สัญญานั้น หรือไม่ก็ขายความกลัวว่าถ้าศัตรูบุกมา ครอบครัวคุณจะตายทันที
คุณแค่ยกสองกรณีที่มีคนพูดว่า ไม่มีทางเกิด แล้วสุดท้ายมันเกิดขึ้นจริงมาเท่านั้น
แล้วกรณีอีกมหาศาลที่มีคนพูดเหมือนกันและสุดท้ายก็ไม่เกิดอะไรขึ้นล่ะ จะอธิบายยังไง
ถ้าผมบอกกับคนหลายล้านคนที่ซื้อลอตเตอรี่ทุกคนว่า “คุณไม่ถูกรางวัลหรอก” ผมก็จะทำนายถูกเกือบทั้งหมด
ที่มีคนหนึ่งถูกรางวัล ไม่ได้แปลว่าคำทำนายผมผิดเสมอไป มันอาจเป็นแค่ reporting bias
ทุกคนอาจไม่ได้มั่นใจว่า Putin จะโง่ได้ถึงขนาดนั้น แต่กองทัพยูเครนยุ่งมากกับการเตรียมแนวป้องกัน เสบียงสำรอง และยุทธวิธีรับมือเผื่อเกิดเหตุขึ้นจริง
ยิ่งนานวัน ผมยิ่งรู้สึกว่า programming as theory building ของ Peter Naur สำคัญขึ้นเรื่อย ๆ
ลิงก์: https://gwern.net/doc/cs/algorithm/1985-naur.pdf
เป็นงานอ่านที่อยากแนะนำอย่างมาก