การพัฒนาจะเปลี่ยนไปอย่างไรด้วย Claude Mythos และ Fable: จากการตรวจสอบ "การเขียนโค้ดที่ถูกต้อง" สู่ "การทำงานที่ถูกต้อง"

เมื่อวันที่ 9 มิถุนายน 2026 Anthropic ได้เปิดตัว Claude Mythos คลาส และ Claude Fable 5 ซึ่งเป็นโมเดลในสายตระกูลเดียวกันที่เปิดให้ใช้งานทั่วไป โดย Fable 5 มีจุดเด่นในด้าน "long-horizon agentic work (การทำงานแบบเอเจนต์ในระยะยาว)" และได้รับการอธิบายว่ามีความสามารถที่เพิ่มขึ้นในด้านวิศวกรรมซอฟต์แวร์ งานด้านความรู้ และงานที่เกี่ยวข้องกับการมองเห็น

อะไรคือสิ่งที่โมเดลรุ่นนี้จะเข้ามาเปลี่ยนแปลงในการทำงานจริง? คำตอบอยู่ที่แนวทางปฏิบัติของทีม Claude Code วิศวกรของทีมกล่าวว่า "Fable 5 ได้เปลี่ยนวิธีการทำงานในแต่ละวันของทีมไปแล้ว" และ "จากเดิมที่เราเคยต้องตรวจสอบว่า Claude ทำงานถูกต้องหรือไม่ ตอนนี้เราเปลี่ยนมาตรวจสอบว่าสิ่งที่มันทำนั้นเป็นงานที่ถูกต้องแล้วหรือยัง" บทความนี้จะสรุปข้อมูลจากทางการสำหรับหัวหน้าทีมพัฒนาและผู้รับผิดชอบทีมที่ใช้งาน AI โค้ดดิ้งเอเจนต์เป็นประจำ เพื่อให้เห็นว่า Claude Mythos / Fable 5 จะเข้ามาเปลี่ยนการพัฒนาซอฟต์แวร์อย่างไร และจะออกแบบการทำงานอย่างไรเพื่อให้สามารถมอบหมายงานได้อย่างเต็มที่โดยไม่ตกหลุมพรางของการ "ปล่อยวางโดยไม่ควบคุม"

Claude Mythos คือคลาสโมเดลของ Claude ที่มุ่งเน้นการทำงานของเอเจนต์แบบอัตโนมัติในระยะยาว โดย Claude Fable 5 เป็นโมเดลประสิทธิภาพสูงในสายตระกูลนี้ที่เปิดให้ใช้งานทั่วไป ในบทความนี้ เราจะมาทำความเข้าใจข้อมูลอย่างเป็นทางการก่อนว่าทั้งสองสิ่งนี้คืออะไร และมีการปรับปรุงในส่วนใดบ้าง

Anthropic ได้เปิดตัว Claude Fable 5 และ Claude Mythos 5 เมื่อวันที่ 9 มิถุนายน 2026 ตามการจัดวางตำแหน่งอย่างเป็นทางการ Fable 5 เป็นโมเดลประสิทธิภาพสูงที่อยู่ในคลาส Mythos ซึ่งเปิดให้ใช้งานทั่วไป (General Availability) โดยได้รับการแนะนำว่าเป็นโมเดลที่ทุกคนสามารถใช้ได้ในชีวิตประจำวัน

หากสรุปการเรียกชื่อให้เข้าใจง่ายขึ้น "Mythos" หมายถึงคลาส (ตระกูล) ส่วน "Fable 5" หมายถึงโมเดลเฉพาะที่เปิดให้ใช้งานอย่างแพร่หลายในตระกูลนั้น ในบทความนี้จะกล่าวถึงโมเดลรุ่นนี้ในฐานะรากฐานที่สนับสนุนการทำงานแบบอัตโนมัติของ Claude Code ซึ่งจะอธิบายรายละเอียดต่อไป ดังนั้นเนื้อหาหลังจากนี้จะเน้นไปที่ Fable 5 เป็นหลัก

Fable 5 ของจุดแข็งที่ทางผู้พัฒนาได้ระบุไว้คือ long-horizon agentic work (การทำงานของเอเจนต์ในระยะยาว) นอกจากนี้ยังมีการอธิบายว่าความสามารถในด้านวิศวกรรมซอฟต์แวร์ งานที่ใช้ความรู้ และงานด้านทัศนวิสัย (visual tasks) ได้รับการปรับปรุงให้ดียิ่งขึ้นด้วย

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

