AI ทำให้นักพัฒนาโอเพนซอร์สทำงานช้าลง และ Peter Naur อาจอธิบายเหตุผลได้

• งานวิจัยล่าสุดระบุว่า เมื่อนักพัฒนาโอเพนซอร์สใช้เครื่องมือ AI กับโค้ดเบสที่ตนคุ้นเคยดี กลับทำให้เวลาในการทำงาน เพิ่มขึ้น 19%
• นักพัฒนา เชื่อว่า AI ทำให้ตนทำงานได้เร็วขึ้น แต่ในความเป็นจริงกลับช้าลง สะท้อน ช่องว่างระหว่างการรับรู้กับความเป็นจริง
• สาเหตุหลักคือ ข้อจำกัดในการถ่ายทอดความรู้ ระหว่าง AI กับ mental model ที่ละเอียดซับซ้อน (โครงสร้างความเข้าใจ) ที่นักพัฒนามีอยู่
• ตาม ทฤษฎีของ Peter Naur สิ่งสำคัญที่สุดในการเขียนโปรแกรมไม่ใช่โค้ด แต่คือ "mental model" ในหัวของนักพัฒนา
  • นักบุกเบิกด้านวิทยาการคอมพิวเตอร์ชาวเดนมาร์ก และผู้ได้รับรางวัลทัวริงปี 2005 มีส่วนร่วมกับ สัญกรณ์ Backus-Naur Form (BNF) ที่ใช้ในการอธิบายไวยากรณ์ของภาษาโปรแกรม
• ใน มุมมองระยะยาว หากต้องการเข้าใจโปรเจ็กต์อย่างลึกซึ้ง การ เขียนโค้ดด้วยตนเองเพื่อสร้าง mental model เป็นสิ่งสำคัญ

---

ปรากฏการณ์ที่ AI ทำให้นักพัฒนาโอเพนซอร์สช้าลง

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

ทำไม AI จึงทำให้นักพัฒนาโอเพนซอร์สที่เชี่ยวชาญช้าลง

• ตามบทความ “Programming as Theory Building” ของ Peter Naur ผลลัพธ์ที่แท้จริงของการเขียนโปรแกรมไม่ใช่โค้ด แต่คือ ‘mental model ของนักพัฒนาที่มีต่อโปรเจ็กต์’
• mental model นี้เป็นหัวใจของความเข้าใจระบบ การวินิจฉัยปัญหา และการปรับปรุงอย่างมีประสิทธิภาพ
• AI ที่อิง LLM ไม่สามารถเข้าถึง mental model ของนักพัฒนาได้โดยตรง และแม้จะให้ข้อมูลบางส่วนไปก็ยังเกิด การสูญเสียโดยเนื้อแท้ในกระบวนการถ่ายทอดความรู้
  • ตัวอย่างเช่น เวลาเราฝากใครสักคนช่วยกล่อมเด็กให้หลับ แม้จะอธิบายไว้อย่างชัดเจน แต่บ่อยครั้งผลลัพธ์จริงก็ออกมาต่างจากที่ตั้งใจ
• การถ่ายทอด mental model มีความซับซ้อนอย่างยิ่ง และแทบเป็นไปไม่ได้ที่ AI จะซึมซับสิ่งนี้ได้จากข้อความเพียงอย่างเดียว
• ดังนั้น เมื่อมอบหมายงานในโปรเจ็กต์ที่ตนเข้าใจอย่างลึกซึ้งให้ AI ทำ กลับยิ่งทำให้ผลิตภาพลดลง
• ข้อมูลเชิงบริบทที่อุดมสมบูรณ์และความเข้าใจเชิงสัญชาตญาณของนักพัฒนา เป็นสิ่งที่ AI แทนที่ได้ไม่ง่าย

ควรห้ามใช้เครื่องมือ AI ในการทำงานจริงหรือไม่?

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

การสร้าง mental model และ AI

• หากยังไม่มี mental model ต่อโปรเจ็กต์ LLM อาจช่วยเพิ่มผลิตภาพได้
• แต่หากแก่นแท้ของการพัฒนาซอฟต์แวร์คือ ‘การสร้าง mental model’ การพึ่งพา AI มากเกินไปอาจทำให้ความสามารถนี้ถดถอยลง
• หากต้องการเข้าใจโปรเจ็กต์อย่างลึกซึ้งและขับเคลื่อนการเปลี่ยนแปลงได้อย่างเชิงรุกในระยะยาว ประสบการณ์การเขียนโค้ดด้วยตนเองเป็นสิ่งจำเป็น
• ในทางกลับกัน หากเป็นงานลักษณะ ‘แค่ทำให้มันใช้งานได้’ การใช้ AI ก็อาจมีประสิทธิภาพกว่า

