พนักงาน Amazon กำลังสร้างงานขึ้นมาเองท่ามกลางแรงกดดันให้ใช้ AI
(fastcompany.com)- พนักงาน Amazon ถูกกดดันให้ใส่ AI ลงในงานมากขึ้น แต่จุดที่จะนำไปใช้กลับไม่ชัดเจน จนเกิดงานที่ไม่จำเป็น
- พนักงานบางส่วนใช้เครื่องมือภายใน MeshClaw เพื่อสร้างเอเจนต์ที่เพิ่มปริมาณกิจกรรม AI มากกว่าช่วยเพิ่มประสิทธิภาพการทำงาน
- พนักงานมองว่าการติดตาม การใช้โทเค็น AI ทำให้บรรยากาศในที่ทำงานให้ความสำคัญกับปริมาณการใช้งานมากกว่าคุณภาพ
- Amazon ระบุว่าไม่มีตัวชี้วัด AI ระดับทั้งองค์กรหรือ leaderboard ภายใน แต่พนักงานบอกว่ามีเป้าหมายการใช้งาน 80% และมีการติดตามจริง
- OpenClaw และ MeshClaw ทำงานแบบรันในเครื่อง จึงมีความเป็นอิสระสูง แต่ความเสี่ยงอาจเพิ่มขึ้นเมื่อให้สิทธิ์เข้าถึงมากเกินไป
แรงกดดันให้ใช้ AI และการใช้งาน MeshClaw
- พนักงาน Amazon ถูกกดดันให้นำ AI เข้าไปอยู่ในขั้นตอนการทำงานมากขึ้น แต่กลับไม่มีความชัดเจนว่าควรนำไปใช้ตรงไหน จึงเปิดช่องให้ทรัพยากร AI ถูกใช้ไปกับงานที่ไม่จำเป็น
- ตามรายงานของ Financial Times พนักงาน Amazon บางส่วนใช้เครื่องมือ AI ภายในอย่าง MeshClaw เพื่อสร้างเอเจนต์ AI ที่ไม่จำเป็น ซึ่งช่วยเพิ่มปริมาณกิจกรรม AI มากกว่าช่วยเพิ่มประสิทธิภาพการทำงาน
- พนักงานคนหนึ่งกล่าวว่า “มีแรงกดดันให้ใช้เครื่องมือเหล่านี้มากเกินไป” พร้อมบอกว่าบางคนใช้ MeshClaw เพื่อ เพิ่มการใช้โทเค็นให้สูงที่สุด
ความเห็นที่แตกต่างเกี่ยวกับตัวชี้วัดการใช้งาน
- พนักงานมองว่า Amazon ติดตาม การใช้โทเค็น AI จนทำให้เพื่อนร่วมงานบางคนให้ความสำคัญกับปริมาณการใช้เทคโนโลยีมากกว่าคุณภาพ
- พนักงาน Amazon หลายคนที่ไม่เปิดเผยชื่อมองว่าสภาพแวดล้อมการทำงานกำลังแย่ลง เพราะความคาดหวังเรื่องการใช้ AI สูงขึ้น
- ดูเหมือนว่า Amazon ได้แจ้งพนักงานว่าสถิติการใช้ AI จะไม่ถูกนำไปใช้ในการประเมินผลงาน แต่ไม่ใช่พนักงานทุกคนที่จะเชื่อเช่นนั้น
- พนักงานอีกคนมองว่าการติดตามการใช้งานสร้าง แรงจูงใจที่บิดเบี้ยว และทำให้พนักงานบางคนมีพฤติกรรมแข่งขันกันอย่างมาก
- พนักงานที่ให้สัมภาษณ์ระบุว่าบริษัทมีเป้าหมายให้ 80% ของนักพัฒนาใช้ AI ทุกสัปดาห์ และมีการติดตามการใช้โทเค็นของพนักงานผ่าน leaderboard ภายใน
- โฆษกของ Amazon ระบุว่าไม่มี ตัวชี้วัด AI ระดับทั้งองค์กร และไม่มี leaderboard ภายในที่ใช้เปรียบเทียบพนักงานกัน
- Amazon ระบุว่าพนักงานสามารถดูปริมาณการใช้ AI ของตนเองได้จากแดชบอร์ดส่วนบุคคล
OpenClaw และความเสี่ยงของการรันในเครื่อง
- MeshClaw ซึ่งพนักงาน Amazon บางส่วนใช้เพื่อปั่นตัวเลขการใช้งาน AI เป็นเครื่องมือที่ได้แรงบันดาลใจจากเครื่องมือ AI อีกตัวอย่าง OpenClaw
- OpenClaw และ MeshClaw แตกต่างจากโมเดล AI อื่น ๆ ตรงที่สามารถ รันในเครื่อง บนฮาร์ดแวร์ของผู้ใช้เองได้ จึงมีความเป็นอิสระสูง
- เมื่อต้นปีนี้ ผู้อำนวยการด้าน alignment ของ Meta Superintelligence Labs กลายเป็นประเด็นหลังจากOpenClaw เกือบลบอีเมลทั้งหมดในกล่องขาเข้าของเธอ ซึ่งสะท้อนความเสี่ยงที่เกิดขึ้นเมื่อให้สิทธิ์เข้าถึง AI มากเกินไป
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ไม่ใช่แค่ Amazon แต่รู้สึกว่า บริษัทเทคใหญ่โดยรวม รวมถึงบางบริษัทเล็ก ๆ ก็กำลังเพี้ยนไปพร้อมกัน
มันคล้ายกับสถานการณ์ที่วันหนึ่ง CEO บอกว่า “ต้องสนับสนุนการเบิกค่าเดินทางธุรกิจ เพราะงั้นให้จองทริปให้มากที่สุดและใช้เงินให้เต็มที่ เวลาไปออฟฟิศสาขาก็นั่งเฟิร์สคลาส แทนที่จะเรียก Uber ก็เรียกลีมูซีน กินร้านหรู ๆ ถ้าเบิกค่าเดินทางไม่พอจะได้คะแนนประเมินผลงานต่ำ”
ตอนนี้เป็นยุคที่ผิดปกติอย่างสิ้นเชิง
ถ้าเป็นรองประธานที่ Amazon ก็คงพิจารณาข้อเสนอซื้อกิจการ และตอนนี้ก็กำลังทำเวอร์ชัน enterprise ที่มีฟีเจอร์เพิ่มอยู่ด้วย
Show HN: https://news.ycombinator.com/item?id=48151287
นึกว่าจะโดนดุ แต่กลับได้คำชม แถมยังถูกขอให้ทำพรีเซนต์สั้น ๆ แชร์วิธีประสบความสำเร็จให้พนักงานคนอื่นฟังอีก
ตอนนี้ 20% ของค่าใช้จ่ายโครงสร้างพื้นฐานคือ token และจำนวน pull request รายสัปดาห์ต่อ developer เพิ่มจาก 4.2 เป็น 5.1
หลายอันในนั้นก็เป็นแค่เอเจนต์ไปแก้ไฟล์ config หนึ่งหรือสองบรรทัด เลยดูเหมือนความคิดแบบเชื่อเรื่องมหัศจรรย์ทั้งหมด
ทั้งที่บางสายการบินสามารถนั่งเฟิร์สคลาสได้ถูกกว่า แต่ตามนโยบายบริษัทกลับนั่งเฟิร์สคลาสไม่ได้
เราอยู่ในยุคผิดปกติมาตลอดนั่นแหละ
พอสิ่งนั้นไม่เกิดขึ้น ก็ดูเหมือนจะสรุปว่าที่ไม่เกิดเพราะพนักงานยังใช้ AI มหัศจรรย์นี้ไม่บ่อยพอ
บริษัทที่สร้างผลิตภัณฑ์ AI เองก็อาจอยากให้พนักงานใช้ AI ให้มากที่สุด เพื่อเก็บข้อมูลฝึกโมเดลที่จะมาแทนพนักงานส่วนใหญ่หรือทั้งหมดในท้ายที่สุด
การลงโทษพนักงานที่ปฏิเสธจะช่วยฝึกตัวแทน AI ของตัวเอง แม้ตอนนี้จะมีต้นทุน แต่ถ้ามองว่าภายหลังประหยัดได้มากกว่าก็อาจฟังดูสมเหตุสมผลสำหรับพวกเขา
ราว ๆ 6 เดือนก่อน เคยฟังพนักงาน AWS พรีเซนต์ เครื่องมือ AI ที่เหมาะกับ use case ของเรา
ระหว่างพรีเซนต์ เขาแชร์หน้าจอแล้วจู่ ๆ ก็พูดว่า “ดูสิว่าเดือนนี้ผมใช้ token ไปเท่าไหร่ ผมรัน Opus หนักมาก” และตัวเลขนั้นใหญ่จนน่าอาย
ตอนนั้นผมคิดว่า “เป็นการอวดที่แปลกดีนะ ของแพงขนาดนี้ การใช้เยอะน่าจะเป็นสัญญาณอันตรายไม่ใช่เหรอ”
เขาโชว์หลาย use case ของ Claude Code สำหรับจัดการและปรับแต่ง AWS infrastructure แต่ในสายตาผมที่เป็น sysadmin หนวดหงอกซึ่งแก่กว่าอินเทอร์เน็ต มันดูเหมือน “ใช้ AI ทำสิ่งที่คำสั่งเดียวก็จบ”
เพราะงั้นเรื่องนี้เลยฟังขึ้น เท่ากับว่ามีการผลักดันให้ใช้แบบจัดเต็มมาตั้งแต่ 6 เดือนก่อนแล้ว
แต่ถ้ากด
tabมันก็นับว่าบรรทัดนั้นเป็นบรรทัดที่ AI แก้อีกจำนวนมากก็เป็นสิ่งที่ถ้าเรียนรู้ multi-cursor, การเคลื่อนที่แบบ vim หรือ macro มาก่อน ก็ทำได้เร็วพอกันอยู่แล้ว
ความจริงก็แค่ไม่เคยต้องเรียน เพราะไม่เคยช้าจนความเร็วในการพิมพ์โค้ดขึ้นจอเป็นคอขวด
คงไม่ใช่การแบ่งแบบขาวดำ และน่าจะขึ้นกับหลายปัจจัย แต่ก็น่าแปลกที่รายงานซึ่งต่างกันมากแบบนี้ปรากฏพร้อมกัน
ถ้าอย่างนั้นก็พอคำนวณได้ว่าคำสั่งแบบนี้มาจากไหน และทำไมถึงไม่ระมัดระวังหรือสมดุล
นี่เป็นจุดอ่อนใหญ่ของการพัฒนาระบบ และสำหรับฝ่ายตรงข้ามมันอาจกลายเป็น พื้นผิวการโจมตี ขนาดมหึมา
มูลค่าจำนวนมากของ AI อยู่ตรงนั้นพอดี
ตอนนี้ไม่จำเป็นต้องรู้คำสั่งนั้นแล้ว แค่รู้ สัญญาเชิงหน้าที่ ก็ทำงานที่ต้องการได้
นี่คือความเปลี่ยนแปลงครั้งใหญ่
มีเรื่องเล่ามากมายแนว “ต้องใช้ token เลยเอาไปเผาในเรื่องไร้ประโยชน์” ซึ่งเป็นพฤติกรรมที่ไม่น่าเชื่อในภาวะ ฉุกเฉินด้านสภาพภูมิอากาศ
ถ้าผลักต่ออีกหน่อยก็คงพาไปถึงภาวะโลกร้อน 3 องศาได้เลย
มันทำให้นึกถึงเรื่องที่โซเวียตเกือบทำให้วาฬสูญพันธุ์ เพราะต้องการให้ครบโควตาล่าวาฬ ทั้งที่ไม่มีใครอยากกินเนื้อวาฬนั้น
เรามีการวางแผนจากศูนย์กลางโดยพฤตินัยแล้ว และโรคทางระบบของมันก็เหมือนกันทุกอย่าง ต่างจากโซเวียตก็แค่ GOSPLAN ของเราถูกบริหารโดยคนไม่กี่คนที่รวยขึ้นมาแบบฟลุค ๆ หรือไม่ก็ให้สินบนถูกคน
ไม่ใช่เพื่อเพิ่มผลิตภาพ “ของจริง” แต่แค่ เพื่อใช้ token
ถ้าไม่เผา token ก็จะไม่ผ่าน KPI และอาจโดนติดป้ายว่าเป็นพวก Luddite แล้วถูกไล่ออกก่อนที่ AI จะมาแย่งงานเสียอีก
เห็นด้วยว่าแนวโน้มนี้กับพวกคลั่งสงครามกำลังช่วยกันทำลายโลก
ส่วนคำว่า “ไม่มีใครอยากกินมัน” ก็ไม่ได้มีหลักฐานรองรับมากนัก
โชคดีที่ทำฝั่งการจัดการแอปและรู้ว่าดูได้แค่วันใช้งานครั้งสุดท้าย ดังนั้นวันละ query เดียวก็พอรอด
แต่ผมเหนื่อยกับ กระแส AI ร้อนแรงเกินจริง นี้มากจริง ๆ
ผมทำงานอยู่ FAANG แห่งหนึ่ง แต่ไม่ใช่ Amazon และได้ยินเรื่องแบบนี้จากทั้งข้างในและข้างนอกเยอะมาก
แต่คนสำคัญจริง ๆ คือระดับผู้นำ ไม่เคยพูดแบบเป็นทางการเลยสักครั้ง
มันมักเริ่มจากข่าวลือหรือ dashboard/metric ที่ใครสักคนภายในทำขึ้น แล้วก็ขยายต่อ
ผมก็เคยได้ยินผู้นำพูดว่า “สิ่งที่เราดูไม่ใช่แบบนั้น และไม่ควรสิ้นเปลือง token แพง ๆ”
แน่นอนว่าเมื่อก่อนก็เคยมีการใช้ metric โง่ ๆ อย่างจำนวนบรรทัดโค้ดหรือจำนวน commit โดยยอมรับตรง ๆ อยู่บ้าง แต่ผมไม่เชื่อว่ามันจะง่ายตรง ๆ แบบ token ยิ่งมากยิ่งดี
พอเราค้าน ผู้นำก็ยอมรับว่าการใช้จ่าย token ไม่ใช่ metric ที่ดีและมีโอกาสสูงที่คนจะเล่นเกมกับมัน แต่จากนั้นก็บอกให้เพิ่มการใช้ token ของทีมอีกทันที
มี dashboard ติดตาม token ที่ผู้นำดูอยู่ และผมรู้เพราะเขาเปิดให้ดูตรง ๆ ในที่ประชุม
อย่างน้อยตอนนี้ยังไม่ได้เปิดเป็นกระดานจัดอันดับให้ทุกคนเห็น เลยยังพอมีโชคอยู่บ้าง
มีข่าวลือเยอะว่า token spend จะถูกใส่ในผลงานประเมิน และถึงผู้นำจะปฏิเสธ แต่ไม่นานก็จัดประชุมเพิ่มว่าเหตุใดการเพิ่ม token spend จึงสำคัญ และคุยถึงตัวเลขที่ dashboard แสดงว่ายังขาดอยู่
ในบริษัทที่สร้าง leaderboard การใช้ token หรือส่งสัญญาณว่าวิศวกรที่ปฏิเสธใช้เครื่องมือ AI อาจถูกไล่ออก ปัญหาจะระเบิดทันที
จากนั้นก็กลายเป็นการแข่งขันว่าใครจะใช้ token ได้มากที่สุดเพื่อเอาตัวรอด
โดยเฉพาะในหมู่นักพัฒนาที่อ่านโซเชียลมีเดียเยอะ
ใน Twitter, Threads, Mastodon, LinkedIn ฯลฯ มีเรื่องไวรัลแนวว่าต้อง become AI-native และจะไล่คนที่ใช้ AI ไม่พอออก ถูกนำมารีไซเคิลซ้ำ ๆ จนนักพัฒนาที่กังวลคิดว่าถ้าอยากรอดจากการปลดคนที่หลีกเลี่ยงไม่ได้ ก็ต้องเผา token ให้เร็วกว่าคนรอบข้าง
หลังจากนั้น individual contributors ในองค์กรก็ถูกบอกให้ใช้ AI กับทุกอย่าง และถ้าไม่ทำอาจมีผลเสียต่ออาชีพ
มีทั้งการอบรมภาคบังคับ เวิร์กช็อป และ hackathon เพื่อ “กระตุ้น” ให้ใช้ AI ในงานประจำวัน
แม้แต่งานที่ shell script ทำได้ง่าย ๆ ก็ยังตั้งคำถามว่า “จะเปลี่ยนสิ่งนี้ให้เป็น agent ได้อย่างไร”
เพราะจ่ายเงินให้ Copilot ไปเยอะ เลยอยากเห็นคนใช้งานมัน
เป้าหมายอาจเป็นการทำให้ผู้คน เล่นกับ metric นี้อยู่แล้วก็ได้
ถ้าผลักให้ใช้ AI มากขึ้น คนก็จะลองผิดลองถูก ทดลอง และ “เสียเวลา” ไปพร้อมกับการเรียนรู้
นั่นแหละคือเป้าหมายสุดท้าย
ตอนนี้พวกเขากำลังใช้ token ไปกับเรื่องที่ยังไร้ประโยชน์เพื่อหาว่าตรงไหนมันช่วยได้ และก็ต้องเรียนรู้เหมือนกันว่าตรงไหนมันช่วยไม่ได้
บริษัทเราก็กำลังทำแบบเดียวกัน
มันอาจสิ้นเปลือง แต่เป็นวิธีที่เร็วที่สุดในการสำรวจว่า AI มีประโยชน์กับธุรกิจจริง ๆ ตรงไหน
ต่อให้พนักงาน 80% แค่เผา token ทิ้ง แต่ 20% ที่เหลือก็กำลังหาวิธีเจออยู่
ถ้ามีเงินเหลือพอจะเผา ก็อาจคิดวิธีใช้จ่ายที่แย่กว่านี้ได้เหมือนกัน แต่ถ้ามองจริงจังก็เป็นเรื่องโง่มาก
เคยมีเครื่องมือไหนที่บริษัทต่าง ๆ ทุ่มเงินหลายล้านดอลลาร์และเวลาคนจำนวนมาก เพื่อ “ค้นหาว่าเครื่องมือนี้จะมีประโยชน์ทำอะไรได้บ้าง” ไหม
มันคือคำตอบที่ออกตามหาปัญหาโดยแท้
ถ้าในช่วงแรกยังไม่ชัดว่าเครื่องมือนี้แก้ปัญหาอะไร ก็ควรทิ้งแล้วไปต่อ
เอาเงินที่เหลือไปให้พนักงานกับผู้ถือหุ้นยังจะดีกว่า
น่าเศร้าที่ตอนนี้ AI มีโครงการ งานถ้วนหน้าขั้นพื้นฐาน แล้ว แต่มนุษย์ยังไม่มี
บริษัทต่าง ๆ กำลังจ่ายเงินให้ AI ขุดหลุม แล้วจ่ายให้ AI อีกตัวมาถมหลุมนั้น
[1] https://locusmag.com/feature/cory-doctorow-full-employment/
โซเวียตเคยบรรลุการจ้างงาน 100% มานานแล้ว[0] พร้อมกับความยากจนที่ตามมา
แต่นี่ไม่เหมือนกัน เพราะไม่ได้ขับเคลื่อนด้วยภาษี
บริษัทเอกชนกำลังทดลองด้วยเงินของตัวเอง และก็ยอมรับความเสี่ยงว่าภายหลังต้นทุนจะสูงขึ้นจนลูกค้าย้ายไปที่อื่น
อย่างน้อยก็ดีกว่าการเก็บภาษีแบบบังคับแล้วแจกเงินให้คนโดยไม่เกี่ยวกับผลิตภาพมาก
[0] https://nintil.com/the-soviet-union-achieving-full-employmen...
ภายใน Amazon ถ้าใช้ Kiro มันคือ การทำให้การใช้ token เป็นเกม ไปแล้ว
เพราะไม่ใช่โมเดลที่คิดค่าใช้จ่ายให้ทีมแบบ AWS หรือให้มาอธิบาย capacity แบบระบบเก่า
ผมได้ยินมาอย่างน่าเชื่อถือว่าคนเล่นเกมกับ metric นี้กันตั้งแต่ก่อนจะมีใครเห็นอันดับภายในเสียอีก และพวก power user ก็สร้างและแชร์โปรเจกต์ภายในกันสารพัด
แน่นอนว่าผู้จัดการที่ได้ฟังการนำเสนอภายในเรื่องเพิ่มผลิตภาพ N00% ก็ย่อมกดดัน แต่ในที่ที่ผมอยู่ ถ้าใครสร้างงานปลอมแทนงานจริงก็น่าจะถูกจับได้เร็วพอสมควร
แรงกดดันมาจาก deadline ที่ดุดันและการเปลี่ยนสู่รูปแบบที่คล่องตัวขึ้นในกระบวนการ OP1 รายปีมากกว่า
ได้ยินเรื่องคล้าย ๆ กันจากทั้ง AWS และพนักงาน FAANG ที่ไม่ใช่ AWS
ทุก leaderboard ของ token จะมีคำปฏิเสธความรับผิดชอบแปะว่า “สิ่งนี้ไม่ถูกนำไปใช้ในการประเมินผลงาน” แต่ให้ความรู้สึกว่ามี การส่งสัญญาณแบบรู้กันอยู่ ตามมา
องค์กรหนึ่งที่ผมได้ยินมามีคนรัน GasTown ตลอด 24 ชั่วโมงเพื่อกิน token
แทบไม่มีผลงานอะไร แต่ก็นั่งอันดับหนึ่งแบบสบาย ๆ
เขารัน GasTown และให้ agent ไปแตะโค้ดทั่วทั้ง codebase จนได้ commit วันละประมาณ 50 อัน
เป็นพวกเวอร์ชันที่เข้ากันได้ การจัด format อะไรทำนองนั้น
แต่ปัญหาไม่ใช่เทคโนโลยี เป็นตัวเขาเอง
เขาเป็นแบบนี้มาตั้งแต่ก่อนยุค LLM แล้ว
เขาเคย “รีแฟกเตอร์” repository ให้แตกเป็น repository ย่อย ๆ เพื่อให้ชื่อเขาไปปรากฏบนโค้ดทั้งหมดอย่างฉับพลัน จนถ้าดูผ่าน ๆ จะเหมือนว่าเขาเป็นคนสร้างก้อนใหญ่ของ codebase บริษัท
เขาเคยปฏิเสธสิ่งที่ผมอยากทำ แล้วภายหลังก็มาทำเอง
เขาจะหาเรื่องติ PR ของผมได้ไม่รู้จบ หรือไม่ก็บอกว่าไม่ควรทำงานนั้นตั้งแต่แรก แล้วหันไปลงมือทำเอง
เขาไม่ได้คัดลอกโค้ดผมตรง ๆ แต่มักจะกลับไปทำไอเดียเดียวกับที่เขาเคยปฏิเสธ หลังจาก PR ของผมเปิดแล้ว
เขาฉลาดมาก แต่ก็ไม่ซื่อสัตย์มาก และซ่อนความไม่ซื่อสัตย์ได้เก่ง
ถ้าถาม เขาจะตอบประมาณว่า “ผมแค่คิดว่าวิธีนี้ดูสะอาดกว่านะ”
จากข้างนอกจะยังพอเถียงได้ว่าวิธีหนึ่งดีกว่าอีกวิธี เลยไม่เห็นความไม่ซื่อสัตย์ชัดเจน แต่ผมเห็นสิ่งที่เขาทำอยู่ 100% จึงเห็นแพตเทิร์นชัดเจนเต็ม ๆ
เพิ่มเติมคือ ครั้งหนึ่งผมบอกว่าจะลาหยุดสัปดาห์หนึ่ง เขาไม่ได้ปฏิเสธตรง ๆ แต่พูดว่ามีแรงกดดันให้ต้องส่งมอบ The Thing และถามว่าผมเลื่อนได้ไหม
พอผมบอกว่า “ไม่ ผมจะไม่เลื่อน” เขาก็อนุมัติ แต่พอถึงสัปดาห์นั้นจริง ๆ เขากลับลาหยุดสัปดาห์เดียวกันเอง
ผมไม่ได้ไปเอาเรื่อง เพราะก่อนหน้านั้นก็รู้พอแล้วว่าเขาไม่ละอายที่จะเรียกร้องจากคนอื่นในสิ่งที่ถ้าเป็นตัวเองจะไม่มีวันยอมรับ
ถ้าโฆษก Amazon บอกว่าไม่มีทั้ง metric การใช้ AI ระดับทั้งบริษัท ไม่มี leaderboard ภายในที่เอาพนักงานมาเทียบกัน และแต่ละคนดูได้แค่การใช้งานของตัวเองใน dashboard ส่วนตัว นั่นคือเรื่องเหลวไหลล้วน ๆ
มี dashboard ระดับ global ที่จัดอันดับพนักงานตาม token usage ของ Kiro/QuickSuite (เดิมคือ Amazon Q)
ตัว dashboard อยู่บน QuickSight ซึ่ง QuickSight เองก็กลายเป็นส่วนหนึ่งของ QuickSuite ไปแล้ว
ข้อมูลไม่เพียงเปิดให้ใครก็ได้ดู แต่ยัง sort ได้ตามอันดับ ปริมาณการใช้รายวัน รายสัปดาห์ รายเดือน และรายปี
มีทั้งพนักงานปัจจุบันและอดีตพนักงานรวมอยู่ตาม alias ภายใน
แถมยังมีระบบ “รางวัล” ภายในที่แสดงบนโปรไฟล์ PhoneTool ด้วย โดยแต่ละคนจะได้ยศ Kiro/AmazonQ/Quicksuite อย่าง “Blaze”, “Thunderstorm” เป็นต้น
และแค่คลิกก็เห็นคนอื่นที่ได้รางวัลเดียวกันได้ด้วย
PhoneTool เองก็คือไดเรกทอรีโปรไฟล์ภายในสำหรับค้นหาพนักงานคนอื่น
ในอีกด้านหนึ่ง ผมรู้จักหลายคนที่ยังเขียนโค้ดดี ๆ ด้วยตัวเองไม่ได้ หรือเอาอะไรไป integrate เองไม่เป็น
แต่คนที่ต้องให้จับมือพาเดินตลอดกลับผลิตงานออกมามหาศาลผ่าน Kiro/AmazonQ จนช่วงนี้ได้อันดับสูงกว่า SDE เสียอีก
คนเหล่านี้ใกล้เคียง SysDev, support engineer, TPM มากกว่า SDE
ตัวมันเองอาจไม่ได้ดีหรือแย่เสมอไป แต่ถ้าจัด stack rank ตามการใช้ token วิศวกรดี ๆ ที่พยายามเขียนโค้ด “ดี” จะมีโอกาสถูกประเมินต่ำกว่าคนที่ไม่พยายามหาทางแก้ที่กระชับกว่า
คุณภาพสุดท้ายก็จะตกลง และกว่าผู้นำจะรู้ว่าเกิดอะไรขึ้นก็คงสายไปแล้ว
ผมเห็น incident ที่เกี่ยวกับ Amazon-Q/Kiro มาแล้ว แต่พวกเขาก็ยังปฏิเสธต่อไป
ที่ทำงานผมเองกระแสนี้ก็เริ่มมาเหมือนกัน
ถ้าไม่ใช้ Copilot ใน MS Office ทุกวัน มันจะส่งการแจ้งเตือนแบบไม่พอใจมาให้ ดังนั้นผมเลยพิมพ์แค่ Hello ลงไป