ภาพลวงของคำอ้าง AI Coding: ทำไมการระบาดของ 'Shovelware' จึงไม่เกิดขึ้น

• เมื่อตรวจสอบคำอ้างเรื่องการเพิ่มผลิตภาพของ เครื่องมือเขียนโค้ดด้วย AI ด้วยข้อมูลล่าสุด พบว่าในความเป็นจริง ความเร็วหรือผลงานไม่ได้เพิ่มขึ้นอย่างเห็นได้ชัด
• ผลวิจัยของ METR ระบุว่า แม้นักพัฒนาจะเชื่อว่าเครื่องมือเขียนโค้ดด้วย AI ช่วยเพิ่ม ผลิตภาพ ได้ 20% แต่ ในความเป็นจริงกลับลดลง 19%
• คำโฆษณาจำนวนมาก รวมถึงคำอ้างเรื่อง ผลิตภาพเพิ่ม 10 เท่า จากบริษัทและนักพัฒนาบางส่วน ไม่ได้สะท้อนอยู่ในสภาพตลาดจริงหรือการเปิดตัวซอฟต์แวร์ใหม่
• ไม่พบปรากฏการณ์อย่างการพุ่งขึ้นของ Shovelware (แอปผลิตจำนวนมาก, ซอฟต์แวร์คุณภาพต่ำ) จึงยังไม่เห็นความเปลี่ยนแปลงที่ชัดเจน
• การ พูดเกินจริงเรื่องผลิตภาพ จากบริษัทอย่าง GitHub, Copilot, Cursor, Google, OpenAI และนักพัฒนาบางส่วน กำลังถูกนำไปใช้ในทางที่ผิดกับ การลงทุน การปรับโครงสร้างองค์กร และการกำหนดเงินเดือน
• ข้อสรุปสำคัญ: “ตราบใดที่ยังไม่มีซอฟต์แวร์ออกมามากขึ้นจริง คำอ้างว่า AI coding ทำให้นักพัฒนาเก่งขึ้น 10 เท่าก็เป็นเรื่องแต่ง” ดังนั้นนักพัฒนาไม่ควรหวั่นไหวต่อแรงกดดัน และควรตอบโต้ด้วยข้อมูล

---

บทนำ: นักพัฒนาซอฟต์แวร์กำลังไม่พอใจกับ AI coding

• ใช้ชีวิตมาอย่างยาวนานในฐานะ นักพัฒนาซอฟต์แวร์ และมีทั้งความภาคภูมิใจและตัวตนผูกกับการเขียนโปรแกรม
• ในช่วงแรกของการนำ เครื่องมือเขียนโค้ดที่ขับเคลื่อนด้วย AI มาใช้ ผู้เขียนมีความคาดหวัง แต่ผลวิจัยล่าสุด (METR) ทำให้เริ่มรู้สึกเคลือบแคลง
  • ผู้เขียนคิดว่า AI coding ทำให้ตนเอง เร็วขึ้นราว 25% แต่ผลวิจัยของ METR กลับพบว่า ช้าลง 19%
• งานวิจัยดังกล่าวยืนยันว่า การรับรู้ของนักพัฒนาต่อประสิทธิภาพของเครื่องมือ AI กับข้อมูลที่วัดจริงนั้นสวนทางกันโดยสิ้นเชิง
• แม้จากการทดลองด้วยตนเอง ก็สัมผัสได้ว่า การใช้ AI ไม่ได้ส่งผลบวกต่อเวลาในการเขียนโปรแกรมจริง

ตรวจสอบด้วยตัวเอง: การทดลองเปรียบเทียบแบบสุ่มกับ AI

