จำนวนบรรทัดโค้ดได้คนประชาสัมพันธ์ที่เก่งกว่าเดิม

• การประเมินประสิทธิภาพของนักพัฒนาควรวัดจาก ตัวชี้วัดผลลัพธ์ เช่น คุณค่าที่ส่งมอบให้ลูกค้า รายได้ และความน่าเชื่อถือ มากกว่าปริมาณโค้ด
• ตัวเลขประชาสัมพันธ์ AI coding ล่าสุดจาก Google, Anthropic, OpenAI และ Cursor ต่างโฟกัสที่ข้ออ้างเชิงปริมาณ เช่น สัดส่วนโค้ดที่สร้างโดย AI หรือจำนวนบรรทัดโค้ด
• คำกล่าวอ้างในอดีตของ GitHub Copilot ว่าช่วยเพิ่มความเร็วในการทำงาน 55% เป็นผลลัพธ์ที่ตรวจสอบได้ แต่ “สัดส่วนโค้ดที่ AI เขียน” สามารถเพิ่มขึ้นได้โดยไม่เกี่ยวกับว่าดีขึ้นจริงหรือไม่
• งานวิจัยจริงให้ผลคละกัน ตั้งแต่ Cui et al. ที่พบอัตรางานเสร็จเพิ่ม +26% ไปจนถึง METR ที่บอกว่า "ช้าลง 19%" ก่อนกลับลำภายหลัง และผลสำรวจที่พบว่า 90% ของบริษัทวัดผลไม่เจอว่าได้ประโยชน์ ทำให้ ผลในระดับองค์กรอยู่ราว 10%
• การนำ AI มาใช้เป็นสิ่งจำเป็น แต่การวัดผลควรอิงเกณฑ์ที่พิสูจน์แล้ว เช่น ตัวชี้วัด DORA, ความน่าเชื่อถือ, ความเร็วของการเปลี่ยนแปลงที่มีความหมาย, รายได้ และคุณค่าต่อลูกค้า

---

การหวนกลับมาของตัวชี้วัดจำนวนบรรทัดโค้ด

• เมื่อ 15 ปีก่อน ต่อให้ในบริษัท SaaS มีนักพัฒนาอาวุโสคนหนึ่งเขียนโค้ด มากกว่าอีกคน 40% ก็ไม่ได้แปลว่าเขาเป็นนักพัฒนาที่เก่งกว่า
  • สิ่งที่สำคัญจริง ๆ คือมีอะไรถูก ปล่อยขึ้นใช้งานจริง (ship) และสิ่งนั้นช่วยลูกค้า รายได้ และเสถียรภาพอย่างไร ขณะที่จำนวนบรรทัดโค้ดและจำนวน PR ถูกเรียนรู้มาหลายสิบปีแล้วว่าเป็นวิธีวัดที่แย่
• ตัวเลขเด่นที่อุตสาหกรรมหยิบมาใช้ในปี 2026 ล้วนโฟกัสที่ สัดส่วนโค้ดที่ AI เขียน
  • Google: 75% ของโค้ดใหม่ถูกสร้างโดย AI
  • Anthropic: ประมาณ 80% ของโค้ดโปรดักชันที่ถูก merge เขียนโดย Claude และวิศวกรปล่อย "โค้ดได้มากขึ้น 8 เท่า" ต่อไตรมาส
  • OpenAI: ประมาณ 80% เช่นกัน
  • Cursor: “เขียนโค้ดระดับองค์กรมากกว่า 100 ล้านบรรทัดต่อวัน”
• ตัวเลขเหล่านี้ทั้งหมดเป็นข้ออ้างเชิง ปริมาณ (volume) และ "สัดส่วนโค้ดที่ AI เขียน" ก็เป็นเพียง จำนวนบรรทัดโค้ดที่ได้สโลแกนประชาสัมพันธ์ที่ดูหรูขึ้น
  • และเพราะทุกบริษัทเหล่านี้ล้วนเป็น ผู้ขาย AI การทำให้ตัวเลขการนำไปใช้ดูสูงจึงเป็นแรงจูงใจสำคัญ

