LLM ช่วยเพิ่มประสิทธิภาพการทำงานของโปรแกรมเมอร์ได้มากแค่ไหนกันแน่?

• เครื่องมือช่วยเขียนโค้ดที่อิงกับ LLM เปิดตัวมาได้ราว 2 ปีแล้ว
• นักพัฒนาบางคนรายงานว่าประสิทธิภาพการทำงาน เพิ่มขึ้นได้สูงสุด 5 เท่าถึง 10 เท่า
• อย่างไรก็ตาม ยังไม่มี หลักฐานที่ชัดเจน ว่าประสิทธิภาพของทั้งอุตสาหกรรมซอฟต์แวร์เพิ่มขึ้น 5~10 เท่า
• ในความเป็นจริง สำหรับงานที่มากกว่าการเพิ่มฟีเจอร์ boilerplate แบบง่าย ๆ ลงใน codebase เครื่องมือ LLM มักทำงานได้อย่างยุ่งยาก
• โปรแกรมเมอร์ส่วนใหญ่ไม่รู้วิธีใช้เครื่องมือ LLM อย่างมีประสิทธิภาพ หรือไม่ก็ไม่ได้สนใจ

ทำไมการเพิ่มประสิทธิภาพจึงกระจุกตัวอยู่กับผู้ใช้บางกลุ่มเท่านั้น

• หากประสิทธิภาพเพิ่มขึ้น 5 เท่าถึง 10 เท่า ก็มีแนวโน้มสูงว่าจะ จำกัดอยู่ในกลุ่มผู้ใช้ขั้นสูงหรือผู้พัฒนาที่เชี่ยวชาญเพียงส่วนน้อย ที่ใช้ LLM ได้เก่ง
• ไม่มีสัญญาณว่าทั้งอุตสาหกรรมซอฟต์แวร์กำลังส่งมอบฟีเจอร์ที่มีประโยชน์ได้มากขึ้นอย่างรวดเร็ว หรือมีคุณภาพดีขึ้นอย่างเห็นได้ชัด
• ผู้เขียนแทบไม่รู้สึกถึงอิทธิพลของ LLM เลยตลอดช่วง 1~2 ปีที่ผ่านมา

แล้วจริง ๆ LLM ทำให้เกิดโปรเจ็กต์แบบไหนได้บ้าง?

• ยังไม่ชัดเจนว่ามีโปรเจ็กต์ใดบ้างที่เกิดขึ้นได้เพราะความสามารถของ LLM
• แม้แต่ในงานวิจัยก็แทบไม่พบตัวอย่างที่เป็นรูปธรรม (ตัวอย่างเดียวที่พอมีคือการรีแฟกเตอร์ COBOL)
• แม้แต่ผลิตภัณฑ์ที่อิงกับ LLM จากห้องวิจัย AGI ก็ไม่ได้แสดงผลลัพธ์ที่น่าประทับใจเป็นพิเศษ
  • อยู่ในระดับให้ฟีเจอร์พื้นฐานอย่างการอัปโหลด PDF ในกล่องแชต
  • ยังขาดความสามารถที่ทำให้ LLM เชื่อมต่อกับซอฟต์แวร์และชนิดข้อมูลที่หลากหลายได้อย่างลื่นไหล

คำถาม: มีด้านไหนบ้างที่ประสิทธิภาพเพิ่มขึ้นจริง?

• ไม่มีหลักฐานชัดเจนว่าโปรเจ็กต์ใดถูกปล่อยได้เร็วขึ้นเพราะ LLM
• ไม่เห็นร่องรอยว่ามีสาขาใดใน ecosystem ซอฟต์แวร์เติบโตขึ้น 10 เท่า

สิ่งที่ต้องการคือหลักฐานเชิงรูปธรรมที่ชัดเจน

• ข้อมูลประเภทต่อไปนี้ไม่จำเป็น
  • คำกล่าวอ้างคลุมเครือว่าประสิทธิภาพเพิ่มขึ้น 10 เท่า
  • การพูดถึงตัวชี้วัดทางเศรษฐกิจแบบนามธรรมหรือปริมาณโค้ดที่เพิ่มขึ้น
  • กรณีสร้างเครื่องมือหรือฟีเจอร์ง่าย ๆ ที่อิงกับ LLM
  • ตัวอย่างเล็กน้อยอย่าง "สร้าง Snake clone ด้วย ChatGPT"

