- มีการทำการทดลองแบบสุ่มมีกลุ่มควบคุมกับ เครื่องมือ AI ช่วงต้นปี 2025 เพื่อศึกษาผลกระทบต่อผลิตภาพจริงของนักพัฒนาโอเพนซอร์ส
- ผลการวิจัยพบว่า เมื่อใช้เครื่องมือ AI เวลาที่ใช้ทำงานให้เสร็จโดยเฉลี่ยนานขึ้น 19%
- นักพัฒนาคาดว่า AI จะช่วยให้พวกเขาเร็วขึ้น 24% แต่กลับพบการชะลอตัวที่ขัดกับความรู้สึกที่รับรู้จริง
- ความเหลื่อมล้ำระหว่างความสามารถของ AI ที่เห็นในเบนช์มาร์กกับประสบการณ์ในชีวิตประจำวัน เมื่อเทียบกับผลจริงนั้นเด่นชัดมาก
- งานวิจัยเน้นย้ำถึง ความสำคัญของการทำความเข้าใจผลกระทบด้านผลิตภาพของ AI อย่างแม่นยำและการประเมินที่หลากหลาย
ภาพรวม
- งานวิจัยนี้ทำ การทดลองแบบสุ่มมีกลุ่มควบคุม (RCT) เพื่อยืนยันว่า เครื่องมือ AI ช่วงต้นปี 2025 (Early-2025) ส่งผลต่อผลิตภาพของนักพัฒนาโอเพนซอร์สที่มีประสบการณ์อย่างไร
- ตรงกันข้ามกับความคาดหมาย พบว่า เมื่อนักพัฒนาใช้เครื่องมือ AI จะใช้เวลานานขึ้น 19%
- ผลลัพธ์นี้สามารถตีความได้ว่าเป็นกรณีศึกษาหนึ่งของการวัดผลกระทบจริงของ AI ที่ช่วยงานวิจัยอัตโนมัติ ต่อการพัฒนาซอฟต์แวร์
- ผู้วิจัยระบุว่ามีแผนจะใช้ระเบียบวิธีนี้ต่อไปเพื่อ ประเมินผลจริงของการเร่ง R&D ด้วย AI อย่างต่อเนื่อง
แรงจูงใจของงานวิจัย
- เบนช์มาร์กด้านโค้ดดิ้ง/เอเจนต์ ที่มีอยู่เดิมยังมีข้อจำกัดในการสะท้อนสถานการณ์การทำงานจริงอย่างเพียงพอ
- ด้วยลักษณะอย่างการทดสอบเฉพาะกิจ งานเดี่ยวที่ไม่มีคอนเท็กซ์ และโครงสร้างการให้คะแนนอัตโนมัติ จึงอาจ ประเมินความสามารถของ AI สูงเกินจริง
- ในทางกลับกัน หากไม่มีการแทรกแซงแบบปรับตัวของมนุษย์ ก็อาจมีความเป็นไปได้ที่จะ ประเมินประสิทธิภาพจริงของโมเดล AI ต่ำเกินไป
- เพื่อชดเชยข้อจำกัดเหล่านี้ จึงทดลองวัดผลกระทบต่อ ผลิตภาพจริงของนักพัฒนาโอเพนซอร์ส เพื่อประเมิน ผลกระทบของ AI ในโลกจริง
วิธีการทดลอง
- คัดเลือก นักพัฒนาโอเพนซอร์สระดับเก๋า 16 คน และเลือก issue จริง 246 รายการจากรีโพซิทอรีขนาดใหญ่ที่แต่ละคนทำงานมาหลายปี (เฉลี่ย 22,000+ stars, โค้ด 1,000,000+ บรรทัด)
- สำหรับแต่ละ issue มีการสุ่มกำหนดให้อยู่ในกลุ่มที่ อนุญาตหรือห้ามใช้ AI
- เมื่ออนุญาตให้ใช้ AI นักพัฒนาสามารถใช้ Cursor Pro และโมเดลใหม่อย่าง Claude 3.5/3.7 Sonnet ได้อย่างอิสระ ส่วนกรณีห้ามใช้จะต้องทำงานโดยไม่มีความช่วยเหลือจาก generative AI
- ผู้เข้าร่วมบันทึกวิดีโอกระบวนการแก้แต่ละ issue (เฉลี่ยใช้เวลา 2 ชั่วโมง) และ รายงานเวลาที่ใช้ด้วยตนเอง
- ผู้เข้าร่วมการทดลองได้รับค่าตอบแทน 150 ดอลลาร์ต่อชั่วโมง
ผลลัพธ์สำคัญ
- เมื่อใช้เครื่องมือ AI เวลาในการแก้ issue นานขึ้นโดยเฉลี่ย 19%
- นักพัฒนาคาดว่า AI จะช่วยเพิ่มผลิตภาพจริง 24% และแม้หลังการทดลองก็ยังตอบว่ารับรู้ว่าเร็วขึ้น 20%
- สิ่งนี้สะท้อนให้เห็นถึง ช่องว่างขนาดใหญ่ระหว่างการรับรู้กับผลลัพธ์จริง
- เพื่อป้องกันความเข้าใจผิดเฉพาะทาง งานวิจัยนี้ ไม่ได้ให้หลักฐาน สำหรับข้อสรุปต่อไปนี้:
- การสรุปเหมารวมว่า AI ทำให้นักพัฒนาทุกคนหรือการพัฒนาซอฟต์แวร์ทั้งหมดช้าลง
- การกำหนดผลของ AI ในโดเมนหรือสภาพแวดล้อมอื่น
- การยืนยันว่าผลลัพธ์เดียวกันนี้จะคงอยู่ต่อไปในอนาคตอันใกล้
- การอ้างว่าไม่สามารถปรับแต่งเทคนิค LLM หรือพรอมป์ตที่มีอยู่ได้
การวิเคราะห์ปัจจัยที่มีผล
- มีการวิเคราะห์ 20 ปัจจัย ที่อาจอธิบายการล่าช้าของงาน และประเมินว่ามี 5 ปัจจัยที่ส่งผลจริง
- ยืนยันได้ว่าตัวแปรหลักอย่างเงื่อนไขการทดลอง โมเดล ความยากของ issue และคุณภาพของ PR ไม่ได้ส่งผลอย่างมีนัยสำคัญต่อผลการทดลอง
- ปรากฏการณ์ความล่าช้าถูกสังเกตอย่างสม่ำเสมอแม้ในชุดข้อมูลย่อยและวิธีประมาณค่าที่แตกต่างกัน
- รายละเอียดการวิเคราะห์เพิ่มเติมสามารถดูได้จากต้นฉบับของบทความวิจัย
การตีความผลลัพธ์และการอภิปราย
ความขัดแย้งของหลักฐานและสาเหตุ
- ความแตกต่างของผลลัพธ์ระหว่างคะแนนเบนช์มาร์ก/รายงานกรณีศึกษา/การทดลองจริงของ AI นั้นชัดเจน
- เบนช์มาร์กวัดความสามารถของ AI โดยเน้น ปัญหาที่แคบและตรวจคะแนนอัตโนมัติได้
- SWE-Bench: PR โอเพนซอร์สที่อิงการทดสอบ, RE-Bench: ปัญหาที่สามารถประเมินด้วยอัลกอริทึมได้
- แต่ใน RCT จริง มนุษย์กลับช้าลงใน งานที่ซับซ้อนและสมจริงซึ่งใช้เวลา 20 นาทีถึง 4 ชั่วโมง
- ในอีกด้านหนึ่ง ในภาคอุตสาหกรรมและชุมชนกลับมี รายงานเชิงคุณภาพจำนวนมากว่า AI มีประโยชน์มากกับงานระยะยาว
กรอบการตีความ
- แต่ละวิธีมีลักษณะของการ วัด “ความสามารถจริง” ในคนละแบบ
- วิธีมองในแต่ละกรณี:
- ปัญหาการประเมินต่ำไปของ RCT: อาจมีลักษณะเฉพาะที่เกิดขึ้นเฉพาะกับสภาพการทดลองนี้
- ความเป็นไปได้ที่เบนช์มาร์ก/กรณีศึกษาจะประเมินสูงเกินไป: มีช่องว่างจากการแก้ปัญหาในโลกจริง และความน่าเชื่อถือของข้อมูลแบบรายงานตนเองยังไม่เพียงพอ
- ทั้งสามแนวทางอาจเหมาะกับเพียงบางปัญหาย่อยของโลกจริงเท่านั้น
- ช่องว่างระหว่างแหล่งข้อมูลที่ต่างกันกับระดับความสามารถจริง อาจตีความได้ผ่าน ความคลาดเคลื่อน/อคติในการวัด (สีแดง) และความแตกต่างของขอบเขตการวัด (สีน้ำเงิน)
นัยเพิ่มเติมจากการทดลอง
- ผลลัพธ์จาก RCT อาจ ไม่ครอบคลุมถึงสภาพแวดล้อมที่มีการสุ่มตัวอย่างผลลัพธ์จาก AI หลายร้อยหรือหลายพันครั้ง
- มีความเป็นไปได้ว่า ต้องใช้เครื่องมือ AI อย่าง Cursor ต่อเนื่องหลายสิบถึงหลายร้อยชั่วโมงก่อนจึงจะเห็นประสิทธิภาพที่ดีขึ้น
- ในสภาพแวดล้อมที่ต้องการโค้ดคุณภาพสูงและมีข้อกำหนดโดยนัยมากมาย (เช่น เอกสาร การทดสอบ การจัดรูปแบบ) ความสามารถของ AI อาจถูกจำกัด
- เบนช์มาร์กมีขอบเขตปัญหาที่แคบ จึง ไม่สามารถสะท้อนความยากของงานจริงได้อย่างเหมาะสม
- รายงานความรู้สึกเชิงคุณภาพอาจมีความน่าเชื่อถือลดลงจาก ผลของการประเมินสูงเกินไปและการหลงเชื่อตนเอง
- ไม่มีวิธีประเมินแบบใดแบบหนึ่งที่สมบูรณ์ จึงจำเป็นต้องใช้หลายวิธีร่วมกันแบบเสริมกัน
แนวโน้มในอนาคต
- ผู้วิจัยมีแผนจะปรับปรุงระเบียบวิธีนี้ต่อเนื่องเพื่อ ติดตามเชิงปริมาณว่าเครื่องมือ AI เปลี่ยนผลิตภาพของนักพัฒนาในโลกจริงมากน้อยเพียงใด
- หากเครื่องมือ AI สามารถเพิ่มประสิทธิภาพของนักพัฒนาในภาคสนามได้อย่างมาก ก็อาจนำไปสู่ การเร่ง AI R&D อย่างรุนแรง ความล้มเหลวของการกำกับดูแล และความเสี่ยงจากการกระจุกตัวของอำนาจ ไปพร้อมกัน
- การพัฒนากรอบการประเมินที่เหมาะกับสภาพแวดล้อมจริงจะมีความสำคัญอย่างมากต่อพัฒนาการของ AI และต่ออุตสาหกรรมโดยรวมในอนาคต
2 ความคิดเห็น
150 ดอลลาร์ต่อชั่วโมง? แค่ตรงนี้ก็คุมตัวแปรกันเละเทะแล้ว 555555
ความคิดเห็นจาก Hacker News
ความเห็นของ Simon Willison:
ตัวบทความฉบับเต็มมีรายละเอียดจำนวนมากที่ไม่มีอยู่ในบทสรุป ลิงก์บทความ
โดยส่วนตัวผมคิดว่า ถ้าจะให้ได้ประสิทธิภาพที่ดีขึ้นจริงจากเครื่องมือ AI ที่ใช้ LLM นั้น มีเส้นโค้งการเรียนรู้ที่ชันกว่าที่คนส่วนใหญ่คาดไว้มาก
งานวิจัยนี้มีผู้เข้าร่วม 16 คนที่มีประสบการณ์ใช้เครื่องมือ AI หลากหลายแบบ โดย 56% เพิ่งใช้ Cursor เป็นครั้งแรก และงานนี้ก็เน้นศึกษาการใช้ Cursor เป็นหลัก
ผู้เข้าร่วมแต่ละคนจัดการปัญหารวมประมาณ 15 issue และแต่ละ issue จะถูกสุ่มกำหนดว่าให้ใช้ AI ได้หรือไม่ได้
กล่าวคือ นักพัฒนาคนเดียวกันจะทำทั้งงานที่อนุญาตให้ใช้ AI และงานที่ไม่อนุญาตให้ใช้ AI ปนกันไป
มีผู้เข้าร่วมเพียง 1/4 ที่ผลงานดีขึ้น และอีก 3/4 กลับแย่ลง
กลุ่มที่ใช้ AI ได้ผลดีที่สุดคือ คนที่ใช้ Cursor มาแล้วเกิน 50 ชั่วโมง
แม้แต่นักวิจัยเองก็ยอมรับว่า นักพัฒนาที่มีประสบการณ์กับ Cursor มากพอมีประสิทธิภาพดีขึ้น
สัญชาตญาณของผมคือ บทความนี้ชี้ให้เห็นว่าในการพัฒนาร่วมกับ AI นั้นเส้นโค้งการเรียนรู้สูงมาก ดังนั้น ถ้าเอาไปผสมเข้ากับ workflow เดิมในงานจริงแบบทันที อาจกลับทำให้ประสิทธิภาพลดลง
เวลามีคนตอบเรื่อง LLM ว่า “ก็คุณใช้มันไม่เป็นเอง” ผมรู้สึกว่านี่เป็นข้อแก้ตัวที่โยนความรับผิดชอบให้ผู้ใช้มากเกินไป
สำหรับผลิตภัณฑ์เทคโนโลยีส่วนใหญ่ ถ้าผู้ใช้ยังไม่รู้สึกถึงคุณค่า ผมมองว่าเป็นปัญหาที่การออกแบบผลิตภัณฑ์เอง ไม่เข้าใจว่าทำไมตรรกะนี้ถึงไม่ถูกใช้กับ AI
ขอบคุณ Simon และขอบคุณที่อ่านบทความละเอียดมาก - ผมเป็นแฟนโครงการ OS และอยากชี้ประเด็นสำคัญบางอย่าง
1) งานวิจัยก่อนหน้าบางชิ้น แสดงให้เห็นว่าประสิทธิภาพดีขึ้นได้แม้มีประสบการณ์กับเครื่องมือน้อย ดังนั้นทฤษฎีเรื่อง “เส้นโค้งการเรียนรู้ชัน” อย่างเดียวอธิบายผลครั้งนี้ไม่ได้ทั้งหมด
2) ก่อนเริ่มการศึกษา ผู้เข้าร่วมกว่า 90% มีประสบการณ์การเขียน prompt ให้ LLM อยู่แล้ว และการเขียน prompt ก็ถือเป็นทักษะหลักที่สำคัญ แนวคิดกระแสหลักคือถ้าคุ้นกับ VSCode ก็จะใช้ Cursor ได้ไม่ยาก
3) ถ้าทุกคนคุ้นกับ AI อยู่แล้ว เวลาถูกห้ามใช้ AI อาจทำงานได้แย่ลงด้วยซ้ำ (อย่างน้อยผมก็เห็นด้วยกับจุดนี้) ซึ่งถ้าเป็นแบบนั้นจะยิ่งทำให้ AI ดูดีกว่าความจริง และทำให้ผลที่วัดได้ลดลง
4) ข้อมูลเรื่องประสบการณ์ถูกแชร์กับผู้เชี่ยวชาญที่ทำการคาดการณ์ล่วงหน้าแล้ว แต่ถึงอย่างนั้น คนคาดการณ์ก็ยังประเมินความคาดหวังเรื่องผลิตภาพสูงเกินจริงมาก
5) อาจมีทักษะแบบ long tail ที่เกิดจากการใช้งานนับร้อยชั่วโมงจริง และงานวิจัยนี้ก็ยังยากจะสรุปในส่วนนั้น
เพราะผลของบทความนี้น่าประหลาดใจ คนอ่านเลยอาจหยิบปัจจัยเดียวขึ้นมาแล้วสรุปง่าย ๆ ว่า “เป็นเพราะสิ่งนี้!”
แต่ในความเป็นจริงอาจเกิดจากหลายสาเหตุร่วมกันก็ได้ (อย่างน้อย 5 อย่าง และยังตัดความเป็นไปได้ได้ไม่ถึง 9 อย่าง ดูตารางหน้า 11)
ข้อสรุปสำคัญมากข้อหนึ่งคือ ความพึงพอใจที่นักพัฒนารายงานด้วยตนเองห่างจากความจริงมาก และไม่เกี่ยวกับชนิดของเครื่องมือที่ใช้
การวัดผลิตภาพจำเป็นต้องใช้ข้อมูลจริงจากภาคสนามเสมอ (ดูภาค C.2.7 ในบทความ: ส่วน “การใช้เครื่องมือ AI ต่ำกว่าค่าเฉลี่ย” อธิบายไว้ละเอียด)
ตีความได้ว่าทั้งที่ผู้เข้าร่วม 75% มีประสบการณ์กับ LLM อยู่แล้ว แต่เมื่อใช้ AI กลับทำงานช้าลง อย่างหนึ่งอาจแปลว่าเส้นโค้งการเรียนรู้ของ LLM ชันมาก อีกอย่างหนึ่งคือประสิทธิภาพที่แท้จริงของ LLM ในการช่วยเขียนโปรแกรมตอนนี้อาจถูกประเมินสูงเกินไป ผู้คนคาดการณ์สมรรถนะของมันพลาดอย่างสม่ำเสมอ
ต่อให้ใช้ LLM เก่งขึ้น ก็อาจเข้าใจโค้ดที่ตัวเองเขียนน้อยลงได้
นักพัฒนามักจะยิ่งเชี่ยวชาญกับโค้ดมากขึ้นเมื่อเวลาผ่านไป แต่ LLM อาจกลับแย่ลงเรื่อย ๆ
แม้ LLM จะช่วยสร้างโค้ดได้เร็ว แต่ถ้าไม่ใส่ใจมากพอ ความชำนาญต่อโค้ดจะไม่สะสมขึ้น
ช่วงแรกอาจดูเหมือนพัฒนาได้เร็วลื่นไหล แต่ข้างหลังกลับมีความเข้าใจไม่พอ และ LLM เองก็เริ่มจากพอใช้ได้แล้วค่อย ๆ ไม่ดีขึ้น สุดท้ายจึงกลายเป็นโค้ดเละเทะที่ทั้ง LLM และผู้ใช้ก็รับมือไม่ไหว
ผมคิดว่าต้องคอยควบคุมมันอย่างเหนียวแน่น ไม่ปล่อยให้หลงกับความสะดวก และผลักดันให้ LLM สร้างโค้ดที่สะอาดขึ้น ขณะเดียวกันตัวเองก็ต้องศึกษาตัวโค้ดให้เข้าใจจริง ต้องพยายามทำความเข้าใจด้วยตัวเอง
จะเห็นได้ว่ามีทั้งคนที่ผลิตภาพดีขึ้นเพราะเครื่องมือ AI และคนที่ไม่ดีขึ้น
ผมเดาว่า คนที่อ่านข้อความยาว ๆ หรือโค้ดจำนวนมากได้เร็วจะได้เปรียบมาก
ความสามารถในการจับข้อเสนอที่ไร้ประโยชน์ได้เร็ว และวนซ้ำจนได้คำตอบที่ดี เป็นเรื่องสำคัญมาก
ทักษะการสแกนเร็วมีความสัมพันธ์กับประสบการณ์ก็จริง แต่ก็น่าแปลกที่บางคนเพิ่งเริ่มต้นก็ทำตรงนี้ได้เร็วเหมือนกัน
คนที่ค้นหาเก่งอาจได้เปรียบในการใช้ LLM ด้วยเช่นกัน ดูคล้ายกับทักษะการ Google หาข้อมูล
ทำให้นึกถึงกฎ 80/20 อีกครั้ง - งาน 80% แรกเสร็จใน 20% ของเวลา แต่ 20% ที่เหลือกลับกินเวลาอีก 80%
มักจะมีความรู้สึกว่า “เกือบเสร็จแล้ว” อยู่ตลอด เลยตกหลุม sunk cost ได้ง่าย
วิธีที่ผมลองใช้ล่าสุดคือ ใช้ AI เป็น “ตัวลดแรงเสียดทาน” ไม่ใช่ “ตัวแก้ปัญหา”
ผมยังเขียนโปรแกรมเอง แต่ถาม AI เฉพาะเรื่องเล็ก ๆ น้อย ๆ เช่น syntax ที่ลืม เพื่อเร่งงานให้ไวขึ้น
แทบไม่ดูข้อเสนอโค้ดทั้งก้อนจากมันเลย เขียนโค้ดด้วยการคิดเองตลอด เพื่อป้องกันไม่ให้ความเข้าใจและฝีมือลดลง
เมื่อก่อนมันเหมือน inverse Pareto คือใช้งาน 80% แรกด้วยแรง 80% แล้ว 20% ที่เหลือก็ยังต้องใช้แรงอีก 80%
เห็นด้วยกับการใช้ AI แค่แก้ “อุปสรรคเล็ก ๆ”
เมื่อวานผมยังปวดหัวกับ
ConcurrentOperationsExceptionตอนจัดการListด้วย Java stream API อยู่เลยพอเขียนเมธอดเองแล้วไม่ผ่าน เลยให้ AI ช่วยทำ “เมธอดแปลง list ที่ thread-safe” มันกลับบอกว่ามีเมธอดนี้อยู่ใน API อยู่แล้ว
เรื่องจุกจิกแบบนี้ AI เก่งมาก - โดยเฉพาะงานที่ซับซ้อนแต่ขอบเขตชัดเจน
มีประโยชน์มากเวลาใช้แทน Stack Overflow แบบที่ทรงพลังขึ้น โดยเฉพาะเวลาผมพอรู้ว่าต้องทำอะไร แต่ไม่รู้ว่าต้องทำอย่างไรให้เหมาะกับสภาพแวดล้อมของตัวเอง และมันยังช่วยเรื่อง debugging กับ rubber ducking ได้ด้วย
เรื่อง “ใช้เวลา 80% ไปกับ 20% สุดท้าย” นี่เป็นประสบการณ์ของผมตั้งแต่ก่อนมี AI แล้ว แค่ลดเวลาในช่วงต้นได้ก็คุ้มมาก คำประเมิน AI ที่ดีที่สุดที่ผมเคยได้ยินจากคนมีประสบการณ์ในสายนี้คือ “90% ของทักษะผมไร้ค่าไปแล้ว และอีก 10% ที่เหลือกลับสำคัญขึ้นพันเท่า” มันอาจพูดเกินจริง แต่ผมชอบแก่นของมัน
ความหลงผิดแบบ “ใกล้เสร็จแล้วตลอดเวลา” นี่แหละที่ทำให้เสียเวลาเปล่า AI เก่งมากในการทำให้สิ่งต่าง ๆ ดูเหมือนมีประโยชน์ ดังนั้นถ้าจะตัดสินว่ามันเพิ่มผลิตภาพจริงไหม ต้องใช้การคิดเชิงวิพากษ์ในระดับสูง
มีประโยชน์เป็นพิเศษตอนเพิ่มฟีเจอร์ลงใน codebase ที่มีอยู่แล้ว เช่นงานอย่าง “เพิ่ม
fooนอกเหนือจาก search parameter เดิม” หรือ “ช่วยลบโค้ดที่เกี่ยวกับxออก”ถึงผู้ใช้ HN ทุกท่าน ผมเป็นผู้เขียนบทความนี้เอง - ใช้ HN มานาน และวันนี้ถ้ามีคำถามหรือ feedback ในคอมเมนต์ ผมจะพยายามตอบให้มากที่สุด ถ้าไม่มีเวลาอ่านบทความเต็ม ผมแนะนำบล็อกโพสต์แนะนำหรือ เธรดประกาศบน x.com
วิธีวิจัยของบทความนี้และวิธีที่ผู้เขียนมาสื่อสารถือว่ามืออาชีพและน่าประทับใจมาก เป็นงานวิจัยที่ดี
ผมคิดว่านี่เป็นหนึ่งในงานวิจัยที่ดีที่สุด เพราะนำเสนอผลลัพธ์อย่างตรงไปตรงมา ไม่ทำ clickbait และเรียบเรียงให้อ่านง่ายมาก
ได้พิจารณาหรือไม่ว่า ticket ที่นำมาให้ AI จัดการนั้นเป็นงานประเภทที่เหมาะกับ AI จริงหรือเปล่า? วิธีแบบ “ลองให้ AI ทำ ticket นี้ดู” ฟังดูสมจริงก็จริง แต่ก็อาจไม่มีประสิทธิภาพ AI ช่วยได้มากเมื่อใช้กับงานที่เหมาะ แต่หลายครั้งก็ให้ผลตรงกันข้าม ถ้าผู้เข้าร่วมมีประสบการณ์กับ AI มากพอ ก็น่าจะจำแนกความต่างนี้ได้ แต่ตอนอ่านบทความผมยังรู้สึกว่าไม่ชัดเจนว่าทำได้หรือไม่
อยากรู้ว่าจะมีโอกาสเผยแพร่ชุดข้อมูลดิบที่ทำให้นิรนามได้ หรืออย่างน้อยเพิ่มข้อมูลเวลาใช้ทำงานจริงแบบ absolute time ของนักพัฒนาแต่ละคนลงในบทความหรือไม่ ผมอยากรู้ว่าผู้เข้าร่วมที่มีประสบการณ์ Cursor สูงนั้นเร็วกว่าคนอื่นจริงหรือแค่เป็นคนที่เดิมช้ากว่าแล้ว AI เลยช่วยยกผลลัพธ์ได้มากขึ้น ดีใจที่ได้เห็นการประเมินเชิงทดลองที่ดีมากและยังคำนึงถึง Hawthorne effect ด้วย
(ผมไม่ได้อ่านบทความ อ่านแค่โพสต์) อยากรู้ว่าได้วัด subjective fatigue ไว้ด้วยไหม ในฐานะตัวชี้วัดที่อาจอธิบายว่าทำไมคนถึงเข้าใจผิดว่า AI เร็วกว่า ตอนเปลี่ยนจากนักพัฒนาไปเป็นผู้จัดการ เวลาสมองล้า AI ให้ความรู้สึกว่าสะดวกกว่าเลยชอบมัน
ผลการศึกษานี้ โดยเฉพาะส่วนที่ว่า “นักพัฒนาคาดว่า AI จะเพิ่มความเร็ว 24% แต่จริง ๆ แล้วช้าลง และแม้ใช้งานจริงแล้วก็ยังเชื่อว่าเร็วขึ้น 20%” น่าสนใจมาก ทำไมช่องว่างระหว่างความจริงกับการรับรู้ถึงใหญ่ขนาดนี้? ผมสงสัยว่าสมองอาจเข้าใจผิด โดยเอา ‘ความพยายามทางจิต’ ไปปนกับประสบการณ์เรื่องเวลาหรือเปล่า
ไม่มีหลักฐานนะ แต่ผมมีความคิดที่น่ากลัวอย่างหนึ่ง: เวลาทำโค้ด การโต้ตอบกับ AI มันกระตุ้นสมองคล้าย dopamine loop ของโซเชียลมีเดียหรือเปล่า (แม้ระดับจะต่างกันก็ตาม) AI คอยเสนอคำตอบซ้ำ ๆ ทำให้สมองรู้สึกเหมือนได้รับการยืนยันเชิงบวก เลยทำให้นักพัฒนาประเมิน AI ในแง่บวกกว่าความจริง? แล้วถ้ามันถึงขั้นก่อพฤติกรรมเสพติดได้จริง จะยิ่งทำให้คนประเมินผลต่อผลิตภาพสูงเกินจริงหรือไม่?
ปรากฏการณ์นี้อาจเป็นผลจากแคมเปญขนาดใหญ่ในตลาด ที่ทำให้ผู้คนจำนวนมากเชื่อว่าเครื่องมือ AI เก่งกว่าความจริง กลุ่มผู้เชี่ยวชาญเศรษฐศาสตร์และ ML เองก็มีส่วนทับซ้อนกับผู้มีผลประโยชน์ในบริษัท AI และผู้บริหารก็รับเรื่องนั้นไปตรง ๆ แล้วสัญญาผลงานใหญ่โต สุดท้ายจึงยกระดับความคาดหวังพื้นฐานขึ้นทั้งระบบ และมันก็ส่งผลแม้กระทั่งกับนักพัฒนาที่มีประสบการณ์ แม้จะพิสูจน์เชิงประจักษ์ได้ยาก แต่ก็อาจอธิบายได้ว่าทำไมภาพลวงรวมหมู่เรื่องผลิตภาพของ AI ถึงแพร่กว้าง
ผมก็สงสัยว่าแฟนพันธุ์แท้ AI จำนวนมากในคอมเมนต์ HN อาจตกอยู่ในปรากฏการณ์นี้เหมือนกัน ถ้าไม่ได้วัดสมรรถนะของตัวเองจริง ๆ ก็ยังน่าสงสัยว่า AI ช่วยเพิ่มผลิตภาพให้ตัวเองจริงหรือไม่
บางทีก็เจอประสบการณ์ตรงข้ามเลย วันนี้ผมลองใช้ Claude code สร้างโค้ดสำหรับแอปเดโมตัวอย่าง ตอนนั่งดูมันทำงานก็รู้สึกเท่มาก เหมือน Sci-Fi และสนุกดี แต่พอผ่านไป 15 นาที กลับรู้สึกสมองล้าและเบื่ออย่างมาก
พอเห็นข้อความว่า “นักพัฒนาคาดว่า AI จะเร็วขึ้น 24% แต่ทั้งที่จริงช้าลงกลับยังเชื่อว่าเร็วขึ้น 20%” ผมรู้สึกว่ามีปัญหาอยู่สองอย่าง
อย่างแรกคือ คนคนเดียวกันแทบจะเปรียบเทียบเวลาได้อย่างถูกต้องไม่ได้ ว่าในบริบทเดียวกันถ้าทำงานด้วย AI กับไม่ใช้ AI ใช้เวลาต่างกันเท่าไร
อีกอย่างคือ มันวัดประสิทธิภาพของ AI ด้วยตัวชี้วัดผิวเผินอย่างเวลาเปิด PR หรือ merge ได้ง่าย แต่ในความจริงเมื่อใช้ AI เวลาจะถูกย้ายไปอยู่กับงานหลังบ้านมากขึ้น เช่น refactoring, testing, แก้ issue ต่าง ๆ
ถ้าดูแค่ว่า “เปิด PR ได้เร็วขึ้น” ก็เลยหลงคิดง่ายว่า AI เร็วกว่า ทั้งที่มองข้ามงานถัดไปที่เพิ่มขึ้น
การวัดผลว่าทักษะหรือแนวปฏิบัติใดส่งผลต่อผลิตภาพแค่ไหนเป็นเรื่องยากมาก ผมคิดว่าอันตรายถ้าจะเชื่อแต่ anecdote แล้วสรุปผล เพราะใคร ๆ ก็หลอกตัวเองได้ง่าย ตัวงานวิจัยเองก็ยอมรับข้อจำกัดอยู่แล้ว ดังนั้นเวลาอภิปรายเรื่องผลิตภาพควรตระหนักถึงช่วงความคลาดเคลื่อนที่กว้าง เทคโนโลยีอย่าง AI เป็นสิ่งที่ประหลาดที่สุดที่ผมเคยเห็นมา การพยายามอ่านเหตุและผลจากเคสสั้น ๆ หรือ benchmark ที่ชวนสงสัยแทบเหมือนการทำนายดวง
ในบทความนี้ไม่พบว่าคุณภาพของ PR ลดลงระหว่างเงื่อนไขที่ใช้ AI กับไม่ใช้ AI ผู้เข้าร่วมส่วนใหญ่คุ้นกับมาตรฐานของ repository อยู่แล้ว และไม่ได้มีสไตล์แบบ “ส่งลวก ๆ ให้ขึ้น PR ไปก่อน” เวลา review ระหว่างทางของ PR ในงานวิจัยนี้อยู่ราว 1 นาที อย่างที่คุณพูด วิธีใช้เวลานั้นเปลี่ยนไปอย่างชัดเจน หน้า 10 ของบทความมีการแจกแจงเวลาระหว่างใช้กับไม่ใช้ AI ให้ดู เมื่อใช้ AI เวลาลงมือเขียนโค้ดจะลดลง แต่เวลาโต้ตอบกับ AI กลับเพิ่มขึ้น
สำหรับข้อชี้ว่ามันเป็นไปไม่ได้ที่จะรู้เวลาแตกต่างอย่างแม่นยำว่า “คนเดียวกันในบริบทเดียวกันใช้ AI แล้วใช้เวลาเท่าไร เทียบกับไม่ใช้ AI เท่าไร” นั้น การออกแบบการทดลองใช้การสุ่มกำหนด (random assignment) เพื่อแยกผลของกลุ่ม AI และกลุ่มไม่ใช้ AI ความแตกต่างเฉพาะตัว สถานการณ์ และสภาพแวดล้อมจะถูกเฉลี่ยหักล้างกันด้วยการสุ่ม ถ้าขนาดตัวอย่างและขนาดผลมากพอ ก็สามารถดึงความแตกต่างที่มีนัยสำคัญทางสถิติออกมาได้
ถ้าดู Figure 21 จะเห็นว่าแม้แต่เวลาเริ่มต้นทำ implementation จนถึงเปิด PR ก็เพิ่มขึ้น และหลัง review PR เวลาก็เพิ่มต่ออีก แต่โดยรวมดูเหมือนผลกระทบจะไม่มากนัก อย่างที่เห็นใน Figure 18 เวลาที่ใช้เขียนโค้ดจริงลดลง แต่ถูกหักล้างด้วยเวลาที่ใช้เขียน prompt, รอผลลัพธ์ และตรวจ output งานเล็ก ๆ ที่ใช้เวลาไม่เกิน 5 นาทีอาจจะดีกว่าถ้าไม่ใช้ LLM เลย
ผมอยากเห็นการเปรียบเทียบเนื้อหา PR ตามแต่ละ workflow Copilot มักเสนอโค้ดมากกว่าที่ผมจะเขียนเอง และหลายครั้งก็เป็นโค้ดที่ยืดยาวโดยไม่มี abstraction ที่ดี มีการเช็กหรือทำซ้ำเกินจำเป็น สมมติฐานส่วนตัวของผมคือ เวลาคนเห็น LLM เขียนโค้ดออกมาเยอะ ๆ จะทำให้การรับรู้ว่าต้องใช้เวลานานแค่ไหนในการแก้ปัญหาบิดเบือนไป
จุดที่ยากจริง ๆ ของการใช้ LLM ทำงานกับ codebase ขนาดใหญ่ คือการอธิบายงานที่ต้องทำให้แม่นยำ การจะอธิบาย issue ท่ามกลางปฏิสัมพันธ์ของโค้ดจำนวนมาก บางครั้งกลับใช้เวลานานกว่าลงมือแก้เองด้วยมือ แต่สำหรับงานโปรเจกต์ใหม่ที่ต้องสร้าง boilerplate code ดูเหมือน LLM จะเหมาะที่สุด
แค่ค่าหาคนเข้าร่วมก็กินงบ 300 x 246 = ประมาณ 73K แล้ว แต่บทความนี้ก็ยังไม่ได้ตีพิมพ์ในวารสารหรือผ่าน peer review ด้วยซ้ำ ภายนอกมันดูเรียบร้อยและไม่ได้เหมือน AI สร้างขึ้น แต่ก็ยังสงสัยว่าหาเงินทุนมาทำแบบนี้ได้อย่างไร
แหล่งสนับสนุนทางการเงินที่ใหญ่ที่สุดคือ The Audacious Project ซึ่งตรวจสอบได้จาก ประกาศอย่างเป็นทางการ และยังมี เชิงอรรถบนเว็บไซต์ ระบุด้วยว่าจนถึงเดือนเมษายน 2025 พวกเขายังไม่ได้รับค่าตอบแทนสำหรับการประเมินจากบริษัท AI
บริษัทต่าง ๆ มักปล่อย ‘whitepaper’ ลักษณะนี้ออกมาบ่อย มันเป็นรูปแบบผสมระหว่างรายงานเทคนิค ข้อเสนอเชิงนโยบาย และสื่อประชาสัมพันธ์
ผมไม่คิดว่าการยึดติดแค่ว่ามีวารสารหรือ peer review หรือไม่จะมีความหมายมาก วิทยาศาสตร์ไม่ได้สำคัญเพราะใครเป็นคนตีพิมพ์ แต่สำคัญที่การทำซ้ำและผลที่ยืนยันซ้ำได้ อย่างกรณีวิกฤตการทำซ้ำในจิตวิทยา การได้ลงวารสารเองก็ไม่ได้รับประกันความน่าเชื่อถือ
ประเทศส่วนใหญ่มีเงินสนับสนุนสาธารณะสำหรับงานวิจัย สหรัฐฯ เคยสนับสนุนมากกว่านี้ในอดีต แต่ช่วงหลังถูกตัดลดลงอย่างมาก
ถ้าดูจาก หน้าแนะนำองค์กร เหมือนว่าจะได้รับเงินจากหลายฝ่าย ทั้งบริษัท AI และหน่วยงานรัฐ
สำหรับโครงการ OSS งานอดิเรก AI กลับเป็นตัวรบกวนมากกว่า เรื่องสร้างโค้ดหรือ scaffolding ไม่ใช่สิ่งที่น่ากังวลเลย สิ่งสำคัญกว่าคือ code review และการดูแลชุมชน ซึ่งเป็นงานที่เครื่องมือ AI ช่วยได้จำกัดชัดเจน แต่มีคนเอาเครื่องมือ AI code review ไปใส่ใน PR ที่ผมเปิด ทำให้ PR แค่ 30 บรรทัดมีสรุปยาว 2 หน้า พร้อม emoji และ bullet point ที่จัดสวยงาม กลายเป็นแค่ noise ที่ไม่จำเป็น ตอนนี้เลยต้องเสียเวลาจริงไปกับการลบหรือซ่อนคอมเมนต์พวกนั้นเพิ่มอีก
ต่อให้ข้ามเส้นโค้งการเรียนรู้ไปแล้วมันอาจเร็วขึ้นจริง (หรืออย่างที่มีคนพูดว่า “จนลืมวิธีทำงานโดยไม่มี AI ไปเลย”) สิ่งที่ควรวัดจริง ๆ คือ… ตอนตี 3 เมื่อ PagerDuty แจ้งเตือนขึ้นมา จะใช้เวลานานแค่ไหนกว่าจะ debug โค้ดนั้นได้ และคุณภาพระยะยาวของโค้ดนั้นเป็นอย่างไร ผมใช้เวลานานมากในการปรับโครงสร้างโค้ด เช่น ดึง business logic ขึ้นไปไว้ใน shared folder รวม call chain ขึ้นด้านบน ทำให้ API ด้านล่างสะอาดขึ้น แยก logic/API/display ออกจากกัน ทำ encapsulation ฯลฯ (รวมถึงลด coupling ด้วย dependency injection) แล้วโค้ดที่ AI เขียนจะมีคุณภาพ ความย้ายข้ามระบบ และความขยายต่อได้ดีกว่าในระยะยาวหรือไม่? หรือสุดท้ายจะกลายเป็นโค้ดคุณภาพต่ำที่กองพะเนินจนกลายเป็นกองขยะพันกัน แล้วท้ายที่สุดต้องใช้เวลาครึ่งหนึ่งไปกับการแก้บั๊ก?