นักพัฒนาบางคนใน Amazon บอกว่างานของพวกเขาเริ่มคล้ายงานในคลังสินค้า

 (nytimes.com)
7 คะแนน โดย GN⁺ 2025-05-26 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • นักพัฒนา Amazon กำลังเผชิญกับ แรงกดดันด้านความเร็วในการทำงานและการทำให้งานเรียบง่ายลง หลังการนำ AI มาใช้
  • ผู้จัดการ ผลักดันอย่างหนัก ให้ใช้เครื่องมือ AI โดยให้เหตุผลเรื่อง การเพิ่มผลิตภาพ
  • บางคนมองว่าการลดงานซ้ำๆ ทำให้ คุณภาพของงานดีขึ้น แต่ก็มี ความกังวลว่านักพัฒนารุ่นใหม่จะสูญเสียโอกาสในการเติบโต
  • เมื่อ การเขียนโค้ดเปลี่ยนจากการสร้างสรรค์โดยตรงไปเป็นงานที่เน้นการตรวจทานและยืนยัน บางคนจึงรู้สึกว่านี่ไม่ใช่งานของตัวเองอีกต่อไป
  • กลุ่มภายในบริษัทอย่าง Amazon Employees for Climate Justice กำลัง แบ่งปันความเครียดจากงานและความกังวลต่ออนาคต ซึ่งรวมถึงประเด็นนี้ด้วย

At Amazon, Some Coders Say Their Jobs Have Begun to Resemble Warehouse Work

ยุคที่การเขียนโค้ดก็กลายเป็นการแข่งขันด้านความเร็ว

  • นับตั้งแต่การปฏิวัติอุตสาหกรรม ปรากฏการณ์ การทำให้งานเรียบง่ายลงจากการใช้เครื่องจักร ที่เกิดซ้ำๆ กำลังเกิดขึ้นในสายงานการเขียนโค้ดด้วย
  • AI ไม่ได้ ทำให้ตำแหน่งงานหายไป แต่กำลัง เปลี่ยนงานเดิมให้เป็นรูปแบบที่ทำได้ง่ายและเร็วขึ้น
  • ตามงานวิจัยของ Microsoft ผลิตภาพของนักพัฒนาที่ใช้ผู้ช่วย AI อย่าง ‘Copilot’ เพิ่มขึ้นมากกว่า 25%
  • Amazon ยอมรับแนวทางนี้และกำลังเรียกร้องให้ทำงาน เร็วขึ้นและมีประสิทธิภาพมากขึ้นด้วย AI โดยเน้นย้ำใน จดหมายถึงผู้ถือหุ้น ว่านี่คือหัวใจของ ‘การลดต้นทุนและรักษาความสามารถในการแข่งขัน’
  • ตัวอย่างเช่น มีทีมพัฒนาทีมหนึ่งที่ ทำงานด้วยจำนวนคนเพียงครึ่งหนึ่งของปีก่อน แต่ยังถูกคาดหวังให้ส่งมอบโค้ดในปริมาณเท่าเดิม

แนวโน้มทั้งภาคธุรกิจ

  • Shopify ระบุชัดว่าการใช้ AI เป็นข้อกำหนดพื้นฐาน สำหรับพนักงานทุกคน และ นำไปใช้ในการประเมินผลงาน ด้วย
  • Google ใช้หัวข้อ การพัฒนาเครื่องมือ AI เพื่อยกระดับผลิตภาพในงานประจำวัน ในแฮ็กกาธอนภายในองค์กร และตอนนี้ มากกว่า 30% ของโค้ดถูกสร้างจากข้อเสนอแนะของ AI แล้ว

