12 วิธีที่ใช้วัดผลการเขียนโค้ดแบบมี AI ช่วยแล้วอาจผิดพลาด

 (third-bit.com)
9 คะแนน โดย GN⁺ 2 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • คุณค่าของ การเขียนโค้ดแบบมี AI ช่วย ยากจะย่อให้เหลือเพียงตัวเลขง่าย ๆ อย่างจำนวนบรรทัดโค้ด จำนวนตั๋วงาน หรือความพึงพอใจ และข้อสรุปอาจบิดเบือนได้ตามวิธีประเมิน
  • จำนวนบรรทัดโค้ด รวมถึงจำนวนคอมมิต, Pull Request และตั๋วงาน เป็นเพียงตัวชี้วัดปริมาณกิจกรรมเท่านั้น และเมื่อกลายเป็นเป้าหมายก็สามารถถูกปั่นตัวเลขได้ง่าย อีกทั้งไม่สามารถแยกแยะคุณภาพได้
  • อัตราการยอมรับ และอัตราการนำไปใช้ เป็นเพียงสัญญาณว่าข้อเสนอ “ดูเข้าท่า” หรือเครื่องมือถูกนำไปแจกจ่ายแล้ว ไม่ได้รับประกันความถูกต้อง ความปลอดภัย หรือความสามารถในการบำรุงรักษา
  • งานทดลองแบบของเล่น การเปรียบเทียบก่อน-หลังที่ไม่มีกลุ่มควบคุม การเปรียบเทียบผู้ใช้แบบสมัครใจ และ baseline ที่อ่อนแอ ทำให้แยกผลของ LLM ออกจาก selection bias ได้ยาก
  • การตัดสินเรื่องผลิตภาพจำเป็นต้องใช้ ตัวชี้วัดระดับระบบ ที่รวมการรีวิว การดีบัก ความปลอดภัย technical debt คอขวดของทีม และการเปลี่ยนแปลงระยะยาว

สิ่งที่กำลังถูกประเมินและสมมติฐานตั้งต้น

  • เมื่อพยายามพิสูจน์ว่าค่าใช้จ่ายค่าสมาชิกของ เครื่องมือเขียนโค้ดแบบมี AI ช่วย คุ้มค่าหรือไม่ จำนวนบรรทัดโค้ดที่สร้างขึ้น จำนวนตั๋วงานที่ปิดได้ และแบบสำรวจความพึงพอใจของนักพัฒนา ต่างก็อาจนำไปสู่ข้อสรุปที่ผิดพลาดได้คนละแบบ
  • ประเด็นสำคัญไม่ใช่ คุณค่าของการเขียนโค้ดโดยมี LLM ช่วย ในตัวมันเอง แต่คือวิธีประเมินผลนั้นหลงทางได้ง่ายเพียงใด
  • คำวิจารณ์เดียวกันนี้สามารถปรับใช้ได้เกือบตรงตัวกับข้ออ้างเกี่ยวกับการพัฒนาแบบ Agile, test-driven development และแนวปฏิบัติด้านการพัฒนาซอฟต์แวร์อื่น ๆ
  • ข้อสรุปคือ หากวิศวกรรมซอฟต์แวร์รับเอาวิธีวิจัยจากสายมนุษยศาสตร์/สังคมศาสตร์มาใช้อย่างจริงจัง ก็น่าจะไปได้ไกลกว่านี้มากในการศึกษาเรื่องลักษณะนี้