สิ่งที่แสดงให้เห็นอย่างชัดเจนว่าโมเดลรุ่นนี้เปลี่ยนการทำงานจริงไปอย่างไร คือประสบการณ์ตรงจากทีม Claude Code โดย Thariq Shihipar วิศวกรของทีม ได้กล่าวบน X (ชื่อเดิมคือ Twitter) ว่า "Claude Fable 5 changed how we work on the Claude Code team day to day (Fable 5 ได้เปลี่ยนวิธีการทำงานในแต่ละวันของทีม Claude Code)" และ "We used to verify that Claude did the work right. Now we verify that it's doing the right work. (เราเคยต้องตรวจสอบว่า Claude ทำงานถูกต้องหรือไม่ แต่ตอนนี้เรากำลังตรวจสอบว่ามันกำลังทำงานที่ถูกต้องอยู่หรือไม่)"

แม้ว่า Thariq จะได้รับการแนะนำในฐานะวิศวกรของทีม Claude Code แห่ง Anthropic แต่ควรทราบว่าโพสต์เหล่านี้ไม่ใช่เอกสารอย่างเป็นทางการ แต่เป็นประสบการณ์ส่วนตัวและโพสต์เชิงประชาสัมพันธ์ของสมาชิกในทีม อย่างไรก็ตาม ความรู้สึกที่ว่าจุดเน้นของการตรวจสอบกำลังเปลี่ยนจาก "ความถูกต้องของการเขียนโค้ด (Implementation)" ไปสู่ "ความถูกต้องของเนื้องาน (Task)" นั้น สอดคล้องกับการออกแบบฟีเจอร์อย่างเป็นทางการที่จะได้เห็นในบทถัดไป

การเปลี่ยนจุดเน้นของการตรวจสอบ หมายถึงการลดสัดส่วนงานที่ต้องตรวจสอบ "ความถูกต้องของการเขียนโค้ด (Implementation)" ทีละบรรทัดลง และเพิ่มสัดส่วนงานที่ต้องตรวจสอบว่า "กำลังทำงานที่ถูกต้องตามวัตถุประสงค์หรือไม่" แทน ทั้งนี้ไม่ได้หมายความว่าการตรวจสอบอย่างใดอย่างหนึ่งจะหายไป สิ่งที่เปลี่ยนไปคือการจัดสรรเวลาอันจำกัดของมนุษย์ว่าจะทุ่มเทให้กับงานส่วนใดมากกว่ากัน

การตรวจสอบแบบเดิมเน้นไปที่การอ่านความแตกต่างของโค้ดที่ AI เขียนขึ้นทีละบรรทัด เพื่อยืนยันความถูกต้องของไวยากรณ์ ประเภทข้อมูล ตรรกะ และการผ่านการทดสอบ นี่คือการตรวจสอบเพื่อดูว่า "ได้สร้างสิ่งที่ถูกต้องหรือไม่ (did it build the thing right)" ในช่วงที่เครื่องมือยังคงจำกัดอยู่เฉพาะจุด ผลลัพธ์ของ AI จะอยู่ที่เพียงไม่กี่บรรทัดหรือระดับฟังก์ชันเดียวเท่านั้น ซึ่งการที่มนุษย์จะตรวจสอบความถูกต้องผ่านการรีวิวถือเป็นเรื่องที่ทำได้จริง

ในขั้นตอนนี้ ภาระส่วนใหญ่ของผู้วิจารณ์ (reviewer) มาจากการที่ "ไม่สามารถเชื่อใจสิ่งที่ AI เขียนได้อย่างเต็มที่" ในความเป็นจริง แม้แต่ใน บทความเปรียบเทียบ Claude Code และ Codex ก็ได้ระบุว่าการนำผลลัพธ์จากเอเจนต์ไปใช้งานจริงโดยไม่ผ่านการรีวิวนั้นถือเป็นความผิดพลาดทั่วไป การอ่านความแตกต่างของโค้ดอย่างละเอียดจึงเป็นวิธีการประกันคุณภาพที่มีประสิทธิภาพในขณะที่ผลลัพธ์ยังมีขนาดเล็กอยู่