ในอดีตเคยอ้างเรื่องผลลัพธ์

• เมื่อไม่กี่ปีก่อน ตัวเลขหลักไม่ได้ต่างกันแค่ขนาด แต่ต่างกันตั้งแต่ประเภท
  • ข้ออ้างเด่นของ GitHub คือเมื่อใช้ Copilot จะ ทำงานเสร็จเร็วขึ้น 55%
  • แม้จะมีเสียงวิจารณ์มาก แต่นี่คือข้ออ้างเรื่อง ผลลัพธ์ (outcome) ที่ชัด กล้าพูด และหักล้างได้ เป็นเรื่องของคุณค่า — ถ้าผิดก็พิสูจน์ได้ว่าผิด
• ข้ออ้างในปี 2026 ถูกสร้างมาให้แพ้ไม่ได้
  • "75% ของโค้ดเขียนโดย AI" อาจเป็นความจริงและเพิ่มขึ้นเรื่อย ๆ ได้ โดยไม่เกี่ยวเลยว่าจะปล่อยงานได้เร็วขึ้น ลดเหตุขัดข้อง หรือทำให้ลูกค้าพอใจขึ้นจริงหรือไม่
  • ตัวเลขเชิงปริมาณจะทำให้ผิดหวังก็แค่ตอนที่ การนำไปใช้หยุดโต เท่านั้น และคนส่วนใหญ่ก็เห็นตรงกันอยู่แล้วว่ามีการนำไปใช้จริง
• ข้ออ้างใหญ่ขึ้น แต่สิ่งที่มันสื่อกลับน้อยลง

สิ่งที่ไม่ขึ้นไปอยู่บนป้ายโฆษณา

• สิ่งที่เกิดขึ้นระหว่างนั้นคือ หลักฐานด้านผลลัพธ์ซับซ้อนขึ้น

• ผลลัพธ์ที่สนับสนุนการนำไปใช้

  • Cui et al.: จากนักพัฒนาราว 5,000 คน พบว่า งานที่ทำเสร็จเพิ่มขึ้น 26% โดยเฉพาะนักพัฒนาจูเนียร์ที่ดีขึ้นมากที่สุด — แทบไม่มีข้อกังขา

• หลักฐานในทางตรงข้าม

  • GitClear: ยิ่งใช้ Copilot มากขึ้น code churn ก็ยิ่งเพิ่มขึ้น และการรีแฟกเตอร์ก็พังลง
  • METR: นักพัฒนาโอเพนซอร์สที่มีประสบการณ์ เมื่อใช้ AI กับโค้ดเบสของตัวเองกลับ ช้าลง 19% แต่เจ้าตัวเชื่อว่าตัวเองเร็วขึ้น 20%

• การกลับลำของ METR

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

• ผลในระดับบริษัท

  • ผลสำรวจผู้บริหารราว 6,000 คนของ NBER: 69% ของบริษัทใช้ AI อยู่แล้ว แต่เกือบ 9 ใน 10 รายงานว่ายังไม่พบผลด้านประสิทธิภาพที่วัดได้
  • ข้อสรุปร่วมข้ามงานวิจัยคือ ดีขึ้นระดับองค์กรประมาณ 10% — มีประโยชน์ แต่ยังไม่ถึงขั้น "ไม่ต้องมีนักพัฒนาแล้ว"
• คนที่ยังหยิบเฉพาะผล "ช้าลง 19%" มาอ้างก็เป็นการเลือกข้อมูลเข้าข้างตัวเองเช่นกัน เพราะงานวิจัยยังอัปเดตต่อเนื่อง ขณะที่อุตสาหกรรมเปลี่ยนสิ่งที่เลือกวัด

ตัวชี้วัดหลอกตัวเองฉบับ AI

• ปัญหานี้ไม่ได้มีแค่คำกล่าวอ้างจากผู้ขาย AI

