ผลกระทบของ Gen AI ต่องานที่ต้องใช้ทักษะสูง: การทดลองกับนักพัฒนาซอฟต์แวร์
(papers.ssrn.com)สรุป
- ภาพรวมของงานวิจัย
- งานวิจัยนี้ประเมินผลกระทบของ generative AI ต่อผลิตภาพของนักพัฒนาซอฟต์แวร์ ผ่านการทดลองแบบสุ่มมีกลุ่มควบคุม 3 ชุดที่ดำเนินการใน Microsoft, Accenture และบริษัทผู้ผลิตอุปกรณ์อิเล็กทรอนิกส์ในกลุ่ม Fortune 100 ที่ไม่เปิดเผยชื่อ
- การทดลองดำเนินไปในฐานะส่วนหนึ่งของงานประจำวันของแต่ละบริษัท โดยมอบ GitHub Copilot ซึ่งเป็นผู้ช่วยเขียนโค้ดที่ขับเคลื่อนด้วย AI ให้แก่นักพัฒนาที่ถูกสุ่มเลือก
- งานวิจัยนี้ซึ่งครอบคลุมนักพัฒนาซอฟต์แวร์ทั้งหมด 4,867 คน พบว่าจำนวนงานที่ทำเสร็จของนักพัฒนาที่ใช้เครื่องมือ AI เพิ่มขึ้น 26.08% (ค่าคลาดเคลื่อนมาตรฐาน: 10.3%)
- โดยเฉพาะอย่างยิ่ง นักพัฒนาที่มีประสบการณ์น้อยกว่ามีอัตราการยอมรับการใช้งานและการเพิ่มขึ้นของผลิตภาพที่สูงกว่า
สรุปโดย GN⁺
- งานวิจัยนี้แสดงให้เห็นว่า generative AI สามารถเพิ่มผลิตภาพของนักพัฒนาซอฟต์แวร์ได้อย่างมีนัยสำคัญ
- มีประโยชน์อย่างยิ่งสำหรับนักพัฒนาที่มีประสบการณ์น้อยกว่า ซึ่งบ่งชี้ว่าเครื่องมือ AI อาจช่วยลดความชันของเส้นโค้งการเรียนรู้ได้
- เครื่องมือ AI อย่าง GitHub Copilot สามารถมีบทบาทสำคัญในการเพิ่มประสิทธิภาพของการพัฒนาซอฟต์แวร์
- โครงการอื่นที่มีความสามารถคล้ายกัน ได้แก่ TabNine และ Kite
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
บางครั้งก็สงสัยว่าเหตุผลที่คุณภาพของบุคลากร IT ลดลง เป็นเพราะบริษัทต่าง ๆ พยายาม ลดจำนวนคน ด้วยการยัดบทบาทให้คนคนเดียวมากขึ้นเรื่อย ๆ หรือเปล่า
สมัยก่อน การพัฒนา การปฏิบัติการ และความปลอดภัยเป็นบทบาทเฉพาะทางแยกกัน แต่พอมี DevOps บางบริษัทกลับตีความว่าไม่ใช่การรวมทีม แต่หมายความว่าสามารถมีคนแค่ 2/3 ก็พอ และพอมี DevSecOps ก็คิดว่าต้องมีคนแค่ 1/3 ของบทบาทเดิมก็พอ ให้ developer ทำทั้ง operations และ application security ไปด้วย
ไม่ได้กำลังวิจารณ์แนวคิด shift-left หรือโมเดลการปฏิบัติการแบบรวมศูนย์ในตัวมันเอง แต่หมายความว่านี่คือผลลัพธ์เชิงตรรกะที่โมเดลเหล่านี้ก่อให้เกิด เมื่อผู้บริหารคิดว่าถ้าลดคนเพื่อตัดต้นทุนได้ก็จะได้โบนัสมากขึ้น
ตอนนี้ developer หน้าใหม่ต้องเข้ามาอยู่ในสภาพแวดล้อมไมโครเซอร์วิสจำนวน n ตัวที่ซับซ้อนอย่างไร้เหตุผล ต้องเรียนรู้ codebase เดิม pipeline CI/CD 5 ชุด ไปจนถึงบทบาท DBA พร้อมกับต้องรักษารอบการ release ให้สม่ำเสมอ
มันน่าแปลกใจจริงหรือที่พวกเขาใช้ ChatGPT เพื่อพยายามไล่ให้ทัน และเรื่องนี้จะดำเนินต่อไปจนกว่าบริษัท IT จะหยุดลดจำนวนคนเพื่อ “ดันตัวเลขกำไร” แทนที่จะมีกลยุทธ์ธุรกิจที่ดี
สิ่งที่พวก MBA มองข้ามคือปรากฏการณ์ ข้อจำกัดที่มากเกินไป ถ้าแยกบทบาททั่วไปอย่าง “developer” ออกเป็น “development, operations, security” ก็จะเกิดรายละเอียดปลีกย่อยสารพัดว่าบทบาทแต่ละอย่างควรทำอย่างไร ต่อให้รวมกลับมาเป็น DevSecOps รายละเอียดเหล่านั้นก็ยังคงอยู่เหมือนเดิม ทำให้คนคนเดียวไม่ได้ทำงานมีประสิทธิภาพขึ้น 3 เท่า แต่ต้องแบกรับงาน 3 เท่า
ถ้าจะย้อนกลับให้ถูกต้อง ต้องผ่อนคลายข้อจำกัด และปล่อยให้คนคนนั้นใช้วิจารณญาณเองว่าจะทำงานอย่างไร
ข้อสรุปจากเรื่องนี้คือขนาดองค์กรไม่สามารถลดลงได้ มีแต่จะเพิ่มขึ้นเท่านั้น ยิ่งพนักงานมากขึ้น หน้าที่งานก็ยิ่งเฉพาะทางมากขึ้น และถ้าตัดคนเหล่านั้นออก ฟังก์ชันนั้นก็จะไม่ถูกทำไปเลย เพราะในระดับความเฉพาะทางนั้น พนักงานที่เหลือยากจะรับผิดชอบงานใหม่ ๆ เพียงด้วยการปรับ job description นิดหน่อย
สุดท้ายจึงต้องทิ้งองค์กรเก่า แล้วเริ่มใหม่ด้วยองค์กรที่เล็กและใหม่กว่า และนี่ก็เป็นเหตุผลที่ระบบนิเวศ private equity/venture capital/startup มีอยู่ กฎของ Gall ก็อยู่ในบริบทเดียวกัน: https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law
ในทางกลับกัน ถ้าดูสตาร์ทอัพใหม่ ๆ ที่เกิดขึ้นช่วงนี้ จะเห็นคนที่มีพรสวรรค์จริง ๆ มากขึ้นเรื่อย ๆ ผมคิดว่าในสภาพแวดล้อมที่เงินทุนตึงตัวกว่าเดิม หากจะเริ่มบริษัทก็ต้องการคนที่เก่งจริงมากขึ้น และคนเหล่านั้นก็จะจ้างคนเก่ง ๆ เข้ามาอีก
วงการเทคโนโลยีตอนนี้ให้ความรู้สึกคล้ายช่วง 2004~2008 มากขึ้นมาก ซึ่งเป็นช่วงที่แทบทุกคนที่สนใจสตาร์ทอัพกระโดดเข้ามาเพราะชอบแฮ็กปัญหาทางเทคนิค
จากประสบการณ์ที่ลองใช้ Cursor มันยอดเยี่ยมสำหรับงานที่วิศวกรระดับธรรมดาทำได้ แต่แย่มากสำหรับงานที่สูงกว่านั้น และยังต้องอาศัยความสามารถในการทำความเข้าใจโค้ดของคนอื่นอย่างรวดเร็วด้วย
คงทำให้วิศวกรเทคนิคระดับสูงที่ไม่ได้โฟกัส frontend หรือ web app development ไม่จำเป็นต้องจ้าง junior web developer มากเท่าเดิม คล้ายกับที่ webmaster หายไปเมื่อมี framework และเครื่องมือสำหรับสร้าง HTML/CSS พื้นฐานของหน้าเว็บได้อย่างรวดเร็ว
สมมติว่าคนสาย “DevSecOps” กำลังทำงานมากกว่าที่ควรทำ 3 เท่า เราก็ควรดูด้วยว่าพวกเขายังทำอะไรอีกบ้าง อาจเป็นการจองการเดินทาง การเบิกและรายงานค่าใช้จ่าย การรายงานเวลาทำงานแยกตามหมวดธุรกิจ การจัดการวันลา การจัดการประชุม การทำสไลด์นำเสนอด้วยกราฟิกที่ทำเอง ไปจนถึงเตรียมงาน 80% สำหรับการจัดซื้อจาก vendor ภายนอก
งานเหล่านี้ไม่ได้อยู่ใน job description ขัดขวางงานจริง และกัดกร่อนความสามารถในการทำงานหลักอย่างไม่สมดุล สมัยก่อนงานแต่ละอย่างเหล่านี้มีผู้เชี่ยวชาญเฉพาะทางรับผิดชอบ และสามารถจัดการได้มีประสิทธิภาพกว่า 10 เท่าในต้นทุนที่ถูกกว่ามาก
ผู้เชี่ยวชาญอย่างเลขานุการ แผนกกราฟิกภายใน หรือบุคลากรการเงิน ปรากฏอยู่ในงบการเงิน การตัดบทบาทเหล่านั้นออกไม่ได้ทำให้งานหายไป แต่มันแค่ถูกกระจายเป็นชิ้นเล็กชิ้นน้อยไปให้ทุกคน ภายใต้ข้ออ้างว่าซอฟต์แวร์สำนักงานแบบ self-service ช่วยปรับปรุง “ผลิตภาพ”
ผลคือทุกคนช้าลงอย่างไม่สมดุล แต่คนที่ดูแค่ตัวเลขจะเห็นเพียงเงินเดือนที่ประหยัดได้จากบทบาทที่ถูกตัดออกไป ความช้าลงปรากฏเพียงเป็นความรู้สึกพร่ามัวของผลิตภาพโดยรวมที่ลดลง เหมือนโรคต้นทุนลึกลับที่ทุกคนต้องเจอ
ผมคิดว่ามันไม่ใช่เรื่องลึกลับเลย ไม่มีการเพิ่มผลิตภาพ แถมยังเกิดการสูญเสียด้วย เพียงแต่มันเปลี่ยนต้นทุนที่ชัดเจนและมองเห็นได้ ให้กลายเป็นต้นทุนที่กระจัดกระจายและคำนวณยาก จึงทำให้เข้าใจผิดได้ง่ายว่ากำลังประหยัดเงินอยู่
ความสามารถสำคัญที่ถูกมองข้ามคือความสามารถในการเข้าใจธุรกิจที่บริษัททำอยู่ ต่อให้มีทักษะพัฒนาซอฟต์แวร์ในระดับพอใช้ หากผสานกับความเข้าใจเป้าหมายทางธุรกิจที่ดี ก็ยังคงมีคุณค่าได้ต่อไป แม้ developer สายโค้ดล้วน ๆ บางส่วนจะถูก AI แทนที่
ผมทำงานในบริษัทสายธนาคารมา 13 ปี เห็นความซับซ้อนเพิ่มขึ้นมาก และระบบราชการที่ไร้เหตุผลก็เพิ่มขึ้นตามไปด้วย ทุกวันนี้ยังทำงานที่จำเป็นได้ แต่ไม่มีสิทธิ์เข้าถึง และก็ไม่มีทางได้สิทธิ์นั้น
งานง่าย ๆ ตอนนี้กลายเป็นเรื่องที่ต้องเจรจา 10 ขั้นกับทีม Pune นิรนาม และต้องตามจี้กับ escalate 10 ครั้งกว่าพวกเขาจะตระหนักว่ามีงานจริงที่ต้องทำ
กระบวนการกลายเป็นเรื่องไร้สาระจนเมื่อเริ่มทำอะไรสักอย่าง ก็ไม่รู้ว่าจะใช้เวลา 2 วันหรือ 3 เดือน แอปทุกตัวพังได้ค่อนข้างเร็วถ้าไม่บำรุงรักษาอย่างต่อเนื่อง เพราะงานเครือข่ายใหม่ ๆ, การอัปเดต Unix ที่ไม่ได้ตรวจสอบ หรือหนึ่งในสารพัดสิ่งที่ย่อมเกิดขึ้นแน่ ๆ
สุดท้ายคนทำเอกสารกับคนที่งานหลักก็ทำได้แค่ระดับเฉลี่ยฝังตัวลึกใน process และเป็นฝ่ายชนะ ส่วน business unit ได้รับ IT คุณภาพต่ำ โปรเจกต์ล่าช้าและงบเกิน นี่ยิ่งตอกย้ำภาพจำของ IT ว่าเป็น “สิ่งชั่วร้ายที่แย่แต่ต้องทน”
ตอนนี้ผมเลิกใส่ใจแล้ว งานเป็นแค่เครื่องมือสำหรับชีวิตก็พอ โฟกัสและความสำเร็จของผมอยู่ที่ “ชีวิต” ฝั่งนั้น
สิ่งที่วัดนั้นสำคัญ งานวิจัยนี้ดูแค่ ปริมาณการใช้ Copilot เท่านั้น
ผมเป็นวิศวกรที่มีประสบการณ์สูง แต่สำหรับผม Copilot ไม่ใช่แค่ไร้ประโยชน์ ยังเป็นตัวรบกวนด้วย เวลาส่วนใหญ่ผมใช้ไปกับการทำความเข้าใจโดเมนของปัญหา ทำความเข้าใจข้อจำกัดและความเป็นไปได้ของสภาพแวดล้อมที่ตัวเองอยู่ และคิดว่าจะเขียนโค้ดอย่างไร
พอเริ่มพิมพ์โค้ดจริง ๆ ผมก็รู้อยู่แล้วว่าจะเขียนอะไร ดังนั้น autocomplete ของ Copilot ที่ “ช่วยเหลือ” จึงมีแต่ทำให้เสียสมาธิ ทำให้ workflow ของผมแย่ลงมาก
ในทางกลับกัน AI มีประโยชน์อย่างมหาศาลในขั้นตอนก่อนลงมือโค้ดจริง บางครั้งแค่ prompt ที่ทำมาดีโดยอิงจากสิ่งที่คิดไว้ล่วงหน้า ก็ได้ร่างเริ่มต้นมาแล้ว และหลังจากนั้นการจับคู่ทำงานกับ LLM เพื่อหาคำตอบอย่างรวดเร็วต่อปัญหาเล็ก ๆ ที่คาดไม่ถึงซึ่งเกิดขึ้นระหว่างทางก็ช่วยได้มาก
ดังนั้นต่างจากรายงานนี้ ผมคิดว่านักพัฒนาที่ชำนาญ หากใช้ AI ได้ดี อาจได้ ประโยชน์มากกว่า นักพัฒนาที่ยังไม่ชำนาญด้วยซ้ำ
แต่ถ้าใช้ Claude Sonnet 3.5 ร่วมกับ Cursor หรือ Continue.dev จะดีขึ้นแบบก้าวกระโดด เราสามารถควบคุมบริบทได้อย่างชัดเจน เช่น เลือกไฟล์ 6–7 ไฟล์เพื่อใส่เข้าไปได้ และเมื่อรวมกับความสามารถที่ยอดเยี่ยมของ Claude แล้ว เกมก็เปลี่ยนไปโดยสิ้นเชิง
แล้วแต่งาน แต่เร็วขึ้นได้ง่าย ๆ 2–5 เท่า งานที่เดิมอาจใช้ครึ่งวัน สามารถทำให้กลายเป็นโค้ดพร้อมขึ้น production 100 บรรทัดพร้อมการทดสอบได้ภายในหนึ่งชั่วโมง
ผมพูดในฐานะคนมีประสบการณ์ 26 ปี และทำบทบาท principal/staff/lead มาตั้งแต่ปี 2012 อย่างไรก็ตาม ผมไม่คาดหวังว่าจะได้การยกระดับแบบเดียวกันในระดับประสบการณ์ต่ำกว่า senior เพราะต้องอธิบายสิ่งที่ต้องการค่อนข้างละเอียด และโดยปกติต้องรับแนวทางเริ่มต้นที่พอทำงานได้มา แล้วปรับแต่งอีกราวหกครั้งให้เป็นรูปแบบที่เหมาะสมและแยกส่วนได้ดี
เช่น เวลาเขียน IaC สำหรับ AWS มีสิ่งที่ต้องค้นหาเยอะมาก ถาม AI ก็ได้คำตอบและตัวอย่างเร็วมาก หากกำลังเรียนรู้ IaC ของบริการใหม่ ผมจะดูเอกสาร AWS แต่ถ้าต้องการคำตอบเร็ว ๆ หรือแค่ทบทวน AI เร็วกว่าเยอะ
ยิ่งพึ่งพาแพตเทิร์นแบบ functional มากขึ้น ออกแบบ monad ทำ input/output เฉพาะที่ boundary และใช้ fluent programming ผลลัพธ์ก็ยิ่งมหาศาล
ขอเสริมว่านี่เป็นประสบการณ์ใน Java ผมใช้ Java มา 3.5 ปี และพึ่งพาฟีเจอร์ Java 8+ อย่างมาก ถ้าใช้ generics เยอะในโค้ดไลบรารี ก็จะเปิดโอกาสให้ LLM เลือกได้ถูกต้องอย่างสม่ำเสมอมากขึ้น
ในงานออกแบบที่เร็วกว่าและทำแบบคร่าว ๆ จะไม่ได้ประโยชน์ระดับนี้เท่าไร ผมอยากฟังประสบการณ์จากผู้ใช้ functional programming จริง ๆ อย่าง Haskell, OCaml, F#, Scala ให้มากกว่านี้
มันพอมีประโยชน์สำหรับการเขียน boilerplate ของ unit test โดยเฉพาะ table-driven test แต่ไม่ถึงขั้นคุ้มจะคง subscription แบบเสียเงินไว้
มันมีคุณค่ามากเวลาทำงานกับภาษาที่ไม่คุ้นเคย หรือกับงานซ้ำ ๆ ที่สามารถตัดสินได้ง่ายว่าโค้ดที่ generate ออกมานั้นโอเคไหม
ในทางกลับกัน มันอ่อนลงเมื่อสิ่งที่ผมอยากทำชัดเจนมาก และคล้ายกับ implementation มาตรฐานแต่เป็นงานที่ใหม่ขึ้นเล็กน้อย เรื่องนี้เกิดขึ้นบ่อยกับ “reduce” หรือกระบวนการที่กำกวมกว่า
ผมเป็น platform engineer ที่ต้องสลับไปมาหลายพื้นที่ เช่น Bash, Python, browser, vanilla JS, TS, Node, GitHub Actions, Jenkins Java workflow, Docker ฯลฯ มันช่วยให้สมองได้พักและวอร์มอัปตอนสลับโดเมนได้
สงสัยว่างานวิจัยได้รวม หนี้ทางเทคนิค ที่เกิดจากนักพัฒนาประสบการณ์น้อยใช้ AI ช่วย contribute แล้วสุดท้ายนักพัฒนาที่มีประสบการณ์มากกว่าต้องมาจัดการหรือไม่ เพราะโดยส่วนตัวเจอเรื่องแบบนี้บ่อยมากในหนึ่งในบริษัทที่อยู่ในงานวิจัย
อีกอย่าง เคยเห็นด้วยตัวเองว่านักพัฒนาที่ไม่ค่อยสนใจตัวเทคโนโลยีเท่าไร แต่สนใจการส่งมอบงานมาก ๆ มักจะสนใจ AI มากกว่า PM ชอบคนแบบนั้นก็จริง แต่
สิ่งที่เราขอคือการเปลี่ยนเล็ก ๆ ประมาณ 5 บรรทัดพร้อมเทสต์ แต่ตอนนี้นอกจากหนี้ใหม่แล้ว เรายังต้องรับโค้ดที่ไม่มีใครอธิบายได้ว่าทำไมถึงถูกเปลี่ยนใหม่ทั้งหมด บางส่วนก็เป็นการเปลี่ยนเพื่อให้มีการเปลี่ยนเฉย ๆ และยังเป็นโค้ดที่ดูแปลกหน้าสิ้นเชิงสำหรับคนที่ต้องดูแลมัน
เห็นแบบนี้ซ้ำ ๆ ในหมู่คนที่ใช้เครื่องมือพวกนี้แต่ไม่ใช่วิศวกรระดับสูง สุดท้าย PR แบบนั้นก็ต้องปฏิเสธแล้วบอกให้ทำใหม่ เวลาเพิ่มที่คิดว่าได้มาตอนแรกก็หายไป
ไม่ได้หมายความว่าเครื่องมือพวกนี้ไร้ประโยชน์ แต่ผู้คนใช้มันโดยไม่เข้าใจว่า output คืออะไร และไม่เข้าใจผลกระทบระยะยาวต่อ codebase ด้วย
วันที่ผมรู้สึกเหมือนสูญเสียจิตวิญญาณไปส่วนหนึ่ง คือวันที่ถามนักพัฒนาคนหนึ่งว่าขอให้ feedback เรื่อง DB schema ได้ไหม เขาบอกว่าได้ แล้วไม่กี่นาทีต่อมาก็ตัดบทว่า “ครับ ผมไม่ค่อยสนใจ X เท่าไร”
ไม่สนใจงั้นเหรอ? ในฐานะผู้เชี่ยวชาญด้านนั้น ผมกำลังบอกอยู่ว่าอะไรปรับปรุงได้ ควรทำอย่างไร และทำไปทำไม แต่กลับไม่สนใจ
คลาวด์เป็นความผิดพลาด มันปลูกความคิดให้ผู้คนว่าเพราะสามารถ scale up/out ได้ตลอด จึงไม่จำเป็นต้องไล่ตามประสิทธิภาพและการปรับแต่งให้เหมาะสม ผมไม่ได้พูดถึง microbenchmark ด้วยซ้ำ แต่พูดถึงเรื่องง่ายมาก ๆ อย่าง “ใช้ data structure ตัวนั้นแทนตัวนี้น่าจะดีกว่าไหม”
เราก็ใช้กันภายในด้วย และผมมองว่า หนี้ทางเทคนิค เป็นภัยคุกคามขนาดใหญ่ที่ยังประเมินกันไม่ถูกต้อง
มันมีประโยชน์มากในการหว่าน API และแพตเทิร์นที่เราไม่คุ้นเคยลงในโค้ดแบบถล่มพรม แต่ถ้าไม่ระวัง จะก่อให้เกิดโค้ดซ้ำซ้อนมหาศาลและ boilerplate ที่จัดการยาก
เหตุผลมาจาก bias ใหญ่ ๆ สองอย่าง อย่างแรก ข้อมูลฝึกของโมเดลเป็นข้อมูลตัวอย่างสไตล์ StackOverflow จึงไม่คำนึงถึงบริบทและข้อจำกัด อย่างที่สอง มันมีแนวโน้มจะคัดลอกและทำซ้ำ มากกว่าจะดู codebase เดิมแล้วเสนอการ refactor
อย่างแรกบรรเทาได้ด้วยการทำงานของตัวเองจริง ๆ คือรีวิวและแก้ไขสิ่งที่ LLM พ่นออกมา
อย่างที่สองจะบรรเทาได้ก็ต่อเมื่อ diff และประวัติ commit เข้าไปอยู่ในข้อมูลฝึก แต่ dataset แบบนี้จัดการและติดแท็กยากกว่ามาก การเปลี่ยนบางอย่างดีเหมือนการ refactor แต่บางอย่างอาจเป็น bug ที่ถูกแก้ใน commit ต่อมา และ commit message ก็แทบจะเป็นคำโกหก จึงแยกให้ชัดได้ยาก ไม่มีใครเขียนว่า “เพิ่ม bug”
แถม merge, rebase, squash ยังเปลี่ยนความหมายของ history หรือลบมันออก หรือเพิ่ม noise ทำให้ทุกอย่างยิ่งพร่ามัวกว่าเดิม
ผมชอบเทคโนโลยีและเขียนซอฟต์แวร์เป็นงานอดิเรกด้วย แต่การทำงานร่วมกับ AI นั้นสนุกกว่าในเชิงวัตถุวิสัย ผลิตภาพเพิ่มขึ้นมาก และที่สำคัญที่สุดคืออาการผัดวันประกันพรุ่งหายไป
เวลาติดขัดหรือไม่อยากเริ่มงาน พอเริ่มคุยกับ Aider ไปสักพัก ก็พบว่ามีงานหนึ่งชิ้นที่ถ้าไม่มี AI วันนั้นคงไม่ได้ทำ เสร็จไปแล้ว
ต้องขอบคุณมัน โปรเจกต์ public/private ที่เมื่อก่อนใช้เวลาหลายเดือนถึงหลายปี ตอนนี้ผมปล่อยได้ทุก 2 สัปดาห์ ค่าใช้จ่ายเหมือนมีทีมนักพัฒนาที่เร็วและมีประสบการณ์นั่งอยู่ข้าง ๆ คือวันละไม่กี่ดอลลาร์เป็นอย่างมาก
ก่อนจะหยิบข้อสรุปมาใช้ จำเป็นต้องดูตัวงานวิจัยให้ลึกกว่านี้อีกหน่อย ตัวงานวิจัยเองก็น่าจะสรุปผลลัพธ์ได้ดีกว่านี้
บทคัดย่อและบทสรุประบุผลลัพธ์เป็นสัดส่วนเดียวคือ ผลิตภาพเพิ่มขึ้น 26.08% ซึ่งดูเหมือนมีทศนิยมมากเกินไป พอดูเข้าไปอีกหน่อย จะเห็นตัวเลขว่า Junior อยู่ที่ 27~39% ส่วน Senior อยู่ที่ 8~13%
ถ้าดูลึกลงไปอีก ไม่ใช่แค่ประสบการณ์เท่านั้น แต่ความแตกต่างระหว่างบริษัทก็สูงด้วย ที่ Microsoft นอกจาก pull request แล้ว ตัวชี้วัดผลลัพธ์อื่น ๆ เช่น commit, build, อัตรา build สำเร็จ ดูเหมือนจะไม่มีนัยสำคัญทางสถิติ การเพิ่มขึ้นของ PR ก็ดูมีนัยสำคัญที่ Microsoft แต่ที่ Accenture ดูเหมือนจะไม่ใช่ และแม้แต่ตรงนั้นก็อาจเป็นจริงเฉพาะกับ Junior เท่านั้น
บทคัดย่อและบทสรุปจำเป็นต้องสรุปก็จริง แต่ผลลัพธ์เปลี่ยนไปมากตามตัวแปร จึงไม่แน่ใจว่าการให้ตัวเลขรวมตัวเดียวเป็นบทสรุปนั้นสมเหตุสมผลหรือไม่ โดยเฉพาะเพราะนัยสำคัญทางสถิติดูไม่สม่ำเสมอ
Accenture เป็นบริษัทที่ร่วมมือและทำการตลาดร่วมกับองค์กรขนาดใหญ่อย่าง Microsoft กลุ่มนักพัฒนาประมาณ 300 คนแทบไม่สามารถขยับตัวอย่างทั้งหมดได้ และบริษัทก็กำลังสร้างฝ่ายการตลาด/ที่ปรึกษารอบ ๆ เวิร์กโฟลว์ AI อยู่ จึงยากที่จะสันนิษฐานว่าเป็นกลาง
บริษัทนิรนามแห่งที่สามจริง ๆ แล้วไม่ใช่การทดลองแบบสุ่มมีกลุ่มควบคุม ดังนั้นจึงบอกได้ยากว่าควรรวมผลลัพธ์นั้นเข้ากับ RCT อย่างไร นอกจากนี้ ในบรรดาบริษัทเทคโนโลยีขนาดใหญ่ น่าจะมีที่อื่นอีกที่ทำการทดลองคล้ายกันและอยากรู้ประสิทธิผล ดังนั้นจึงสันนิษฐานได้ว่ามีข้อมูลอื่นนอกเหนือจากที่รวมอยู่ในผลลัพธ์นี้
ทำไมถึงเลือกบริษัทเหล่านี้จากชุดตัวอย่างที่ใหญ่กว่า? อาจเป็นเพราะ Microsoft และ Accenture มีแรงจูงใจให้เกิดการนำไปใช้ ส่วนบริษัทที่สามถูกเลือกด้วย p-hacking
โดยเฉพาะประโยคในบทคัดย่อที่ว่า “การทดลองแต่ละรายการมีสัญญาณรบกวน แต่เมื่อนำทั้งสามการทดลองมารวมกัน” เป็นสัญญาณที่แย่มาก แทบจะเป็นการยอมรับว่าเมื่อดูแต่ละบริษัทจะไม่มีผลลัพธ์ที่มีนัยสำคัญทางสถิติ แต่เมื่อนำสามกลุ่มนี้มารวมกันแล้วจึงมีนัยสำคัญ นี่ไม่ใช่วิทยาศาสตร์
นักพัฒนา Junior อาจทำงานที่ LLM เดาถูกได้ง่าย หรือทำพลาดโดยยอมรับร่างแรกเพราะดูเหมือน LGTM ทำให้ throughput ดูสูงขึ้น
การใช้โมเดลสร้างโค้ดก็ต้องใช้ทักษะเช่นกัน และทักษะนั้นก็เหมือนกับทักษะที่จำเป็นเมื่อต้องมอบหมายงานให้ผู้อื่น และบูรณาการแนวทางแก้ปัญหาจากผู้เขียนหลายคนให้เป็นระบบเดียวที่สอดคล้องกัน
เป็นแค่สัญชาตญาณของผม แต่ผมมองว่า การเขียนโค้ดโดยมี LLM ช่วย เป็นโทษต่อการเติบโตเป็นนักพัฒนา ดูเหมือนมันจะยกระดับผลิตภาพได้แค่ถึงระดับหนึ่ง และระดับนั้นอาจเป็นงานซ้ำ ๆ น่าเบื่อสำหรับ Senior แต่เป็นกระบวนการก่อร่างสร้างตัวสำหรับ Junior
จากประสบการณ์ของผม LLM ไม่ได้ถูกใช้แค่กับโค้ด boilerplate ง่าย ๆ แต่ถูกเรียกใช้เมื่อนักพัฒนา Junior เจองานที่ค่อนข้างพบบ่อยแต่ยังไม่เข้าใจดีพอ กระบวนการทดลอง เรียนรู้ และทำความเข้าใจส่วนใหญ่ถูกแทนที่ด้วย LLM และทักษะที่แท้จริงกลายเป็นการปรับ prompt จนกว่ามันจะดูเหมือนทำงานได้
เมื่อคืนผมตั้งค่า Linux RAID เป็นครั้งแรก ไม่ใช่งานที่ยากมาก แต่ต้องใช้เครื่องมือหลายอย่าง เช่น mount, umount, fstab, blkid, mdadm, fdisk, lsblk, mkfs และระหว่างทางอาจไม่เป็นไปตามขั้นตอนในไกด์เป๊ะ ๆ ดังนั้นการดูแค่ tutorial หรือเอกสารจึงไม่ได้ช่วยเป็นพิเศษ
ผมถามคำถามหลายสิบข้อเกี่ยวกับแต่ละเครื่องมือและแต่ละขั้นตอน ซึ่งถ้าเป็นเมื่อก่อนผมคงแค่ copy-paste แล้วภาวนา
สองวันก่อน ผมก็เรียนรู้ผ่าน ChatGPT และกู้ข้อมูลทั้งหมดจาก SSD ที่เสียได้สำเร็จ แม้อาจผิดได้ 20% แต่การจัดการทักษะใหม่เอี่ยมโดยมี “ไกด์” ที่ดีกว่าค่าเฉลี่ยของอินเทอร์เน็ตเปิดมาก ๆ นั้นดีจริง ๆ
สำหรับคนที่ชอบเรียนรู้ มันให้ความรู้สึกเหมือนรองเท้าเจ็ดลีกเมื่อเทียบกับการคุ้ยขยะอินเทอร์เน็ตไม่รู้จบ แน่นอนว่าเหมือนทุกอย่างบนอินเทอร์เน็ต เราต้องสงสัยสิ่งที่ AI พูดด้วย แต่มันลดความยุ่งยากได้มหาศาล
ผมก็มีสัญชาตญาณแบบเดียวกัน และอยากเรียกให้หนักกว่านั้นว่าเป็นความเห็นที่แข็งแรงและมีเหตุผลรองรับ ผมคิดว่าอีกไม่กี่ปีข้างหน้า อุตสาหกรรมจะต้องชดใช้ราคา
ท่อส่งอุปทานของ “นักพัฒนาซอฟต์แวร์ Junior ที่มีเซนส์” จะเหือดแห้งลงอย่างมาก และถูกแทนที่ด้วยน้ำหลากของ “นักพัฒนาซอฟต์แวร์ Junior ที่พึ่งพา AI” ระหว่างสองกลุ่มนี้มีหุบเหวลึกคั่นอยู่
แน่นอนว่าสิ่งนี้จะส่งผลลูกโซ่ต่อจำนวน Developer ระดับกลางที่มีเซนส์ และ Senior Developer ที่มีเซนส์ด้วย
ในทางกลับกัน คนที่อยากเข้าใจโค้ดทั้งหมดที่ตัวเองใช้ ก็มีแนวโน้มจะไปค้นคว้าส่วนที่ไม่รู้ในสิ่งที่ LLM พ่นออกมา
อย่างน้อยผมก็ใช้แบบนั้น และเพื่อยกตัวอย่างแย้งสมมติฐานนี้ บางครั้ง LLM ใช้ฟังก์ชันหรือคอมโพเนนต์ของไลบรารีที่ผมไม่รู้จัก จึงช่วยประหยัดเวลาได้มากเมื่อเรียนภาษาใหม่หรือ toolkit ใหม่ สำหรับผมมันเร่งการเรียนรู้มากกว่าทำให้ช้าลง
แต่สำหรับคนที่จะประสบความสำเร็จอยู่แล้ว มันเหมือนการถามคำถามใน StackOverflow แล้วได้รับคำตอบทันทีโดยไม่มีการตำหนิ จึงเป็นของขวัญชิ้นใหญ่มาก
มันไม่ได้ถูกเสมอไป แต่ StackOverflow ก็เป็นแบบนั้นเหมือนกัน สุดท้ายก็ขึ้นอยู่กับตัวบุคคลเหมือนเช่นเคย
เมื่อ 50 ปีก่อน machine code แทบจะเป็นสิ่งจำเป็นถ้าต้องการสร้างอะไรสักอย่าง แล้วนักพัฒนาปัจจุบันมีกี่คนที่เขียนได้
LLM อาจกำลังเปลี่ยนจาก ไม้ค้ำยันเชิง abstraction อีกอย่างหนึ่ง ไปเป็นเสาหลัก abstraction ที่แข็งแรงก็ได้
จุดที่น่าสนใจที่สุดของงานวิจัยนี้คือ เมื่อแบ่งตามระดับประสบการณ์แล้ว นักพัฒนาที่มีระยะเวลาทำงานมากกว่าค่ามัธยฐานไม่มีการเพิ่มขึ้นอย่างมีนัยสำคัญทางสถิติในตัวชี้วัดแทนที่ไม่ดีอย่าง “ประสิทธิภาพการผลิต” ช่วงความเชื่อมั่น 95% ยังลงไปลึกทางฝั่งลบในทุกตัวชี้วัด และแค่เอียงไปทางบวกเล็กน้อยเท่านั้น
ตรงกับประสบการณ์ของผมด้วย Copilot ดีในแง่ที่ช่วยลดงานน่าเบื่อบางส่วนและทำให้ใช้สมองไปกับคำถามที่ลึกขึ้นได้ แต่ไม่ได้ถึงขั้นเปลี่ยนโลกอย่างที่นักพัฒนาจูเนียร์พูดกัน
อีกทั้งมันมักผิดแบบละเอียดอ่อน ซึ่งเป็นแบบที่นักพัฒนาประสบการณ์น้อยอาจมองข้าม ผมต้องหยุดแล้วปรับแก้สิ่งที่มันสร้างขึ้นมาส่วนใหญ่ และนักพัฒนาที่ทักษะน้อยกว่าอาจไม่รู้ว่าควรปรับอย่างไร
หลังใช้มาหลายปี ตอนนี้ผมค่อนข้างจับทางได้แล้วว่าควรใช้ Copilot เมื่อไรและไม่ควรใช้เมื่อไร ดังนั้นผลสุทธิน่าจะเป็นบวก แต่ก็ไม่ได้เป็นแบบนั้นมาตลอด
นอกจากนี้ ผมยังสงสัยด้วยว่าเหตุผลส่วนหนึ่งที่ “ประสิทธิภาพการผลิต” ของนักพัฒนาซีเนียร์ดูเหมือนลดลง อาจมาจากประสิทธิภาพการผลิตที่เพิ่มขึ้นของจูเนียร์ในบริษัทหรือไม่ ถ้าจูเนียร์สร้าง PR มากขึ้นและมีข้อผิดพลาดมากขึ้นในนั้น ทำให้เวลารีวิวเพิ่มขึ้น ประสิทธิภาพที่เพิ่มขึ้นของซีเนียร์ก็อาจลดลงตามสัดส่วนได้
ประสิทธิภาพการผลิตเพิ่มขึ้น 26% โดยรวมแล้วตรงกับประสบการณ์ของผม สิ่งที่ควรดูเพิ่มคือกำลังทำงานกับเทคโนโลยีใหม่ หรือเทคโนโลยีที่คุ้นเคยอยู่แล้ว AI ช่วยได้มากกว่ามากในภาษา หรือเฟรมเวิร์กที่ผมกำลังเรียนรู้
ผมจำลักษณะเฉพาะและกับดักของภาษาเสริมต่าง ๆ ได้ไม่ดี เช่น ถ้าจะเขียนเงื่อนไขใน Bash ต้องใช้คาถาเครื่องหมายคำพูดแบบไหนถึงจะถูกต้อง ดังนั้นในอดีตผมแทบไม่เขียนสคริปต์ Bash เพื่อทำ automation เลย และจะลงแรงก็ต่อเมื่องานนั้นต้องทำบ่อยพอ การจัดการ JSON ด้วย jq หรือการ parse ด้วย AWK ก็เหมือนกัน
ตอนนี้เพราะมี LLM ผมจึงทำสคริปต์ Bash มากขึ้นมาก และมันง่ายขึ้นจนผมใช้ในการทำเอกสารกระบวนการบ่อยขึ้นด้วย สิ่งที่เมื่อก่อนเป็น README แบบขั้นตอนคงที่ ตอนนี้มาพร้อมสคริปต์ Bash แบบโต้ตอบที่รับอินพุตจากผู้ใช้
โดยทั่วไปผมเห็นโปรแกรมเมอร์ซีเนียร์คุยกันเยอะว่าทำไมเครื่องมือ AI ถึงใช้ไม่ได้ ส่วนจูเนียร์ใช้ไปเลยโดยไม่มีอคติ
ที่มีประโยชน์มีสี่อย่าง อย่างแรกคือคำถามเกี่ยวกับเฟรมเวิร์ก/ภาษาอย่าง Qt หรือ CSS ที่ผมไม่ได้ใช้บ่อย แต่มีเนื้อหาตัวอย่างเยอะ
อย่างที่สองคือคำถามเฉพาะเจาะจงมาก ๆ ที่เดิมทีผมคงหาใน Google Search หรือ StackOverflow เช่น คำถามอย่าง “วิธีที่มีประสิทธิภาพที่สุดในการดึงการใช้งาน CPU และ RAM ของ Windows ด้วย Python” มันจะชี้ไปที่ไลบรารีหรือตัวอย่าง มากกว่าจะสร้างโค้ดให้ copy-paste ได้ทันที
อย่างที่สามคือโค้ด boilerplate ที่ผมเขียนเป็นอยู่แล้ว แต่ช่วยประหยัดเวลาเล็กน้อยและลดความผิดพลาดจากการพิมพ์ ตอนใช้ปลั๊กอิน CoPilot สำหรับ PyCharm ถ้าเขียนคอมเมนต์ในไฟล์ว่าอยากทำอะไร มันจะเติมอีกไม่กี่บรรทัดถัดไปให้ ผลลัพธ์ดีที่สุดเช่นกันเมื่อสั้นและเจาะจงมาก ถ้ายาวขึ้นต้องวนแก้กับ CoPilot มากเกินไปจนไม่คุ้มแล้ว
อย่างที่สี่คือวิธีค้นเอกสารอย่างรวดเร็ว
มีคนบอกว่ามันดีสำหรับการเขียน unit test แต่สำหรับผมไม่ใช่ อย่างน้อยก็ไม่ใช่ unit test แบบที่ผมต้องการ
ถ้าให้วัดเป็นตัวเลข ผมคิดว่าประสิทธิภาพการผลิตเพิ่มขึ้นประมาณ 5–10% น้อยกว่าการใช้ IDE เต็มรูปแบบอย่าง PyCharm แทน Notepad หรือการใช้ git client ดี ๆ แทนการพิมพ์คำสั่ง git โดยตรงใน CLI มาก กล่าวคือมันเป็นเพียงหนึ่งในเครื่องมือเพิ่มประสิทธิภาพหลาย ๆ อย่าง ไม่ใช่สิ่งที่ผมจะเรียกว่า “ปฏิวัติ”
ผมลองใช้ Cursor ประมาณ 10 วันกับโปรเจกต์ Ruby on Rails ขนาดใหญ่ และใช้สแต็กนี้มานานกว่า 13 ปีแล้ว
ไม่ได้ประสิทธิภาพเพิ่มไปกว่าที่ GitHub Copilot ให้ไว้อยู่แล้ว ประเมินว่าการเพิ่มขึ้นจาก Copilot อยู่ราว 25%
แต่กรณีเริ่มโปรเจกต์ใหม่อย่าง Node.js จากโฟลเดอร์ว่าง มันทรงพลังอย่างประหลาด สามารถสร้าง API ที่จัดการ request จาก OpenAPI schema และให้บริการ OpenAPI schema ผ่าน swagger ได้ในราว 5 นาทีด้วย prompt เท่านั้น
อย่างไรก็ตาม การเริ่มโปรเจกต์ใหม่ตั้งแต่ศูนย์เป็นสิ่งที่ผมทำไม่บ่อย ดังนั้นคงกลับไปใช้ Copilot กับ VSCode พื้นฐาน
มันทำให้คนสร้าง PR ได้มากขึ้น ว้าว สุดยอดเลย ใครแคร์ล่ะ
จำนวนรายการที่ผ่าน QA เพิ่มขึ้นหรือไม่? สิ่งที่ทำด้วยความช่วยเหลือจาก AI มีบั๊กที่พบหลัง QA น้อยลงหรือไม่? ภายหลังขยายหรือแก้ไขได้ง่ายไหม หรือเป็นดีไซน์ที่แข็งและไม่ยืดหยุ่น?
เครื่องมือที่เปลี่ยนนักพัฒนาให้เป็น ลิงเขียนโค้ด ซึ่งไม่รู้คุณภาพ ไม่ใช่สิ่งที่ผมตามหา ผมอยากได้เครื่องมือที่ช่วยให้นักพัฒนาหาบั๊กหรือข้อบกพร่องด้านการออกแบบในสิ่งที่ตัวเองทำ หรือช่วยให้เขียนการทดสอบที่ออกแบบมาอย่างดีได้
การนับแค่จำนวน PR ไม่ได้บอกอะไรที่เป็นประโยชน์เลย ตรงกันข้าม มันไปกระตุ้นลางสังหรณ์ของผมว่าเมื่อมีโค้ดต่อหน่วยเวลามากขึ้น คุณภาพเฉลี่ยจะลดลง
Copilot: “ได้เลยครับ จัดให้! นี่คือคอมมิตใหม่ครับ!”
นักพัฒนาซีเนียร์: “ทำไมล่ะ? การเปลี่ยนแปลงนี้เป็น atomic อยู่แล้ว ถ้าฝ่ายบริหารหยิบตัวชี้วัดโง่ ๆ อย่างจำนวนการเปลี่ยนแปลงรายเดือนกลับมาใช้อีก ผมจะบอกอย่างสุภาพให้ไปไกล ๆ เอง”
นี่น่าจะเป็น Copilot ที่ใช้ GPT-3.5
Microsoft: กันยายน 2022–3 พฤษภาคม 2023
Accenture: กรกฎาคม 2023–ธันวาคม 2023
บริษัทนิรนาม: ตุลาคม 2023–?
การอัปเดต GPT-4 ของ Copilot Chat คือวันที่ 30 พฤศจิกายน 2023: https://github.blog/changelog/label/copilot/
สำหรับผม AI ทำให้ เอกสารประกอบ กลับมามีชีวิตอีกครั้ง เฟรมเวิร์กใหม่ ๆ มีเอกสารน้อยเกินไป เอกสารชุดสุดท้ายที่ผมรู้สึกว่าดีคือหนังสือ DOS ทุกวันนี้นักพัฒนาน่าจะไม่ค่อยมีเซนส์แล้วว่าเอกสารที่ดีเป็นอย่างไร
ถึงอย่างนั้น AI ก็อาจให้คำแนะนำที่ต่างกันทุกครั้ง ดังนั้นการตัดสินใจยังต้องเป็นหน้าที่ของนักพัฒนาที่มีประสบการณ์อยู่ดี สุดท้ายแล้ว AI มาแทนเอกสารและการพิมพ์
ถ้าเป็นโปรเจกต์สาธารณะ เอกสารก็กลายเป็นส่วนหนึ่งของข้อมูลฝึกของ LLM แล้ว ดังนั้นการที่เอกสารละเอียดและถูกต้องจึงสำคัญขึ้นมาก เพราะนักพัฒนาจำนวนมากจะได้คำตอบจากระบบนั้น
ถ้าเป็นโปรเจกต์ปิด ก็สามารถใส่เอกสารเข้าไปในชุดข้อมูลสำหรับ fine-tuning หรือระบบ RAG เพื่อให้ได้ผลแบบเดียวกัน
นั่นอาจอธิบายได้ว่าทำไมไม่มีอะไรถูกทำเป็นเอกสารเลย
ดังนั้นมันจึงมีผลในทางปฏิบัติที่บังคับให้นักพัฒนาทำเอกสารประกอบโค้ดให้ดีขึ้นด้วย
ไม่จำเป็นต้องเป็นเอกสารแบบ live สมัยใหม่ อะไรก็ได้ ผมอยากดูว่าในอดีตมีอะไรที่ยอดเยี่ยมจนเราทำหายไป และอยากลองนำบางส่วนมาใช้กับเอกสารของผมเอง