ทฤษฎีสมคบคิด: เป็นไปได้ไหมว่า LLM ยังเพิ่มประสิทธิภาพจริงไม่ได้

• กลับต้องเสียเวลาไปกับการแก้โค้ดและแก้ปัญหาที่ LLM สร้างขึ้น
• หาก codebase ขนาดใหญ่ที่ LLM สร้างขึ้นมีความซับซ้อนเกินระดับหนึ่ง ก็อาจแก้ไขต่อไม่ได้และสุดท้ายต้องเขียนใหม่ตั้งแต่ต้น
• แม้ LLM จะสร้างซอฟต์แวร์ใหม่ได้ แต่ส่วนใหญ่อาจเป็นเพียงเครื่องมือใช้ครั้งเดียวหรือโค้ดพิสูจน์แนวคิดที่ไม่ได้ถูกใช้งาน
• แม้ในซอฟต์แวร์ที่มีประโยชน์จริง หากปริมาณโค้ดเพิ่มขึ้น ก็มีความเสี่ยงที่ฟีเจอร์ไม่จำเป็นหรือ bloatware จะเพิ่มขึ้นด้วย
• เป็นไปได้ที่โปรแกรมเมอร์กำลังถูกหลอกด้วยประสบการณ์แบบ “เวทมนตร์” ที่ได้ผลลัพธ์ทันทีจาก LLM

ขอบเขตการเพิ่มประสิทธิภาพที่สมจริง

• จากประสบการณ์ของผู้เขียน LLM มีประโยชน์เฉพาะในบางกรณีต่อไปนี้
  • เขียนฟีเจอร์เล็กน้อย
  • ช่วยเรียนรู้ไลบรารีหรือ codebase บางตัว
  • ทำงานรีแฟกเตอร์ง่าย ๆ
• มีแนวโน้มสูงว่าการเพิ่มประสิทธิภาพจะอยู่ราว 10~30%
• การยกระดับประสิทธิภาพอย่างสุดขั้วดูเป็นเรื่องยาก จนกว่าจะมี AGI (ปัญญาประดิษฐ์ทั่วไป)

---

[ความเห็นจาก Richard Horvath]

กรณีที่ LLM อาจช่วยเพิ่มความเร็วได้ 10 เท่าในบางสถานการณ์

• การเขียนสคริปต์ขนาดเล็กแบบแยกเดี่ยว
  • ให้ผลลัพธ์ดีมากเมื่อเขียนงานง่าย ๆ (เช่น bash script สำหรับจัดการไฟล์, โค้ด Excel VBA)
  • เขียนได้ง่ายด้วยคำอธิบายสั้น ๆ และตรวจสอบความถูกต้องได้ง่าย
  • เขียนได้แม้ไม่มีความรู้ลึกในภาษานั้น
  • ไม่จำเป็นต้องคำนึงถึงการบำรุงรักษา การทำให้เป็นโมดูล หรือ unit test
  • โดยเฉพาะงานที่เกี่ยวกับ regex มีประสิทธิภาพมาก
• เพิ่มความเร็วในการเรียนรู้เมื่อทำงานกับสแตกที่ไม่คุ้นเคย
  • ทำความเข้าใจคลาสและเมธอดของไลบรารีใหม่ ๆ ได้รวดเร็ว
  • แม้โค้ดจะยังทำงานไม่ได้สมบูรณ์ ก็ช่วยเสนอแนวทางแก้ปัญหาได้
  • ลดเวลาที่เดิมต้องใช้ไปกับการค้นเอกสารหรือดูบทเรียนได้มาก
  • แต่โค้ดที่สร้างขึ้นยังต้องแก้ไขและรีแฟกเตอร์ด้วยตนเอง

คนที่รายงานว่าประสิทธิภาพเพิ่มขึ้น 10 เท่า มีแนวโน้มจะเข้าข่ายดังนี้