• โมเดลความเป็นผู้ใหญ่และบันไดขั้น

  • Carnegie Mellon SEI และ Accenture เพิ่งเปิดตัว AI Adoption Maturity Model — มี 5 ระดับ 8 มิติ และเอาสถิติที่ว่า "95% ขององค์กรยังไม่ทำกำไร" มาใช้ทำการตลาด
  • "8 levels of AI-assisted development" ของ Steve Yegge จัดอันดับตามว่าใช้เครื่องมืออะไรและต้องคุมดูแลมากแค่ไหน
  • ผู้ขายเครื่องมือทุกรายต่างออกบันไดวัดความเป็นผู้ใหญ่ และขั้นสูงสุดก็มักหมายถึง "ใช้สินค้าของตัวเองให้มากขึ้น"
  • บันไดเหล่านี้คือการวัด ความเข้มข้นของการนำไปใช้ แล้วเรียกมันว่าความเป็นผู้ใหญ่ เป็นของแทนแบบเดิมที่แค่เปลี่ยนแพ็กเกจ

• ความสับสนด้านนิยาม

  • เมื่อ Augment ถามผู้นำวิศวกรรม 219 คนว่า "AI-native engineering" คืออะไร ก็ได้ คำตอบต่างกัน 219 แบบ

• สองด้านของ Anthropic

  • ด้านหนึ่งอ้างว่า "ปล่อยโค้ดได้มากขึ้น 8 เท่า" แต่อีกด้านก็เผยงานวิจัยที่เข้มงวดที่สุดชิ้นหนึ่งของปีนี้
  • ผล RCT พบว่านักพัฒนาที่มี AI ช่วยได้คะแนน ความเข้าใจโค้ดที่เพิ่งปล่อยต่ำลง 17% และไม่พบการเพิ่มขึ้นของประสิทธิภาพที่มีนัยสำคัญทางสถิติ
  • หน่วยวิจัยปรับข้อมูลตามหลักฐานล่าสุด ขณะที่ฝ่ายการตลาดยังนับปริมาณโค้ด — และทั้งสองอย่างนี้ก็จริงพร้อมกันได้

เหตุผลที่ต้องใส่ใจกับปัญหานี้

• ตัวเลขเหล่านี้ไม่ใช่ของประดับ แต่มีผลต่อ งบประมาณ ความคาดหวังด้านผลงาน และแผนกำลังคน

• การปลดคนโดยอ้าง AI

  • เดือนกุมภาพันธ์ Jack Dorsey ลดพนักงานของ Block ไป มากกว่า 40% (4,000 คนขึ้นไป) โดยชู AI เป็นเหตุผลหลักอย่างชัดเจน — "ทีมที่เล็กกว่าสามารถทำได้มากกว่าและดีกว่าเดิมด้วยเครื่องมือที่เราสร้าง"
  • ไม่กี่สัปดาห์ต่อมา Atlassian ลดพนักงาน 10% (ราว 1,600 คน) พร้อมยอมรับว่า "ถ้าจะแกล้งทำเป็นว่า AI ไม่เปลี่ยนชุดทักษะที่ต้องใช้หรือจำนวนบทบาทที่ต้องมี ก็คงไม่ซื่อสัตย์"
  • ในประกาศเดียวกัน Dorsey ยังบอกด้วยว่าธุรกิจยังแข็งแรงและ กำไรขั้นต้นกำลังเติบโต

• คำถามต่อข้ออ้างเรื่องประสิทธิภาพ

  • ถ้า "AI ทำให้ทุกคนมีประสิทธิภาพมากขึ้นจนต้องใช้คนน้อยลง" ก็อยากเห็นหลักฐานนั้น แต่ตอนนี้ยังมองว่าไม่มี
  • ต้องพิสูจน์ให้ได้ว่าคนบางส่วนว่างงานจริงหรือถูกใช้ไม่เต็มที่ และสำหรับธุรกิจผลิตภัณฑ์/SaaS ที่มีโรดแมปไม่มีวันหมด กำลังที่เพิ่มขึ้นก็ควรถูกเอาไปใช้กับ คุณค่าต่อลูกค้าและความเร็ว — ซึ่งควรสะท้อนใน MAU, conversion และรายได้
  • การเลือกปลดคนจึงเป็นสัญญาณว่าข้ออ้างเรื่องประสิทธิภาพกำลังทำหน้าที่เป็น PR ให้กับการตัดสินใจที่อาจถูกกำหนดไว้แล้วด้วยเหตุผลอื่น เช่น การจ้างเกินหรือแรงกดดันจากนักลงทุน