ตัวชี้วัดผลิตภาพที่ชวนให้เข้าใจผิด

  • นับจำนวนบรรทัดโค้ดที่สร้างขึ้น

    • จำนวนบรรทัดโค้ด ถูกใช้มาอย่างยาวนานในฐานะตัวชี้วัดแทนผลิตภาพซึ่งวัดตรง ๆ ได้ยาก
    • LLM อาจสร้างโค้ดได้มากขึ้น แต่ไม่ได้รับประกันผลลัพธ์ที่ดีกว่า
    • ทีมที่มีจำนวนบรรทัดโค้ดต่อนักพัฒนาเพิ่มขึ้น 40% หลังใช้ LLM อาจไม่ได้กำลังวัดผลิตภาพ แต่กำลังวัด ความฟุ่มเฟือยของโค้ด
    • การปรับปรุงที่แทนที่ลอจิกยุ่งเหยิง 2,000 บรรทัดด้วยโค้ดสะอาด 200 บรรทัด จะดูเหมือนเป็นความสูญเสียหากดูจากตัวชี้วัดจำนวนบรรทัดโค้ด
    • โค้ดที่มากขึ้นหมายถึงสิ่งที่ต้องอ่าน ต้องบำรุงรักษา และต้องดีบักมากขึ้น และภาระในอนาคตที่ AI ทิ้งไว้ก็ไม่ปรากฏในตัวเลขจำนวนบรรทัด

  • นับคอมมิต, Pull Request, ตั๋วงาน

    • ในปี 2023 McKinsey เสนอแนวทางวัดผลิตภาพของนักพัฒนารายบุคคลด้วยจำนวนกิจกรรม เช่น คอมมิต, Pull Request และ code review
    • ตาม กฎของ Goodhart เมื่อค่าที่ถูกวัดกลายเป็นเป้าหมาย มันจะไม่ใช่ตัวชี้วัดที่ดีอีกต่อไป
    • หากมีการติดตามจำนวนคอมมิต นักพัฒนาก็จะทำคอมมิตให้เล็กลงและถี่ขึ้น และหากติดตามจำนวนตั๋วงาน ตั๋วก็จะถูกแตกย่อย
    • ตัวเลขอาจดูดีขึ้น แต่ตัวงานจริงที่อยู่ข้างใต้ไม่ได้ดีขึ้นเสมอไป
    • กิจกรรมไม่ใช่ผลลัพธ์ และแม้ผลลัพธ์ก็ยังไม่ใช่มูลค่าในทันที

  • มองอัตราการยอมรับข้อเสนอเป็นสัญญาณคุณภาพ

    • อัตราการยอมรับข้อเสนอที่สูงของ LLM coding assistant มักถูกยกมาเป็นหลักฐานว่าเครื่องมือนั้นมีประโยชน์
    • อัตราการยอมรับ วัดเพียงว่าโค้ดที่สร้างขึ้น “ดูน่าเชื่อพอ” ให้ผู้พัฒนากด Tab หรือไม่ ไม่ได้วัดความถูกต้อง ความปลอดภัย หรือความสามารถในการบำรุงรักษา
    • นักพัฒนาที่ถูกกดดันเรื่องเวลาจะยอมรับข้อเสนอมากขึ้น และในนั้นย่อมมีข้อเสนอที่ไม่ปลอดภัยปะปนอยู่
    • งานวิจัยในองค์กรกับนักพัฒนา 400 คนพบอัตราการยอมรับเฉลี่ย 33% และความพึงพอใจของนักพัฒนาที่สูง แต่ไม่ได้ติดตามความถูกต้องหรือความปลอดภัยของโค้ดที่ถูกยอมรับ
    • ตัวชี้วัดที่ให้รางวัลกับสิ่งที่ “ดูเหมือนดี” ไม่ใช่ตัวชี้วัดที่ให้รางวัลกับสิ่งที่ดีจริง

  • มองอัตราการนำไปใช้เป็นตัวชี้วัดความสำเร็จ

    • คำพูดว่า “เราทำให้อัตราการนำ AI tool ไปใช้ในทั้งองค์กรวิศวกรรมแตะ 90% ได้แล้ว” เป็น ผลงานด้านการจัดซื้อและการกระจายเครื่องมือ ไม่ใช่ผลงานด้านผลิตภาพ
    • อัตราการนำไปใช้วัดเพียงว่าเครื่องมือถูกติดตั้งและถูกเปิดใช้งานหรือไม่ ไม่ได้บอกว่าข้อเสนอมีประโยชน์ไหม นักพัฒนายอมรับแบบไม่วิจารณญาณหรือไม่ หรือข้อเสนอที่ยอมรับนั้นถูกต้องหรือไม่
    • หากอัตราการนำไปใช้สูงแต่คุณภาพของข้อเสนอต่ำ นักพัฒนาอาจเสียเวลาไปกับการจัดการเครื่องมือมากกว่าจะได้รับประโยชน์จากมัน
    • งานวิจัย IBM เกี่ยวกับ enterprise AI coding assistant พบว่าเครื่องมือมักสร้างผลเพิ่มผลิตภาพสุทธิได้ แต่ประโยชน์นั้นไม่ได้กระจายเท่ากันในผู้ใช้ทั้งหมด
    • อัตราการนำไปใช้วัดง่ายกว่าประโยชน์ และนั่นเองคือเหตุผลที่มันมักถูกนำไปรายงาน

