บทนำ ‒ ความเข้าใจผิดและความเป็นจริงเกี่ยวกับประสิทธิภาพของนักพัฒนาเมื่อใช้ AI
- Mark Zuckerberg (CEO ของ Meta) ประกาศว่า "ภายในปลายปี 2025 จะใช้ AI แทนวิศวกรระดับกลางทั้งหมด" ทำให้ CTO ของหลายบริษัทต้องเผชิญแรงกดดันแบบเดียวกัน
- ผู้บรรยายย้ำชัดว่า "AI ไม่สามารถทดแทนนักพัฒนาได้ทั้งหมด" และเน้นว่า แม้การนำ AI มาใช้จะช่วยเพิ่มประสิทธิภาพได้อย่างชัดเจน แต่ก็ไม่ได้เป็นเช่นนั้นเสมอไป และหลายกรณีกลับพบว่าประสิทธิภาพลดลงด้วย
การออกแบบงานวิจัยและข้อมูล
- วัดผลตลอด 3 ปี ครอบคลุมบริษัทกว่า 600 แห่ง วิศวกรซอฟต์แวร์มากกว่า 100,000 คน โค้ดมากกว่าพันล้านบรรทัด และคอมมิตหลายสิบล้านรายการ
- ข้อมูลส่วนใหญ่มาจาก Private Repo จึงสามารถวัดการเปลี่ยนแปลงของประสิทธิภาพจริงในระดับทีมพัฒนาและระดับองค์กรได้
ข้อจำกัดของงานวิจัยเดิม
- รายงานที่ขับเคลื่อนโดยผู้ขาย มักมีเป้าหมายเพื่อโปรโมตเครื่องมือ AI ของตนเอง จึงขาดความเป็นกลาง
- การดูเพียงจำนวนคอมมิต/PR หรือการเปลี่ยนแปลงของเวลาเฉลี่ยในการทำงาน อาจบิดเบือนประสิทธิภาพจริงได้
- ตัวอย่าง: ทันทีหลังเริ่มใช้ AI จำนวนคอมมิตที่เป็นบั๊กหรือการทำซ้ำงาน (rework) มักเพิ่มขึ้นด้วย จึงทำให้ดูเหมือนว่าประสิทธิภาพสูงขึ้นเพียงผิวเผิน
- ใน "การทดลองแบบ Greenfield (โปรเจกต์ใหม่)" ผลของ AI ดูสูงมาก แต่เมื่อเป็นโค้ดเดิม (Brownfield) ความแตกต่างจะลดลง
- แบบสำรวจนักพัฒนา (Self-report) มีความสัมพันธ์กับประสิทธิภาพจริงต่ำมาก (ช่องว่างระหว่างความรู้สึกกับความจริงมากกว่า 30 จุดเปอร์เซ็นต์)
โมเดลการวัดประสิทธิภาพของ Stanford
- ใช้ โมเดลอัตโนมัติที่ขับเคลื่อนด้วย AI ซึ่งทำงานคล้ายการประเมินโดยคณะผู้เชี่ยวชาญ:
- วัด การเปลี่ยนแปลงเชิงหน้าที่ ของแต่ละคอมมิต (added/removed/refactored/rework)
- ไม่ได้ดูแค่ "จำนวนบรรทัด" แต่เน้นที่ "ฟังก์ชัน การบำรุงรักษา และคุณภาพ"
- วัดได้ละเอียดทั้งปริมาณการเพิ่มฟังก์ชัน การรีแฟกเตอร์ และสัดส่วนการแก้ซ้ำ (rework) ของคอมมิตล่าสุด
ผลลัพธ์หลักของการวิจัย
- โดยรวมแล้ว เมื่อใช้ AI ประสิทธิภาพเฉลี่ยเพิ่มขึ้น 15~20%
- แต่ก็มักมาพร้อม "การทำซ้ำงาน" (rework) ในปริมาณมาก ทำให้ประโยชน์ที่รับรู้อาจถูกประเมินสูงเกินจริง
- มี ความแปรปรวนสูง ตามทีม บริษัท และประเภทของงาน
สาเหตุของช่องว่างด้านประสิทธิภาพ: ความยากของงาน ประเภทโปรเจกต์ ภาษา และขนาดของ codebase
| ประเภทโปรเจกต์ | ความซับซ้อนต่ำ | ความซับซ้อนสูง |
|---|---|---|
| Greenfield (ใหม่) | 30~40% ↑ | 10~15% ↑ |
| Brownfield (เดิม) | 15~20% ↑ | 0~10% ↑ |
- ใน โปรเจกต์ใหม่แบบ Greenfield ที่ซับซ้อนไม่มาก ผลของ AI สูงมาก
- แต่ใน ระบบเดิมแบบ Brownfield ที่ซับซ้อน ประสิทธิผลจะลดลงอย่างชัดเจน และบางกรณีพบว่า ประสิทธิภาพลดลงด้วย
- อ้างอิงจากตัวอย่างจริง 136 ทีมใน 27 บริษัท (ตามที่กล่าวในบรรยาย)
ความนิยมของภาษาและผลของ AI
- ใน Python/Java/JavaScript (ภาษายอดนิยม) AI ช่วยเพิ่มประสิทธิภาพได้มาก
- ส่วน COBOL/Elixir/Haskell (ภาษาที่ไม่เป็นที่นิยม): แทบไม่ได้รับประโยชน์จาก AI และในงานที่ซับซ้อนอาจกลายเป็นการเสียเวลาและทำให้ประสิทธิภาพลดลง
- ตัวอย่าง: ในภาษาที่ไม่เป็นที่นิยมและมีความยากสูง "มีข้อผิดพลาดมาก และเขียนโค้ดที่ถูกต้องไม่ได้" → ไม่มี AI ยังดีกว่า
ขนาดของ codebase และผลของ AI
- ยิ่ง codebase มีขนาดใหญ่ ผลในการเพิ่มประสิทธิภาพจาก AI ยิ่งลดลงอย่างรวดเร็ว
- สาเหตุ:
- ข้อจำกัดของ context window: LLM ไม่สามารถใส่บริบททั้งหมดจากหลายไฟล์หรือหลายแสนถึงหลายล้านบรรทัดได้ครบ
- "อัตราส่วนสัญญาณต่อสัญญาณรบกวน" ลดลง: ยิ่งมีข้อมูลบริบทมาก AI ยิ่งระบุข้อมูลที่เหมาะสมได้ยาก
- ยิ่งมีความซับซ้อนเฉพาะโดเมนและบริการมากขึ้น ความยากในการทำซ้ำหรือสร้างใหม่ก็ยิ่งสูงขึ้น
- ในทางปฏิบัติ LLM ขนาดใหญ่รุ่นใหม่ (เช่น Gemini 1.5 Pro) มีความแม่นยำลดฮวบจาก 90% เหลือต่ำกว่า 50% เมื่อ "จำนวนโทเคน" เพิ่มขึ้น
- สาเหตุ:
สรุปรวม: AI มีประสิทธิภาพเมื่อใด?
- AI ช่วยเพิ่มประสิทธิภาพของนักพัฒนาอย่างชัดเจนในกรณีส่วนใหญ่ โดยเฉพาะการเขียนโค้ดใหม่ที่ไม่ซับซ้อน
- แต่ในสภาพแวดล้อมที่มี งานบำรุงรักษาซับซ้อน โค้ดเก่าขนาดใหญ่ ภาษากลุ่มเฉพาะ หรือ dependency จำนวนมาก ข้อจำกัดจะเด่นชัดมาก
- กลยุทธ์การใช้ AI เพื่อเพิ่มประสิทธิภาพที่ดีที่สุด ต้องออกแบบอย่างรอบคอบให้เหมาะกับลักษณะของบริษัท ทีม และงานแต่ละประเภท (ไม่ใช่ "one size fits all")
- แบบสำรวจ ตัวชี้วัดทางการตลาด หรือการเพิ่มขึ้นของจำนวนคอมมิตเพียงอย่างเดียวเชื่อถือได้ยาก จึงจำเป็นต้องใช้ "การวัดตามสภาพจริง" เช่น ฟังก์ชันของโค้ด สัดส่วนงานซ้ำ และปริมาณการ rework
ความเห็นเพิ่มเติมและกรณีตัวอย่าง
- "Ghost engineer": ในข้อมูลพบว่า 10% ของวิศวกรแทบไม่ได้ทำงาน แต่ยังได้รับเงินเดือนอยู่
- เน้นย้ำความจำเป็นของเครื่องมือ "การตัดสินใจบนฐานตัวชี้วัด" เพื่อให้หัวหน้าทีมและ CTO วินิจฉัยปัญหาจริงได้อย่างรวดเร็ว
บทสรุป
- AI ช่วยเพิ่มประสิทธิภาพใน "สถานการณ์ส่วนใหญ่" แต่ต้องระวังทั้งการประเมินค่าสูงเกินจริงและต่ำเกินจริง
- ควรระบุ "เงื่อนไขเฉพาะ" ที่ทำให้การใช้งานได้ผลดี (งานง่าย/งานใหม่/ภาษายอดนิยม/codebase ขนาดเล็ก) แล้วจึงนำไปใช้ เพราะการนำมาใช้แบบไม่วิจารณญาณหรือใช้แบบหว่าน อาจให้ผลย้อนกลับได้
2 ความคิดเห็น
แม้จะยังไม่นำไปใช้กับซอฟต์แวร์หลัก แต่ AI ก็ช่วยประหยัดเวลาได้มากทั้งในโปรแกรมทดสอบหรือช่วงเริ่มต้นของโปรเจ็กต์
ต่อให้ไม่นับเรื่องที่มันช่วยเขียนโค้ดให้ ผมก็คิดว่าฟังก์ชันผู้ช่วยเปลี่ยนไปแบบหน้ามือเป็นหลังมือหลังจากนำ AI เข้ามาใช้ ตอนนี้ผมมองว่า AI ไม่ใช่ทางเลือกอีกต่อไป แต่เป็นสิ่งจำเป็นแล้ว
จริง ๆ แล้วมันช่วยได้มากในขั้นทำ MVP โดยเฉพาะงานเขียนคอมเมนต์ การทำล็อกกิง และการเขียนประวัติการเปลี่ยนแปลง ซึ่งผมคิดว่าควรใช้แบบไม่ต้องลังเล
แต่เมื่อโค้ดเบสใหญ่ขึ้น มันจะเกิดอาการหลอนและลืมโค้ดเดิม ทำให้สร้างผลลัพธ์แปลก ๆ ออกมาได้ จึงต้องหาวิธีใช้ context engineering หรือหาวิธีลดขนาดโค้ดเบส
คิดว่าถ้าใช้พรอมป์ต์ที่ใหญ่กว่านี้ได้ก็น่าจะดีขึ้น
ตอนนี้ดูเหมือนว่าจะทำงานได้ดีกับ Java, Python, JavaScript และ Go ผมใช้ Copilot เป็นหลัก และใช้ Claude กับ ChatGPT ด้วย