อีกด้านหนึ่งคือการตรวจสอบว่า "กำลังทำงานที่ถูกต้องอยู่หรือไม่ (is it doing the right work)" ต่อให้โค้ดจะไม่มีข้อผิดพลาด แต่หากสิ่งที่สร้างขึ้นไม่ตรงกับวัตถุประสงค์หรือข้อจำกัด การนำไปใช้งานนั้นถึงจะ "ถูกต้อง" แต่ก็ไม่ใช่ "งานที่ถูกต้อง" นี่คือการตรวจสอบความสมเหตุสมผลในขั้นตอนต้นน้ำ เช่น การตีความความต้องการ (Requirement), การตัดสินใจด้านการออกแบบ และการจัดลำดับความสำคัญ

ความรู้สึกที่ทีม Claude Code กล่าวไว้ตอนต้นว่า "ตอนนี้เรากำลังตรวจสอบว่ามันกำลังทำงานที่ถูกต้องอยู่หรือไม่" นั้น หมายถึงการตรวจสอบในขั้นตอนต้นน้ำนี้เอง ยิ่งเราสามารถมอบหมายงานที่เป็นชิ้นเป็นอันได้มากขึ้นเหมือนอย่าง Fable 5 สัดส่วนของการตรวจสอบทิศทางของสิ่งที่กำลังสร้างจะยิ่งมีความสำคัญมากกว่าการไล่เช็กความถูกต้องของโค้ดทีละบรรทัด ซึ่งความรู้สึกนี้ไม่ใช่สิ่งที่ระบุไว้ในเอกสารอย่างเป็นทางการ แต่เป็นประสบการณ์จากการปฏิบัติจริง และยังสอดคล้องกับการออกแบบฟีเจอร์อย่างเป็นทางการที่จะได้เห็นในบทถัดไปอีกด้วย

การตรวจสอบทั้งสองแบบนี้ไม่ใช่การแลกเปลี่ยน (trade-off) แต่เป็นคนละระดับกัน "ความถูกต้องของการนำไปใช้งาน" (Implementation correctness) สามารถรับประกันได้ง่ายขึ้นด้วยวิธีที่เป็นระบบมากกว่าเดิม ไม่ว่าจะเป็นการตรวจสอบประเภทข้อมูล (type checking), การทดสอบอัตโนมัติ (automated testing), CI และการตรวจสอบซึ่งกันและกันระหว่างเอเจนต์ที่จะกล่าวถึงต่อไป ดังนั้น ภาระของมนุษย์ที่ลดลงจึงเป็นส่วนของ "ความถูกต้องของการนำไปใช้งาน" เป็นหลัก

ในทางกลับกัน "งานที่ทำนั้นถูกต้องหรือไม่" (Correct work) เป็นสิ่งที่มนุษย์ที่เข้าใจวัตถุประสงค์ บริบท และข้อจำกัดเท่านั้นที่จะตัดสินได้ในท้ายที่สุด สิ่งนี้ไม่ได้หายไปไหน แต่ยังคงเป็นสิ่งที่มนุษย์ต้องให้ความสำคัญในการตรวจสอบ ทั้งนี้ กลไกที่ช่วยป้องกันความผิดพลาดเชิง "โครงสร้าง" (เช่น CLAUDE.md, กฎเกณฑ์ หรือการสร้าง CI guard) เป็นประเด็นที่แยกต่างหากจากการตรวจสอบ ซึ่งได้กล่าวถึงโดยละเอียดใน Harness Engineering แล้ว

การเปลี่ยนแปลงนี้ได้รับการสนับสนุนจากกลไก 3 ประการที่ทำให้ AI สามารถ "ดำเนินการงานขนาดใหญ่ได้ในคำสั่งเดียว รวมถึงการตรวจสอบผลลัพธ์" ได้แก่ การทำงานที่ขับเคลื่อนด้วยเป้าหมาย (Goal-driven execution), การตรวจสอบซึ่งกันและกันโดยซับเอเจนต์ (Sub-agent mutual verification) และโมเดลที่รองรับการทำงานระยะยาว (Long-running task models) โดยจะขออธิบายตามลำดับโดยอ้างอิงจากข้อมูลอย่างเป็นทางการดังนี้