• ใช้วิธีทดลองวัด ส่วนต่างของเวลา (Delta) ระหว่างกรณีที่ใช้ AI และไม่ใช้ AI ในแต่ละหน่วยงาน
• ข้อมูลที่ได้จากการทดลอง 6 สัปดาห์ ไม่พบความแตกต่างที่มีนัยสำคัญทางสถิติ
• แม้จะเป็นตัวอย่างขนาดเล็ก แต่ก็พบแนวโน้มว่า การใช้ AI กลับทำให้ ช้าลง 21% (ตัวเลขเดียวกับงานวิจัย METR)
• หากมีผลเพิ่มประสิทธิภาพจริงระดับ 2 เท่าหรือ 10 เท่า ก็ควรปรากฏชัดเจนในข้อมูล
• ความฝันเรื่อง AI coding ในปัจจุบันยังไม่เป็นจริง และในทางปฏิบัติยังไม่มีอะไรเปลี่ยนแปลง

ความคาดหวังกับความจริง: ทำไมจึงไม่มีการระบาดของ Shovelware

• หากการปฏิวัติผลิตภาพจาก AI coding เป็นเรื่องจริง ก็ควรเห็นการเพิ่มขึ้นมหาศาลของ แอป บริการ และเกม ทุกประเภท
• มีข้อความการตลาดของเครื่องมือ AI coding จำนวนมากหลั่งไหลออกมา เช่น “Built to make you extraordinarily productive”
• Google, OpenAI, GitHub Copilot และรายอื่น ๆ ต่างก็อ้างว่า นักพัฒนา เร็วขึ้น 25% หรือมี ผลิตภาพเพิ่ม 10 เท่า
• แต่ในข้อมูลการเปิดตัวซอฟต์แวร์ใหม่จริง (GH Archive, BigQuery ฯลฯ) กลับ ไม่พบการเติบโตแบบพุ่งชันหรือการระเบิดของปริมาณ
• แม้ AI coding จะถูกใช้อย่างแพร่หลายตั้งแต่ปี 2022 เป็นต้นมา แต่จำนวนรีลีสและโปรเจกต์ใหม่ทั่วโลกก็ไม่ได้เปลี่ยนไปมากนัก

ผลกระทบต่อตลาดและความจริงของนักพัฒนา

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

บทสรุป: ความจำเป็นของการตัดสินใจบนฐานข้อมูลอย่างเยือกเย็น

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

โต้แย้งคำคัดค้านที่พบบ่อย

1. "ถ้าเชี่ยวชาญ prompt engineering จริง ก็จะเป็นนักพัฒนา 10x ได้"

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

2. "มันยังอยู่ในช่วงเริ่มต้น ต้องใช้เวลา"

   • มีการลงทุนไปแล้วหลายหมื่นล้านดอลลาร์ และถูกนำไปใช้จริงในงานอาชีพแล้ว
   • การตัดสินใจในวันนี้ ส่งผลโดยตรงต่อชีวิตของผู้คนจริง

3. "ถ้าไม่ใช้ตอนนี้จะตามไม่ทัน"

   • แม้แต่ข้อมูลของ Github Copilot ก็ชี้ว่า การเพิ่มผลิตภาพจริงตามระดับความชำนาญ นั้นน้อยมาก (อัตราการยอมรับ 29% → 34%)

4. "คุณภาพดีขึ้นเฉย ๆ ปริมาณเลยเท่าเดิม"

   • โดยรวมแล้วคุณภาพของอุตสาหกรรมกลับ ถดถอยลง และการทดสอบก็ลดลง
   • ถ้ามันเป็นเครื่องมือสร้าง coder 10x จริง ก็ควรเห็น Shovelware ล้นตลาดแล้ว

5. "ทุกอย่างตอนนี้เน้นเว็บ และเดี๋ยวนี้ก็ไม่มีใครสนใจโดเมนเนมแล้ว มีแต่ซับโดเมนของ Vercel อะไรพวกนั้น"

   • ยังมีผู้ใช้จำนวนมากที่ชอบ โดเมนเฉพาะของตัวเอง อยู่

6. "โดเมน .ai พุ่งแรง (47% ปีนี้) = การเติบโตจริง"

   • การเพิ่มขึ้นของโดเมนใหม่เป็นเพียงผลจากการ pivot ของสตาร์ตอัป AI เท่านั้น ไม่ใช่การพุ่งขึ้นของ จำนวนโดเมนใหม่โดยรวม
   • จำนวนโดเมนทั้งหมดไม่ได้เป็นเช่นนั้น