ประเด็นอภิปรายเพิ่มเติมและบทสรุป

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

[paruaa]

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

[tested]

> ในทางกลับกัน หากเป็นงานแบบ ‘แค่ทำให้มันรันได้’ การใช้ AI ก็อาจมีประสิทธิภาพ

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

[xguru]

การวัด "ผลกระทบของ AI" ต่อประสิทธิภาพการทำงานของนักพัฒนาโอเพนซอร์สที่มีประสบการณ์

[GN⁺]

ความคิดเห็นจาก Hacker News

• ทุกคนใน HN ผมเป็นผู้เขียนงานวิจัยนี้เอง
  ผมคิดว่าโพสต์บล็อกนี้หยิบยกปัจจัยเชิงรูปธรรมข้อหนึ่งที่น่าสนใจ ว่าเหตุใด AI จึงอาจทำให้ความเร็วในการพัฒนาช้าลงได้
  ในงานวิจัยก็มีคำพูดอ้างอิงจากนักพัฒนาอยู่ด้วยในส่วน C.1.5 ลองดูได้
  หลายคนอ่านงานวิจัยแล้วเจอปัจจัยหนึ่งที่ตัวเองรู้สึกตรง จึงสรุปได้ง่าย ๆ ว่า “ปัญหาข้อนี้ข้อเดียวคือเหตุผลที่ทำให้ช้าลง”
  แต่ในความเป็นจริงมีหลายปัจจัยร่วมกัน (อย่างน้อย 5 ข้อที่น่าจะเป็นไปได้ และมากสุดอาจตัดทิ้งไม่ได้ถึง 9 ข้อ ดูตารางปัจจัยหน้า 11)
  การวิเคราะห์สาเหตุแบบหลายมุมจึงสมเหตุสมผลกว่าสมมติว่ามีสาเหตุหลักเพียงข้อเดียว
  ถ้าใครมีแผนจะลองทดลองด้วยตัวเอง ผมหวังว่าจะช่วยแชร์ผลลัพธ์กลับมาทางอีเมลในงานวิจัยด้วย
  และสำหรับหัวข้อบทความที่ใช้ว่า “AI slows down open source developers. Peter Naur can teach us why” ผมคิดว่าถ้าจะให้แม่นยำกว่านี้ ควรเป็นประมาณว่า “ช่วงต้นปี 2025 AI ทำให้นักพัฒนาโอเพนซอร์สที่มีประสบการณ์ทำงานช้าลง Peter Naur ช่วยให้บริบทเพิ่มเติมต่อปัจจัยบางอย่างได้”
  ถ้อยคำอาจเร้าอารมณ์น้อยลง แต่ผมคิดว่าความแม่นยำสำคัญกว่า
  ขอบคุณอีกครั้งสำหรับบทความที่ยอดเยี่ยม ผมยังตามอ่านคอมเมนต์อยู่เรื่อย ๆ
  กระทู้ก่อนหน้าที่เกี่ยวข้อง
  ข้อความเต็มของงานวิจัย
  • มีข้อสงสัยส่วนตัวอยากถามว่า ในงานวิจัยวัดอย่างน่าเชื่อถือได้อย่างไรว่าระยะเวลาจริงก่อนและหลังใช้ AI ต่างกันแค่ไหน คือให้นักพัฒนาคาดการณ์ก่อนหรือไม่ว่าหลังใช้ AI เวลาจะลดลงเท่าไร แล้วค่อยวัดเวลาที่ใช้จริงเพื่อดูส่วนต่างนั้นหรือเปล่า และเวลาที่ความยากของ issue หรือเวลาที่ใช้แก้ประเมินได้ยาก ทีมวิจัยควบคุมเรื่องนี้อย่างไรบ้าง ผมเข้าใจดีว่าการวัดแบบนี้ซับซ้อนมาก
  • ผมเห็นด้วยกับผลลัพธ์และขอบคุณสำหรับคำตอบ เรื่องหัวข้อผมคงไม่เปลี่ยนเพราะชอบสไตล์ที่แรงหน่อย แต่จะปรับแก้ให้ชัดเจนในบทความว่าเดิมใช้ถ้อยคำไม่แม่นนัก ผมยังระบุด้วยว่าสิ่งที่ผมเขียนสอดคล้องกับปัจจัยหลักที่งานวิจัยพบ เช่น “นักพัฒนาคุ้นเคยกับ repo สูง”, “repo ใหญ่และซับซ้อน”, และ “บริบทของ repo ที่เป็นนัย” ผมเองก็อยากลองทำการทดลองกับตัวเองดูเหมือนกัน แต่รู้สึกว่ายากมากที่จะสร้างสภาพแวดล้อมที่ควบคุมได้พร้อมกับต้องทำตามความต้องการของงานไปด้วย อีกทั้งก็ขาดรายการงานที่ชัดเจนและทำเสร็จได้ภายในเวลาสั้น ๆ
  • หากคุณเปลี่ยน workflow ที่ปรับจูนมาอย่างดีในโปรเจ็กต์ที่คุณรู้จักมากอยู่แล้ว ผมก็คาดว่าจะช้าลงในช่วงแรก สิ่งสำคัญคืออีก 6 เดือนหรือ 1 ปีข้างหน้าคนกลุ่มนี้จะเป็นอย่างไร งานวิจัยนี้ไม่ได้บอกแนวโน้มระยะยาว จึงหวังว่าอนาคตจะมีงานที่ติดตามนักพัฒนาคนเดิมหลังคุ้นเคยแล้วว่าผลงานเปลี่ยนไปอย่างไร ผมเองก็เจอกับตัวว่า AI ช่วยให้ผมเขียนสคริปต์สำหรับงานหลายอย่างที่ก่อนหน้านี้ทำให้อัตโนมัติได้ยาก แต่ก็ต้องถามตัวเองเสมอว่า “สิ่งนี้คุ้มกับเวลาที่ใช้หรือไม่?”
    การ์ตูน xkcd เรื่องการจัดการเวลา
  • มีคนชี้ว่าแม้แต่คำว่า “ช่วงต้นปี 2025 AI ทำให้นักพัฒนาโอเพนซอร์สที่มีประสบการณ์ทำงานช้าลง” ก็ยังเหมารวมเกินไป เพราะ AI ก็มีงานบางประเภทที่ช่วยประหยัดเวลาได้ ดังนั้นผลลัพธ์จึงขึ้นอยู่กับลักษณะของงาน
  • ความช้าลงไม่ได้แปลว่าแย่เสมอไป และการเขียนโปรแกรมแบบช้า ๆ (literate programming/แนวทางของ Knuth) อาจช่วยเรื่องการสร้างทฤษฎีความเข้าใจได้มากกว่า จึงอาจโต้แย้งได้ว่าการพัฒนาอย่างช้าแต่ผ่านการคิดและการยกระดับนามธรรมอย่างเพียงพอ สำคัญกว่าการเขียนโปรแกรมแบบฟาสต์ฟู้ด