• มีความรู้ด้านการพัฒนาน้อย
  • หากทักษะการเขียนโค้ดพื้นฐานยังไม่ดี โค้ดที่ได้ด้วยความช่วยเหลือจาก LLM อาจดูดีกว่าเดิมมาก
  • แต่ในกรณีเช่นนี้ โค้ดจาก LLM มีแนวโน้มสูงที่จะส่งผลเสียในระยะยาว
• ต้องเขียนโซลูชันขนาดเล็กแบบแยกเดี่ยวจำนวนมาก
  • เช่น งานอัตโนมัติใน Excel หรือการเขียน shell script ในงาน DevOps ซึ่ง LLM มีประโยชน์มากเป็นพิเศษ
• ต้องทดลองสแตกและไลบรารีหลากหลายอยู่บ่อยครั้ง
  • เป็นกรณีที่ลักษณะงานเน้นการทดลอง มากกว่าการทำงานระยะยาวกับสแตกใดสแตกหนึ่ง
• เกิด Anchoring Effect
  • เมื่อ LLM ให้ผลลัพธ์ทันทีในบางงาน ก็มีแนวโน้มจะประเมินเกินจริงว่าเป็นการเพิ่มประสิทธิภาพในระยะยาว

---

[ความเห็นจาก Davidmanheim]

• จากมุมมองของคนเขียนโค้ดและผู้บริหารในบริษัททั่วไป การเพิ่มประสิทธิภาพจาก LLM อาจมีข้อจำกัดโดยธรรมชาติ
• อธิบายได้ด้วยมุมมองของ Theory of Constraints:
  • สมมติว่าเดิมงานหนึ่งเสร็จสิ้นผ่านกระบวนการดังต่อไปนี้:
    • นักวิเคราะห์ธุรกิจ (Business Analyst) → ใช้เวลา 1 วัน
    • ผู้ทดสอบ QA → ใช้เวลา 1 วัน
    • โปรแกรมเมอร์ → ใช้เวลา 1 วัน
  • แม้ประสิทธิภาพของโปรแกรมเมอร์จะเพิ่มขึ้น 2 เท่าหรือ 5 เท่า เวลารวมของงานก็ไม่ลดลง
    • เพราะขั้นตอนอื่น (การวิเคราะห์ธุรกิจและ QA) กลายเป็นคอขวด ทำให้ความเร็วของทั้งกระบวนการยังเท่าเดิม
• จำเป็นต้องปรับโครงสร้างกระบวนการขององค์กรใหม่
  • หากต้องการใช้ประโยชน์จากการเพิ่มประสิทธิภาพของ LLM ให้เต็มที่ ต้องออกแบบกระบวนการทั้งหมดขององค์กรใหม่
  • แต่ตอนนี้มีเพียงบางบริษัทเท่านั้นที่เริ่มทำการปรับโครงสร้างลักษณะนี้

---

[ความเห็นจาก faul_sname]

• ประสบการณ์ที่เด่นชัดกับ LLM คือในงาน สร้าง UI mockup:
  • ก่อนหน้านี้การสร้าง UI mockup กินเวลาราว 10% ของเวลาทำงานทั้งหมด
  • ด้วย LLM ความเร็วในการสร้าง UI mockup เพิ่มขึ้นราว 5 เท่า
  • แต่เวลาในการทำงานโดยรวมไม่ได้ลดลง
    • กลับกัน รายละเอียด และ ความสามารถในการโต้ตอบ ของ UI mockup ดีขึ้นมาก
    • ทำงานวนซ้ำได้มากขึ้น ส่งผลให้คุณภาพของผลิตภัณฑ์ดีขึ้นในที่สุด
• “โค้ดที่ถูกทิ้ง” ไม่ได้แปลว่าไร้ประโยชน์เสมอไป
  • แม้จะเป็น prototype หรือโค้ดพิสูจน์แนวคิด ก็อาจมีส่วนช่วยให้พัฒนาผลิตภัณฑ์สุดท้ายได้ดีขึ้น