• บางครั้งการลดคนเพราะต้องการเพิ่มประสิทธิภาพก็สมเหตุสมผลได้ แต่ถ้าเป็นแบบนั้น ควรใช้ ระบบประเมินผลงานรายบุคคล ที่มีอยู่แล้วในการดำเนินงาน ไม่ใช่จำนวนโทเค็น "สัดส่วนโค้ดที่ AI เขียน" หรือคะแนนบนบันไดความเป็นผู้ใหญ่
  • ถ้าเหตุผลในการคัดเลือกอิงกับตัวชี้วัดหลอกตัวเอง การคัดเลือกนั้นก็ไม่ต่างจาก "ลอตเตอรี่ที่ทาลิปสติก"

บทสรุป

• ไม่ได้ต่อต้าน AI และเห็นว่าทุกวิศวกร ควรใช้ AI ทุกวัน
  • จะเรียก AI-first หรือ AI-proficient ก็ตาม สิ่งสำคัญคือการลองใช้เครื่องมือใหม่และโมเดลล่าสุดด้วยความอยากรู้อยากเห็น
  • อุตสาหกรรมนี้รับเอาภาษาโปรแกรมระดับสูง, IDE, ระบบเติมโค้ดอัตโนมัติ, agile และ devops มาโดยตลอด และทุกครั้งก็มักมีคนที่โหยหาอดีตอยู่ก่อนจะเข้าร่วมในที่สุด
  • สิ่งที่ต่างออกไปครั้งนี้คือ ความเร็ว — การนำ "คลาวด์" มาใช้ ต่อให้เลื่อนไปหลายปีก็ยังอยู่รอดได้ แต่กับ AI อาจมีเวลาแค่ไม่กี่เดือน
• การนำ AI มาใช้คือ เส้นออกตัว ไม่ใช่กระดานคะแนน
  • เรารู้วิธีวัดผลด้านวิศวกรรมกันอยู่แล้ว — ตัวชี้วัด DORA, ความน่าเชื่อถือ, สัดส่วนของการเปลี่ยนแปลงที่มีความหมาย และท้ายที่สุดคือรายได้กับคุณค่าต่อลูกค้า
  • ไม่มีเหตุผลให้ทิ้งวิธีที่พิสูจน์แล้ว แล้วหันไปใช้คะแนนหลอกตัวเองแบบ AI
• คำถามที่ควรถามเวลาเจอ vendor pitch, executive review หรือฟีด LinkedIn คือ: "นั่นคือ ผลลัพธ์ หรือปริมาณ?"
• วิธีทำงานควรเป็น AI-first แต่วิธีวัดผลควรเป็นแบบที่ผ่านการพิสูจน์มาแล้ว (battle-tested)

[GN⁺]

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