/goal คือคำสั่งของ Claude Code ที่ช่วยให้คุณกำหนดเงื่อนไขความสำเร็จ เพื่อให้ Claude ทำงานต่อไปจนบรรลุเงื่อนไขนั้นได้โดยไม่ต้องคอยป้อนคำสั่งในทุกขั้นตอน เอกสารอย่างเป็นทางการ (code.claude.com/docs/en/goal) อธิบายไว้ว่า "เป็นการกำหนดเงื่อนไขความสำเร็จเพื่อให้ Claude ทำงานต่อไปจนถึงเป้าหมายโดยไม่ต้องรอรับคำสั่งทีละขั้นตอน" โดยจำเป็นต้องใช้ Claude Code เวอร์ชัน 2.1.139 ขึ้นไป

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

Dynamic workflows คือฟีเจอร์ของ Claude Code ที่ให้ Claude เขียนสคริปต์ JavaScript เพื่อจัดระเบียบและสั่งการซับเอเจนต์ (sub-agents) จำนวนมากในระดับสเกลใหญ่ โดยเอกสารอย่างเป็นทางการ (code.claude.com/docs/en/workflows) ได้ระบุถึงกรณีการใช้งาน เช่น การไล่ล่าบั๊กข้าม codebase, การย้ายระบบขนาด 500 ไฟล์ และการวิจัยที่ต้องตรวจสอบซอร์สโค้ดแบบไขว้กัน

สิ่งที่น่าสนใจคือมีการนำระบบการตรวจสอบมาไว้ในตัว โดยการออกแบบได้รวมเอา "adversarial verification" (การตรวจสอบแบบปรปักษ์) ซึ่งเป็นกระบวนการที่เอเจนต์อิสระจะตรวจสอบผลลัพธ์ของกันและกันอย่างวิพากษ์ก่อนที่จะรายงานผล อย่างไรก็ตาม ฟีเจอร์นี้ยังอยู่ในสถานะ Research Preview และการใช้งานจำเป็นต้องใช้ Claude Code v2.1.154 ขึ้นไป รวมถึงต้องมีแพ็กเกจแบบเสียค่าบริการ โดยสำหรับผู้ใช้ Pro สามารถเปิดใช้งานได้ผ่าน /config ทั้งนี้ควรทราบว่านี่ไม่ใช่ฟีเจอร์ที่ "ใครก็สามารถโยนงานให้ทำได้ทันที" แต่เป็นฟีเจอร์ขั้นสูงที่มีเงื่อนไขเบื้องต้นในการใช้งาน สำหรับแนวคิดการออกแบบที่เกี่ยวข้อง สามารถดูเพิ่มเติมได้ที่ เอเจนต์ออร์เคสตรา และ ระบบหลายเอเจนต์

สิ่งที่ขับเคลื่อนฟีเจอร์เหล่านี้ให้ใช้งานได้จริงคือโมเดลที่รองรับงานระยะยาวอย่าง Fable 5 ดังที่ได้เห็นในบทก่อนหน้า Fable 5 มีจุดแข็งในด้าน long-horizon agentic work ซึ่งช่วยขยายขอบเขตของงานที่สามารถจัดการได้ในคราวเดียว ด้วยเหตุนี้ ฟีเจอร์ที่เน้นการ "มอบหมายงานแบบกลุ่ม" อย่างการขับเคลื่อนด้วยเป้าหมายผ่าน /goal และ Dynamic workflows จึงสามารถใช้งานได้จริง

นอกจากนี้ ในการประกาศเปิดตัว Claude Opus 4.8 ได้มีการอธิบายเกี่ยวกับ Dynamic workflows ไว้ว่า "Claude จะวางแผนงาน ดำเนินการซับเอเจนต์แบบขนานหลายร้อยรายการภายในเซสชันเดียว (ซึ่งใน Opus 4.8 เอเจนต์สามารถทำงานได้ยาวนานขึ้น) จากนั้นจึงตรวจสอบผลลัพธ์ก่อนที่จะรายงานกลับไปยังผู้ใช้" การที่เอเจนต์สามารถจัดการงานได้มากขึ้นในคราวเดียวและสามารถตรวจสอบผลลัพธ์ด้วยตนเองก่อนส่งมอบ คือเบื้องหลังทางเทคนิคของยุค Mythos / Fable ที่สนับสนุนปรากฏการณ์ "การเปลี่ยนผ่านของแกนกลางในการตรวจสอบ" (shifting axis of verification)

เมื่อการทำงานเริ่มดำเนินไปเป็นกลุ่มก้อน เวลาของนักพัฒนาจะเปลี่ยนจากการคอยสั่งการทีละขั้นตอนว่า "จะเขียนโค้ดอย่างไร" ไปสู่การออกแบบว่า "จะทำอะไร ภายใต้ข้อจำกัดใด ถึงระดับไหน และจะตรวจสอบอย่างไร" ซึ่งเป็นการเปลี่ยนแปลงจากผู้สั่งการ ไปสู่การเป็นนักออกแบบที่ร่วมพัฒนาด้วยกัน