• ผมเห็นด้วยกับปรากฏการณ์ที่ว่า “นักพัฒนาไม่รู้จริง ๆ ว่าเครื่องมือทำให้ตัวเองเร็วขึ้นหรือช้าลง” มีการยกตัวอย่างเรือที่ถูกลมและกระแสน้ำพัดออกจากเป้าหมาย คือเรารับรู้ความคืบหน้าจากการเคลื่อนไหวรอบตัวในปัจจุบัน แต่สัญชาตญาณจะไม่ค่อยบอกได้ว่าเราเข้าใกล้เป้าหมายจริงไหม เพราะแบบนี้คนจึงมักเลือกกลยุทธ์ที่ทำให้รู้สึกว่า “กำลังก้าวหน้า” และสิ่งนั้นก็อาจพาไปสู่เส้นทางที่ไม่มีประสิทธิภาพหรือช้ากว่าเดิมจริง ๆ (เช่น การขับรถแล้วเลี้ยวขวาบ่อย ๆ)
  • ตอนเริ่มใช้เครื่องมือ AI ใหม่ ๆ ความรู้สึกที่มันไม่ติดขัดและงานดูไหลต่อเนื่องนั้นดีมาก แต่ในความเป็นจริง บางครั้งแก้โค้ดเองเพียงบรรทัดเดียวกลับเร็วกว่า ทว่าก็ยังเผลอเรียก AI ตามความเคยชิน คล้ายอุปมาเรื่องการขับรถ คือถ้าถนนเส้นหนึ่งติด ก็เหมือน GPS ที่พาเราวนกลับมาแนะนำเส้นเดิมซ้ำ ๆ ได้ง่าย
  • มันคล้ายกับแอปนำทางอย่าง Waze ที่บางครั้งพาอ้อมเป็นเส้นทางยาวกว่า แต่ด้วยความสลับซับซ้อนของทางลัดทำให้เรารู้สึกว่า “กำลังเคลื่อนที่” จึงเหมือนถึงเร็วกว่า เครื่องมือ AI ก็คล้ายกัน คือเรารู้สึกว่าการเขียนโปรแกรมง่ายขึ้น แต่ผลิตภาพจริงอาจลดลง มนุษย์มักจำประสบการณ์ระยะสั้นที่ก้าวหน้าโดยไม่เจ็บปวด และตีความว่านั่นคือความคืบหน้า
  • สุดท้ายแล้วมนุษย์ก็ชอบ greedy algorithm ตามสัญชาตญาณ
  • ผู้ใช้ Linux/Unix มักคิดว่าการควบคุมด้วยคีย์บอร์ดและเครื่องมือ CLI มีประสิทธิภาพสูงสุด แต่มีงานวิจัยว่าหลายงานจริง ๆ แล้วเมาส์เร็วกว่า เหตุที่รู้สึกว่าพิมพ์เร็วกว่าก็เพราะจำนวนการกระทำต่อวินาทีสูงกว่า
  • โค้ดที่ AI สร้างขึ้นแทบไม่ได้รับการรีวิว และนักพัฒนาจำนวนมากก็รู้สึกว่าการรีวิวโค้ดนั้นเหนื่อยจนไม่อยากอ่านเลย นี่จึงเป็นเหตุผลหนึ่งที่เฟรมเวิร์กใหม่หรือการเขียนใหม่ทั้งก้อนดูได้รับความนิยม
    Joel on Software: Things you should never do, part I
    โค้ดที่ AI สร้างจำนวนมากแค่ถูกสร้างขึ้นมา ผ่านการทดสอบง่าย ๆ แล้วก็จบ มีโค้ดจำนวนไม่น้อยที่แม้แต่ตัวผู้ใช้เองก็ไม่ได้เข้าใจบริบททั้งหมดหรือเหตุผลของมันอย่างเพียงพอ
