งานวิจัย METR: ใช้ AI เขียนโค้ดแล้วช้าลง 19% แต่รู้สึกว่าเร็วขึ้น 20%

กลางปี 2025 องค์กรวิจัย METR ปล่อยผลการทดลองที่คนในวงการพูดถึงกันมาก นักพัฒนาที่ชำนาญใช้ AI ช่วยเขียนโค้ดแล้ว ใช้เวลามากขึ้น 19% ทั้งที่ก่อนเริ่มคาดว่าจะเร็วขึ้น 24% และหลังทำเสร็จก็ยังเชื่อว่าเร็วขึ้น 20% ตัวเลขนี้ถูกยกไปใช้ทั้งฝั่งที่บอกว่า AI ไม่ช่วย และฝั่งที่บอกว่างานวิจัยผิด บทความนี้สรุปว่าการทดลองทำอะไร บอกอะไรได้ บอกอะไรไม่ได้ ผลรอบใหม่ปี 2026 เป็นยังไง และเราเอาวิธีของเขามาวัดงานตัวเองได้ยังไง

ตรวจข้อเท็จจริงกับ: บล็อกของ METR และ paper บน arXiv (2507.09089) รวมถึงบันทึกอัปเดตของ METR เมื่อ 24 กุมภาพันธ์ 2026 ณ ตุลาคม 2026

การทดลองทำอะไร

METR ทำ randomized controlled trial (RCT) ซึ่งเป็นแบบการทดลองที่น่าเชื่อถือที่สุดเมื่ออยากรู้ว่าอะไรเป็นสาเหตุ

• คน: นักพัฒนา 16 คน แต่ละคนดูแลโปรเจกต์ open source ใหญ่มาหลายปี โปรเจกต์เฉลี่ยมีดาวบน GitHub กว่า 22,000 และโค้ดกว่าล้านบรรทัด
• งาน: 246 issue จริงจากโปรเจกต์ของเขาเอง (แก้บั๊ก เพิ่มฟีเจอร์ refactor) เฉลี่ยงานละราว 2 ชั่วโมง
• การสุ่ม: แต่ละงานถูกสุ่มว่า “ใช้ AI ได้” หรือ “ห้ามใช้ AI”
• เครื่องมือ: ส่วนใหญ่ใช้ Cursor Pro กับ Claude 3.5/3.7 Sonnet ซึ่งเป็นรุ่นแนวหน้าของช่วงนั้น
• การวัด: อัดหน้าจอ และให้รายงานเวลาที่ใช้ จ่ายค่าตอบแทนชั่วโมงละ 150 ดอลลาร์

จุดที่ทำให้ผลนี้มีน้ำหนักคือ การสุ่มรายงาน คนเดียวกัน โปรเจกต์เดียวกัน ต่างกันแค่ได้ใช้ AI หรือไม่ได้ใช้

ผลที่ได้

ตัวเลข	ค่า
นักพัฒนาคาดก่อนเริ่ม	เร็วขึ้น 24%
ผู้เชี่ยวชาญเศรษฐศาสตร์คาด	เวลาลดลง 39%
ผู้เชี่ยวชาญ ML คาด	เวลาลดลง 38%
ผลจริง	ใช้เวลามากขึ้น 19% (ช่วงความเชื่อมั่น +2% ถึง +39%)
นักพัฒนาเชื่อหลังทำเสร็จ	เร็วขึ้น 20%

ข้อที่น่าสนใจที่สุดไม่ใช่ตัวเลข 19% แต่คือ ช่องว่างระหว่างความรู้สึกกับเวลาจริง คนที่ทำงานนั้นเอง รู้ว่ากำลังถูกวัด ยังประเมินผิดทิศ

ตัวอย่างคำนวณ: ช่องว่างในงาน 2 ชั่วโมง

เอางานเฉลี่ย 2 ชั่วโมง (120 นาที) มาคิด

1. เวลาจริงเมื่อใช้ AI: 120 × 1.19 = 142.8 ≈ 143 นาที
2. เวลาที่รู้สึก (เชื่อว่าเร็วขึ้น 20%): 120 × 0.80 = 96 นาที
3. ช่องว่าง: 143 − 96 = 47 นาที ต่องาน