ในอดีต กระบวนการทำงานหลักคือการที่เราต้องคิดขั้นตอนการทำงานแต่ละขั้น สั่งการเอเจนต์ แล้วคอยรีวิวส่วนต่าง (diff) ที่ได้รับกลับมา แต่ในปัจจุบัน เพียงแค่ระบุเงื่อนไขความสำเร็จและข้อจำกัด เอเจนต์ก็สามารถดำเนินการในขอบเขตงานที่กว้างขึ้นได้ด้วยตัวเอง ซึ่งช่วยลดเวลาที่เคยใช้ไปกับการสั่งงานทีละขั้นตอนลงได้อย่างเห็นได้ชัด

ในสภาพแวดล้อมการพัฒนาของบริษัทเรา จุดเน้นของการรีวิวก็กำลังเปลี่ยนจากการ "ไล่ดูส่วนต่างทีละบรรทัด" ไปสู่การ "ตรวจสอบว่าการเปลี่ยนแปลงนี้เหมาะสมเมื่อเทียบกับเงื่อนไขการยอมรับ (acceptance criteria) และเจตนาในการออกแบบหรือไม่" เรามีความรู้สึกว่าน้ำหนักของการตั้งคำถามว่า "การเปลี่ยนแปลงนั้นมุ่งไปในทิศทางที่ถูกต้องตามความต้องการหรือไม่" มีมากขึ้นเมื่อเทียบกับการดูตัวส่วนต่างเพียงอย่างเดียว การที่ต้องสั่งงานทีละขั้นตอนลดน้อยลง ทำให้เรามีพื้นที่ในการคิดมากขึ้นว่าสิ่งใดที่ควรตรวจสอบ

เวลาที่เหลือจากการสั่งงานแบบทีละขั้นตอนจะถูกนำไปใช้กับการออกแบบในขั้นตอนต้นน้ำ (upstream design) โดยเฉพาะอย่างยิ่งคือการออกแบบว่าจะกำหนดวัตถุประสงค์ ภูมิหลัง ข้อจำกัด เงื่อนไขความสำเร็จ และวิธีการตรวจสอบอย่างไร ในแง่ที่ว่าคุณภาพของบริบทที่ส่งให้กับเอเจนต์เป็นตัวกำหนดผลลัพธ์ สิ่งนี้จึงเป็นแนวทางที่ต่อเนื่องจากการทำ Prompt Engineering ไปสู่ Context Engineering

นอกเหนือจากวิธีการทำงานของรายบุคคลแล้ว การเคลื่อนไหวเพื่อสร้างมาตรฐานในการออกแบบนี้ในระดับทีมก็มีความสำคัญเช่นกัน การไม่ปล่อยให้วิธีการเขียนเงื่อนไขความสำเร็จหรือรูปแบบการตรวจสอบกลายเป็นเรื่องเฉพาะบุคคล แต่ใช้วิธีการแบ่งปันผ่านกลไกอย่าง CLAUDE.md, Skills และ Hooks นั้น ได้ถูกกล่าวถึงไว้ใน คู่มือการใช้งาน Claude Code สำหรับทีม การเปลี่ยนเวลาไปใช้กับการออกแบบไม่ใช่การให้ทุกคนต่างคนต่างพยายามแบบเฉพาะหน้า แต่เป็นการเปลี่ยนวิธีการมอบหมายงานและวิธีการตรวจสอบให้กลายเป็นสินทรัพย์ของทีม

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

คำกล่าวอ้างที่พบเห็นได้ทั่วไปบน SNS อย่าง "ไม่ต้องสั่งงานละเอียดอีกต่อไป" หรือ "ปล่อยให้เป็นหน้าที่ของ AI ได้เลย" นั้น ควรตีความว่าเป็นเพียงเรื่องเล่าเชิงโฆษณาชวนเชื่อมากกว่าความเป็นจริง เพราะการที่ความสามารถของ AI พัฒนาขึ้น ไม่ได้หมายความว่า "ไม่ต้องมีการกำกับดูแล" แต่หมายความว่า "ความสำคัญของการออกแบบเป้าหมายและการออกแบบการตรวจสอบนั้นเพิ่มมากขึ้น"

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