• ใจความของงานวิจัยนี้สรุปได้ว่า “AI ทำให้เกิดภาพลวงว่าผลิตภาพเพิ่มขึ้นมากกว่าความจริง” มีเพียงผู้เข้าร่วมบางส่วนเท่านั้นที่ผลิตภาพเพิ่มขึ้นเล็กน้อย ส่วนใหญ่กลับลดลงค่อนข้างมาก มีคนมากมายบอกว่าผลิตภาพของตนพุ่งขึ้นมหาศาลเพราะ AI แต่สิ่งที่งานวิจัยชี้ให้เห็นคือ ผลลัพธ์นั้นเองอาจเป็นภาพลวง ซึ่งกลับถูกมองข้ามไป AI เป็นสินค้าที่ถูกปรับให้เหมาะกับการทำให้ผู้ใช้เชื่อว่าควรใช้และมีประโยชน์ คุณค่าระดับปัจเจกเป็นเรื่องของการรับรู้จริง จึงไม่อาจปฏิเสธได้ แต่คนที่พึ่งพา AI มากควรระวังอย่างยิ่งเรื่องการบิดเบือนการรับรู้ตนเอง ความรู้สึกสำเร็จปลอม และการพึ่งพาเครื่องมือ แม้ AI จะตอบกลับมาด้วยสตรีมโทเคนที่ถูก optimize แล้ว แต่ก็ควรถามตัวเองบ้างว่าเป้าหมายที่แท้จริงของการ optimize นั้นคืออะไร
  • LLM มีประโยชน์เวลาเรียนรู้อะไรบางอย่างจริง แต่ความเข้าใจที่ได้จะมีลักษณะนามธรรมมากและออกไปทางสไตล์ของ LLM ผมจึงคิดว่าตอนเรียนควรใช้หลายวิธีผสมกัน
  • เครื่องมือ AI ไม่ได้ทำให้นักพัฒนา “เร็วขึ้น” เท่ากับทำให้รู้สึกว่า “คล่องแคล่วฉับไวขึ้นชั่วขณะ” มันมีลักษณะเหมือนภาพลวงที่ทำให้รู้สึกว่าภาระทางสมองลดลง เป็นปรากฏการณ์ที่น่าสนใจซึ่งเกิดจาก feedback loop แบบอื่นทำให้ตัวความรู้สึกเปลี่ยน และกลไกการสร้างความทรงจำก็เปลี่ยนไปด้วย