ด้านบวกและความกังวล

  • ผู้จัดการบางคนอ้างว่าการนำ AI มาใช้ช่วยลด งานน่าเบื่อและงานซ้ำๆ ทำให้โฟกัสกับงานที่สร้างสรรค์มากขึ้น
  • Amazon ระบุว่า AI ช่วย ประหยัดงานพัฒนาไปได้เทียบเท่า 4,500 ปี
  • แต่ Lawrence Katz นักเศรษฐศาสตร์จาก Harvard ชี้ว่า ผลกระทบด้านลบคือโอกาสเติบโตในงานของนักพัฒนามือใหม่อาจหายไป
  • คล้ายกับ ‘การแข่งขันด้านความเร็ว’ ที่แรงงานโรงงานเคยเผชิญ นักพัฒนาก็กำลังถูกกดดันให้ ทำงานให้เร็วขึ้นและรับมือกับปริมาณงานที่มากขึ้น

การเปลี่ยนแปลงที่นักพัฒนารับรู้

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

การเติบโตในอาชีพและการมีส่วนร่วมที่ลดลง

  • นักพัฒนามือใหม่อาจ สูญเสียโอกาสในการทำความเข้าใจโค้ดอย่างลึกซึ้ง เพราะระบบอัตโนมัติด้านการทดสอบ
  • AI ช่วยสนับสนุน งานหลากหลายตั้งแต่การเขียนเอกสารวางแผนไปจนถึงการทดสอบโค้ด แต่สภาพแวดล้อมการประเมินกำลังเปลี่ยนไปเป็นแบบ ยึดเครื่องมือเป็นศูนย์กลางมากกว่ามนุษย์
  • Harper Reed อดีต CTO ของแคมเปญ Obama มองว่านี่คือยุคที่ ไม่จำเป็นต้องเข้าใจทุกส่วนอย่างลึกซึ้ง และอธิบายว่านี่คือ การเปลี่ยนแปลงที่คล้ายภาคการผลิต
  • ในทางกลับกัน Simon Willison ประเมิน AI ในแง่บวกว่า ช่วยให้การทำไอเดียให้เกิดขึ้นจริงเร็วขึ้น

ความไม่พอใจและปฏิกิริยาในองค์กร

  • จากการใช้ AI และการเปลี่ยนแปลงของงานที่ตามมา นักพัฒนาจำนวนมากกำลัง แบ่งปันความกังวลและความเครียด กันในกลุ่ม Amazon Employees for Climate Justice
  • โดยเฉพาะความกังวลเรื่อง คุณภาพงานที่ลดลงและความไม่แน่นอนของเส้นทางอาชีพ ซึ่งคล้ายกับ ความเครียดจากการแข่งขันด้านความเร็ว ที่แรงงานในอุตสาหกรรมยานยนต์เคยรู้สึก
  • แม้ยังไม่มีความเคลื่อนไหวในการจัดตั้งสหภาพแรงงานของนักพัฒนา แต่ ฉันทามติภายในองค์กรกำลังขยายตัวมากขึ้น