แปลว่าในความรู้สึกเขาประหยัดไป 24 นาที แต่ความจริงเสียเพิ่ม 23 นาที ถ้าทำงานแบบนี้วันละ 3 งาน ช่องว่างต่อวันคือ 47 × 3 = 141 นาที หรือราว 2 ชั่วโมงกว่า ที่คนทำไม่รู้ตัว

ความรู้สึกว่าเร็วขึ้นไม่ใช่หลักฐานว่าเร็วขึ้น ถ้าอยากรู้ ต้องจับเวลา

เวลาหายไปไหน

paper วิเคราะห์ภาพหน้าจอ เมื่อใช้ AI นักพัฒนาใช้เวลาเขียนโค้ดเองและค้นข้อมูลน้อยลง แต่ไปใช้กับการเขียน prompt, รอ AI, อ่านและแก้สิ่งที่ AI ทำ และนั่งว่างมากขึ้น ตัวเลขบางส่วนจาก paper

• ยอมรับโค้ดที่ AI สร้าง ไม่ถึง 44% ส่วนที่เหลือทิ้งหรือเขียนใหม่
• ราว 9% ของเวลาไปกับการรีวิวและเก็บกวาดผลของ AI
• ราว 4% ของเวลาคือรอ AI สร้างคำตอบ

ผู้วิจัยดู 20 ปัจจัยที่อาจอธิบายผล และพบหลักฐานว่า 5 ข้อน่าจะมีส่วน

1. คาดหวังกับ AI สูงเกินไป ใช้แม้ในงานที่ทำเองเร็วกว่า
2. นักพัฒนารู้จักโปรเจกต์ดีมากอยู่แล้ว AI จึงเหลือที่ให้ช่วยน้อย
3. โปรเจกต์ใหญ่และซับซ้อน
4. AI ยังให้ผลที่ใช้ได้ไม่สม่ำเสมอ
5. มีบริบทของโปรเจกต์ที่ไม่ได้เขียนไว้ (กติกา ธรรมเนียม) ที่ AI ไม่รู้

ข้อ 5 ตรงกับที่เราเจอเอง วิธีแก้ส่วนหนึ่งคือเขียนกติกาโปรเจกต์ให้ AI อ่าน ดู ไฟล์ส่งต่องานระหว่าง session และอีกส่วนคือรีวิวให้เป็นระบบ ดู checklist รีวิวโค้ดที่ AI เขียน

ผลนี้ไม่ได้บอกอะไร

METR เขียนรายการไว้เองว่าผลนี้ ไม่ได้ แสดงว่า

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

ข้อจำกัดอื่น 16 คนถือว่าน้อย และมีความเป็นไปได้ว่าคนที่สมัครเข้าร่วมไม่ใช่ตัวแทนทั่วไป ผลของการเรียนรู้หลังใช้ Cursor เกินราว 50 ชั่วโมงก็ยังตัดออกไม่ได้

ผลรอบใหม่ กุมภาพันธ์ 2026

METR ทำการทดลองรอบใหม่ เริ่มสิงหาคม 2025 ใหญ่กว่าเดิม: นักพัฒนา 57 คน 143 โปรเจกต์ กว่า 800 งาน และติดป้ายบนหน้าผลเดิมว่า “ผลล้าสมัยแล้ว”

กลุ่ม	ผล (ค่าลบ = ใช้เวลาน้อยลง)	ช่วงความเชื่อมั่น
รอบแรก (ต้นปี 2025)	+19%	+2% ถึง +39%
คนเดิมที่กลับมา (10 คน)	−18%	−38% ถึง +9%
คนใหม่ (47 คน)	−4%	−15% ถึง +9%