• ระหว่างที่กำลังคุยกันถึงงานวิจัยที่ว่า “เมื่อนักพัฒนาโอเพนซอร์สที่มีประสบการณ์ใช้ AI กับโปรเจ็กต์ของตัวเองกลับทำงานช้าลง” ผมกลับต้องไปทำงานกับ codebase ที่คนอื่นเขียนไว้ อายุ 3 เดือน และใช้เฟรมเวิร์กที่ไม่คุ้นเคย แต่ด้วยการใช้ Claude Code ผมทำงานบางอย่างเช่น data synchronization ได้เสร็จภายในไม่กี่ชั่วโมง ทั้งที่เมื่อก่อนกับโปรเจ็กต์อื่น งานแบบเดียวกันนี้อาจใช้เวลา 1–2 วัน หรือมากสุดถึง 2 สัปดาห์ มันเป็น jump start ที่มหาศาล แม้พอความซับซ้อนสูงขึ้นจะค่อย ๆ ช้าลง แต่ก็ยังน่าทึ่งที่มันช่วยให้เริ่มต้นได้เร็วมาก
  • ผมก็มีประสบการณ์คล้ายกัน แต่สิ่งที่งานวิจัยนี้พูดถึงไม่ใช่ ramp-up แบบที่เราเจอ หากเป็นกรณีที่นักพัฒนาโอเพนซอร์สซึ่งคุ้นเคยกับโปรเจ็กต์ของตัวเองมากอยู่แล้วใช้ AI ทำงาน LLM ช่วยให้ปรับตัวเข้ากับ codebase ใหม่ได้เร็วขึ้นจริง แต่หลังจากคุ้นเคยแล้ว กลับมีประสบการณ์ว่ามันรบกวนมากกว่า
  • พอมีคำกล่าวแนว “PR ที่เคยใช้ 2 สัปดาห์ ตอนนี้เหลือไม่กี่ชั่วโมง” เรื่องผลิตภาพที่เพิ่มขึ้นก็มักตามมาเสมอ แต่ผมคิดว่าเราแทบไม่เคยตรวจสอบจริงจังเลยว่าการคาดการณ์เวลาในการพัฒนาของเรานั้นแม่นแค่ไหน และ PR ที่ทำออกมาเร็วขนาดนั้นยังมีคุณภาพตรงตามที่คาดไว้เดิมจริงหรือไม่ หรือแค่รีบจนข้ามบริบทสำคัญของระบบ ทำให้โอกาสเกิดบั๊กสูงขึ้น หากยอมลดคุณภาพ ต่อให้ไม่มี AI ก็ทำให้เร็วขึ้นได้เหมือนกัน
  • ผมก็สงสัยว่าโดยเฉลี่ยแล้ว AI ทำให้ความชำนาญต่อ codebase และระบบเพิ่มขึ้นเองตามธรรมชาติหรือไม่ ผลของการเรียนรู้เมื่อใช้ LLM ให้ความรู้สึกเหมือนอ่านภาษาใหม่ได้ แต่พอให้เขียนเองตั้งแต่ต้นกลับยาก หากยกตัวอย่าง C++ ก็คืออ่านได้ แก้ของเดิมได้ แต่จะสร้างใหม่จากศูนย์ไม่ง่าย
  • สิ่งที่ผมอยากบอกคือ AI ให้ jump start ใหญ่มากจริง ๆ ไม่ได้ตั้งใจจะวิจารณ์งานวิจัย บทความ หรือ paper เพียงแต่อยากบอกว่าในบางบริบท AI มีประโยชน์จริง ๆ และไม่ใช่แค่ช่วยเขียนโค้ดเท่านั้น เช่น Claude Code ยังช่วยลองเชื่อมต่อ AWS cluster จากภายในคอนเทนเนอร์ของโปรเจ็กต์ได้โดยตรง ช่วยให้เข้าใจโครงสร้างพื้นฐานและสถาปัตยกรรมโดยรวมได้มาก จากประสบการณ์ของผม งาน 80–90% ให้ความสำคัญกับ “คุณค่าทางธุรกิจ” มากกว่าคุณภาพโค้ด ส่วนงานที่คุณภาพโค้ดสำคัญจริง หรือเกี่ยวข้องกับอัลกอริทึมหรือโครงสร้างข้อมูลเฉพาะทาง ผมก็ไม่แน่ใจว่ามันจะมีประโยชน์แค่ไหน แต่ถ้าให้ตัวอย่างที่ดีและบริบทชัดเจน มันก็เขียนโค้ดที่ใช้งานได้ค่อนข้างดี เครื่องมือเหล่านี้พัฒนาเร็วมากเป็นรายสัปดาห์หรือรายเดือน สุดท้ายแล้ว AI ไม่ใช่เวทมนตร์ แต่เป็นเครื่องมือ และความรับผิดชอบต่อ product/ผลลัพธ์สุดท้ายก็ยังเป็นของเรา
  • ควรจำไว้ว่าสิ่งที่ paper (TFA) ศึกษาคือกรณีในโปรเจ็กต์ที่คุ้นเคยมาก ส่วนกรณีที่ผมเจออยู่คนละด้าน คือ AI เก่งมากในสถานการณ์ที่เราไม่คุ้นเคย