ข้อสันนิษฐานนี้ไม่ได้มาจากมุมมองส่วนตัวของผู้พัฒนา แต่ได้รับการสนับสนุนจากการออกแบบอย่างเป็นทางการ หน้าแนะนำ Claude Code ของ Anthropic (anthropic.com/product/claude-code) ระบุไว้อย่างชัดเจนว่า "Human oversight remains central (การกำกับดูแลโดยมนุษย์ยังคงเป็นหัวใจสำคัญ)" โดยอธิบายว่าระบบจะขออนุญาตก่อนทำการแก้ไขไฟล์หรือเรียกใช้คำสั่ง และนักพัฒนาจะเป็นผู้ควบคุมสิ่งที่ถูกคอมมิต (commit) อย่างสมบูรณ์

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

ในการปฏิบัติงานจริง จำเป็นต้องมีการออกแบบที่สร้างสมดุลระหว่าง "การมอบหมายงานอย่างเต็มที่" และ "การตรวจสอบอย่างแม่นยำ" หัวใจสำคัญคือการกำหนด 3 สิ่งนี้ไว้ล่วงหน้าก่อนเริ่มงาน ได้แก่ การออกแบบอินพุต (Input), การออกแบบการตรวจสอบ (Verification) และการตัดสินใจส่งมอบงาน (Shipment decision) ต่อไปนี้คือวิธีการส่งมอบงานอย่างเป็นรูปธรรมตามลำดับ

ประการแรก คือการออกแบบอินพุต (Input) โดยต้องส่งมอบชุดข้อมูลที่ประกอบด้วย วัตถุประสงค์ (Goal), บริบท (Background), ข้อจำกัด (Constraints) และเงื่อนไขความสำเร็จ (Completion criteria) ให้กับเอเจนต์ ไม่ใช่การสั่งงานแบบแยกส่วนเป็นครั้งๆ แต่เป็นการให้ข้อมูลในคราวเดียวว่า "ทำไปเพื่ออะไร" "อยู่ภายใต้สมมติฐานใด" "ต้องรักษาเงื่อนไขอะไรบ้าง" และ "ทำถึงแค่ไหนจึงจะถือว่าเสร็จสิ้น"

ตัวอย่างเช่น หากใช้ /goal วิธีการส่งคำสั่งจะเป็นดังนี้: "จงดำเนินการตามสเปกนี้และทำงานต่อไปจนกว่าจะผ่านเงื่อนไขการยอมรับ (Acceptance criteria) ทั้งหมด โดยมีข้อแม้ว่าห้ามทำลายความเข้ากันได้ของ API เดิม และหากจำเป็นต้องเปลี่ยน DB schema ให้เสนอแผนการล่วงหน้า" ในที่นี้ "ห้ามทำลาย API เดิม" และ "การเสนอเปลี่ยน schema ล่วงหน้า" คือข้อจำกัด ส่วน "จนกว่าจะผ่านเงื่อนไขการยอมรับ" คือเงื่อนไขความสำเร็จ ยิ่งกำหนดข้อจำกัดและเงื่อนไขความสำเร็จไว้ตั้งแต่ต้นชัดเจนเท่าไร ก็จะยิ่งช่วยลดการทำงานที่ออกนอกลู่นอกทางเมื่อมอบหมายงานเป็นชุดได้มากขึ้นเท่านั้น

ประการที่สอง คือการออกแบบการตรวจสอบ (Verification) โดยต้องกำหนดเงื่อนไขการยอมรับ (Acceptance Criteria) และรูปแบบของรายงานที่ต้องการให้ส่งก่อนเริ่มงาน ตัวอย่างเช่น หากระบุว่า "หลังจากดำเนินการเสร็จสิ้น ให้รายงานไฟล์ที่มีการเปลี่ยนแปลง เนื้อหาที่ทำไป จุดที่ยังไม่ได้ดำเนินการ ผลการทดสอบ และส่วนที่แตกต่างจากข้อกำหนด" จะช่วยให้สามารถรีวิวผลลัพธ์จากมุมมองที่ว่า "เป็นงานที่ถูกต้องหรือไม่" ได้ง่ายขึ้น