บริบททางประวัติศาสตร์และแนวโน้มในอนาคต

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-05-26
ความคิดเห็นจาก Hacker News
  • แชร์ลิงก์ archive.ph/HVZRL
  • สำหรับฉัน การพัฒนาแบบใช้ LLM ดูเป็นกระแส hype ที่ถูกปั่นเกินจริงคล้ายคริปโตหรือ VR ประสบการณ์ล่าสุดในการแก้บั๊กของโค้ดเบสที่เขียนด้วย vibe coding ทำให้รู้สึกว่าวิธีนี้คือก้อนความยุ่งเหยิงชนิดหนึ่ง ที่ย้ายปัญหาธุรกิจซึ่งไม่มีระบบไปเป็นโค้ดโดยไม่มีโครงสร้าง เมื่อส่วนที่ต้องปรับปรุงถูกอุดด้วยแพตช์แคบ ๆ ผลลัพธ์ก็คือโค้ดที่ซับซ้อนและไร้ระเบียบ พอชนข้อจำกัดของ context window แล้ว LLM ก็จำแม้แต่แพตช์ที่ตัวเองทำไว้ไม่ได้ ภาษาอังกฤษ (หรือภาษามนุษย์) ก็คลุมเครือเกินกว่าจะอธิบายโค้ดที่ฉันต้องการได้อย่างแม่นยำ และการคลี่ทุกประสบการณ์กับบทเรียนลองผิดลองถูกจำนวนมหาศาลที่นักพัฒนาระดับซีเนียร์ฝังไว้ในโค้ดออกมาเป็นพรอมป์ต์นั้นเป็นงานที่หนักมาก สิ่งที่ต่างจากคำถามว่า "ทำไมถึงเขียนแบบนี้" คือมันต้องการรายการที่เฉพาะเจาะจงและไม่มีวันจบว่า "ในสถานการณ์แบบนี้อย่าทำแบบนี้ แต่ให้ทำแบบนั้น"
    • เป็นข้อสังเกตที่ตรงกับคำอธิบายของโค้ดเบสส่วนใหญ่ที่ฉันเห็นมาตลอด 30 ปีที่ผ่านมาแทบทั้งหมด (ยกเว้นแค่หนึ่งเดียว)
    • ขอแย้งนิดหนึ่ง—AI ก็เคยช่วยให้ฉันหาแพตเทิร์นของโค้ดในราว 30 จุดที่ต้องดึงโครงสร้างออกมาได้ ปัญหาของ vibe coding คือทัศนคติ คนที่พยายามเลี่ยงการเขียนโค้ดเองมักโฟกัสแค่ความสะดวกตอนนี้มากกว่าคุณภาพหรือโครงสร้างระยะยาว มันเลยเหมือนตัวขยายความขี้เกียจ
    • ความจริงแล้วโค้ดโปรดักชันจำนวนมากก็คือชุดเศษ snippet ที่ทำงานได้เพราะถูกแปะแพตช์ไปเรื่อย ๆ น่าเศร้าที่ในโลกจริง CPU เร็วมากจนโค้ดแบบนี้ก็ยังรันได้เฉย ๆ
    • เห็นด้วยกับประเด็นที่ว่าภาษามนุษย์ไม่ชัดเจน สุดท้ายความพยายามจะจัดการซอฟต์แวร์อย่างชัดเจนด้วยภาษาธรรมชาติก็ถูกลองมาหลายครั้งแล้ว และเหมือนกฎหมาย มันหนีไม่พ้นพื้นที่สีเทาในการตีความ ถ้าอนาคตนักพัฒนาต้องมาถกเถียงกันเรื่องความหมายของโปรแกรมก่อนคอมไพล์ อนาคตนั้นก็มืดมน
    • AI ก็ดูเป็น hype ที่เกินจริงพอ ๆ กับคริปโตหรือ VR แต่สุดท้ายระบบอัตโนมัติก็จะกระทบแม้อาชีพที่มีความเป็นเทคนิคสูงอย่างวิศวกรรมซอฟต์แวร์ ตลอด 10 ปีที่ผ่านมา คนในวงการเทคหลงคิดว่าตัวเองไม่เกี่ยวกับปัญหาของแรงงานกลุ่มอื่น แต่ตอนนี้วัฒนธรรมการรีออร์ก/เลย์ออฟกำลังทำให้การกดค่าจ้างเกิดขึ้นอย่างจริงจัง แม้ AI จะยังแทนคนทั้งระบบไม่ได้ทันที แต่เมื่อสิ่งที่เคยต้องใช้ 5 คน กลายเป็นใช้ 4 คนร่วมกับ AI ได้ ก็จะมี 1 คนถูกปลด และคนที่เหลือก็ไม่กล้าขอขึ้นเงินเดือน วงจรแบบนี้จะเกิดซ้ำ ๆ วงการเทคเองก็ต้องตระหนักว่าในที่สุดแล้วพวกเขาก็คือแรงงาน
  • ต่อความเห็นของ Harper Reed ที่ว่า “ไม่จำเป็นต้องเข้าใจโค้ดอย่างลึกซึ้ง” คำพูดแบบนี้กลับให้ความรู้สึกเหมือนตรรกะลวก ๆ แบบ “แค่คอมไพล์ผ่านก็ปล่อยขึ้นโปรดักชันเถอะ” แม้ในสายการผลิตอัตโนมัติจะมีการวัดคุณภาพอย่างต่อเนื่อง แต่เครื่องจักรจริงไม่ได้เกิดภาพหลอนอย่างการอ่านมุมผิดหรือเชื่อมผิดจุดแบบไร้สาระซ้ำ ๆ ขณะที่ซอฟต์แวร์ที่อิง LLM กลับมีความคลาดเคลื่อนเล็ก ๆ แบบนี้เกิดซ้ำอยู่เรื่อย ๆ
  • น่าสงสัยว่าเครื่องมือที่อิง LLM ได้เพิ่มผลิตภาพของนักพัฒนาอย่างก้าวกระโดดจริงหรือไม่ หรือองค์กรแค่ค้นพบว่าพวกเขาใช้จำนวนนักพัฒนาที่น้อยลง—และมีอภิสิทธิ์น้อยลงกว่าเดิม—ก็พอแล้ว ฉันยังไม่ค่อยเห็นกรณี “เพิ่มผลิตภาพแบบพลิกเกม” ในบริษัทเทคขนาดใหญ่ และจนถึงตอนนี้สิ่งที่มีดูเหมือนเป็นแค่การเพิ่มผลิตภาพเล็กน้อยพอให้หักล้างเงินลงทุนได้เท่านั้น
    • ส่วนหนึ่งมากคือปัญหาเรื่องการรับรู้ เมื่อก่อนการพัฒนาเป็นงานยาก แต่พอมีเครื่องมือ AI คนก็มองว่าอุปสรรคในการเริ่มเขียนโค้ดต่ำลง ซอฟต์แวร์ดีเวลลอปเมนต์เลยค่อย ๆ ให้ความรู้สึกเหมือนงานโรงงานมากขึ้น และความพึงพอใจทางปัญญาก็ลดลง
    • สงสัยเรื่องความสามารถในการบำรุงรักษาโค้ดเบสระยะยาว vibe coding จะค่อย ๆ สะสมความซับซ้อน บั๊กที่ละเอียดอ่อน และปัญหาเชิง abstraction จนสุดท้ายทำให้การบำรุงรักษาและการพัฒนาฟีเจอร์ใหม่ยากขึ้น มีความเสี่ยงว่าจะติดกับดักผลิตภาพระยะสั้นแต่คุณภาพระยะยาวลดลง
    • องค์กรต่าง ๆ ใช้กระบวนการแบบราชการเพื่อ “ลดความเป็นเทคนิค” มานานแล้ว กล่าวคือแทนที่ทักษะชั้นสูงด้วยแรงงานที่มาตรฐานกว่า แม้จะเป็นกลยุทธ์ที่ระยะยาวอาจย้อนกลับมาทำร้ายตัวเอง แต่ตราบใดที่มีความสม่ำเสมอ พวกเขาก็ยอมอยู่กับ “โซลูชันธรรมดาที่พอใช้ได้”
    • ถ้าตรรกะนี้จะฟังขึ้น ก็ต้องตั้งสมมติฐานว่าฝ่ายบริหาร Amazon ให้ความสำคัญกับกำไรระยะสั้นมากกว่าคุณภาพระยะยาว แต่ฉันยังไม่มั่นใจเรื่องนั้น
  • ในฐานะคนที่ใกล้เกษียณ ฉันรู้สึกหดหู่กับการเปลี่ยนแปลงช่วงหลัง ตอนเริ่มต้นเส้นทางอาชีพในยุค 90 ยังมีเวลายาว ๆ ให้ทดลองและดื่มด่ำกับความคิดสร้างสรรค์ ทุกวันนี้กลับกลายเป็นว่าต้องมีงานย่อย รายงานสถานะ และการคอยอธิบายตัวเองอยู่ตลอด ต่อไปก็คงยังมีนักพัฒนาที่น่าสนใจอยู่ แต่โอกาสแบบนั้นกำลังลดลง ที่จริงมันก็เป็นเส้นทางเดียวกับอาชีพอื่น ๆ ที่ชีวิตยากขึ้นเพราะระบบอัตโนมัติ ซึ่งก็นับว่ายุติธรรมดี
    • การรายงานสถานะประจำวันอย่าง stand-up นั้นกินเวลา แถมเป็นเพียงการตอบสนองเชิงพิธีกรรมเพื่อให้ฉันได้พ้นจากคนที่ไม่เข้าใจงานของฉันไปอีกหนึ่งวัน มันลดคุณค่าของงานลง
    • ฉันก็เข้าทำงานตั้งแต่ยุค 90 และรู้สึกร่วมกับปรากฏการณ์ที่ทุกอย่างถูกควบคุมอย่างละเอียดผ่าน JIRA แต่ก็ไม่ได้คิดว่าอดีตคือยุคทองเสมอไป บางทีเราอาจได้อิทธิพลจากความทรงจำแบบเลือกจำแต่เรื่องดี ๆ อย่างไรก็ตาม ทุกวันนี้ก็ยังมีงานที่ท้าทายและดีพอ รวมถึงสิ่งให้เรียนรู้อีกมาก
    • มากกว่าการทำให้งานวิศวกรอัตโนมัติ มันทิศทางไปทางแทนที่งานบริหารด้วยการเฝ้าติดตามที่ขับเคลื่อนด้วย AI เสียมากกว่า
  • ถ้าอยากเร่งความเร็วในการพัฒนาซอฟต์แวร์แบบก้าวกระโดด ก็มีอีกวิธีคือคัดลอกโค้ดโอเพนซอร์สของคนอื่นมาใช้ตรง ๆ แล้วลบร่องรอยด้านลิขสิทธิ์/ไลเซนส์ออกก่อนนำไปใช้ ถ้ากลัวถูกจับได้เองก็จ้างเอาต์ซอร์สมา “ฟอก” ให้ หรือเดี๋ยวนี้ใช้ AI ฟอกได้ทั้งถูกและเร็ว Google เมื่อก่อนยังยับยั้งชั่งใจเรื่องนี้อยู่และไม่กล้าพอ แต่สตาร์ทอัพเล็ก ๆ กลับหวังความสำเร็จรวดเร็วด้วยการใช้ AI โดยไม่สนความเสี่ยงละเมิดลิขสิทธิ์
    • ในอุตสาหกรรมที่ฉันอยู่ ปัญหาใหญ่ยิ่งกว่าการไม่มีโค้ด คือการนิยามว่า “ต้องทำอะไรและทำอย่างไร” มีปัญหาเฉพาะตัวจำนวนมากที่แก้ไม่ได้ด้วย Stackoverflow หรือ Github
    • ที่จริง Google ก็ทำแบบนี้มานานแล้ว คือดึงคอนเทนต์จากเว็บไซต์คนอื่นไปแสดงตรงในผลการค้นหา ใช้คอนเทนต์ของคนอื่นโดยไม่ส่งทราฟฟิกกลับไป รอบนี้แค่ช้ากว่าเดิมเท่านั้น
    • น่าประหลาดดีที่บางคนกลับหวังให้บริษัทยักษ์ใหญ่ลอกโค้ดโอเพนซอร์สบ้าง อย่างน้อยมันก็ยังดีกว่าที่ผู้ใช้ต้องถูกบังคับให้ใช้วิธีทำงานเย็นชาและไร้ประสิทธิภาพที่บริษัทเหล่านั้นสร้างเอง
    • เห็นด้วยกับข้อจำกัดของการเอาโค้ดขึ้นโอเพนซอร์ส บริษัทยักษ์ใหญ่มักส่งเสริมโอเพนซอร์สเพราะเป็นวิธีดึงแรงงานฟรี แม้ระยะสั้นการมีส่วนร่วมจะลดลง แต่ระยะยาวอุตสาหกรรมอาจสุขภาพดีขึ้น
    • ชี้ถึงความไร้ความรับผิดชอบของทั้งการมาของ ChatGPT และภาวะผู้นำของ Sam Altman
  • คำพูดของ Simon Willison ที่ว่าการอ่านโค้ดยากและสนุกน้อยกว่าการเขียน รวมถึงกรณีนักพัฒนา Amazon ที่ AI ช่วยงานประกอบอย่างการเขียนเอกสารและการทดสอบได้มาก เป็นสิ่งที่น่าประทับใจ ตอนนี้บทบาทกำลังเปลี่ยนจากการเขียนโค้ดไปเป็นการรีวิวโค้ดเดิมและแก้บั๊กมากกว่า
    • ทำให้นึกถึงช่วงแรก ๆ ที่การเขียนโค้ดสนุกมาก ตอนนี้ฉันกลับสนุกกับการแก้บั๊กมากกว่า และ LLM ก็รับหน้าที่งานโค้ดซ้ำ ๆ ง่าย ๆ ไป ทำให้ฉันโฟกัสกับโจทย์ที่ท้าทายได้ ด้วย LLM ความสนุกบางส่วนของงานพัฒนายังพออยู่รอด
    • บรรยากาศที่สัมผัสได้จากบทความนี้ค่อนข้างเป็นลบ
  • เมื่อมีเทคโนโลยีเพิ่มผลิตภาพใหม่ ๆ ออกมา บริษัทก็จะรีบคว้าผลประโยชน์และทำให้มันกลายเป็นมาตรฐาน ถ้าจะตามให้ทันก็ต้องเรียนรู้อย่างต่อเนื่อง และวันหนึ่งก็อาจต้องคิดเรื่องย้ายไปสู่สภาพแวดล้อมที่เราเก็บเกี่ยวผลจากการเติบโตของตัวเองได้โดยตรงมากขึ้น (เช่น ทำธุรกิจเอง) แต่การทำงานคนเดียวก็หมายถึงต้องแข่งขันกับคนที่ใช้ AI ได้คล่องด้วย จึงไม่ใช่คำตอบง่าย ๆ
    • คาดการณ์อนาคตไว้สามฉากทัศน์ 1) โค้ดเบสจะค่อย ๆ พังทลายลงสู่ความสับสนและความไม่เสถียร จนสุดท้ายอาจต้องดึงนักพัฒนามากประสบการณ์กลับมาในราคาสูง 2) AI สร้างโค้ดที่พอใช้งานได้ คุณภาพและความน่าเชื่อถือไม่สูงนักแต่ก็ไม่ถึงกับเกิดหายนะใหญ่ 3) AI ฉลาดขึ้นอย่างรวดเร็วจนแนวคิดเรื่องโค้ดเบสหายไป กลายเป็นยุคของซอฟต์แวร์ที่ถูกสร้างและวิวัฒน์แบบไดนามิกตามความต้องการ ซึ่ง LLM ปัจจุบันยังห่างไกลมาก ผู้บริหารบริษัทเชื่อในข้อ 3 แต่ตอนนี้ความจริงยังอยู่ระหว่างข้อ 1 กับ 2 และถ้าบริหารจัดการดี ก็อาจไปสู่มุมมองสมดุลแบบข้อ 2 ได้
    • ยังมีโมเดลที่แบ่งปันผลประโยชน์จากผลิตภาพอย่างยุติธรรมกว่านี้ได้ เช่น การลดชั่วโมงทำงานแบบยุโรปในอดีต ทุกวันนี้แม้แต่คนทำงานเองก็ดูเหมือนกำลังง่วนอยู่กับงานจุกจิกประหลาดที่ทำให้ดูยุ่งอยู่ตลอด
    • ที่จริงคุณกำลังพูดจากมุมมองแบบมาร์กซิสต์ แต่แปลกดีที่ข้อสรุปกลับไปจบที่ความแปลกแยกจากตัวเอง ทั้งที่ถ้ารวมพลังกันอีกนิดก็น่าจะปรับปรุงอะไรได้ แต่กลับไม่ทำ
    • อย่ายอมรับว่าต้องใช้ชีวิตแบบพัฒนาตัวเองไม่หยุดเพียงอย่างเดียว ยังมีวิธีร่วมมือกับสมาชิกในสังคมแล้วเรียกร้องต่อนายจ้างไปด้วยกันได้ด้วย สัปดาห์ทำงาน 5 วัน วันละ 8 ชั่วโมง และการห้ามใช้แรงงานเด็กก็ล้วนเป็นผลจากการลงมือร่วมกัน ไม่จำเป็นต้องตั้งหน้าตั้งตาทำแต่งานของตัวเองและมองแต่เรื่องให้คนอื่นประสบความสำเร็จ
  • ฉันประหลาดใจเสมอกับการที่อุตสาหกรรมของเราดูเป็นเด็ก ๆ ลงเรื่อย ๆ ใครที่เคยทำงานในบริษัทใหญ่หรือกับโค้ดเบสขนาดใหญ่ย่อมรู้ว่าการสร้างโค้ดใหม่เป็นเพียงส่วนเล็ก ๆ ของการพัฒนาเท่านั้น
    • ที่จริงงานอื่นนอกจากการเขียนโค้ดใหม่ หรือส่วนประกอบจุกจิกอื่น ๆ ก็ไม่มีประสิทธิภาพในองค์กรใหญ่เหมือนกัน AI อาจเปลี่ยนจุดนี้ด้วยและทำให้การประชุมไม่รู้จบหรือการถกเถียงเชิงนามธรรมลดลง
    • คนจำนวนมากที่กำลังตื่นเต้นอยู่ตอนนี้ ที่จริงคือคนที่ติดอยู่กับกระบวนทัศน์ล่าสุดจนแม้แต่การเขียนโค้ดเองก็ยากขึ้น พอมีเครื่องมือ LLM อย่าง Copilot ก็รีบทำ POC ให้เสร็จไวแล้วดันขึ้นโปรดักชัน โดยไม่ได้คิดลึกเรื่องคุณภาพหรือการขยายระบบมากนัก แล้วคนกลุ่มนี้ก็ออกมาโฆษณากรณีเพิ่มผลิตภาพจาก AI แบบเหมารวมโดยเชื่อมไปกับผลประโยชน์ของบริษัทใหญ่ ทั้งที่คนที่ใช้งานจริงต่างก็รู้ว่ามันยังมีจุดน่าผิดหวังอีกมาก
    • ฉันเองใช้เวลาแค่ราว 20% ไปกับการเขียนโค้ด ที่เหลือเป็นการเก็บ requirement ออกแบบ ทดสอบ และจัดการตารางงาน ถ้างานเขียนโค้ด 20% นั้นลดลงครึ่งหนึ่ง ฉันก็น่าจะเอาเวลาที่เหลือไปทำการทดสอบหรือเขียนเอกสารเพิ่มได้
  • มีความเข้าใจผิดว่า LLM จะเพิ่มประสิทธิภาพการพัฒนาได้มหาศาล ทั้งที่จริงจะเพิ่มผลิตภาพโดยไม่เสียคุณภาพได้ก็ต่อเมื่อมีพื้นฐานฝีมือเดิมอยู่ก่อน กล่าวคือมันเป็นตัวคูณผลิตภาพสำหรับคนมีประสบการณ์ แต่ถ้าเอา LLM ไปให้กองทัพมือใหม่จำนวนมาก คุณก็ยากจะได้ซอฟต์แวร์คุณภาพดี
    • ได้ยินข้ออ้างแบบนี้ซ้ำ ๆ แต่ประเด็นสำคัญคือเส้นตัดของคำว่า “คุณภาพ” อยู่ตรงไหน จริง ๆ แล้วทีมเรียนรู้ของนักพัฒนารุ่นใหม่ที่ฉันรู้จักมีเพื่อนสาย SRE คอยรีวิวรายสัปดาห์ และใช้ LLM อย่างจริงจังด้วย คุณภาพโค้ดและการขยายระบบก็ถือว่าเพียงพอ แค่ช้าหน่อยแต่ความสมบูรณ์ไม่ได้แย่
    • มีแค่บางที่เท่านั้นที่ต้องการซอฟต์แวร์ “ดี” จริง ๆ และถ้าดูโครงสร้างรายได้ของบริษัทอย่าง Deloitte หรือ Accenture จะเห็นว่าบริษัทส่วนใหญ่แทบไม่ได้สนใจคุณภาพเลย สำหรับคนส่วนมาก ซอฟต์แวร์ที่ “ดูพอใช้ได้” ก็เพียงพอแล้ว