• มีคนอ้างอุปมาว่า “เครื่องมือ AI แบบ agentic (Claude Code, Amp, Gemini CLI ฯลฯ) ต่อการเขียนโปรแกรม ก็เหมือน table saw ต่อช่างไม้” คือถ้าฝึกใช้เป็นแล้ว งานบางอย่างจะเร็วขึ้นและทำได้ดีกว่า แต่ถ้ายังไม่ชำนาญก็อาจถึงขั้นเจ็บตัวได้ ผมเองพบว่า agentic AI ทำให้กล้าลองโปรเจ็กต์ที่ทะเยอทะยานขึ้น และเอางานที่ไม่อยากทำหรือซ้ำ ๆ ให้ AI จัดการแทน จึงมีพื้นที่ทางความคิดมากขึ้น ขณะเดียวกันก็ต้องระวังไม่ปล่อยให้ AI ทำแทนทุกอย่างแล้วตัวเองแค่ commit โดยไม่เข้าใจ เราควรพยายามเรียนรู้วิธีใช้มันให้ดีขึ้นตามแบบของเครื่องมือ
  • ผมว่าการเปรียบกับ table saw ไม่ค่อยเข้ากัน เพราะ table saw เป็นเครื่องมือที่แม่นยำเมื่อเทียบกับเครื่องมือช่างแบบใช้มือ แต่ agentic AI กลับห่างไกลจากความแม่นยำมาก
  • ตรรกะทำนอง “คุณใช้ AI ผิดเอง” เป็นการดูถูกนักพัฒนาที่สร้างสแต็กโอเพนซอร์สทั้งหมดขึ้นมาก่อนที่ AI จะโผล่มาเสียอีก และจนถึงตอนนี้ก็ยังไม่มีหลักฐานว่า AI สร้างซอฟต์แวร์ที่มีคุณค่าขึ้นมาได้จริง
• ในงานวิจัยนี้มีนักพัฒนาเพียงคนเดียวเท่านั้นที่มีประสบการณ์กับ Cursor เกิน 50 ชั่วโมง (รวมเวลาที่เข้าร่วมวิจัยด้วย) และนักพัฒนาคนนั้นทำงานเร็วขึ้น 25% ที่เหลือทั้งหมดเป็นมือใหม่ และถ้ามือใหม่ใช้เครื่องมือใหม่แล้วช้าลงก็เป็นเรื่องธรรมดามาก ผมจึงคิดว่ายากจะใช้การศึกษานี้สรุปภาพรวมเรื่องผลิตภาพจาก AI
  • แต่ถ้าดูรายละเอียดในงานวิจัย จะเห็นว่าการศึกษาก่อนหน้านี้ที่ใช้ผู้เข้าร่วมซึ่งมีประสบการณ์กับเครื่องมือในระดับใกล้เคียงกัน (หรือแม้แต่น้อยกว่า) กลับรายงานว่าความเร็วเพิ่มขึ้นด้วยซ้ำ คนส่วนใหญ่ก็มีประสบการณ์กับการเขียน prompt สำหรับ LLM เพียงพออยู่แล้ว และ Cursor ก็คล้าย VSCode มากจนแทบไม่มี learning curve เพิ่ม หากวันหนึ่งนักพัฒนาทุกคนชำนาญเครื่องมือ AI มาก ๆ ก็อาจเกิดกรณีที่ทักษะการทำงานโดยไม่ใช้ AI แย่ลง จนเมื่อกลับมาใช้ AI ผลลัพธ์จึงดูเหมือนเร็วขึ้น เพียงเพราะ baseline แย่ลง ประเด็นสำคัญไม่ใช่ว่าใช้เครื่องมืออะไร แต่คือการประเมินผลิตภาพด้วยตัวเองนั้นมองโลกในแง่ดีเกินจริงเมื่อเทียบกับผลลัพธ์จริง หากอยากตัดสินผลกระทบจริง ต้องมีตัวชี้วัดที่เป็นรูปธรรม
    (พูดไว้ละเอียดกว่านี้ในส่วน C.2.7 ของ paper “การใช้เครื่องมือ AI ต่ำกว่าค่าเฉลี่ย”)
  • ถ้าเป็นนักพัฒนาที่ใช้ IDE เดิมของตัวเองมาอย่างยาวนาน (เช่น Vim/Neovim) การย้ายไปเครื่องมือใหม่อย่าง Cursor ก็อาจทำให้ผลิตภาพตกลงอย่างชัดเจนเป็นเวลาหลายเดือน
  • ผมก็คิดเหมือนกัน นักพัฒนาที่ไม่คุ้นกับเครื่องมือย่อมช้าลงแน่นอน AI ก็ไม่ใช่ข้อยกเว้น
