- Uber ใช้งาน Claude Code และ Cursor เพิ่มขึ้นจนใช้งบ AI ทั้งหมดของปี 2026 หมดภายในเวลาเพียง 4 เดือน และการทดลองด้านประสิทธิภาพการทำงานก็นำไปสู่การทบทวนงบประมาณในทันที
- CTO ของ Uber เปิดเผยว่าค่าใช้จ่าย API รายเดือนต่อวิศวกรอยู่ที่ราว 500~2,000 ดอลลาร์ และ 95% ของวิศวกรใช้เครื่องมือ AI ทุกเดือน
- โค้ดที่ถูกคอมมิตใน Uber จำนวน 70% มีที่มาจาก AI แสดงให้เห็นว่าเครื่องมือเขียนโค้ดด้วย AI ได้กลายเป็นส่วนสำคัญของเวิร์กโฟลว์งานวิศวกรรมแล้ว
- Claude Code ถูกแจกสิทธิ์ให้ทีมวิศวกรรมในเดือนธันวาคม 2025 และหลังจากยืนยันความสามารถในการทำงานหลายขั้นตอนได้แล้ว การใช้งานก็เพิ่มขึ้นเป็นสองเท่าภายในเดือนกุมภาพันธ์ 2026 ก่อนจะใช้งบประจำปีหมดทั้งหมดในเดือนเมษายน
- ขณะที่การใช้งาน Cursor เพิ่มขึ้นอย่างชะงักงัน Claude Code กลับกลายเป็นเครื่องมือหลัก และ Uber จึงต้องคำนวณค่าใช้จ่ายของเครื่องมือเขียนโค้ด AI ใหม่ภายใต้งบ R&D รายปีมูลค่า 3.4 พันล้านดอลลาร์
การขยายการใช้งานและการทบทวนงบประมาณ
- Uber มองเห็นคุณค่าของ Claude Code และ Cursor สูงมากจนแม้ต้นทุนจะพุ่งขึ้นอย่างรวดเร็ว วิศวกรก็แทบไม่สามารถหยุดใช้งานทั้งสองเครื่องมือได้
- สิทธิ์เข้าถึง Claude Code ถูกแจกให้ทีมวิศวกรรมในเดือนธันวาคม 2025 และเมื่อพิสูจน์ได้ว่ามีความสามารถในการทำงานหลายขั้นตอน การใช้งานก็เพิ่มขึ้นเป็นสองเท่าภายในเดือนกุมภาพันธ์ 2026
- เมื่อค่าใช้จ่ายในเดือนเมษายน 2026 ใช้งบ AI รายปีหมดทั้งหมด ฝ่ายบริหารจึงต้องเผชิญกับการตัดสินใจที่ไม่คาดคิด
- CTO ของ Uber ระบุว่าบริษัทต้องกลับไป “back to the drawing board” ในการจัดทำงบ AI ใหม่
การเปลี่ยนแปลงการใช้งานแยกตามเครื่องมือ
- Cursor เป็นอีกหนึ่งเครื่องมือหลักที่แข่งขันกันเพื่อการยอมรับใช้งาน แต่การเติบโตของการใช้งานกลับหยุดชะงัก
- Claude Code กลายเป็นเครื่องมือหลักในเวิร์กโฟลว์งานวิศวกรรม
- การนำมาใช้ซึ่งเริ่มต้นจากการทดลองด้านประสิทธิภาพการทำงานได้ขยายตัวอย่างรวดเร็ว จนการใช้เครื่องมือ AI ในงานวิศวกรรมภายในบริษัทเกิดขึ้นอย่างจริงจัง
ความหมายของแรงกดดันด้านต้นทุน
- การใช้งบเกินคาดของ Uber แสดงให้เห็นว่าเครื่องมือ AI ถูกมองว่ามีคุณค่าสูงเพียงใดต่อประสิทธิภาพงานวิศวกรรม
- บทบาทของเครื่องมือ AI ขยายใหญ่ขึ้นจนถึงระดับที่การจำกัดการเข้าถึงกลับถูกมองว่าเป็นการลดผลิตภาพเสียมากกว่า
- เมื่อมีนักพัฒนาจำนวนมากขึ้นนำ Claude Code มาใช้ บริษัทอื่นก็อาจกำลังเผชิญผลกระทบในลักษณะคล้ายกัน
- บริษัทซอฟต์แวร์จะต้องเผชิญแรงกดดันในการควบคุมต้นทุน ขณะเดียวกันก็ต้องรักษาความเร็วในการพัฒนาไว้
- หากเครื่องมือเพิ่มผลิตภาพสำหรับนักพัฒนามีคุณค่ามากจนวิศวกรใช้งบทั้งหมดหมดภายใน 4 เดือน ข้อสรุปก็คือปัญหาไม่ได้อยู่ที่ตัวเครื่องมือ แต่อยู่ที่การตั้งงบซึ่งเร็วเกินไปกว่าจะคาดการณ์เส้นโค้งการยอมรับใช้งานได้
2 ความคิดเห็น
ฟินกับการถลุงงบ
ความเห็นจาก Hacker News
ถ้าลองเปิดดูค่าใช้จ่ายของบริษัทเดือนละครั้ง ก็จะเริ่มงงว่าทำไมคนจำนวนมากขึ้นเรื่อย ๆ ถึงใช้ ค่า token เดือนละ $1k กันได้
ต่อให้ใช้ LLM ทุกวัน และใช้ทั้งโมเดลที่แพงที่สุดพร้อมโหมดคิดลึก โดยปกติขีดบนก็แค่ $200~$400 เท่านั้น ไม่ได้เป็นพวกลัดไดต์ที่ต่อต้านการใช้งาน แค่ไม่เข้าใจว่าคนจะเผางบระดับนั้นต่อเดือนอย่างมีความรับผิดชอบได้อย่างไร อยากเห็นคนที่ใช้เดือนละ $5k~$10k แสดงให้เห็นว่านั่นแปลงเป็นมูลค่า $50k~$100k ได้อย่างไร ในมุมบริษัท แทนที่จะพยายามหาเหตุผลให้ค่าใช้ token ปีละ $100k ดูสมเหตุสมผล ผมว่าจ้างวิศวกรจูเนียร์ที่ใช้แค่ $100~$200/เดือนแต่ยังสร้างผลงานได้ น่าจะดีกว่า
ระดับกลางจะเริ่มติดรูปแบบอย่าง “เปิด sub-agent 5 ตัวให้วิเคราะห์ทางแก้จากคนละมุมแล้วสรุปมา” ซึ่งตัวมันเองไม่ใช่นิสัยเสีย แต่ถ้าไม่ระวังก็ใช้เครดิตเกินมาก ส่วนคนชำนาญอาจรัน task tree 10 ชุดขนานกันตลอด แล้วสลับไปมาระหว่างคำตอบของเอเจนต์ ทำ multitasking แบบสุดโต่งจนค่าใช้จ่ายพุ่งแบบทวีคูณได้
อีกปัจจัยคือ codebase ใหญ่หรือปัญหาที่ซับซ้อน ถ้าเพิ่งเข้าทีมใหม่และยังมีส่วนที่ไม่รู้เยอะ เวลารับงานมาก็จะให้ Claude หาโค้ดที่เกี่ยวข้อง ทำความเข้าใจ flow เดิมก่อน แล้วค่อยเริ่มแก้ ความเชี่ยวชาญของคนอาจสะสมน้อยลง แต่ถ้าใช้ Claude แล้วงานที่ปกติ 5 วันเสร็จได้ใน 1 วัน และทุกคนทำแบบนั้นหมด ก็ถอยหลังไม่ได้ ผมเลยเลือกทางสายกลางคือทำให้เสร็จใน 2~3 วันแทน 1 วัน พร้อมพยายามอ่านโค้ดด้วย โดยเฉพาะเพราะ AI ทำให้ความเร็วในการเปลี่ยนโค้ดสูงขึ้นมาก จนผมยังทำเครื่องมือให้ LLM อธิบาย pull request แบบละเอียดด้วย ไม่ได้ใช้แทน reviewer แต่ใช้ตามงานของทีมให้ทัน ผมยังไม่ได้คิดจริงจังด้วยซ้ำว่าจะใช้ LLM ให้คุ้มกว่านี้อย่างไร และถ้าผมคุ้นกับ codebase มากกว่านี้ก็คงใช้มากกว่านี้อีก คอขวดก็ยังเป็นเรื่องการทดสอบและรีวิวที่เหมาะสมอยู่ดี สำหรับโค้ดภายในที่ไม่สำคัญมากหรือโปรเจกต์ส่วนตัว ผมแทบปล่อยให้ AI ทำเกือบทั้งหมด และถ้าใช้สกิล “superpowers” ก็จะเผา token เยอะมากแม้กับงานพื้นฐาน ปกติเริ่มที่ 20~40K token แล้วตอนจบขึ้นไปถึง 80~90K token ดังนั้นหลายคำขอก่อนเสร็จจริง ๆ ก็เหมือนส่ง 80K token ทุกครั้ง มันสิ้นเปลือง แต่ถ้าคนอื่นจ่ายก็เป็นแบบนั้นแหละ
ตอนแรกก็ดี แต่เอเจนต์ตัวหนึ่งเขียน output หลายแสนบรรทัดลงใน cell จนได้ไฟล์
ipynbขนาด 500MB แล้ว Claude ก็พยายามอ่านมันซ้ำหลายรอบจนกิน context limit หมด วิธีแก้คือกำหนดโครงสร้างงานให้ดีกว่านี้ด้วยสคริปต์วิเคราะห์แบบ CLI และโฟลเดอร์เก็บผลการวิจัย แต่สุดท้ายคนควบคุมอย่างผมนี่แหละที่ต้องวางแผนกับออกแบบ คนที่ใช้ token เดือนละ $10k ดูยังไงก็เหมือนกำลังปล่อยให้ Claude Code ซึ่งเป็นค้อนราคาแพงจัดการปัญหาแบบขี้เกียจไปหมด เช่น ให้ Claude อ่านอีเมลทั้งหมดทุกวัน ทั้งที่วิธีที่ฉลาดกว่าคือกำจัดสัญญาณรบกวนจาก HTML ในเนื้อหาอีเมลก่อนในทางกลับกัน ถ้าเป็นของเล็กหรือใช้ framework ทั่วไปที่โมเดลเคยเรียนมาแล้ว ก็ทำอะไรได้เยอะด้วย context window เล็กกว่า และใช้ token ต่ำกว่ามาก
ตั้งแต่เริ่มใช้ coding agent มีแค่ครั้งเดียวที่เข้าใกล้ลิมิต คือทำ cross-platform development พร้อมกันบนคอม 3 เครื่องภายใต้เงื่อนไขเดียวกัน และตอนนั้นก็แค่เกือบชนเพดานรายสัปดาห์ ปกติ usage จะลงไปประมาณ 20% ของลิมิต แต่แทบไม่ต่ำกว่านั้น ผมก็เล่นกับ prompt และ query เยอะอยู่แล้วเพื่อความสนุก แต่ยังไม่รู้จะใช้ให้มากกว่านี้ได้อย่างไร
ผมรู้ว่าตอนนี้กำลังตอบ AI อยู่ แต่คำว่า “กำลังหาว่าบริษัทจะรับภาระ productivity ระดับนี้ในระดับองค์กรได้หรือไม่” ฟังดูแปลก ถ้ามัน productive จริง รายได้ก็ควรเพิ่ม และเรื่องแบกรับได้หรือไม่ก็ไม่ควรเป็นปัญหา
ประโยคที่ว่า “95% ของวิศวกร Uber ใช้เครื่องมือ AI ทุกเดือนแล้ว และ 70% ของโค้ดที่ commit มาจาก AI” เป็นเรื่องที่คาดได้อยู่แล้ว ถ้าการใช้เครื่องมือ AI ถูกเอาไปผูกกับ การประเมินผลงาน มันก็ต้องออกมาแบบนั้น
ผมไม่เข้าใจส่วนที่ว่า “กำลังหาว่าบริษัทจะรับ productivity ระดับนี้ในสเกลได้หรือไม่” ใช้งบไปแล้ว และมี ข้อมูล 4 เดือน แล้ว ประเด็นคือมีผลลัพธ์อะไรให้ดูบ้าง
ผมไม่ได้เกลียด AI หรือเป็นพวกลัดไดต์ และก็ใช้แพ็กเกจ Max $200 อยู่ แล้วนี่หมายความว่า Uber เปิดให้ใช้เครื่องมือนี้และสนับสนุนให้ทุกคนใช้ พอมันใช้ได้ผลก็กลับงงว่าทำไมถึงเกิดเรื่องนี้เหรอ การตัดสินว่า AI ไม่คุ้ม productive ต่อค่าใช้จ่ายเป็นอีกเรื่องหนึ่ง หรือว่าตอนนี้หมดของที่จะสร้างต่อแล้ว?
ที่ Salesforce ผมก็เห็นความเปลี่ยนแปลงที่งานซึ่งเคยกินเวลาหลายสัปดาห์ดูเหมือนจะเหลือแค่ไม่กี่วัน มันยังไม่แปลงเป็นเงินทันที แต่เพิ่มศักยภาพในการหาเงิน
ควรถามว่าทำไมต้องใช้ token เยอะขนาดนั้น และได้อะไรกลับมา ถ้าเป็น AWS ทุกคนคงชี้นิ้วถามแล้วว่า “ไม่ดูค่าใช้จ่ายรายเดือนเลยหรือไง”
เวลาเจอบทความแบบนี้ น่าสนใจที่จู่ ๆ หลายคนคิดว่าการวัด productivity ของนักพัฒนานั้นง่าย แม้จะจริงที่ productivity อาจนำไปสู่รายได้หรือการลดต้นทุน และรายได้วัดได้ แต่เรื่องจริงไม่ได้ง่ายขนาดนั้น
เราใช้เงินวันนี้เพื่อสร้างฟีเจอร์ที่จะสร้างรายได้ในอนาคต เพราะงั้นต่อให้ต้นทุนวันนี้พุ่ง ก็ยังไม่มีรายได้ให้วัด AI ช่วยให้ฟีเจอร์เสร็จวันนี้ ก็ไม่ได้แปลว่า AI productive หรือไม่ productive ทันที ต้องประเมินด้วยว่าถ้าไม่มี AI จะทำอะไรได้แค่ไหนและจะมีรายได้เท่าไร ธุรกิจมักเป็นเหมือน การแข่งขันแบบราชินีแดง ถ้าไม่พัฒนา ก็อาจเสียรายได้ให้คู่แข่ง การใช้ AI ก็น่าจะปะปนกันระหว่างงานสำคัญกับงานประเภท “ไหน ๆ ก็ง่ายแล้ว ลองโยนอะไรมั่ว ๆ เข้าไปดู” ถ้าจะวัด productivity จริง ต้องรู้วิธีเก็บอย่างแรกและหลีกเลี่ยงอย่างหลัง ไม่ใช่เรื่องเชียร์หรือแอนตี้ AI แค่อยากบอกว่าอย่าพูดแบบขี้เกียจว่า “ถ้ามัน productive ก็น่าจะวัดได้”
ไม่รู้เหมือนกันว่าไปได้ไอเดียมาจากไหนว่าการวัด productivity ของคนที่ไม่ใช่แรงงานโรงงานเป็นเรื่องง่าย
เห็นด้วยว่าวัดยากมาก แต่เมื่อดูจากต้นทุนนี้แล้ว มันเป็นคำถามที่ต้องตอบได้ และตัวคูณก็ต้องมากพอจะทำให้ค่าใช้จ่ายสมเหตุสมผล
ตาม [1] องค์กรวิศวกรรมของ Uber มีประมาณ 5,500 คน ถ้าเอาค่ากลางของช่วงการใช้จ่ายที่ $1,250 ค่าใช้จ่าย AI ของฝ่ายวิศวกรรมก็ประมาณ $6.8M และช่วงอยู่ที่ $2.75M~$12M บทความบอกว่าค่าใช้จ่าย R&D อยู่ที่ $3.4B
ค่าใช้จ่าย AI ไม่ได้เป็นสัดส่วนใหญ่มากในงบ R&D ถ้าคิด 4 เดือนก็ราว 0.3% ถ้าคิดทั้งปีก็ประมาณ 1% ถ้าไม่ได้วางแผนไว้ล่วงหน้าก็ไม่ใช่เงินจำนวนน้อยในงบ แต่ในภาพรวมก็ไม่ได้ใหญ่มาก คำถามจริงคือได้อะไรจากเงินก้อนนั้น บทความอ้างว่า 70% ของ code commit ถูกสร้างโดย AI ก็น่าจะหมายถึงมันผ่านการรีวิวและทดสอบแล้ว สิ่งสำคัญคือจำนวนฟีเจอร์เพิ่มขึ้นไหม ปัญหาคุณภาพลดลงไหม หรือมีประโยชน์อื่นหรือไม่ น่าเสียดายที่บทความพูดถึงแต่การใช้จ่ายที่เพิ่มขึ้น ไม่ได้พูดถึงผลลัพธ์อื่น 4 เดือนอาจยังเร็วเกินไปจะประเมินประโยชน์ก็ได้ แต่อีกมุม ถ้าเป็นโลกแบบ agile ก็อาจไม่ใช่ [1] https://www.unifygtm.com/insights-headcount/uber
และยังบอกด้วยว่า “บริษัทไม่ได้เปิดเผยตัวเลขที่แน่นอนของงบซอฟต์แวร์หรือค่าใช้จ่ายเครื่องมือ AI coding”
ในฐานะคนทำธุรกิจแบบ bootstrap หลายครั้งก็อิจฉาวิศวกรบริษัทใหญ่ แต่ก็อดกังวลไม่ได้ว่า แรงจูงใจ มันพัง
ถ้าผมเป็นวิศวกร Uber ผมไม่มีเหตุผลอะไรเลยที่จะไม่ใส่
gpt 5.5 pro @ very high thinking + fast modeลงใน prompt แม้แต่กับการแก้เล็ก ๆ ไม่มีแรงจูงใจให้ไม่ใช้โมเดลที่แรงที่สุดและจึงแพงที่สุด ผมเคยลอง prompt แบบนี้กับงานทดสอบ image→HTML แล้ว prompt เดียวกินไป $40 ถ้าต้องจ่ายเองแทบจะไม่มีทางใช้การตั้งค่านี้ แต่ในบริษัทใหญ่ถ้ามีคนอื่นออกเงินให้ ก็น่าจะรันบ่อย ผลลัพธ์ดีกว่าจริง ๆ อยู่แล้ว วิศวกรถูกประเมินจากสิ่งที่ส่งมอบ ไม่ใช่ต้นทุนของกระบวนการ มีวิธีทำให้ถูกกว่านี้ก็จริง แต่ไม่มีแรงจูงใจให้นักพัฒนาทำแบบนั้นแน่นอนว่าของจริงเป็นแบบนั้นหรือไม่ ผมก็ยังไม่มั่นใจ แค่ในทางทฤษฎีมันเป็นอย่างนั้น และการพยายามลดค่าใช้จ่าย LLM ก็เป็นดาบสองคมด้วย เพราะเงินที่นักพัฒนาประหยัดจาก LLM ต้องมากกว่าต้นทุนที่จ่ายให้คนนั้น ถ้าใช้เวลาทั้งวันเพื่อลดค่าเรียกใช้งานลง $1 ต่อครั้ง ก็ต้องใช้เวลาเกือบ 2 ปีถึงจะคืนทุนค่าเงินเดือน ยิ่งกว่านั้น LLM เปลี่ยนเร็วมากจนยากจะมั่นใจว่าวิธีแก้นั้นจะไม่ใช้ไม่ได้ภายใน 2 ปี อีก 2 ปีข้างหน้าอาจไม่รู้ด้วยซ้ำว่าจะยังเรียกเครื่องมือกันแบบเดิมไหม โหมด reasoning จะยังอยู่ไหม แม้แต่ผู้ให้บริการแนวหน้าก็คงไม่รู้
ยิ่งผู้บริหารคิดกันมากขึ้นว่าสามารถแทนซอฟต์แวร์เอนจิเนียริงด้วยเอเจนต์ได้ ผมก็ยิ่งสงสัยว่าการตัดสินใจเหล่านั้นตั้งอยู่บนภาพจำที่ไม่สมจริงของวิศวกรซอฟต์แวร์ทั่วไปหรือเปล่า
อีกด้านหนึ่งมันก็มีลักษณะ garbage in, garbage out อยู่ CTO ที่เก่งอาจตื่นเต้นมากกับสิ่งที่ทำได้ด้วยเอเจนต์ แล้วเผลอคิดว่าวิศวกรทุกคนก็ทำแบบเดียวกันได้ ทั้งที่ในความจริง วิศวกรเฉลี่ยในองค์กรอาจไม่มีแม้แต่ความคิดสร้างสรรค์พอจะมองออกว่าตรงไหนลดงานได้ ถ้าบังคับใช้เอเจนต์ productivity อาจไม่เพิ่ม แต่ค่าใช้จ่าย AI เพิ่มแน่ ๆ อีกด้านหนึ่ง การใช้ AI ทำให้เห็นช่องว่างสองแบบชัดขึ้น คือใครจะเป็นคนบอกเอเจนต์ว่าต้องทำอะไร และจะรองรับรอบ QA/review อย่างไร ในหลายองค์กร ฝ่ายผลิตภัณฑ์ไม่ได้มีพื้นฐานเทคนิคพอจะทำสเปกหรือแผนที่ละเอียดระดับให้ LLM ใช้ได้ ส่วนฝั่งนักพัฒนาที่ทำงานเหมือนเฟืองเครื่องจักรก็ไม่ได้อยู่ในตำแหน่งที่จะสร้างสเปก แต่อยากเขียนตามที่สั่งมากกว่า ถ้าคาดหวังว่านักพัฒนาที่ใช้เอเจนต์จะเป็นคนลงมือทำทั้งหมดเอง อาจยิ่งทำให้มีคนที่นั่งรอให้งานวิ่งมาหามากขึ้น ผมสนับสนุนการนำ LLM มาใช้แบบเลือกจุดเพื่อเพิ่มความเร็วและคุณภาพของนักพัฒนาที่มีอยู่ แต่กระแสแบบ “มาปรับโครงสร้างองค์กรกันเถอะ” โดยเฉพาะในบริษัทขนาดกลางและเล็ก ดูเสี่ยงมาก
ผมเองก็อาจมีอคติเพราะมี product mindset มากกว่านักพัฒนาคนอื่น แต่ผมคิดว่าคนแบบนี้อยู่ในตำแหน่งที่จะ productive กับเอเจนต์มากกว่า เพราะรู้เทคนิคพอจะให้เอเจนต์ลงมือ implement ได้ และก็รู้ด้าน product พอจะรู้ว่าควร implement อะไร คิดว่าบริษัทอื่นก็น่าจะเดินตาม
ไม่เข้าใจว่า Uber กำลังพัฒนาอะไรอยู่ มีทั้งแอปและ backend สำหรับจัดสรรรถแล้ว และทั้งคู่ก็ทำงานได้โอเค ทำไมต้องใช้เยอะขนาดนั้นก็เลยน่าสงสัย
เพราะ รถไร้คนขับ เขาก็เลิกทำไปแล้ว ไม่น่าใช่อันนั้น
ถ้าเป็น API token โดยเฉพาะเวลาใช้ context 1M แล้วไม่คอยล้าง context เก่าอย่างระมัดระวัง มันง่ายมากที่จะเผาเงินไปหลายร้อยดอลลาร์ใน session เดียว
ในขณะที่ subscription กลับอนุญาต usage ระดับเดียวกันได้ด้วยเงินแค่ไม่กี่ร้อยดอลลาร์ต่อเดือน ดูเหมือน Anthropic จะเก็บแพงมากกับผู้ใช้ API หรืออุดหนุน subscription หนักมาก หรือทั้งสองอย่าง
“ปีที่แล้ว Cursor ประเมินว่า subscription Claude Code ราคา $200 ต่อเดือน สามารถใช้ compute ได้มูลค่าสูงสุดถึง $2,000 ซึ่งชี้ว่ามีการอุดหนุนจาก Anthropic อย่างมาก ปัจจุบันการอุดหนุนนี้ดูยิ่งดุดันขึ้น โดยแพ็กเกจ $200 สามารถใช้ compute ได้ราว $5,000”
เหมือนให้ติด token ราคาถูกก่อน แล้วพอโตค่อยเก็บคืน Uber คงได้ส่วนลดจากราคา list แต่ก็คงไม่ใกล้ราคา subscription สำหรับองค์กรไม่เกิน 150 คนแน่
จะตั้งเพดานรายผู้ใช้ก็ได้ แต่ถ้าไม่มี rolling cap แบบรายเดือน ก็จะลงเอยด้วยการต้องบอกทีมว่า “ที่เหลือของเดือนนี้ไม่มี AI แล้วนะ” สำหรับผมโครงสร้างแบบนี้ถือเป็นดีลที่เสี่ยงพอสมควร