กลไกที่ให้เอเจนต์รีวิว findings ของกันและกัน เช่น Dynamic workflows จะช่วยทำให้การตรวจสอบนี้กลายเป็นระบบอัตโนมัติในฐานะตัวกรองขั้นต้น อย่างไรก็ตาม นี่ไม่ใช่การทดแทนการตรวจสอบโดยมนุษย์ แต่เป็นการเตรียมขั้นตอนก่อนหน้าเพื่อให้มนุษย์สามารถโฟกัสไปที่การตรวจสอบขั้นสุดท้ายได้ โดยเกณฑ์ที่ใช้ตัดสินว่าอะไรคือ "งานที่ถูกต้อง" นั้น มนุษย์ยังคงจำเป็นต้องเป็นผู้กำหนดอยู่เช่นเดิม

ประการที่สาม คือการตัดสินใจปล่อยผลิตภัณฑ์ (Shipment decision) มนุษย์จะเป็นผู้ตรวจสอบความแตกต่าง ผลลัพธ์การทดสอบ ความแตกต่างจากข้อกำหนด และประเด็นที่ยังไม่ได้รับการแก้ไขที่เอเจนต์ส่งกลับมา เพื่อตัดสินใจว่าจะปล่อยผลิตภัณฑ์หรือไม่ ดังที่กล่าวไปข้างต้น เนื่องจากมีการออกแบบให้ผู้พัฒนาเป็นผู้ควบคุมว่าจะคอมมิต (commit) สิ่งใด ดังนั้นจึงไม่ข้ามขั้นตอนที่เป็นด่านสุดท้ายนี้

โดยเฉพาะอย่างยิ่ง การเปลี่ยนแปลงที่เกี่ยวข้องกับส่วนที่มีผลกระทบสูงหากเกิดข้อผิดพลาด เช่น การยืนยันตัวตน (Authentication) สิทธิ์การเข้าถึง (Authorization) การแยกเทแนนท์ (Tenant isolation) และการเรียกเก็บเงิน (Billing) ยิ่งเป็นงานที่มอบหมายให้ทำเป็นกลุ่มก้อนมากเท่าใด ก็ยิ่งต้องตรวจสอบอย่างระมัดระวังมากเท่านั้น การที่ "ผ่านการทดสอบ" อาจเป็นหลักฐานว่า "การนำไปใช้งาน (Implementation) ถูกต้อง" แต่ไม่ใช่เครื่องพิสูจน์ว่า "กำลังทำงานอย่างถูกต้อง" การที่มนุษย์เป็นผู้ตัดสินใจว่าจะปล่อยหรือส่งกลับไปแก้ไข โดยพิจารณาเทียบกับเงื่อนไขการยอมรับ (Acceptance criteria) และทำความเข้าใจประเด็นที่ยังค้างอยู่ คือบทสรุปของการออกแบบวิธีการมอบหมายงานนี้

จากนี้ไป จะขอตอบ 3 คำถามที่พบบ่อยในหน้างาน โดยสรุปเฉพาะประเด็นสำคัญ

สรุปคือ เป็นไปได้ และยิ่งทีมมีขนาดเล็กก็ยิ่งเห็นผลชัดเจน เพราะในทีมที่มีบุคลากรสำหรับทำ Review จำกัด การมุ่งเน้นไปที่การออกแบบเงื่อนไขความสำเร็จ (Completion criteria) ให้แม่นยำ แล้วทุ่มทรัพยากรบุคคลไปที่การตรวจสอบและการตัดสินใจขั้นสุดท้ายนั้น เป็นแนวทางที่สมเหตุสมผลกว่าการไล่ตามรายละเอียดการ Implement ทั้งหมด

อย่างไรก็ตาม ฟีเจอร์ดังกล่าวมีข้อกำหนดเบื้องต้น โดย /goal ต้องใช้ใน Claude Code v2.1.139 ขึ้นไป ส่วน Dynamic workflows ต้องใช้ใน v2.1.154 ขึ้นไปและต้องเป็นแพ็กเกจแบบชำระเงิน (สำหรับ Pro สามารถเปิดใช้งานได้จาก /config) ซึ่งฟีเจอร์หลังนี้ยังอยู่ในขั้นตอน Research Preview แนะนำให้เริ่มจากการปรับตัวด้วยการกำหนดเงื่อนไขความสำเร็จผ่าน /goal ก่อน แล้วจึงขยายไปใช้ Dynamic workflows ตามความจำเป็น ซึ่งเป็นลำดับขั้นตอนที่เหมาะสมที่สุด

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