ข้อผิดพลาดในการออกแบบการทดลอง

  • จับเวลางานประดิษฐ์ที่ไม่สะท้อนโลกจริง

    • งานวิจัย GitHub Copilot ที่ถูกอ้างถึงอย่างแพร่หลาย พบว่าผู้ใช้ทำงานเสร็จเร็วกว่าผู้ไม่ใช้ 55%
    • งานนั้นคือการสร้าง HTTP server ด้วย JavaScript จากศูนย์ ภายในเวลา 90 นาที และนักพัฒนาไม่มีภาระอื่นใดในวันนั้น
    • แต่การพัฒนาซอฟต์แวร์จริงต้องมีทั้งการสำรวจ codebase ขนาดใหญ่ที่ตนไม่ได้เขียน การทำความเข้าใจ requirements ของตั๋วงานที่กำกวม การประสานงานกับเพื่อนร่วมทีม และการประชุม
    • ความเร็วใน งาน greenfield แบบของเล่น จึงไม่สามารถทำนายความเร็วของงานจริงเหล่านี้ได้
    • ใน randomized controlled trial กับนักพัฒนาโอเพนซอร์สที่มีประสบการณ์ กลับพบสวนทางกับความคาดหวังของผู้เข้าร่วมว่า การให้สิทธิ์เข้าถึง AI tool ทำให้เวลาทำงานเสร็จเพิ่มขึ้น 19%

  • เปรียบเทียบก่อน-หลังโดยไม่มีกลุ่มควบคุม

    • หากเริ่มใช้ LLM ในเดือนมกราคม แล้วในเดือนมิถุนายน Pull Request ถูก deploy ได้เร็วขึ้น ก็อาจดูเหมือนว่าเครื่องมือเป็นสาเหตุ
    • แต่ถ้าในช่วงเดียวกันมีการจ้างวิศวกรเพิ่ม 12 คน รีแฟกเตอร์ CI pipeline และเปลี่ยน cloud provider ก็จะไม่สามารถแยกสาเหตุออกจากกันได้
    • หากไม่มีกลุ่มที่ไม่ได้ใช้เครื่องมือ ก็ยากจะบอกว่าผลที่เห็นมาจาก LLM หรือจากการเปลี่ยนแปลงอื่นที่เกิดขึ้นพร้อมกัน
    • ความเที่ยงตรงภายใน ต้องอาศัย counterfactual ที่น่าเชื่อถือว่า หากไม่มีเครื่องมือนั้น อะไรจะเกิดขึ้น

  • เปรียบเทียบผู้ที่สมัครใจใช้กับผู้ที่ไม่ใช้

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

  • เปรียบเทียบ AI กับ ‘ไม่มีอะไรเลย’

    • หากนำ AI-assisted developer ไปเทียบกับกลุ่มควบคุมที่ไม่ใช้เครื่องมือใดเลย ก็เท่ากับเลือก baseline ที่ไม่มีอยู่จริงในงานจริง
    • แม้นักพัฒนาที่ไม่มี LLM assistant ก็ยังมีเอกสาร มีเพื่อนร่วมงาน และมีเวลาคิดปัญหาด้วยตนเอง
    • คำถามสำคัญคือ LLM tool ดีกว่าทางเลือกที่นักพัฒนามีอยู่แล้วหรือไม่ แต่การเปรียบเทียบเช่นนี้กลับพบได้น้อย
    • หากเลือก baseline ที่อ่อนแอ เครื่องมืออะไรก็ดูดีได้ทั้งนั้น แต่นั่นไม่ได้แปลว่ามันมีประโยชน์จริง