• นอกจากนี้ LLM ยังตอบคำถามเกี่ยวกับข้อผิดพลาดเฉพาะที่หาได้ยากจาก search engine
  • ตัวอย่าง: "วิธีแก้ข้อผิดพลาดที่เกิดขึ้นในงานที่รันอยู่บนสแตก xyz"
  • ช่วยดีบักในสถานการณ์ที่เกี่ยวข้องกับสแตกเฉพาะและการตั้งค่า Kubernetes
• ประเมินว่าอัตราการเพิ่มประสิทธิภาพโดยรวมอยู่ที่ประมาณ 10~30%
  • แต่ไม่ได้หมายความว่าประสิทธิภาพดีขึ้นอย่างสม่ำเสมอในทุกงาน
  • บางงานเร็วขึ้นอย่างก้าวกระโดด (เช่น UI mockup, การดีบัก ฯลฯ)
  • แทบไม่เห็นผลในงานที่ซับซ้อนหรือโค้ด legacy
  • ผลด้านประสิทธิภาพเด่นชัดในช่วงต้นโปรเจ็กต์ แต่ลดลงในช่วงบำรุงรักษาที่ซับซ้อน
• ดังนั้น ข้อจำกัดที่แท้จริงในที่นี้ไม่ใช่การขาด agency แต่เป็นปัญหาเรื่อง context management

---

[ความเห็นจาก Noosphere89]

• อ้างถึงมุมมองของ Ajeya Cotra เกี่ยวกับผลของ LLM ต่อประสิทธิภาพของโปรแกรมเมอร์ โดยมีประเด็นดังนี้:
  • AI มีประสิทธิภาพในการทำงานด้านโค้ดสูงกว่าที่คาดไว้
    • AI ทำผลงานได้ดีมากในงานเขียนโค้ด
    • แต่ในงานนอกเหนือจากการเขียนโค้ด ประสิทธิภาพลดลงอย่างมาก
    • ดังนั้น ผลกระทบต่อภาคอุตสาหกรรมโดยรวมของ AI จึงยังมีจำกัด
• ลิงก์คำกล่าวที่เกี่ยวข้องของ Ajeya Cotra
  • ลิงก์ทวีต 1
  • ลิงก์ทวีต 2
• สำหรับข้ออ้างที่ว่า “ต้องมี AGI จึงจะเกิดผลลัพธ์ระยะยาวได้”
  • เส้นทางการพัฒนา AI ในปัจจุบันมีความเป็นความสามารถทั่วไป (Generality) น้อยกว่าที่คาด
  • ประสิทธิภาพของ AI มักดีขึ้นอย่างมากในบางงาน หรือแสดงจุดอ่อนในบางด้าน
  • เพราะความไม่สมดุลของประสิทธิภาพนี้ แนวคิดเรื่อง AGI (ปัญญาประดิษฐ์ทั่วไป) อาจมีประโยชน์น้อยกว่าที่คาด

---

[ความเห็นจาก yo-cuddles]

• ตัวอย่างของคนที่ทำ robotic process automation (RPA) ในออฟฟิศของฉัน
  • เขายืนกรานอย่างหนักแน่นว่าตัวเองทำงานได้มีประสิทธิภาพขึ้นมาก
  • แต่ในความเป็นจริง งานของเขาไม่มีประสิทธิภาพและเชื่อถือได้ต่ำ ทำให้คนอื่นต้องเสียเวลาแก้ตามหลัง
  • เพื่อนร่วมงานพยายามกันเขาออกจาก workflow
• ผู้คนมักวัดประสิทธิภาพของตัวเองได้ไม่แม่น และมักรับรู้เฉพาะผลสำเร็จหรือความสูญเสียบางแบบเท่านั้น:
  • โฟกัสกับผลลัพธ์ที่มองเห็นชัด
    • เมื่อทำงานเสร็จเร็วด้วยวิธีอัตโนมัติ จะเกิดความรู้สึกสำเร็จทันทีอย่างมาก
    • เพราะผลลัพธ์ที่เร็วเห็นได้ทันที จึงถูกมองว่าเป็นผลเชิงบวก
  • รับรู้ต้นทุนระยะยาวได้ยาก
    • ต้นทุนด้านเวลาที่เกิดขึ้นหลังจากนั้นติดตามได้ยาก
    • โดยเฉพาะเมื่อปัญหาถูกแก้โดยคนอื่น ต้นทุนเหล่านั้นยิ่งมองไม่เห็น
    • แม้ข้อผิดพลาดจากงานอัตโนมัติจะถูกแก้ไขไปแล้ว ก็ยากที่จะรู้สึกถึงเวลาที่สูญเสียไปเพราะมัน
