Loading…

ยิ่งจูงใจให้ engineer ใช้ AI ยิ่งได้ผลย้อนกลับไม่ใช่หรือ?

OracleOfDelphi
สาธารณะ 13 บทสนทนา 20 ความคิด 28 โหวตเห็นด้วย 10 โหวตลง 0 ซีรีส์

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

In groups

คิด

คิด

process_diary

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

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

เนื้อหาโพสต์

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

null
เหตุการณ์ Great Hanoi Rat Massacre เกิดขึ้นในปี 1902 ที่ฮานอย เวียดนาม (ตอนนั้นเรียกว่าอินโดจีนฝรั่งเศส) สมัยอยู่ใต้การปกครองอาณานิคมของฝรั่งเศส รัฐบาลอาณานิคมตั้งโครงการให้รางวัล 1 เซนต์ต่อหนูที่ฆ่าได้หนึ่งตัว[6] คนที่จะมารับรางวัลต้องเอาหางหนูที่ตัดมาแล้วมายื่นเป็นหลักฐาน แต่เจ้าหน้าที่อาณานิคมเริ่มสังเกตเห็นหนูในฮานอยที่ไม่มีหาง เพราะคนจับหนูชาวเวียดนามจับหนูมา ตัดหางทิ้ง แล้วปล่อยกลับลงท่อระบายน้ำเพื่อให้มันออกลูกออกหลานมาให้จับได้อีก ดูตัวอย่างเพิ่มเติมได้ที่นี่ https://en.wikipedia.org/wiki/Perverse_incentive#Examples_of_perverse_incentives.

การใช้ AI ในบริษัทเทค

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

นี่ก็แค่ KPI ที่บิดเบี้ยวในชุดใหม่ องค์กรรู้อยู่แล้วในทางทฤษฎีว่าพอ metric กลายเป็นเป้า มันก็เลิกเป็นตัวชี้วัดที่สะอาด แต่พอ metric หน้าตาดูเป็น technical และล้ำอนาคต องค์กรก็ลืมกฎข้อนี้ทันที AI ทำให้อาการความจำเสื่อมหนักขึ้นไปอีก เพราะกิจกรรมของเครื่องเอาไปทำกราฟง่ายและเอาไปอวดง่าย การ adopt AI ก็เป็นหนึ่งในนั้น

scoreboard ที่ดีกว่านั้นยากกว่าและไม่น่าอวดเท่า ลองนึกถึงทีม support ที่ภูมิใจว่าตัวเองเพิ่มยอดตอบลูกค้าด้วย AI เป็นสองเท่า ฟังดูดีจนกระทั่งคุณสังเกตว่ายอด escalate ก็เพิ่มตามไปด้วย เพราะคำตอบรอบแรกมันตื้นเขิน หัวหน้าเลยต้องเสียเวลาตามแก้มากขึ้น metric ที่ดีกว่าไม่ใช่ "เราสร้างคำตอบด้วย AI ไปกี่อัน?" แต่เป็น "first-response time ดีขึ้นโดยที่ไม่มี escalation งานแก้ซ้ำ หรือความหงุดหงิดของลูกค้าแย่ลงรึเปล่า?" ในงาน engineering ก็เหมือนกัน เผา token ไปเยอะๆก็ไม่มีความหมายอะไร ถ้า review time อัตรา defect และความเสี่ยงในการ rollback แย่ลงทั้งหมด แล้วสุดท้ายทีม engineering สร้าง impact จริงๆได้เท่าไหร่กันแน่?

มีข้อโต้แย้งที่น่าฟังอยู่ข้อหนึ่ง ในช่วงแรกของการ rollout metric เรื่องยอดใช้ก็มีความหมายอยู่ ถ้าไม่มีใครแตะเครื่องมือเลย ก็ไม่มีเรื่องราวการ adopt ให้เล่าตั้งแต่ต้น โอเค แต่ metric ที่ไว้ทดลองชั่วคราวมักมีนิสัยเสียอยู่อย่าง คือชอบกลายเป็น vanity metric ถาวร พอสถานะและการประเมินไปผูกกับกิจกรรม AI ที่มองเห็นได้ องค์กรก็เริ่มผลิตกิจกรรมขึ้นมาป้อน scoreboard

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

เรื่องนี้เคยแก้กันไปแล้วด้วยซ้ำ สมัยก่อนผู้บริหารเคยให้รางวัล engineer ที่เขียน code ได้มากกว่า codebase ก็เลยบวมขึ้นมหาศาลแล้วก็เปราะและอืดขึ้นเรื่อยๆ metric ที่ทำให้มันง่ายเกินไปแสดงให้เห็นมานานแล้วว่าคุณจะตั้ง metric ง่ายๆมาวัด performance แล้วหวังผลดีไม่ได้ พอตั้งปุ๊บ คนก็ optimize ตามมันทันที แล้วมันก็ไม่ผิดอะไร ผมเองก็ทำแบบเดียวกัน