สิ่งที่หายไปจากขอบเขตการวัด

  • วัดแค่ครึ่งเดียวที่วัดง่าย

    • LLM ทำให้การสร้างโค้ดเร็วขึ้น และส่วนนี้วัดได้ง่าย
    • แต่อีกครึ่งที่ยากกว่าคือ เวลาในการรีวิวโค้ดที่ LLM สร้าง เวลาในการดีบักที่สูญเสียไปเพราะข้อเสนอที่ผิดแต่พูดอย่างมั่นใจ ช่องโหว่ด้านความปลอดภัยจากโค้ดที่ดูใช้ได้แต่ไม่ปลอดภัย และ technical debt จากวิธีแก้ปัญหาเฉพาะหน้าที่ไม่สนใจการออกแบบโดยรอบ
    • งานศึกษาซอร์สโค้ดของ GitHub Copilot พบว่าโค้ดที่สร้างขึ้นจำนวนมากมี ช่องโหว่ด้านความปลอดภัย และนักพัฒนาที่ถูกกดดันเรื่องเวลาจะยอมรับข้อเสนอที่ไม่ปลอดภัยในอัตราที่สูงขึ้น
    • การประเมิน LLM หลัก 5 ตัวในปี 2025 พบว่าไม่มีโมเดลใดสร้างโค้ดเว็บแอปพลิเคชันที่ผ่านมาตรฐานความปลอดภัยระดับอุตสาหกรรมได้
    • การวิเคราะห์ขนาดใหญ่ของคอมมิตที่ AI เขียนมากกว่า 300,000 รายการ พบว่ามากกว่า 15% ได้นำปัญหาด้านคุณภาพอย่างน้อยหนึ่งอย่างเข้ามา และเกือบหนึ่งในสี่ของปัญหาเหล่านั้นคงอยู่ใน codebase ระยะยาว
    • หากวัดเฉพาะ input ที่เพิ่มขึ้นแต่ไม่สนต้นทุนที่เพิ่มตามมา นั่นไม่ใช่การวัดผล แต่เป็นการตลาด

  • ต้องวัดระบบ ไม่ใช่แค่รายบุคคล

    • ความเร็วในการเขียนโค้ดของรายบุคคลวัดได้ง่ายที่สุด จึงมักถูกวัดบ่อยที่สุด
    • แม้ AI tool จะทำให้นักพัฒนาเขียนโค้ดได้เร็วขึ้น 30% แต่หาก lead time จากตั๋วงานถึง production ของทีมไม่เปลี่ยน แปลว่าคอขวดไม่ได้อยู่ที่การเขียนโค้ด
    • เมื่อโค้ดที่สร้างขึ้นเพิ่มขึ้น ปริมาณโค้ดที่ต้องรีวิวก็เพิ่มขึ้นตาม และหาก AI เพิ่มแค่ปริมาณโค้ดแต่ไม่เพิ่มความสามารถในการรีวิว cycle time อาจแย่ลงได้
    • งานวิจัยเชิงประจักษ์กับนักพัฒนามืออาชีพพบว่า AI tool เพิ่ม output ของผู้มีประสบการณ์น้อย แต่สำหรับนักพัฒนาระดับ senior ผลิตภาพของตนลดลง 19% เพราะภาระ code review จากโค้ดที่ AI สร้างเพิ่มขึ้น 6.5%
    • การปรับให้เหมาะแค่ขั้นตอนเดียวใน pipeline แล้วมองข้ามส่วนที่เหลือ คือความล้มเหลวของการคิดเชิงระบบที่ปลอมตัวมาในรูปงานวิจัยด้านผลิตภาพ