• กระแสประหลาดนี้ดูเหมือนจะถึงจุดพีคในโพสต์บล็อกของ OpenAI เมื่อเดือนกุมภาพันธ์ 2026 [1] นี่คือโพสต์ล่าสุดที่ขึ้นหน้าแรก [2] ซึ่งพูดถึงกระบวนการสร้างบางสิ่งที่เอเจนต์เขียนให้ 100%
  แต่กลับไม่ได้อธิบายเลยว่าสิ่งนั้นคืออะไร หรือให้คุณค่าอะไรกับผู้ใช้ คำอธิบายที่ใกล้เคียงที่สุดคือ “ผลิตภัณฑ์นี้มีคนใช้ภายในหลายร้อยคน และยังมี power user ภายในที่ใช้งานทุกวัน” เท่านั้น
  แต่ข้อเท็จจริงว่าเป็น โค้ด 1 ล้านบรรทัด กลับถูกย้ำถึงสองครั้งภายในไม่กี่ร้อยคำแรก
  [1] https://openai.com/index/harness-engineering/
  [2] https://news.ycombinator.com/item?id=48416264

  • ถ้า “ผลิตภัณฑ์นี้มีคนใช้ภายในหลายร้อยคน และยังมี power user ภายในที่ใช้งานทุกวัน” ก็น่าจะเป็น ตัวกรองอีเมล
    ถ้าเป็น “โค้ด 1 ล้านบรรทัด” และ “เอเจนต์เขียน 100%” ก็ยิ่งฟังดูใช่ หรือไม่ก็อาจเป็นเมนู JS สำหรับวิกิของแผนก ที่จริงแล้วคือการทำ jquery ขึ้นใหม่ด้วย MS JScript แล้วแปลงกลับเป็น JS 5
  • ทั้ง Linux kernel มีอยู่ราว 40 ล้านบรรทัด และถ้าไม่นับไดรเวอร์ก็ประมาณ 16 ล้านบรรทัด การที่ของบางอย่างที่ OpenAI พูดถึงมีจำนวนบรรทัดโค้ดเท่ากับ 6% ของ Linux kernel ก็ยากจะจินตนาการได้ว่าประโยชน์ใช้สอยจะเข้าใกล้ 6% ด้วย
    ต่อให้ LLM จะทรงพลังแค่ไหน มันก็ดูแทบจะไม่มีทางบำรุงรักษาได้เลย
  • สนามบิดเบือนความจริง รอบ ๆ Anthropic ก็แรงไม่แพ้กัน Anthropic ก็ลงโพสต์บล็อกเหลวไหลที่เหมือน AI เขียนทั้งดุ้นและไม่ได้พูดอะไรเลยเป็นกอง ๆ แต่ก็ยังขึ้นหน้าแรกและได้หลายร้อยอัปโหวตอย่างสม่ำเสมอ
  • นี่ไม่ใช่อันนี้เหรอ?
    https://github.com/openai/symphony
  • ผิดหวังที่มีรายละเอียดน้อยเกินไป เลยคิดว่าอีกไม่นานน่าจะมี โปรเจกต์โอเพนซอร์ส หรือความพยายามบางอย่างที่แสดงให้เห็นว่าสิ่งพวกนี้มีประสิทธิภาพจริงแค่ไหน
    ในบทสัมภาษณ์พอดแคสต์เขาบอกว่าเป็นแอป Electron ที่ผู้ใช้ดาวน์โหลดไปใช้ จึงต้องสร้างบิลด์ใหม่เป็นระยะ ๆ ดูส่วน “Autonomous Merging Flow” ที่นี่: https://www.latent.space/p/harness-eng

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

  • ฉันเคยทำงานในบริษัทที่มีข้อกำหนด code coverage 80% มาก่อน มีผู้รับจ้างคนหนึ่งที่ฉลาดมาก มีสคริปต์สร้างไฟล์เดียวที่ปรับขนาดได้พร้อม test suite ของมันเอง เพื่อดันให้ทั้งโค้ดเบสรวมกันแตะ 80%
    ในความเป็นจริง โค้ดส่วนใหญ่แทบไม่ได้ถูกทดสอบเลย
  • 1,000,000 / 25 / 8 / 60 = มากกว่า 83 บรรทัดต่อนาที
    1 ล้านบรรทัดต่อเดือน / 25 วันทำงานต่อเดือน / 8 ชั่วโมงต่อวัน / 60 นาทีต่อชั่วโมง
    สำหรับคนที่ต้อง รีวิวโค้ด มันดูเป็นปัญหาใหญ่พอสมควร
  • ตลกมากที่เห็นผู้บริหารจู่ ๆ ก็ตระหนักว่าโทเคน มีต้นทุนเป็นเงินจริง แล้วรีบแก้แนวทางการใช้ AI ของพนักงานทันที
    การทำให้วิศวกรแต่ละคนสร้างโค้ด 1 ล้านบรรทัดต่อเดือน โดยไม่คิดว่าบรรทัดเหล่านั้นจะทำเงินให้บริษัทอย่างไร หรือระหว่างทางจะเผาโทเคนไปกี่มากน้อยด้วยต้นทุนเท่าไร ก็ดูจะไม่ใช่แผนที่ผ่านการไตร่ตรองมาดีนัก
  • คำว่า slop เป็นคำที่เลือกมาได้ดีมากเวลาใช้พูดถึงโค้ดที่ AI สร้างออกมาปริมาณมหาศาล มันสื่อถึงความน่าขยะแขยงได้ดีและแม้แต่คนที่ไม่ใช่สายเทคนิคก็เข้าใจได้ ชัดเจนว่า slop คือสิ่งที่ควรหลีกเลี่ยง
    ตรงกันข้าม หนี้ทางเทคนิค ไม่เคยจับความสนใจของผู้บริหารได้ในแบบเดียวกัน หนี้เป็นสิ่งที่โดยทั่วไปอาจกลายเป็นปัญหาได้ แต่จนกว่าจะเป็นปัญหาจริง ก็มักถูกมองว่ายังไม่จำเป็นต้องหลีกเลี่ยงหรือจัดการ จึงถูกเลื่อนออกไปเรื่อย ๆ
  • ฉันสงสัยว่าที่ความคลั่งเรื่องการผลิตบรรทัดโค้ดที่บำรุงรักษาไม่ได้เริ่มลดลงในช่วงไม่กี่เดือนที่ผ่านมา อาจเป็นเพราะคนฝั่งธุรกิจและผลิตภัณฑ์เริ่มลองเอา AI เข้าไปใช้ในงานประจำจริง ๆ ด้วยหรือเปล่า
    ฉันเห็นแบบนี้ในบริษัทเล็กสองแห่งที่ฉันทำงานอยู่ ทั้งสองที่ได้ Claude Cowork มาเมื่อไม่กี่เดือนก่อน ทุกคนตื่นเต้นกันมากและยังใช้อยู่ทุกวัน แต่เมื่อเทียบกับเวทมนตร์ที่คาดหวังไว้ หลายคนก็ค่อนข้างผิดหวัง
    มีคำบ่นว่าผลลัพธ์ออกมาธรรมดา เยิ่นเย้อ ผิดแม้แต่เรื่องพื้นฐานมาก ๆ ชนลิมิตโทเคนตลอด และหลายครั้งทำเองเร็วกว่าเลยกลับไปทำมือ
    ตอนแรกอาจเป็นเพราะยังใช้เครื่องมือไม่เก่งด้วย แต่ผู้คนกำลังเริ่มตระหนักแล้วว่ายังมีช่องว่างระหว่างสิ่งที่ CEO สาย AI, พ่อค้า LinkedIn และคนขายอาหารเสริม AI บน YouTube พูด กับความเป็นจริง

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

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

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

  • คนที่ไม่ใช่สายเทคนิคกำลังกุมอำนาจ และไม่ได้ถูกผูกไว้กับความเป็นจริงแบบวิศวกร ท้ายที่สุดแล้ว ความเป็นจริงเชิงภววิสัย จะชนะ แต่ในระยะสั้นก็ไม่ได้ช่วยป้องกันความเสียหาย
  • เราอธิบายกันมาหลายทศวรรษจริงหรือว่าผลิตภาพวัดได้ไม่ง่าย? ตลอด 10 ปีที่ผ่านมา สิ่งที่ฉันเห็นมีแค่วิศวกรและคนที่ไม่ใช่วิศวกรต่างก็ยิ่งบูชา กราฟกิจกรรม Github มากขึ้นเรื่อย ๆ ในความเห็นฉัน ตลาดนัดนี้หลงทางมาตั้งแต่ก่อน AI แล้ว
  • กลุ่มวิศวกรซอฟต์แวร์บางส่วนอาจช่วยปลูกฝังความจำเป็นของการวัดอย่างรอบคอบ แต่ถ้ามองทั้งวงการโปรแกรมมิ่งโดยรวม มันไม่เคยหลุดพ้นจากความคิดเรื่องตัวชี้วัดง่าย ๆ เลย
    ก็เพราะมีหัวหน้าประเภทมีส่วนร่วมห่าง ๆ แต่ก้าวร้าวและเรียกร้องมากอยู่เสมอ สำหรับหัวหน้าที่หน้าที่หลักคือเค้นแรงพนักงานให้มากขึ้น โดยแทบไม่ช่วยด้านการประสานงานหรือเรื่องอื่น ๆ เลย ก็ยังน่าเศร้าที่มีมูลค่าทางเศรษฐกิจอยู่
    เพราะงั้นจึงมีกลุ่มเมฆของสองแนวทางที่ซ้อนทับกันอยู่เสมอ ระหว่างผลงานจริงกับการวัดแบบจำนวนบรรทัดโค้ด
    AI มอบเครื่องมือครบชุดที่จะทำให้หัวหน้าประเภทมีส่วนร่วมน้อยแต่เรียกร้องมากพอใจได้ ดังนั้นจากนี้ไปคนที่ชอบใช้จำนวนบรรทัดโค้ดและการเพิ่มฟีเจอร์เป็นตัวชี้วัดก็คงยิ่งมีมากขึ้น เพราะตอนนี้มันทำได้ง่ายแล้ว
  • ทั้งหมดนี้ก็เหมือนทำไปเพื่อผลักดัน เครื่อง slop ให้เดินหน้า เพื่อให้ชนชั้นมหาเศรษฐีสามารถผลักผู้คนออกไปอยู่ข้างถนนได้