7. "แก่นแท้ของงานพัฒนาไม่ใช่โค้ด แต่เป็นงานอื่นนอกเหนือจากโค้ด"

   • ในสภาพแวดล้อมของ นักพัฒนาเดี่ยวหรือทีมขนาดเล็ก ที่ไม่ใช่องค์กรใหญ่ โค้ดยังคงเป็นศูนย์กลางจริง
   • โปรเจกต์ใหม่ที่ช่วยตอบสนองความอยากเขียนโค้ดเล็ก ๆ น้อย ๆ ก็ยังไม่ได้เพิ่มขึ้นจนสังเกตได้ชัด

ปิดท้าย

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

[ahwjdekf]

สำหรับนักพัฒนาแบบ 10x ก็อาจกระโดดขึ้นไปได้ราว 12x ด้วยความช่วยเหลือจาก AI นั่นแหละครับ

[overthetop]

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

[nemorize]

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

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

สุดท้ายแล้ว จนกว่างานง่ายๆ นั้นจะเสร็จสมบูรณ์ ผมก็ยังต้องคอยใส่ใจอยู่ตลอด และก็สลับไปทำงานอื่นไม่ได้ด้วย... เลยรู้สึกว่ายากที่จะคาดหวังการพัฒนาที่มีนัยสำคัญครับ

[nemorize]

ผมรู้สึกว่าไปหาคนทำงานพาร์ตไทม์ใน Danggeun จ่ายค่าจ้างชั่วโมงละ 10,000 วอน ให้มาช่วยงานง่าย ๆ สักไม่กี่ชั่วโมง กลับช่วยเพิ่มประสิทธิภาพได้มากกว่าเสียอีก
สำหรับผม แค่มีค่าใช้จ่ายราว ๆ 100,000 วอนต่อสัปดาห์ก็ค่อนข้างน่าพอใจแล้ว

โดยเฉพาะผมเคยทำงานกับคุณป้าหลายท่านที่เคยทำงานบัญชีแล้วลาออกมาเป็นแม่บ้านเต็มเวลา ถึงจะไม่รู้เรื่องการเขียนโค้ดเลย แต่พอให้ฟีดแบ็กสักไม่กี่ครั้ง ก็ทำออกมาได้เรียบร้อยมากเลยครับ
พวกโค้ด boilerplate ก็ยังใช้ Excel เติมอัตโนมัติ ใส่สูตรอะไรต่าง ๆ แล้วทำออกมาได้ในพริบตาเหมือนกัน...

[zxcv123]

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

[kirrie]

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

[ndrgrd]

ผมเพิ่งได้อ่านงานวิจัยของ METR ที่ถูกพูดถึงไปเมื่อไม่นานนี้ ผลลัพธ์มันอธิบายสิ่งที่ผมรู้สึกและตั้งคำถามไว้ได้ดีมาก

ต่อให้สั่งให้ทำ "งานที่ทำซ้ำ" ตามที่มีคอมเมนต์ใน Hacker News บอกไว้ แต่ความจริงแล้วส่วนใหญ่ก็ยังต้องคอยตรวจและแก้ด้วยมืออยู่ดี
ไม่ใช่แค่ครั้งสองครั้งที่ผมเห็นตรรกะแบบสะเปะสะปะของผลลัพธ์ "ง่ายๆ" ที่ AI เขียน แล้วคิดในใจว่าทำเองตั้งแต่แรกน่าจะดีกว่า

งานที่ง่ายมากจริงๆ ในระดับคัดลอกวาง มันก็คงทำได้ดีแหละครับ
แต่กับงานแบบนั้น แค่คัดลอกวางกับใช้สไนเป็ตก็มีประสิทธิภาพกว่าอยู่แล้ว ไม่ต้องต่ออินเทอร์เน็ต อัปโหลดข้อมูลของตัวเองขึ้นไปบนเซิร์ฟเวอร์ของคนอื่น แล้วรอครั้งละหลายสิบวินาทีด้วย