ความบิดเบือนของผลตามกาลเวลา

  • ถามนักพัฒนาว่ารู้สึกว่าผลิตภาพดีขึ้นไหม

    • ผลสำรวจอย่าง “87% ของนักพัฒนารู้สึกว่าตนมีผลิตภาพมากขึ้นเมื่อใช้ AI tool” มักถูกอ้างเป็นหลักฐานว่าเครื่องมือได้ผล
    • แต่ การรายงานด้วยตนเอง สามารถสร้างความเข้าใจผิดอย่างเป็นระบบได้ด้วย 3 เหตุผล
    • จาก Hawthorne effect คนมักทำงานต่างไปเมื่อรู้ว่าตนกำลังถูกสังเกตหรือประเมิน
    • เครื่องมือใหม่ก่อให้เกิด ผลของความใหม่ ซึ่งทำให้รู้สึกว่าเร็วขึ้นเพียงเพราะมันใหม่ และความรู้สึกนี้มักหายไปภายในไม่กี่สัปดาห์
    • social desirability bias ทำให้ผู้ตอบมีแนวโน้มตอบในสิ่งที่คิดว่าแบบสำรวจอยากได้ยิน โดยเฉพาะเมื่อฝ่ายบริหารเป็นผู้เลือกเครื่องมือนั้น

  • วัดเฉพาะช่วงที่ความใหม่ยังทำงานอยู่

    • หากการศึกษา 4 สัปดาห์พบว่าผลิตภาพดีขึ้น สิ่งที่มันพบก็คือผลิตภาพที่ดีขึ้นในช่วง 4 สัปดาห์เท่านั้น
    • นักพัฒนามักทุ่มเทกับเครื่องมือใหม่มากเป็นพิเศษในช่วงแรก ทำให้ผลที่สังเกตได้อาจสูงเกิน baseline ระยะยาว
    • ผลกระทบที่สำคัญจริงมักปรากฏในช่วงหลายเดือน ไม่ใช่ไม่กี่สัปดาห์
    • การเสื่อมของทักษะ จากงานที่มอบหมายให้ AI, technical debt ที่สะสมจากข้อเสนอที่ผิด และการเปลี่ยนแปลงของวิธีทำงานร่วมกันในทีม ล้วนต้องอาศัยการสังเกตระยะยาว
    • งานวิจัยที่ออกแบบมาเพื่อตรวจจับผลดีระยะสั้น จะไม่สามารถบอกได้ว่าเกิดอะไรขึ้นหลังงานวิจัยจบลง
    • การวิเคราะห์โอเพนซอร์สรีโพสิทอรี 807 แห่งที่นำ Cursor ไปใช้ พบว่าความเร็วในการพัฒนาเพิ่มขึ้นมากหลังนำไปใช้ แต่เป็นเพียงชั่วคราว ขณะที่ความซับซ้อนของโค้ดและ static analysis warning เพิ่มขึ้นอย่างมีนัยสำคัญและต่อเนื่อง

บทสรุปเพื่อการตีความที่ดีกว่า

  • การวัดผลิตภาพ ยากจะย่อให้เหลือเป็นตัวเลขเดียวหรือตัวชี้วัดแทนที่หยิบใช้ได้ง่าย
  • หากต้องการตัดสินผลของการเขียนโค้ดแบบมี LLM ช่วย ต้องดูให้ครบทั้งความเร็วในการเขียนโค้ด การรีวิว การดีบัก ความปลอดภัย การบำรุงรักษา technical debt คอขวดของทีม และการเปลี่ยนแปลงระยะยาว
  • หากไม่มีกลุ่มควบคุม baseline ที่สมจริง การควบคุม selection bias การสังเกตระยะยาว และตัวชี้วัดระดับระบบ ก็ยากจะแยกผลของ AI tool ออกจากผลของการเปลี่ยนแปลงอื่น
  • ค่าที่วัดง่ายมักถูกรายงานง่าย แต่ค่าที่ง่ายไม่ได้มาแทนค่าที่สำคัญ
  • หากต้องการประเมินแนวปฏิบัติด้านการพัฒนาซอฟต์แวร์ เราจำเป็นต้องรับเอาวิธีวิจัยจากสายมนุษยศาสตร์/สังคมศาสตร์มาใช้อย่างจริงจังมากขึ้น