• ถ้านักพัฒนาระดับซีเนียร์เกรด A+ ใช้เวลา 8 เดือนสร้างฟีเจอร์ แต่สุดท้ายไม่ได้ปล่อยจริงหรือ MVP ถูกทิ้งไป เท่ากับว่านักพัฒนา A+ คนนั้นถูกใช้ไปอย่างสูญเปล่า และผลิตภาพก็จะเท่ากับวิศวกรระดับ B+ สองคนที่ร่วมอยู่ในโปรเจกต์เดียวกัน
  นี่เป็นปัญหาที่เกิดขึ้นจริงบ่อยมาก แต่ในการจ้างงานหรือการจัดสรรทรัพยากรโปรเจกต์มักถูกมองข้าม AI คงไม่เปลี่ยนเรื่องนี้อย่างมีนัยสำคัญ
  ทีมอาจทำงานเสร็จได้เร็วขึ้นมาก แต่ ลำดับชั้นราชการแบบ官僚 ข้างบนมีแนวโน้มว่าจะยังเหมือนเดิม และถ้าเป็นแบบนั้น ประโยชน์ที่ได้จาก AI coding ก็จะน้อยมาก ถ้าจะให้เข้ากับ AI จริง ๆ บริษัทต้องถูกสร้างใหม่ตั้งแต่บนลงล่าง ซึ่งแทบจะไม่เกิดขึ้น

  • วิศวกรมักมองสิ่งแบบนี้ว่าเป็น ความสูญเปล่า มากเกินไป ที่ลงทุนไปนั้นไม่ใช่ความสูญเปล่า แต่เป็นการจ่ายเพื่อให้ได้ทางเลือกว่าจะปล่อยฟีเจอร์หรือ MVP นั้นหรือไม่ และเป็นค่าใช้จ่ายของการวิจัยเพื่อหาว่าควรปล่อยหรือเปล่า
  • แน่ใจหรือว่า 8 เดือนนั้นถูกใช้ไปกับ “การเขียนโค้ด” ล้วน ๆ? ยังมีงานออกแบบ ข้อมูลจากทีมผลิตภัณฑ์ งานทำซ้ำ ฯลฯ อีก ฉันไม่รู้เหมือนกันว่าไปเห็นภาพวิศวกรระดับ A+ เดินเข้าไปนั่งในคอกคนเดียว แล้วอีก X เดือนค่อยโผล่ออกมาพร้อม MVP แบบแยกตัวโดดเดี่ยวมาจากไหน

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

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

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

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

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

  • เพราะแรงงานถูกเอาเปรียบเพื่อทำให้เจ้าของร่ำรวยขึ้น นั่นคือข้อเท็จจริงพื้นฐาน และชนชั้นเจ้าของก็ทุ่มเงินกับโฆษณาชวนเชื่อมากมายเพื่อทำให้เรื่องนี้ดูชอบธรรมและปกปิดมัน
  • หรือจริง ๆ แล้วที่หมายถึงไม่ใช่ “ผลิตภาพเท่าเดิม” แต่เป็นคนที่น้อยลงสำหรับ ผลผลิตเท่าเดิม? ตามนิยามแล้ว แบบนั้นย่อมหมายความว่าผลิตภาพของบริษัทสูงขึ้น
    เพราะผลิตภาพในระดับบริษัทหรือระดับประเทศคืออัตราส่วนระหว่างผลผลิตกับปัจจัยนำเข้า
    ถ้าได้ผลผลิตเท่าเดิมด้วยคนน้อยลง ก็แปลว่าผลิตภาพของบริษัทหรือประเทศดีขึ้น
    ถ้าคนน้อยลงแต่ผลิตภาพเท่าเดิม ผลผลิตก็ต้องลดลงตามไปด้วย ดังนั้นบริษัทไม่ได้ประโยชน์อะไร และถ้ามีต้นทุนคงที่ก็อาจแย่ลงด้วยซ้ำ
    https://www.mckinsey.com/featured-insights/mckinsey-explaine...

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

