OpenAI เล่าว่า Asana ใช้ Codex ปิดงานที่ประเมินว่าต้องใช้เวลา 5 ปีได้ใน 2 สัปดาห์ แต่ตัวเลขนี้ไม่ได้บอกเงื่อนไขทั้งหมด
OpenAI เล่าเคสของ Asana ว่าใช้ Codex ปิดงานที่ประเมินว่าต้องใช้เวลา 5 ปีได้ใน 2 สัปดาห์ งานจริงคือรื้อไลบรารีทดสอบตัวเดียว ซึ่งเป็นงานค้างมาตั้งแต่ปี 2022

บริษัทซอฟต์แวร์จัดการงานทีมอย่าง Asana ปิดงานวิศวกรรมที่ตัวเองเคยประเมินว่าต้องใช้เวลาอีกราว 5 ปี ได้ภายใน 2 สัปดาห์ปฏิทิน ตัวที่ลงมือแทนวิศวกรคือ Codex เอเจนต์เขียนโค้ดที่รับคำสั่งเป็นภาษาคนแล้วไล่แก้ไฟล์ในโปรเจกต์ให้เอง ค่าโมเดลกับค่าโครงสร้างพื้นฐานที่ใช้จริงรอบนี้อยู่ที่ราว 12,000 ดอลลาร์ ส่วนแผนเดิมที่ใช้คนล้วน ทีมประเมินค่าจ้างไว้ราว 6 ล้านดอลลาร์ ตัวเลขทั้งชุดนี้มาจากเคสสตัดดี้ที่ OpenAI ตีพิมพ์
แต่เรื่องเดียวกันนี้ยังมีอีกฉบับ คือบล็อกที่ Asana เขียนเล่าเอง และในนั้นมีประโยคหนึ่งที่เปลี่ยนความหมายของเลข 5 ปีไปคนละทาง ประโยคนั้นบอกว่าโปรเจกต์เริ่มมาตั้งแต่ปี 2022 และถ้าเดินด้วยความเร็วเดิมต่อไป ก็ยังเหลืออีกราว 5 ปีกว่าจะเสร็จ เลข 5 ปีจึงไม่ใช่เวลาที่ทีมทุ่มลงไปแล้ว แต่เป็นเวลาที่คาดว่าจะต้องใช้ต่อจากนี้ ระยะห่างระหว่างสองฉบับนี้คือจุดที่ควรเริ่มอ่านเคสสตัดดี้ AI
งานจริงคือรื้อชุดทดสอบทั้งกองออกจาก Enzyme
ทุกครั้งที่ทีมแก้โค้ดหน้าเว็บสักจุด จะมีโค้ดอีกชุดคอยรันตรวจให้อัตโนมัติว่าปุ่มยังกดได้ ฟอร์มยังส่งได้ และหน้าจอยังแสดงผลเหมือนเดิมอยู่ไหม โค้ดชุดนั้นคือชุดทดสอบที่ทีมพัฒนาซอฟต์แวร์รันกันทุกวัน
Enzyme คือไลบรารีที่ Asana ใช้เขียนชุดทดสอบฝั่งหน้าเว็บมาตั้งแต่ต้น ปัญหาคือไม่มีคนดูแลต่อแล้ว พอไม่มีคนดูแล เครื่องมือฝั่งหน้าเว็บตัวอื่นก็อัปเกรดต่อไม่ได้ เพราะชุดทดสอบเก่าจะพังตามไปด้วย งานที่ค้างอยู่จึงเป็นการย้ายเทสต์ทั้งกองไปเขียนใหม่ด้วยไลบรารีทดสอบอย่าง React Testing Library ที่ยังมีทีมดูแลอยู่
เอเจนต์เขียนโค้ดทำงานแบบนี้ได้ดีจริง เพราะเป็นงานซ้ำๆ ปริมาณเยอะ และมีเกณฑ์ตัดสินชัดเจนในตัวเอง คือเทสต์ต้องยังรันผ่าน จุดที่ชวนสับสนคือ ตัวเลข «5 ปีเหลือ 2 สัปดาห์» หมายถึงเวลาที่ใช้กับงานรื้อของเก่า ไม่ใช่เวลาที่ใช้สร้างฟีเจอร์ใหม่จากศูนย์ ซึ่งเป็นงานที่ไม่มีเทสต์ชุดไหนตัดสินแทนได้ว่าผลลัพธ์ถูกหรือผิด
สิ่งที่บทความต้นทางไม่ได้บอกคือขนาดของงาน ในบทความระบุไว้แค่ว่าลบ Enzyme ออก โดยไม่มีจำนวนไฟล์ จำนวนเทสต์ หรือข้อมูลที่ช่วยให้คนนอกกะความยากได้ ข้อสังเกตนี้มาจากกระทู้บน Hacker News เว็บบอร์ดของสายพัฒนาซอฟต์แวร์ ที่ยกเคสนี้ไปถกกันเกือบร้อยคอมเมนต์
เลข 5 ปี กับ 6 ล้านดอลลาร์ คือประมาณการของงานที่ยังไม่ได้ทำ