แหล่งข้อมูลสำคัญที่ถูกอ้างถึง

  • Kent Beck, “Measuring Developer Productivity: Real-World Examples”: ตัวอย่างการวัดผลิตภาพนักพัฒนาในโลกจริง
  • Catherine M. Hicks, Carol Lee, Kristen Foster-Marks, “The New Developer: AI Skill Threat, Identity Change & Developer Thriving in the Transition to AI-Assisted Software Development”: ว่าด้วยภัยคุกคามต่อทักษะ การเปลี่ยนอัตลักษณ์ และความงอกงามของนักพัฒนาในช่วงเปลี่ยนผ่านสู่การพัฒนาซอฟต์แวร์แบบมี AI ช่วย
  • McKinsey, “Yes, You Can Measure Software Developer Productivity”: ข้อเสนอการวัดผลิตภาพจากกิจกรรมอย่างคอมมิต, Pull Request และ code review
  • Peng2023: งานวิจัยที่พบว่าผู้ใช้ GitHub Copilot ทำงานสร้าง HTTP server เสร็จเร็วขึ้น 55%
  • Becker2025: งานวิจัยที่พบว่าการให้สิทธิ์เข้าถึง AI tool กับนักพัฒนาโอเพนซอร์สที่มีทักษะสูง ทำให้เวลาทำงานเสร็จเพิ่มขึ้น 19%
  • Pearce2022: งานวิจัยที่ประเมินช่องโหว่ความปลอดภัยในโค้ดที่ GitHub Copilot สร้าง และการยอมรับข้อเสนอที่ไม่ปลอดภัยเพิ่มขึ้นเมื่ออยู่ภายใต้แรงกดดันด้านเวลา
  • He2026: งานวิจัยที่ยืนยันการเพิ่มขึ้นของความเร็วในการพัฒนาระยะสั้นหลังใช้ Cursor และการเพิ่มขึ้นของความซับซ้อนของโค้ดกับ static analysis warning ในระยะยาว
  • Xu2025: งานวิจัยว่าด้วยการที่การเขียนโปรแกรมแบบมี AI ช่วยอาจเพิ่มภาระรีวิวและภาระบำรุงรักษาของนักพัฒนาที่มีประสบการณ์ จนทำให้ผลิตภาพลดลง

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

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

 
GN⁺ 2 시간 전
ความเห็นจาก Lobste.rs

  • ผู้เขียนเป็นหนึ่งในผู้ก่อตั้ง Software Carpentry จึงเป็นคนที่คิดเรื่องวิธีวัด ผลิตภาพซอฟต์แวร์ ให้ดีขึ้นมาตั้งนานก่อน LLM จะถือกำเนิด
    งานวิจัย METR ที่ถูกอ้างถึงน่าสนใจกว่าที่คนมักพูดถึงกันมาก สำหรับหลายคน พาดหัวคือ “AI ทำให้คนทำงานช้าลง” ซึ่งก็อาจโต้แย้งได้ว่าเป็นแค่ LLM แบบปี 2025 ที่ยังคงดีขึ้นเรื่อย ๆ
    แต่ผลที่น่าสนใจกว่าคือ หลังจบการทดลอง ค่าที่แต่ละคนประเมินไว้กลับไม่ตรงกับผลจริงแม้แต่ในแง่ทิศทาง ดูเหมือนจะมีปัจจัยบางอย่างในเรื่องนี้ที่สร้างความยากพื้นฐานให้กับการวัดทุกประเภท ซึ่งบริษัทส่วนใหญ่กลับมองข้าม
    แม้แต่ ความรู้สึกคลุมเครือ ว่าเครื่องมือทำให้คนมีผลิตภาพมากขึ้นก็ยังเชื่อถือไม่ได้ ผู้คนไม่รู้ตัวเองจริง ๆ
    งานศึกษาติดตามผลที่ตามมาก็ล้มเหลวไปแทบหมดเพราะ selection bias

    The primary reason is that we have observed a significant increase in developers choosing not to participate in the study because they do not wish to work without AI
    การที่นักพัฒนาปฏิเสธจะทำงานโดยไม่มี AI อาจแปลว่าเครื่องมือนั้นใช้งานได้ดี หรืออาจแปลว่าพวกเขาค่อย ๆ พึ่งพาเครื่องมือนี้มากขึ้นจนความสามารถในการทำงานยาก ๆ โดยไม่มีมันเสื่อมถอยไปหมดแล้วก็ได้

    • สมมติฐานของฉันคือ ผู้คนมักพึ่ง LLM มากขึ้นกับส่วนของงานที่พวกเขาไม่อยากทำอยู่แล้ว และเวลาเราทำงานที่ไม่อยากทำ เวลาก็มักรู้สึกว่าเดินช้ากว่าปกติมากเสมอ

  • คำพูดที่ว่า “เครื่องมือใหม่รู้สึกว่าเร็วกว่าเพราะมันใหม่ และความรู้สึกนั้นมักหายไปในไม่กี่สัปดาห์” ดูเหมือนจะกลับด้านสำหรับฉัน
    เครื่องมือใหม่ทำให้ฉันช้าลงเสมอเพราะยังไม่คุ้น แน่นอนว่ามองเห็น ศักยภาพ ที่จะเร็วขึ้นได้ แต่ก็ยังใช้มันได้ไม่คล่องพอ

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

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

    • ผลิตภาพ ไม่เหมือนกับการเพิ่มความเร็วในการทำงาน แม้งานบางอย่างจะเร็วขึ้น แต่ถ้างานนั้นไม่ใช่คอขวด หรือการเพิ่มความเร็วนั้นมีต้นทุน ก็อาจไม่มีผลเชิงบวกต่อผลิตภาพเลย
      ต้นฉบับเองก็พูดถึงเรื่องนี้ในฐานะ “การวัดเฉพาะครึ่งที่ง่ายกว่า”

  • สำหรับคำถามที่ว่า “ถ้าสัปดาห์หน้าผู้จัดการขอให้คุณพิสูจน์ว่าเครื่องมือ AI coding ที่บริษัทสมัครไว้คุ้มค่าสมาชิก คุณจะวัดจำนวนบรรทัดโค้ดที่สร้างขึ้น หรือจะวัดจำนวน ticket ที่ปิดได้?” นั้น Claude วัดจำนวนบรรทัดโค้ด อัตราการยอมรับ และการใช้โทเค็นจากข้อมูลการชำระเงินอยู่แล้ว
    จำนวน ticket ที่ปิดได้คงเป็นความเร็วของทีม ซึ่งผลลัพธ์จาก AI ก็เป็นเพียงปัจจัยหนึ่งในนั้น และ Jira ก็วัด sprint velocity อยู่แล้ว
    ไม่ว่าอย่างไร คำถามนี้ก็ถูกปั่นแต่งได้ง่าย ขึ้นอยู่กับว่าคุณคิดว่าผู้จัดการต้องการผลลัพธ์แบบไหน และก็น่าจะมีโอกาสสูงว่ากำลังถูกทำแบบนั้นอยู่แล้ว

  • ดูเหมือนผู้เขียนจะพลาดคำถามสำคัญมากข้อหนึ่งไป นั่นคือ “การใช้ AI ก่อให้เกิดความเสียหายอะไรบ้าง?”
    ฉันมองว่านี่เป็นคำถามที่พื้นฐานกว่าคำถามอื่นทั้งหมด เพราะความเสียหายวัดได้ง่ายกว่ามาก แค่เปิด Git forge ไว้สักตัว แล้วดูพวก crawler พุ่งเข้ามาเหมือนฉลามได้กลิ่นเลือดก็พอ
    การที่ scraper ทำ DDoS ใส่อินเทอร์เน็ตทั้งระบบเป็นปัญหาที่วัดได้ และถ้าคุณโฮสต์ระบบเอง นี่คือความจริงที่สัมผัสได้โดยตรง
    ประโยชน์ที่เรียกกันว่าเป็นข้อดีของ AI ซึ่งเรายังวัดกันได้ไม่ดีนักนั้น คุ้มพอจริงหรือที่จะยอมรับความเสียหายที่เป็นรูปธรรมมากจาก crawler?
    แล้วถ้ารวมพลังงานที่ใช้ในการรัน crawler และประมวลผลคำขอเหล่านั้น ต้นทุนการฝึก ต้นทุนการอนุมาน และความจำเป็นของ data center ที่ใหญ่ขึ้นเรื่อย ๆ เข้าไปด้วยล่ะ?
    ฉันคิดว่าการถามว่าข้อดีที่เรียกกันเช่นนั้นของ AI คุ้มค่าพอจะแลกกับทุกสิ่งเหล่านี้หรือไม่ เป็นคำถามที่สำคัญกว่ามาก

    • สิ่งที่น่าหงุดหงิดเสมอในประเด็นแนว “เราควรพูดถึง X” แบบนี้คือ ฉันเคยเห็นข้อโต้แย้งตรงกันข้ามเป๊ะในบทความที่พูดถึงความเสียหายทางนิเวศวิทยา
      ทำนองว่า “ต่อให้สิ่งเหล่านี้ไม่ใช้พลังงาน มันก็ยังสร้างโค้ดแย่ ๆ อยู่ดี เพราะงั้นเรื่องนั้นสำคัญกว่ามาก” หรือ “จะพูดเรื่องการเขียนโค้ดไปทำไม ความเสียหายที่แท้จริงคือการนำไปใช้เพื่อการสอดส่อง” แล้วประเด็นก็ถูกเลื่อนไปเรื่อย ๆ