ชาติตะวันตกได้ลืมวิธีผลิตสิ่งของไปแล้ว และตอนนี้กำลังลืมแม้กระทั่งโค้ด
(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 มีเพียงพอแค่ 2 วัน
- โรงงานของ 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 ปีครึ่งเพื่อเพิ่มผลผลิตได้ไม่ถึง 2 เท่า, และกระสุน 155 มม. ก็ยังไม่ถึงเป้าหมายแม้ทุ่ม 5 พันล้านดอลลาร์มานาน 4 ปี
- แม้แต่ France เองก็ใช้เวลา 17 ปีในการกลับมาผลิตสารขับดันอีกครั้ง และข้อจำกัดสำคัญไม่ใช่เงิน แต่คือ ความรู้และทักษะฝีมือ
- งานวิจัยของ RAND ประเมินว่า 10% ของทักษะการออกแบบเรือดำน้ำยังต้องอาศัยประสบการณ์ภาคสนามอีก 10 ปีหลังจบ PhD และงานฝีมือด้านกลาโหมเองก็ต้องฝึกงาน 2~4 ปี และต้องใช้ 5~8 ปีจึงจะมีความสามารถในการกำกับดูแล
-
เส้นโค้งการเติบโตของสายซอฟต์แวร์ก็ย่อไม่ได้
- นักพัฒนาระดับ junior ต้องใช้เวลา 3~5 ปีจึงจะกลายเป็น mid-level ที่มั่นคง, 5~8 ปีจึงจะเป็น senior และหากจะไปถึง principal หรือ architect มักต้องใช้มากกว่า 10 ปี
- เวลานี้ไม่ได้สั้นลงเพียงเพราะใช้เงินมากขึ้น และดูเหมือนว่าจะย่อด้วย 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
- ยังมีการเพิ่ม reviewer เฉพาะประจำแต่ละโปรเจกต์ เพื่อใช้สายตามากขึ้นในการจับสิ่งที่โมเดลมองข้าม
ขีดความสามารถที่จะขาดแคลนในอนาคต
-
สภาพแวดล้อมที่เทคนิคอย่างเดียวไม่พออีกต่อไป
- จากนี้ความเชี่ยวชาญทางเทคนิคเพียงอย่างเดียวไม่เพียงพอ แต่ยังต้องมี วิจารณญาณและภาวะผู้นำ ที่พร้อมรับผิดชอบ อธิบาย trade-off และผลักข้อเสนอที่ผิดพลาดแต่ถูกนำเสนออย่างมั่นใจโดยเครื่องจักรออกไป
- ในการจ้างงานล่าสุด มีผู้สมัคร 2,253 คน ถูกคัดออก 2,069 คน และรับเข้าจริงเพียง 4 คน คิดเป็นอัตราแปลง 0.18%
- สิ่งนี้สะท้อนความจริงว่า บุคลากรที่มีทั้งทักษะทางเทคนิคและ วิจารณญาณในการระบุข้อผิดพลาดของ AI แทบไม่มีอยู่ในตลาด
-
การทำเอกสารอย่างเดียวไม่ได้จบการถ่ายทอดความรู้
- มีการทำเอกสารอย่างกว้างขวาง ตั้งแต่ Site Books, SDDs, รายงาน RVS ไปจนถึง boilerplate module ที่มี coverage ครบถ้วน
- ตอนนี้วิธีนี้ยังใช้ได้เพราะคนที่อ่านเอกสารยังมีความเชี่ยวชาญทางวิศวกรรม แต่เมื่อความเชี่ยวชาญนั้นหายไป ก็ไม่แน่ชัดว่าวิธีเดิมจะยังใช้ได้อยู่หรือไม่
- ไม่มีใครคาดการณ์ประสิทธิภาพของโมเดลในปี 2031 ได้ และก็ไม่แน่ว่า AI จะเก่งพอจนสร้างปัญหาน้อยลงจริงหรือไม่
-
วิกฤตมาโดยไม่บอกล่วงหน้า และ senior ก็สร้างขึ้นทันทีไม่ได้
- เช่นเดียวกับที่ไม่มีใครคาดคิดว่าในปี 2022 จะเกิดสงครามเต็มรูปแบบในยุโรป วิกฤตไม่ได้มาตามตารางเวลา
- อีก 5~10 ปีข้างหน้า จะต้องการวิศวกร senior ที่เข้าใจระบบทั้งหมด ดีบักเหตุขัดข้องแบบกระจายศูนย์ตอนตี 2 และแบกรับ institutional knowledge ที่อยู่นอก codebase ได้
- แต่คนแบบนั้นไม่ได้ถูกสร้างขึ้นอยู่ในตอนนี้ และ junior ที่ควรได้เรียนรู้ก็ไม่ได้ถูกจ้าง หรือกำลังสั่งสม AI-mediated competence ตามที่งานวิจัยที่ได้รับทุนจาก DoD เรียกไว้
- ความสามารถในการโยนพรอมป์ต์ให้ 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
เป็นงานอ่านที่อยากแนะนำอย่างมาก