• ปัญหาที่โค้ดจาก LLM ก่อขึ้นยิ่งรับรู้ได้ยากด้วยเหตุผลต่อไปนี้:
  • เมื่อเกิดบั๊ก มักยากที่จะตามสาเหตุได้อย่างแม่นยำว่าเกิดจากโค้ดของ LLM
  • ระหว่างการแก้ปัญหา คนอื่นอาจต้องเสียเวลาเพิ่มอีก
  • ผู้ใช้มักไม่ตระหนักถึงรากของปัญหา และไม่รู้ว่ามันเกิดจากการที่ตัวเองใช้เครื่องมืออัตโนมัติ
  • ความรู้สึกว่า "เสร็จเร็วเพราะระบบอัตโนมัติ" นั้นชัดเจนมาก แต่ "เวลาที่สูญเสียไปเพราะระบบอัตโนมัติ" กลับรับรู้ได้ยาก
• แม้การใช้ LLM จะแพร่หลายขึ้นแล้ว แต่ก็ยังไม่เห็นการเพิ่มขึ้นของประสิทธิภาพในระดับอุตสาหกรรมอย่างชัดเจน
  • ผู้คนอาจอ้างว่าตัวเอง “มีประสิทธิภาพขึ้น 2 เท่า” แต่ในความเป็นจริง ประสิทธิภาพอาจลดลงเพราะปัญหาที่ซ่อนอยู่
  • กล่าวคือ เวลาและทรัพยากรที่ใช้ไปกับการแก้ปัญหาไม่ปรากฏให้เห็น จึงทำให้เกิดการรับรู้ความสำเร็จเกินจริง

[cosine20]

ความรู้สึกคล้ายกับประสบการณ์ของผมเลยครับ

• เวลาต้องเขียนโค้ดที่เรียบง่ายแต่จำได้ยาก (เช่น การจัดการไฟล์อินพุต/เอาต์พุต, การจัดการคอนเทนเนอร์ เป็นต้น)
• ตอนที่เกิดข้อผิดพลาดตอนคอมไพล์หรือรันไทม์ แล้วอยากรู้ว่านี่คือ error อะไรและโค้ดส่วนไหนเป็นสาเหตุ
• เวลาที่อยากเขียนฟังก์ชันใหม่โดยอิงจากฟังก์ชันที่เขียนไว้แล้วและคล้ายกัน แต่เพิ่มความสามารถที่ต่างออกไปเล็กน้อย
• เวลาที่อยากเปลี่ยนโค้ดที่พึ่งพาไลบรารีหนึ่งไปใช้อีกไลบรารีหนึ่ง หรือแทนที่ด้วยฟังก์ชันที่เขียนเอง
• เวลาที่ต้องการไกด์ว่าควรพัฒนาอย่างไรเพื่อสร้างฟีเจอร์บางอย่าง หรือทำงานในสภาพแวดล้อมเฉพาะ

ในเคสแบบข้างต้นช่วยประหยัดเวลาไปได้มากทีเดียวครับ หลายครั้งก็หาไม่ค่อยเจอด้วยชุด Google+Stack Overflow และโดยเฉพาะใน Stack Overflow พอมีคำตอบหนึ่งมา ก็มักจะมีคอมเมนต์โต้แย้งตามมาเยอะเสมอ แถมบางทีก็เป็นวิธี implement ของเวอร์ชันเก่าที่ไม่ควรใช้แล้ว อะไรทำนองนั้น เลยมีหลายครั้งที่น่าหงุดหงิดมาก...

[superego]

ดูเหมือนว่าประสิทธิภาพระดับ 10x จะเกิดขึ้นตอนทำต้นแบบ