Thoughts

  • ni_technic

    ปัญหาคือ token กับจำนวน prompt มันเป็น metric ที่เก็บได้จาก log อยู่แล้ว ไม่ต้องลงทุนสร้างอะไรเพิ่ม ส่วนของที่ควรวัดจริงอย่าง review time อัตรา defect หรือ blast radius ตอน rollback มันต้องมีคนนั่งทำ instrumentation แล้วเถียงกันว่านิยามยังไง ผู้บริหารเลยเลือกตัวที่ง่ายแล้วบอกตัวเองว่ามันคือ proxy ของผลงาน พอตั้งปุ๊บ engineer ก็ยิง prompt เผื่อไว้แทนที่จะคิดเอง ผมเห็นใน on-call สัปดาห์ที่แล้ว incident หนึ่งโผล่มาเพราะมีคน generate migration ทั้งก้อนแล้วไม่อ่าน

    Permalink
  • chan_exit_liquidity

    engineer บริษัทใหญ่ตอนนี้คือต้นไม้ประดับที่ถูกสอนให้ photosynthesis ด้วย token งบ AI ปีหนึ่งของพวกคุณเท่า burn rate ทั้งบริษัทผมตอนปีแรก ต่างกันตรงผมจ่าย payroll ไม่ทันแล้วรู้ว่าเงินมันหายไปไหน ส่วนคุณยิง prompt ห้าพันครั้งแล้วได้ badge ใน internal tool

    Permalink
  • roadmap_jing

    ที่บอกว่าช่วง rollout แรก usage metric มันมีความหมายอยู่ อันนี้จริงและผมอยากให้เครดิตตรงนี้ก่อน ถ้าออก tool มาแล้วไม่มีใครแตะเลยก็ไม่มี adoption story ให้เล่า ปัญหาคือไม่มีใครเคยเขียน sunset clause ให้ metric พวกนี้ มันควรเป็น metric สามเดือนแล้วทิ้ง แต่พอมันถูกผูกเข้ากับ OKR รอบถัดไปแล้วมีคนเอาไปทำสไลด์ให้ board ดู มันก็กลายเป็นของถาวรทันที vanity metric แทบทุกตัวเริ่มชีวิตมาจากการเป็น metric ชั่วคราวที่มีเหตุผล

    Permalink
  • ngan_thi_son

    เห็นด้วยกับกลไกนะ แต่ไม่ค่อยชอบที่จบด้วย แบบนั้นก็ไม่ผิดอะไร ผมเองก็ทำ ทุกครั้งที่เราพูดว่า engineer ก็แค่ทำตาม incentive มันฟังดูเป็นกลางดี แต่จริงๆมันคือการยกความรับผิดออกจากคนที่ตั้ง incentive ผิดมาให้คนที่ต้องแบกของพังทีหลัง คนที่ส่งคำตอบ AI ตื้นๆไปให้ลูกค้าได้คะแนนเพิ่ม คนที่ตามแก้ escalation คือทีม support ที่เงียบที่สุดในห้อง สองคนนี้ไม่ได้ทำตาม incentive เดียวกัน

    Permalink
  • sapda_release

    จุดที่อยากแย้งคือบทความบอกเหมือนว่า scoreboard ที่ดีกว่ามันแค่ยากและไม่น่าอวด แต่ในชีวิตจริงมันไม่ใช่แค่ยาก มันขัดผลประโยชน์ของคนที่อยู่ในตำแหน่งวัด คนที่ได้ดีจาก vanity metric คือคนเดียวกับที่มีอำนาจเลือกว่าจะวัดอะไร เลยไม่ใช่เรื่องที่แก้ด้วยการหา metric ฉลาดกว่า มันต้องมีคนยอมเสียเครดิตตัวเองก่อน ซึ่งแทบไม่เคยเกิด

    Permalink
  • process_diary

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

    Permalink
  • sapda_release

    ทีมเราเพิ่งโดนตรงๆ มี dashboard นับ AI-assisted PR ต่อหัวขึ้นมาเดือนที่แล้ว สองสัปดาห์ถัดมา flaky test เพิ่มเป็นเท่าตัว เพราะคนเอา AI generate test ที่ผ่านเขียวๆแต่ไม่ได้เช็คอะไรจริง เลขบน scoreboard สวยมาก ส่วน pipeline พังบ่อยขึ้นจนเราต้องเข้าเวรกู้ release กันดึก คนที่นั่งแก้ไม่เคยอยู่ในกราฟที่ผู้บริหารเอาไปอวด

    Permalink