ตัวเลขคู่นี้เป็นการประเมินกำลังคน ไม่ใช่บิลที่จ่ายไปแล้ว ซึ่งตอบคำถามว่าถ้าจะทำงานที่เหลือให้จบด้วยคนล้วน ต้องใช้คนเท่าไรและนานแค่ไหน ส่วนเลข 12,000 ดอลลาร์คือเงินที่จ่ายออกไปจริงในรอบนี้ การเอาตัวเลขสองชุดนี้มาหารกันตรงๆ จึงได้อัตราส่วนที่ดูน่าตื่นเต้น แต่นั่นคือการเทียบเงินจริงกับเงินสมมติ
ความเห็นหนึ่งในกระทู้เดียวกันตั้งข้อสังเกตต่อว่า ประมาณการหลักปีในองค์กรใหญ่มักไม่ได้วัดความยากของงานล้วนๆ แต่รวมเวลาประชุม เวลาประสานงานข้ามทีม และเอกสารที่ต้องเขียนเผื่อคนใหม่เอาไว้ด้วย ยิ่งโปรเจกต์ยาวหลายปี ก็ยิ่งเปลี่ยนคนทำไปหลายรอบ งานที่คนคนเดียวนั่งทำรวดเดียวอาจใช้เวลาไม่กี่เดือน แต่พอต้องกระจายให้หลายทีมช่วยกัน ตัวเลขก็บวมขึ้นเอง
ถึงอย่างนั้น ส่วนที่เหลือหลังหักตัวเลขการตลาดออกก็ยังน่าสนใจมากพอ งานที่ค้างมาตั้งแต่ปี 2022 จบลงในกรอบ 2 สัปดาห์ปฏิทิน โดยใช้เวลาทำงานของวิศวกรจริงราว 1.5 สัปดาห์ นั่นคือของจริงที่วัดได้ และมันเปลี่ยนคำตอบว่างานค้างกองไหนในบริษัทที่ควรหยิบขึ้นมาทำ
พรอมป์ต์ 5 ประโยค กับเอเจนต์ 4 ตัวที่วิ่งพร้อมกัน

