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

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

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

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

Anthropic は 2026 年 6 月 9 日に Claude Fable 5 と Claude Mythos 5 を提供開始した。公式の位置づけでは、Fable 5 は Mythos クラスに属する一般提供（一般利用向け）の高性能モデルであり、誰もが日常的に使えるモデルとして案内されている。

名前の整理をしておくと、「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の出力はせいぜい数行から一つの関数程度にとどまり、その正しさを人間がレビューで担保するのが現実的だった。

この段階では、レビュアーの負担の多くは「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-agents), และโมเดลที่รองรับการทำงานระยะยาว โดยจะขออธิบายตามลำดับโดยอ้างอิงจากข้อมูลอย่างเป็นทางการ

/goal は、完了条件を設定すると、毎ステップ指示しなくても Claude がその条件に向かって作業を続ける Claude Code のコマンドである。公式ドキュメント（code.claude.com/docs/en/goal）は「完了条件を設定し、Claude が一手ごとの指示なしにそこへ向かって作業を続ける」と説明している。利用には Claude Code v2.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 なら丸投げで正しくやってくれる」というのは、危険な誤読である。 (การคิดว่า "ถ้าเป็น 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 จะช่วยทำให้การตรวจสอบนี้กลายเป็นระบบอัตโนมัติในฐานะตัวกรองขั้นต้น อย่างไรก็ตาม นี่ไม่ใช่การทดแทนการตรวจสอบโดยมนุษย์ แต่เป็นการเตรียมขั้นตอนก่อนหน้าเพื่อให้มนุษย์สามารถโฟกัสไปที่การตรวจสอบขั้นสุดท้ายได้ โดยเกณฑ์ที่ใช้ตัดสินว่าอะไรคือ "งานที่ถูกต้อง" นั้น มนุษย์ยังคงจำเป็นต้องเป็นผู้กำหนดอยู่เช่นเดิม

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

โดยเฉพาะอย่างยิ่ง การเปลี่ยนแปลงที่เกี่ยวข้องกับส่วนที่มีผลกระทบสูงหากเกิดข้อผิดพลาด เช่น การยืนยันตัวตน (Authentication), สิทธิ์การเข้าถึง (Authorization), การแยกเทนเนอร์ (Tenant Isolation) และการเรียกเก็บเงิน (Billing) ยิ่งเป็นงานที่มอบหมายให้ทำเป็นกลุ่มก้อน ก็ยิ่งต้องตรวจสอบอย่างระมัดระวัง "การที่ผ่านการทดสอบ" อาจเป็นหลักฐานว่า "การนำไปใช้งานนั้นถูกต้อง" แต่ไม่ใช่เครื่องพิสูจน์ว่า "กำลังทำงานอย่างถูกต้อง" การที่มนุษย์เป็นผู้ตัดสินใจว่าจะปล่อยงานออกไปหรือส่งกลับไปแก้ไข โดยพิจารณาจากเงื่อนไขการยอมรับ (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 เอเจนต์ไปพร้อมกัน