• ผมคิดว่าวิศวกรอย่างพวกเราต้องรับผิดชอบไม่น้อยที่จำนวนบรรทัดโค้ดยังถูกมองเป็นสินทรัพย์แทนที่จะเป็นหนี้สิน เราภูมิใจกับสิ่งที่เราสร้างขึ้น แต่พอจะอธิบายว่าบางอย่าง “ใหญ่” แค่ไหน ก็ต้องมีตัวชี้วัด และสุดท้ายก็มักย้อนกลับไปหาตัวชี้วัดที่นับง่ายที่สุด
  เราต้องเปลี่ยนคำพูด โดยเฉพาะควรพูดให้บ่อยขึ้นว่า “...และต้นทุนของมันคือโค้ด N บรรทัด” และควรบอกด้วยว่าใช้โค้ดเหล่านั้นไปกับอะไร
  “เราเพิ่มฟีเจอร์ใหม่ X ได้ โดยใช้แค่ 200 บรรทัดเท่านั้น”
  “บั๊กนั้นหาเจอยากมาก แต่สุดท้ายใช้โค้ดแค่ 6 บรรทัด”
  “ในกรณี X เราทำอย่างหนึ่ง แต่ในกรณี Y เราไม่ทำแบบนั้น แล้วก็พบว่าการแยกความต่างนั้นจริง ๆ ไม่จำเป็นเลย ดังนั้นตอนแก้ปัญหาจึงประหยัดโค้ดไปได้ 20 บรรทัดพร้อมกัน”
  จำนวนบรรทัดโค้ดคือราคาที่เราต้องจ่าย เราไม่เคยอวดว่าใช้เงินไป 200 ดอลลาร์โดยไม่บอกว่าซื้ออะไรมา แล้วทำไมกับจำนวนบรรทัดโค้ดเราถึงทำแบบนั้น?
  “เพราะสมัครช้าเลยต้องจ่ายเพิ่มอีก 200 ดอลลาร์” กับ “ฉันซื้อโคมแขวนเซรามิกทำมือเพนต์มือจากช่างฝีมือมาได้ในราคาแค่ 200 ดอลลาร์ ของโรงงานจาก Amazon ราคาเกิน 1,200 ดอลลาร์” เป็นคนละเรื่องกันโดยสิ้นเชิง และในเรื่องโค้ดก็มีความต่างแบบเดียวกันอย่างแม่นยำ