วิธีที่ทีมใช้เรียบง่ายกว่าที่ตัวเลขชวนให้คิด คำสั่งตั้งต้นยาวประมาณ 5 ประโยค จากนั้นปล่อยเอเจนต์ทำงานพร้อมกันสูงสุด 4 ตัว แต่ละตัวทำงานบนสำเนาโค้ดของตัวเองแยกกัน งานจึงไม่ชนกันเองระหว่างทาง
มีวิศวกรเพียงคนเดียวคอยดูความคืบหน้าวันละ 2 ครั้ง พร้อมรีวิวและอนุมัติทุกการเปลี่ยนแปลงที่เอเจนต์เสนอ ทีมยังสรุปจากการทำงานรอบนี้ว่า คำสั่งที่เรียบง่ายให้ผลดีกว่าการเซ็ตอัปที่ละเอียดซับซ้อน
ตรงนี้มีของให้หยิบไปใช้จริงสองอย่าง อย่างแรกคือรูปแบบงานที่เหมาะจะปล่อยให้เอเจนต์ทำ คืองานที่ซ้ำ มีเกณฑ์ผ่านหรือไม่ผ่านชัด และแตกออกเป็นชิ้นเล็กที่รันคู่ขนานได้ อย่างที่สองคือขั้นตอนที่กินเวลาคนทั้งหมดในเคสนี้ไม่ใช่การเขียนคำสั่ง แต่เป็นการรีวิว การให้คนอนุมัติก่อน AI agent ลงมือจึงเป็นส่วนที่ตัดออกไม่ได้ ต่อให้เอเจนต์ทำงานได้เร็วแค่ไหนก็ตาม
การปล่อยหลายตัวพร้อมกันก็มีสิ่งที่ต้องแลก ยิ่งปล่อยพร้อมกันมาก งานที่รอคนรีวิวก็ยิ่งกองเร็วขึ้นตามไปด้วย ทีมที่มีคนตรวจคนเดียวจึงต้องกำหนดจำนวนเอเจนต์ให้ปริมาณงานที่ได้พอดีกับกำลังตรวจของคน
เทสต์ผ่าน ไม่ได้แปลว่ายังครอบคลุมเคสเดิมครบ
ประเด็นที่คนในกระทู้กลับมาถกซ้ำหลายรอบคือ จะยืนยันได้อย่างไรว่าผลลัพธ์ถูกต้องจริง การที่ชุดทดสอบใหม่รันผ่านหมดบอกได้แค่ว่าผ่าน แต่ไม่ได้พิสูจน์ว่ายังดักกรณีแปลกๆ ที่ของเดิมเคยดักไว้ได้ครบเท่าเดิม ส่วนคนนอกก็ไม่เห็นโค้ดก่อนและหลังแก้ จึงเทียบเองไม่ได้ว่าเทสต์สองชุดทำงานเหมือนกันจริงไหม
อีกเสียงหนึ่งสรุปสั้นกว่านั้น คือสิ่งที่ยืนยันได้มีแค่ว่า Asana เล่าแบบนี้จริง ซึ่งไม่มีใครสงสัยอยู่แล้ว ส่วนผลระยะยาวอย่างบั๊กที่อาจโผล่ตามมาหากชุดทดสอบครอบคลุมไม่ครบ ยังไม่มีรายงานติดตามผลออกมาให้ดู
แรงจูงใจของทั้งสองฝั่งก็อยู่ในหน้าเดียวกับเรื่องเล่า หน้าเคสสตัดดี้มีปุ่มติดต่อฝ่ายขายวางอยู่ ส่วน Asana เองเป็นบริษัทมหาชนที่ได้ภาพลักษณ์กลับไปเต็มๆ การมีแรงจูงใจไม่ได้แปลว่าใครโกหก แต่บอกแค่ว่าเรื่องนี้เล่าจากมุมของคนที่ได้ประโยชน์ ซึ่งเป็นมุมเดียวกับที่ทำให้เครื่องมือ AI ตัวใหม่ดูน่าตื่นเต้นกว่าของที่อยู่ข้างใน
น่าสังเกตว่าบทความต้นทางเองก็ไม่ได้เคลมเกินกว่านั้น โดยมีประโยคกำกับไว้ท้ายเรื่องด้วยซ้ำ
เช็กลิสต์ก่อนเชื่อเคสสตัดดี้ AI ครั้งหน้า
เคสแบบนี้จะทยอยออกมาอีกเรื่อยๆ และมักมาพร้อมตัวเลขคู่หนึ่งเสมอ คำถาม 5 ข้อข้างล่างนี้ใช้ได้กับทุกเคส ไล่ตอบตามลำดับแล้วจะเห็นว่าตัวเลขในพาดหัวมีที่มาอย่างไร
- งานจริงคืออะไร เรียกชื่อให้ได้ในบรรทัดเดียว ถ้าอ่านจบแล้วยังบอกไม่ได้ว่าเขาทำอะไรลงไป (ลบไลบรารีเก่าตัวหนึ่ง ย้ายฐานข้อมูล เขียนรายงานประจำเดือน) ตัวเลขก็ไม่มีอะไรให้เทียบ
- เลขฐานมาจากไหน และใครเป็นคนประเมิน ประมาณการของงานที่ยังไม่ได้ทำ กับเงินที่จ่ายไปแล้วจริง เป็นตัวเลขคนละแบบกัน คนที่ประเมินมักเป็นคนเดียวกับคนที่ได้ประโยชน์จากส่วนต่าง
- งานนี้ตัดสินถูกผิดด้วยอะไร งานที่มีเกณฑ์ชัดอย่างเทสต์ผ่านหรือไม่ผ่าน คืองานที่เอเจนต์ได้เปรียบ ถ้าเคสที่อ่านอยู่เป็นงานที่ไม่มีเกณฑ์แบบนั้น ตัวเลขจากเคสนี้ก็ยืมมาใช้ไม่ได้
- คนเข้ามาเกี่ยวข้องตรงไหนในกระบวนการ กี่คน เข้าไปดูบ่อยแค่ไหน และใครเซ็นอนุมัติผลลัพธ์ ถ้าบทความข้ามส่วนนี้ไป แปลว่ายังไม่มีใครบอกต้นทุนที่แท้จริงของการตรวจงาน
- มีผลติดตามหลังจบงานไหม ของที่ส่งได้เร็วกับของที่ใช้ได้ในระยะยาวเป็นคนละเรื่อง เคสที่เล่าตอนงานเพิ่งจบ ยังไม่ถึงช่วงที่บั๊กจะโผล่
ทั้ง 5 ข้อนี้ไม่ได้มีไว้เพื่อปฏิเสธเคสสตัดดี้ทุกอัน แต่มีไว้เพื่อแยกส่วนที่วัดได้ออกจากส่วนที่เป็นการประมาณ แล้วตัดสินใจจากส่วนแรก
ตัวเลขที่บอกอะไรได้มากที่สุดในเคสนี้กลับเป็นตัวเลขที่เล็กที่สุด คือวิศวกรหนึ่งคนที่เข้าไปดูงานวันละสองรอบ เพราะงานที่วิ่งเร็วขนาดนั้นยังต้องมีคนคอยตัดสินใจเรื่องการเปลี่ยนแปลงทุกครั้งอยู่ดี
ที่มา:
- บทความ Asana cleared 5 years of engineering work in 2 weeks with Codex จาก OpenAI
- ห้องคอมเมนต์ Hacker News ที่ถกเคสเดียวกัน
ชอบเรื่องแนวนี้ มีอีบุ๊คฟรีให้อ่านต่อ
Vibe Coding สำหรับคนไม่ใช่โปรแกรมเมอร์ ใช้ Claude Code สร้าง landing page, mini app และ prototype จริงโดยไม่ต้องเขียนโค้ด
กดสมัครแล้วเราจะส่งเทคนิค AI และของแจกใหม่ๆ ให้ทางอีเมล เลิกรับได้ตลอด
สร้าง AI Automation Pipeline ทุกแบบ ด้วย Agents และ Skills

ปูจากพื้นฐาน prompt, context และ cost ไปจนปั้น Skill สั่ง Agent กับ Sub-agent แล้วต่อทุกอย่างเป็น pipeline อัตโนมัติที่ออกแบบเองได้ ดูฟรี 7 บทก่อนตัดสินใจ