• ผมเป็นหนึ่งในผู้รีวิวโค้ดประจำของ Burn (เฟรมเวิร์ก deep learning บน Rust) และเพิ่งปิด PR แก้บั๊กอันหนึ่งที่ดูเหมือน AI agent เขียนทั้งชุด PR นั้นไม่ได้แก้ต้นตอของปัญหาเลย แค่เมิน error ไปเฉย ๆ เพิ่มโค้ดอธิบายแก้ตัวอย่างยืดยาวโดยไม่จำเป็น และยังใส่เทสต์ที่ตรวจการเมิน error ด้วย ดูเหมือนทำไปเพื่อให้มี commit ติดประวัติเท่านั้น แนวโน้มการใช้ AI แบบผิด ๆ ลักษณะนี้กำลังกระจายออกไปอย่างน่ากังวล
  • ส่วนที่น่าพิศวงคือเวลา LLM ไม่รู้คำตอบ มันจะตอบหลงประเด็นไปก่อน แล้วพอถูกชี้ว่าผิดก็จะตอบประมาณ “ใช่เลย เดี๋ยวผมแก้ใหม่” ผมกลัวจริง ๆ ว่าคนที่ยังไม่มีประสบการณ์จะมองไม่ออกว่า issue ต่างกันอย่างไร หรือไม่ก็ค่อย ๆ เลิกใส่ใจโค้ดไปเอง และก็กังวลว่าจะมีช่องโหว่และการนำไปใช้ในทางที่ผิดทะลักออกมาอย่างจริงจัง
  • ตอนรีวิว MR ของเพื่อนร่วมงาน ผมเจอ test case ที่เห็นชัดมากว่า AI สร้าง เพราะมีแต่ชื่อตัวแปรอย่าง thing1, thing2 เปลี่ยนแค่ชื่อแต่รูปแบบเหมือนกันหมด ผมเลยให้ฟีดแบ็กว่าใช้ชื่อให้แยกกันชัดกว่านี้หน่อย คราวนี้ AI ก็เปลี่ยนไปตั้งชื่อตัวแปรยาวมากแบบพยายามอธิบายลักษณะของแต่ละเคสทุกข้อ ผลคือโค้ดกลับอ่านไม่ออกในแวบแรก ผู้เขียนอาจรู้สึกว่าตัวเองเขียนได้เร็วขึ้นมาก แต่ในความจริง เวลาที่เสียไปกับฟีดแบ็ก การรีวิว และการแก้ไข กลบกำไรด้านผลิตภาพหายหมดแล้ว
  • ยังมีความเห็นเชิงขำ ๆ ด้วยว่า “ทำเฟรมเวิร์ก deep learning ด้วย Rust → วงจรอุบาทว์ที่โยงกับ AI”
  • บรรยากาศที่ใช้ AI เพื่อให้มี commit ติดประวัติจริง ๆ มีมานานแล้ว AI แค่ทำให้การผลิตสแปมง่ายขึ้นมาก
    อ้างอิง: ปัญหา AI spam ตั้งแต่หลายปีก่อน
  • มีคนชี้ว่า LLM มักเขียน try:catch ครอบกว้างเกินไปจนตามต้นตอปัญหายากขึ้น ส่วนตัวผมอยากให้ปัญหาแสดงออกมาเร็วและแรง (fail fast) เพื่อจะได้แก้ตรงจุดทันที