[GN⁺]

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

• สำหรับผม AI เหมือนกราฟระฆัง และคิดว่าคนจำนวนมากก็น่าจะคล้ายกัน สิ่งสำคัญคือเกณฑ์ที่ใช้ประเมินผลลัพธ์ ไม่ใช่ “จำนวนบรรทัดโค้ด” แต่ควรเป็น “จำนวนบรรทัดโค้ดคุณภาพดีที่ดูแลรักษาได้ ขยายต่อได้ และอัปเกรดได้ง่าย” ถ้าวัดด้วยเกณฑ์นี้ ผลจากคำสั่งอย่าง “สร้างทั้ง repo” แทบเป็นขยะไร้ความหมาย แต่การที่ AI ช่วยเติมโค้ดอย่าง getUser(... อัตโนมัติถือว่าเพิ่มผลิตภาพ ส่วนจะเพิ่ม 0.1% 1% หรือ 10% ผมยังบอกไม่ได้แน่ชัด

• สำหรับผม ปัญหาที่หนักที่สุดคือ ปัญหาที่ผมทำอยู่ในบริษัทตอนนี้ต้องอาศัยการวางแผนและการลงมือทำอย่างรอบคอบ แต่ AI กลับช่วยอะไรไม่ได้เลย ขณะที่ผู้จัดการของเราบอกว่าบริษัทเป็น “AI-first company” จึงลดกำหนดส่งโปรเจกต์เหลือ 20% ของเวลาประเมินเดิม กระแสความคลั่งแบบหมู่กำลังแพร่หนักมากในหมู่ SVP กับ PM และผมไม่เคยเห็นอะไรแบบนี้มาก่อน

  • ผู้จัดการบอกว่าลดกำหนดส่งโปรเจกต์เหลือ 20% ของเวลาประเมินเดิม ซึ่งผมว่ามันเหลือเชื่อจริง ๆ ตัวเลขที่ไม่สมจริงแบบนี้มีใครสักคนกำหนดขึ้นมาแล้วทำเหมือนมันเป็นจริง สุดท้ายถ้าทำไม่ได้ ความรับผิดชอบก็จะถูกโยนมาที่ผม แล้วข้างบนก็จะไปเอาผิดกับผู้จัดการคนนั้น ถ้า AI เพิ่มผลิตภาพได้จริง ก็ค่อยจัดการลดนักพัฒนาที่ไม่จำเป็นได้ แต่ควรทำหลังจาก LLM เข้าไปอยู่ในกระบวนการพัฒนาได้สำเร็จแล้ว ถึงขั้นทำให้ผมเริ่มคิดว่าควรถอนเงินลงทุนออกจาก S&P 500 เพื่อรับมือฟองสบู่ AI ไหม
  • ถ้าถึงขั้นเอา LLM ไปทำ incident response ได้จริง ก็ปล่อยให้ CEO ทำตามที่อยากทำ แล้วก็รับความเสียหายด้านชื่อเสียงตามนั้นไป ถ้าล้มเหลวก็แค่ git ย้อนกลับไปก่อนโค้ดที่ LLM เขียนได้ ผมพูดเล่นครึ่งหนึ่งจริงครึ่งหนึ่ง
  • ตอนนี้ AI ยังไม่ถึงระดับแทนนักพัฒนาได้ แต่ผมคิดว่ามันดีพอที่จะทำงานออฟฟิศจำนวนมากหรือบทบาทผู้จัดการที่เมื่อก่อนทำอัตโนมัติได้ยากให้เป็นอัตโนมัติได้แล้ว Google ก็ดูเหมือนลด middle management ลงเยอะเพราะ AI จริง ๆ แต่ไม่ได้ลดนักพัฒนาในสัดส่วนเดียวกัน
  • AI กำลังถูกใช้เป็นข้ออ้างให้ผู้จัดการที่ขาดภาวะผู้นำทางเทคนิคใช้กดดันนักพัฒนา

• หลายอย่างสามารถเป็นจริงพร้อมกันได้ LLM ไม่ได้ทำให้ผลิตภาพของนักพัฒนาเพิ่ม 10 เท่าสำหรับงานทั่วไปที่สุ่มมา แต่ในขณะเดียวกัน LLM ก็เพิ่มผลิตภาพอย่างมหาศาลกับงานบางขอบเขตได้ มันยังใช้ทำงานจุกจิกซ้ำ ๆ ให้เป็นอัตโนมัติได้ แม้เวลาจริงอาจนานกว่ามนุษย์ แต่เพราะมันรันอยู่เบื้องหลังจึงไม่ใช่ปัญหา การเรียนรู้ API หรือไลบรารีใหม่ ๆ ก็เร็วขึ้นมากด้วย LLM และเวลาต้องเขียน glue code เล็ก ๆ ในภาษาที่ไม่คุ้น มันช่วยประหยัดเวลาได้มากโดยไม่ต้องเสียเวลาเรียนรู้เกินจำเป็น สำหรับการบำรุงรักษาโค้ดเบสใหญ่ที่มีอยู่เดิมกลับแทบไม่รู้สึกว่าผลิตภาพต่างกันมาก การตั้งค่า scaffolding เว็บไซต์ใหม่ LLM ทำได้ดีจนน่าตกใจ การเขียน mock class หรือจัดการงานซับซ้อนที่ผมทำปีละสองครั้งแล้วก็ลืม เช่น วิธีใช้ mock library มันทำให้เสร็จได้แทบจะทันที การช่วยทำความเข้าใจโครงสร้างโค้ดเบสใหม่ก็ทำได้ประมาณ 70% จนน่าพอใจ กับโปรเจกต์ที่ออกแบบซับซ้อน เช่น ต้องหาว่า HTTP route อยู่ตรงไหน หรือฟังก์ชัน dependency injection อยู่ตรงไหน แค่ถามว่า “เฮ้ Claude ฟังก์ชันเกี่ยวกับ auth อยู่ตรงไหนบ้าง?” ก็สะดวกดี ผมคิดว่าต้องใช้เครื่องมือที่ถูกกับงานที่ถูก

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

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

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

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

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

• ผมเห็นด้วยกับข้อสรุปนี้ แม้จะใช้ AI ก็ยังไม่เห็นการเพิ่มผลิตภาพแบบก้าวกระโดด ผมคิดว่าถ้าวิศวกรซอฟต์แวร์ไม่ฝึกแก้ปัญหา ใช้วิจารณญาณ และแปลงสิ่งนั้นเป็นโค้ดอย่างต่อเนื่อง ความรู้เชิงประสาทอาจค่อย ๆ อ่อนลง คำสัญญาว่า AI จะพาเราไปสู่ผลิตภาพ 2 เท่าหรือ 10 เท่าในอนาคตดูไม่มีเนื้อหาจริงรองรับ และแม้ในโค้ดเบสส่วนตัวจะพอมีผลิตภาพเพิ่มขึ้นบ้าง แต่ในตลาดจริงก็ไม่ได้เห็นว่ามีผลิตภัณฑ์ที่ดีกว่าถูกปล่อยออกมามากขึ้น เวลาทำงานที่ปรึกษา ผมมักเห็นผู้ก่อตั้งหรือ CTO พยายามยัด AI เข้าไปแล้วกลับควบคุมโค้ดไม่ได้และสร้างความสับสนมากขึ้น ทุกวันนี้ผมจึงมักรับบทที่ปรึกษาเพื่อช่วยวาง engineering best practices ด้วย

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

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

  • เมื่ออัตรากำไรลดลง สุดท้ายบริษัทก็ต้องพยายามเค้นมูลค่าจากต้นทุนแรงงาน ผมคิดว่าเสน่ห์ของ AI ถึง 99% คือการลดค่าแรง และการจ้างเพิ่มก็สวนทางกับเป้าหมายนั้น แม้ผมเองจะไม่เห็นด้วยกับคำอ้างเรื่องผลิตภาพที่เพิ่มขึ้นจาก AI แต่ก็อยากชี้ให้เห็นแรงจูงใจตรงนี้
  • ดูเหมือนผู้บริหารระดับ C จำนวนมากคาดหวังว่าจะใช้ AI แทนพนักงานที่ยังเหลืออยู่ได้อีก โดยยึดตาม narrative ว่า “AGI กำลังจะมาในไม่ช้า” ผมไม่เชื่อแบบนั้น แต่ถ้ามองจากจุดยืนนั้นก็พอเข้าใจเหตุผลที่ไม่อยากจ้างนักพัฒนาเพิ่ม
  • วันนี้คงได้เรียนรู้ว่า “กฎผลตอบแทนลดลง” คืออะไร องค์กรหนึ่งมีขีดจำกัดของคนและทรัพยากรที่จะใส่เข้าไปได้ การใส่มากเกินจำเป็นไม่มีความหมาย เหตุที่การปลดคนเพิ่มขึ้นก็เพราะ AI ช่วยเพิ่มประสิทธิภาพ ถ้างานที่เคยต้องใช้คนหนึ่งคนทำ ถูก AI รับไปทำแทนได้ ปริมาณการจ้างก็ย่อมลดลง ไม่ใช่ความสัมพันธ์แบบคนหนึ่งคนเท่ากับ AI หนึ่งตัว แต่เป็นโครงสร้างที่ปริมาณงานไหลไปอยู่กับ AI จนจำนวนคนลดลง แม้การแทนที่มนุษย์จะยังไม่เสร็จสมบูรณ์ แต่จากนี้ไปคำถามว่าต้องใช้คนมากแค่ไหนจะกลายเป็นมาตรฐานใหม่ของอุปสงค์และอุปทาน คนที่มีความคิดสร้างสรรค์จะยังเป็นที่ต้องการเสมอ แต่คนแบบนั้นมีไม่พอ ในหมู่วิศวกรซอฟต์แวร์ที่อยากได้เงินเดือน 100,000 ถึง 200,000 ดอลลาร์ มีหลายคนที่ไม่รู้ด้วยซ้ำว่าตัวเองช่วยบริษัทประหยัดเงินได้เท่าไร ผมยังรู้สึกว่าการศึกษาในโรงเรียนฆ่าความคิดสร้างสรรค์ไป ปัญหาไม่ใช่ขาดความสามารถ แต่ขาดพลังในการกำหนดทิศทางเองหรือสร้างไอเดียขึ้นมา

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

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

• เรากำลังสร้างอนาคตนั้นอยู่ตอนนี้เอง สำหรับผม จุดที่เริ่มรู้สึกว่าไปได้เร็วจริง ๆ คือช่วงเมษายนถึงพฤษภาคม ตอนที่ agentic AI ดีพอแล้ว แค่วันนี้วันเดียวผมก็ทำเครื่องมือ CLI สำหรับ export iMessage archive ออกมาเป็นเว็บไซต์ และถ้าเป็นเมื่อก่อนงานแบบนี้คงกินเวลาหลายสัปดาห์ แต่ตอนนี้น่าจะทำเป็น homebrew formula ได้ภายในวันหรือสองวันด้วยซ้ำ แอป iOS ที่กำลังทำก็เดินหน้าเร็วกว่าเขียนมือมาก แม้ผมจะตั้งใจทำให้ช้าลงเองก็ตาม อนึ่ง ข้อมูลในโพสต์ต้นทางจบอยู่แค่ช่วงมีนาคมถึงเมษายน ซึ่งผมคิดว่าเป็นช่วงก่อนที่ generative AI จะเริ่มช่วยเรื่องการเขียนโค้ดได้อย่างมีนัยสำคัญ (ผมใช้ Copilot มาตั้งแต่พฤศจิกายน 2022)

  • ทุกครั้งที่มีข้อถกเถียงแบบนี้ ผมยังแปลกใจที่ได้ยินคำตอบเดิม ๆ ว่า “คุณยังไม่ได้ลอง AI ตัวล่าสุดสินะ รอบนี้มันดีจริงแล้วนะ”
  • ประสบการณ์ของผมก็แทบเหมือนกัน ผมขึ้นรถ hype AI ช้ากว่าคนอื่น แต่พอลองโมเดลและชุดเครื่องมือใหม่ ๆ ช่วงหลัง ความคิดก็เปลี่ยนไป รอบตัวผม บริษัทใหญ่เพิ่งเริ่มอนุญาตให้ใช้เครื่องมือพวกนี้ ดังนั้นผมคาดว่าข้อมูลผลิตภาพจริงจะมี lag อยู่พอสมควร และผลกระทบน่าจะค่อย ๆ ปรากฏทีหลัง ผมเองก็ยังเสียดายงานวิจัยของ METR และอยากเห็น meta-study ด้านผลิตภาพแบบนี้มากขึ้น
  • เห็นด้วย agentic AI เป็นเครื่องมือที่ต่างจาก AI แบบ “ดั้งเดิม” อย่างสิ้นเชิง อีก 1 ปีข้างหน้าผมอยากเห็นมากว่าข้อมูลและการทดลองของผู้เขียนจะออกมาเป็นอย่างไร
  • พอได้ยินคำว่า “ในที่สุด AI ก็เร็วพอแล้ว” ทั้งที่พูดถึงแค่เมื่อ 5 เดือนก่อน มันยิ่งทำให้รู้สึกว่าในโลก AI เวลา 5 เดือนเหมือนการเปลี่ยนแปลง 6 ปี

• ผมเคยเป็นนักพัฒนา full-time มาก่อน แล้วภายหลังทำงานเป็นผู้จัดการและ CTO จนค่อย ๆ ห่างจากงานพัฒนา พอลองกลับมาเขียนโค้ดอีกครั้ง การต้องเรียนรู้ framework, API, ภาษา และลูกเล่นยิบย่อยต่าง ๆ ใหม่ แม้เมื่อก่อนจะน่าสนุก แต่ตอนนี้กลับน่ารำคาญ แต่ด้วยเครื่องมืออย่าง Claude Code และประสบการณ์ด้านการออกแบบซอฟต์แวร์ ผมจึงกลับมาพัฒนาระบบใหญ่ ๆ แบบเมื่อก่อนได้อีกครั้ง ผลิตภาพของผมไม่ได้เพิ่ม 20% และไม่ได้เร็วขึ้น 10 เท่า มันทำให้ผมกลับไปทำสิ่งที่เดิมทีไม่คิดจะทำเลย ดังนั้นถ้าจะพูด ผมอยากเรียกมันว่าเป็นการเพิ่มผลิตภาพแบบอนันต์ ถ้าผมเป็นคนที่รักการพัฒนาและทำเก่งอยู่แล้ว เครื่องมือพวกนี้คงมีแต่ความน่ารำคาญ แต่สำหรับคนที่ปกติไม่ได้พัฒนา มันกลับตรงกันข้ามโดยสิ้นเชิง

  • ว้าว คุณกลับไปพัฒนาระบบใหญ่ ๆ ไม่ใช่แค่ครั้งเดียวแต่หลายครั้งเลย อยากให้แชร์กรณีตัวอย่างแบบละเอียดจัง
  • ทฤษฎีใหญ่ของผมเกี่ยวกับเครื่องมือเขียนโค้ดด้วย AI คือ มันไม่ได้ลดเวลาจริงลงมากนัก แต่ลดความน่าหงุดหงิดได้มหาศาล มันช่วยประหยัดความรำคาญที่ไม่จำเป็นจาก syntax, compiler และงานซ้ำ ๆ ทำให้เอาสมองไปใช้กับเรื่องสำคัญจริง ๆ ได้ ผลก็คือเรื่องที่เมื่อก่อนน่ารำคาญเกินกว่าจะทำ ตอนนี้กลับยอมทำ และก่อนเลิกงานก็อาจเลือกนั่งโต๊ะต่ออีกหลายชั่วโมงแทนที่จะออกไปเดินเล่น