ดูเหมือนพลิกเป็นเร็วขึ้น แต่ METR เองเรียกข้อมูลรอบนี้ว่าเป็น “สัญญาณที่เชื่อถือไม่ได้” เหตุผลหลักคือ 30% ถึง 50% ของนักพัฒนาบอกว่าเลือกไม่ส่งบางงานเข้าการทดลอง เพราะไม่อยากทำงานนั้นโดยไม่มี AI งานที่ AI ช่วยได้มากจึงหลุดออกไปจากข้อมูล METR สรุปว่าน่าจะเร็วขึ้นจริงเมื่อเทียบกับต้นปี 2025 แต่ข้อมูลเป็นหลักฐานที่อ่อนมากว่าเร็วขึ้นเท่าไร และกำลังเปลี่ยนวิธีทดลอง

วัดงานตัวเองแบบไม่หลอกตัวเอง

เราไม่ต้องรองานวิจัยรอบหน้า ใช้หลักเดียวกันกับงานตัวเองได้

1. ก่อนเริ่มแต่ละงาน จดว่าคิดว่าจะใช้กี่นาที ถ้าไม่ใช้ AI
2. สุ่ม ว่างานนี้ใช้ AI หรือไม่ (โยนเหรียญ หรือ python -c "import random; print(random.choice(['AI','no AI']))")
3. จับเวลาจริง ตั้งแต่เริ่มจนงานผ่าน review ไม่ใช่แค่ตอนโค้ดเสร็จ
4. หาอัตราส่วน เวลาจริง ÷ เวลาที่เดา แยกสองกลุ่ม แล้วเทียบกัน

ตัวอย่างคิดเลข (ตัวเลขสมมติ เพื่อแสดงวิธีคิด ไม่ใช่ผลวัดจริง) ทำไป 20 งาน กลุ่มละ 10

• กลุ่มใช้ AI: เดารวม 600 นาที ใช้จริง 660 นาที → 660 ÷ 600 = 1.10
• กลุ่มไม่ใช้ AI: เดารวม 600 นาที ใช้จริง 570 นาที → 570 ÷ 600 = 0.95
• เทียบ: 1.10 ÷ 0.95 = 1.16 → กลุ่มใช้ AI ช้ากว่าราว 16%

การหารด้วยเวลาที่เดาไว้ก่อน คือวิธีที่ METR ใช้ปรับความยากของแต่ละงาน งานยากไม่ไปตกกลุ่มไหนกลุ่มหนึ่งจนผลเพี้ยน แต่ต้องจำว่า 20 งานยังน้อยมาก METR ใช้ 246 งานแล้วช่วงความเชื่อมั่นยังกว้าง +2% ถึง +39% ผลจาก 20 งานบอกได้แค่ทิศคร่าว ๆ ให้เก็บต่อเนื่องหลายสัปดาห์

ถ้าทำฟีเจอร์ที่ใช้ AI ในผลิตภัณฑ์ หลักเดียวกันคือวัดด้วยชุดทดสอบ ไม่ใช่ความรู้สึก ดู ชุด eval เล็ก ๆ

ข้อผิดพลาดที่เจอบ่อย

• ยกตัวเลข 19% ไปสรุปว่า AI ไม่ช่วย ทั้งที่ METR บอกเองว่าผลล้าสมัยและใช้กับกลุ่มเฉพาะ
• ยกผลรอบใหม่ไปสรุปว่า AI เร็วขึ้น 18% ทั้งที่ช่วงความเชื่อมั่นคร่อมศูนย์ และ METR เองบอกว่าเชื่อถือไม่ได้
• วัดแค่เวลาเขียนโค้ด ไม่นับเวลารีวิว แก้บั๊กที่ตามมา และรอ AI
• เลือกเองว่างานไหนจะใช้ AI แล้วเอามาเทียบ งานที่เราเลือกใช้ AI มักเป็นงานที่ง่ายกับ AI อยู่แล้ว ผลจึงเข้าข้างเสมอ ต้องสุ่ม
• เชื่อความรู้สึกหลังทำเสร็จ ซึ่งเป็นตัวที่งานวิจัยนี้แสดงว่าผิดได้มากที่สุด

แหล่งอ้างอิง

• Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — METR
• Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — arXiv 2507.09089
• We are Changing our Developer Productivity Experiment Design — METR
• AI coding can make developers slower even if they feel faster — The Decoder