• ถ้าจะแชร์จากความรู้สึกของตัวเอง AI programming ทำให้โฟกัสหลุดบ่อยและเหนื่อยง่ายขึ้น การโค้ดทั้งวันเป็นเหมือนตำนาน ปกติแล้วคนเราจะมีช่วงโฟกัส 1–3 ชั่วโมง สลับพักระหว่างนั้น แม้แต่เวลาที่อ่านโค้ดหรืออ่านการเปลี่ยนแปลงของเพื่อนร่วมงาน เวลานั้นก็นับรวมเป็นเวลางาน แต่กลับไม่ได้แปลว่ามีความคืบหน้าจริงมากนัก agentic AI (เช่น รีแฟกเตอร์โค้ดเล็ก ๆ) อาจมีประโยชน์ แต่ไม่ได้เพิ่มผลิตภาพแบบก้าวกระโดดนัก ส่วน code autocomplete (อย่าง Copilot ยุคแรก) กลับมี noise ที่ไม่จำเป็นมากกว่า
  • ถ้าบันทึกหน้าจอทั้งวันดูว่าเราทำอะไรบ้าง ผลลัพธ์คงหดหู่ไม่น้อย โดยเฉพาะกับ codebase ที่โตเต็มที่แล้ว ต่อให้บอกว่าโฟกัสได้หนึ่งชั่วโมงก็อาจยังพูดเกินจริง
• เวลาดีบักบั๊กยาก ๆ ใน codebase ที่ไม่คุ้นเคย (เช่น race condition) การเพิ่ม logging, สลับใช้ฟังก์ชันในไลบรารี, หรือปรับโครงสร้างเป็นสิ่งจำเป็น แต่ถ้า AI ตอบสั้น ๆ ว่า “ตรงนี้คือ race condition และแก้แบบนี้ได้” แม้มันจะเหมือนแก้เร็วในระยะสั้น ทว่าก็เสี่ยงทำลายความเข้าใจด้านโครงสร้างโค้ดและตรรกะในระยะยาว หากปล่อยให้การแก้ไขโค้ดแบบขับเคลื่อนด้วย AI ดำเนินต่อไปเรื่อย ๆ ท้ายที่สุดโค้ดอาจผิดรูปจนแม้แต่ AI เองก็รับมืออย่างเหมาะสมไม่ได้อีก
  • ทุกครั้งที่ได้ยินเรื่องเล่าว่า “ผมใช้ AI ช่วยแล้วไปมีส่วนร่วมกับภาษาและ codebase ที่ไม่รู้จักได้” ผมจะรู้สึกว่าในระยะสั้นมันอาจเวิร์ก แต่ก็อดถามไม่ได้ว่าจริง ๆ แล้วคุณได้เรียนรู้อะไรบ้าง การมีส่วนร่วมแบบนี้อาจใช้ได้กับงานเล็ก ๆ แต่ผมแทบไม่ค่อยได้ยินเรื่องเล่าการบำรุงรักษาระยะยาวจากแนวทางแบบนี้
• จากการทบทวนโปรเจ็กต์แรกที่ผมใช้เครื่องมือ AI อย่างจริงจัง ผมสรุปได้ว่า 1) ความเร็วไม่ได้เพิ่มขึ้น 2) อาจช้าลงด้วยซ้ำ 3) แต่คุณภาพของผลลัพธ์ดีขึ้น ความช้าลงกับคุณภาพที่เพิ่มขึ้นเชื่อมโยงกัน เพราะผมใช้มันเป็นเครื่องมือช่วยหลัก ๆ ในการตรวจสอบไอเดียและสำรวจทางเลือก AI ยังให้ประสบการณ์การเรียนรู้ที่ดีเมื่อทำงานในโดเมนที่ไม่คุ้นเคย และในโดเมนหลักของผม การขัดเกลาไอเดียของตัวเองหรือของ AI ก็ทำให้คุณภาพสุดท้ายดีขึ้น ความเร็วไม่ใช่ทุกอย่าง แม้คุณภาพจะวัดเชิงปริมาณได้ยาก แต่ผมรู้สึกว่ามันคุ้มค่าแน่นอน
  • เพราะ AI ช่วยยกระดับคุณภาพได้จริง ทุกวันนี้ผมเลยชอบ AI ที่กล้าโต้แย้งและไม่เออออตามง่าย ๆ ถ้าขอให้ AI ช่วยเสนอไอเดียแล้วช่วยโจมตีจุดอ่อน หรือช่วยหาช่องโหว่ในไอเดียของผม มันจะมีประโยชน์มาก ถึงท้ายที่สุดอาจไม่ได้นำไปทำจริง แต่ก็ช่วยให้คิดมุมต่าง ๆ ที่ก่อนหน้านี้ไม่เคยนึกถึงได้ ประสบการณ์นี้คล้ายกับการคุยกับเพื่อนร่วมงานที่พอมีความเห็นต่อโดเมนนั้นได้ในระดับใช้งานจริง

[eususu]

ผมก็คิดคล้าย ๆ กัน แต่ไม่รู้จะอธิบายออกมายังไงดี
การตั้งชื่อว่า mental model นี่เหมาะมากเลยครับ ไว้คงต้องหยิบมาใช้บ่อย ๆ