[hilft]

ผมรู้สึกหวานฉ่ำเลยครับ

[halfenif]

> โปรแกรมเมอร์ส่วนใหญ่ไม่รู้วิธีใช้เครื่องมือ LLM อย่างมีประสิทธิภาพ หรือไม่ก็ไม่ได้สนใจ

นักพัฒนารอบตัวจำนวนมากกลับไม่ค่อยสนใจเทคโนโลยีอย่างน่าประหลาดใจ พวกเขาใช้เวลาส่วนใหญ่ไปกับการเสพ YouTube Shorts ทั้งแบบใหม่และแบบซ้ำ ๆ อย่างเป็นกลไก

[GN⁺]

ความคิดเห็นจาก Hacker News

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

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

• มีคำกล่าวเก่าว่า 10% สุดท้ายของโปรเจ็กต์ซอฟต์แวร์กินเวลาไป 90% ของทั้งหมด AI มีประโยชน์ในช่วง 90% แรก แต่ไม่ช่วยใน 10% สุดท้าย

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

• ที่ FAANG มีการใช้งาน LLM แบบผสานรวมเข้ากับ IDE และมีผลเชิงบวกอยู่บ้าง

  • ผลิตภาพภายใน IDE ดีขึ้นเล็กน้อย และสามารถ autocomplete งานที่ทำซ้ำได้
  • แต่บางครั้ง LLM ก็สร้างผลลัพธ์ที่ดูน่าเชื่อถือ จนกลับไปขัดขวางการเพิ่มผลิตภาพ
  • ดูเหมือนว่าหากขอให้มันสร้างฟีเจอร์โดยตรง อาจได้ผลลัพธ์ที่ดีกว่า

• ตัวอย่างของนักพัฒนาที่ได้การปรับปรุงถึง 10 เท่าจริง ๆ คือกรณีของ Pieter Levels ที่เขียน 3D multiplayer flight simulator เสร็จภายในไม่กี่วัน

  • มันช่วยประหยัดเวลาในงานง่าย ๆ ได้ แต่ไม่ช่วยในงานที่ซับซ้อน

• เคยลองใช้ LLM เพื่อสร้างโค้ด แต่ช่วงแรกผลิตภาพกลับลดลง

  • ช่วงหลังมานี้เมื่อใช้ Claude Code ผลิตภาพดีขึ้นมาก และกำลังทำงานในสไตล์ pair programming
  • คิดว่าคนที่ไม่ใช่นักพัฒนามีโอกาสน้อยที่จะสร้างผลลัพธ์คุณภาพสูงได้

• เป็นสมาชิกของทีมที่พัฒนา Copilot Autofix ที่ GitHub ซึ่งให้ข้อเสนอการแก้ไขโดยอิงจากคำเตือนของ CodeQL

  • จากข้อมูลการโต้ตอบกับนักพัฒนาจริง แสดงให้เห็นว่าความเร็วดีขึ้นเฉลี่ย 3 เท่า และสูงสุด 12 เท่า

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

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

• สมมติฐานที่ว่าผลิตภาพของซอฟต์แวร์ไม่ได้ดีขึ้น 5-10 เท่าอาจเป็นสมมติฐานที่ผิด

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

[ignos]

ดูเหมือนว่ารายการสุดท้ายของ "สรุปความเห็น Hacker News แปล" ที่ว่า "ข้อสันนิษฐานที่ว่าผลิตภาพของซอฟต์แวร์ไม่ได้เพิ่มขึ้น 5-10 เท่านั้น อาจเป็นสิ่งที่ไม่ถูกต้อง" จะเป็นการแปลคลาดเคลื่อน เมื่อตรวจดูต้นฉบับแล้ว การสรุปในทำนองว่า "การบอกว่าผลิตภาพของซอฟต์แวร์เพิ่มขึ้น 5-10 เท่า เป็นสิ่งที่ตั้งอยู่บนข้อสันนิษฐานที่คลาดเคลื่อนเกี่ยวกับการเพิ่มขึ้นของผลิตภาพ" น่าจะเป็นสรุปที่เหมาะสมกว่าครับ