นอกจากนี้ แทนที่จะให้มนุษย์คอยเฝ้าดูอยู่ตลอดเวลา การเตรียมการป้องกันข้อผิดพลาดด้วย "โครงสร้าง" เช่น กฎการอนุญาต, CI Guard และข้อกำหนดของ Repository จะช่วยให้ระบบมีความเสถียรยิ่งขึ้น การออกแบบแนวป้องกันเชิงโครงสร้างนี้ได้อธิบายไว้อย่างละเอียดใน Harness Engineering

ควรเริ่มต้นจากงานที่สามารถเขียนเงื่อนไขความสำเร็จ (Completion Criteria) ได้อย่างชัดเจน และมีผลกระทบจำกัดหากเกิดความผิดพลาด ตัวอย่างเช่น การขยายขอบเขตการทดสอบ (Test expansion), การทำ Refactoring หรือการย้ายระบบที่เป็นงานประจำ (Routine tasks) และการสำรวจข้อมูลในภาพรวม (Cross-cutting research) ซึ่งเป็นงานที่กำหนดเงื่อนไขการยอมรับ (Acceptance criteria) ได้ง่าย และเหมาะสำหรับการฝึกมอบหมายงานเป็นส่วนๆ

ในทางกลับกัน งานที่มีความเห็นเรื่องข้อกำหนดไม่ตรงกัน หรือเป็นงานที่ต้องแตะต้องเส้นทางสำคัญของระบบงานจริง (Production critical path) ควรเก็บไว้ทำหลังจากที่มีความเชี่ยวชาญในการมอบหมายงานมากขึ้นแล้ว สำหรับเกณฑ์การตัดสินใจว่าจะมอบหมายงานระดับความละเอียดใดให้กับเครื่องมือตัวไหน สามารถอ้างอิงข้อมูลจากการทดสอบจริงใน บทความเปรียบเทียบ Claude Code และ Codex ได้

คลาส Claude Mythos และ Fable 5 ที่ Anthropic เปิดตัวนั้น มีจุดแข็งในด้านการทำงานแบบเอเจนต์ระยะยาว และกำลังเปลี่ยนวิธีการพัฒนาซอฟต์แวร์ไปอย่างมั่นคง จุดเน้นของการตรวจสอบโดยมนุษย์ได้เปลี่ยนจาก "การตรวจสอบว่าเขียนโค้ดถูกต้องหรือไม่" ไปสู่ "การตรวจสอบว่ากำลังทำงานที่ถูกต้องตั้งแต่แรกหรือไม่" โดยมีปัจจัยสนับสนุนทางเทคนิค ได้แก่ การขับเคลื่อนเงื่อนไขความสำเร็จด้วย /goal การตรวจสอบซึ่งกันและกันของซับเอเจนต์ผ่าน Dynamic workflows และโมเดลที่แข็งแกร่งในงานระยะยาวอย่าง Opus 4.8

อย่างไรก็ตาม การที่ความสามารถเพิ่มขึ้นไม่ได้หมายความว่าเราสามารถ "ปล่อยวางงานทั้งหมด" ได้ ในการออกแบบอย่างเป็นทางการ มนุษย์ยังคงเป็นศูนย์กลางของการกำกับดูแล และมนุษย์เป็นผู้ตัดสินใจว่าจะส่งมอบงานอะไร ดังนั้น ในการปฏิบัติงานจริง หัวใจสำคัญคือการสร้างสมดุลระหว่างการออกแบบวัตถุประสงค์ ข้อจำกัด เงื่อนไขความสำเร็จ และวิธีการตรวจสอบเพื่อมอบหมายงานในวงกว้าง กับการถือสิทธิ์ตัดสินใจขั้นสุดท้ายโดยอ้างอิงตามเกณฑ์การยอมรับงาน (Acceptance Criteria)

บริษัทของเราให้การสนับสนุนการออกแบบกระบวนการทำงานและการพัฒนาที่ตั้งอยู่บนพื้นฐานของ AI เอเจนต์ เหล่านี้ รวมถึงการนำไปปรับใช้จริงในหน้างาน หากท่านต้องการคำปรึกษาเกี่ยวกับการออกแบบว่า "ควรเริ่มมอบหมายงานจากงานใด และด้วยเงื่อนไขความสำเร็จแบบใด" สามารถติดต่อเราได้ทันที พร้อมศึกษาข้อมูลพื้นฐานเกี่ยวกับ AI เอเจนต์ไปพร้อมกัน