Claude Fable 5 เป็นหัว ที่เหลือเป็นมือ

เช้าวันหนึ่งเราสลับโมเดลหลักใน Claude Code เป็น Claude Fable 5 โมเดลตระกูลใหม่ที่ Anthropic วางไว้เหนือ Opus ฉลาดขึ้นจริง แต่สิ่งที่มาพร้อมกันคือราคาต่อ token ที่สูงกว่า และโควต้าที่หมดไวกว่าเดิมมาก ใช้แบบเดิมที่เคยใช้ Opus ไม่ได้แล้ว ให้มันนั่งไล่หาไฟล์ เขียน boilerplate แก้ typo เหมือนที่เคยทำ เท่ากับเอาสมองที่แพงที่สุดในบ้านไปนั่งเดินเอกสาร

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

บทความนี้เล่าทั้งวิธีตั้งทีม ผลของงานแรก และจุดที่มันพังให้เห็น ตัวเลขทุกตัวมาจาก session จริงวันที่ 3 ก.ค. 2026 ไม่มีตัวไหนแต่งเพิ่ม

ช่วงที่ 1ทำไมโมเดลแพงสุดควรเป็นแค่ "หัว"

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

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

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

ค่าใช้จ่ายก็เป็นเหตุผลเดียวกัน โมเดลระดับ Fable โควต้าหมดไวพอที่จะบังคับให้เลือกว่างานไหนคุ้มกับสมองระดับนั้น (ตัวเลขราคาแต่ละโมเดลเราเคยแจกแจงไว้ในบทความเรื่องราคา Claude Code) พอถูกบังคับให้เลือก ก็พบว่างานส่วนใหญ่ไม่เคยต้องการโมเดลใหญ่เลยต่างหาก

ช่วงที่ 2Claude Code subagents: ตั้งทีมหัวกับมือ

Claude Code มีกลไก subagents ในตัวอยู่แล้ว (เอกสารทางการ) เราแค่สร้างไฟล์ agent สั้นๆ ไว้ที่ .claude/agents/ กำหนดว่าแต่ละตัวชื่ออะไร ใช้โมเดลไหน และรับงานแบบไหน ทีมของเราตอนนี้มีสามตัวบวกเพื่อนต่างค่ายอีกหนึ่ง

รูปแบบนี้ในชุมชน Claude Code เรียกกันว่า claude orchestrator หรือ orchestrator pattern จุดชี้ขาดไม่ได้อยู่ที่จำนวน agents แต่อยู่ที่กติกาที่เขียนกำกับไว้ให้หัวต่างหาก ของเรามีสามข้อ

1. หัวห้ามทำ grunt work เจองานค้นหา งานไล่อ่าน งานกลไกเมื่อไหร่ ให้แตกงานส่งมือทันที ถึงจะ "ทำเองก็ได้" ก็ห้าม เพราะทุก token ที่หัวเผาไปกับงานพวกนี้คือโควต้าที่หายไปจากงานคิด
2. โชว์แผนก่อนลงมือ หัวต้องแตกงานให้เห็นก่อนว่าจะส่งอะไรให้ใคร คนยังได้เห็นและท้วงได้ก่อนเงินไหลออก
3. ห้ามเอาหัวไปฝังใน daemon งานอัตโนมัติที่รันตลอดเวลาใช้โมเดลเล็กหรือกลางพอ โมเดลแพงเอาไว้เรียกเป็นครั้งๆ ตอนต้องคิดจริงเท่านั้น

ไฟล์ agent จริงกับ routing rules ฉบับเต็ม รวมเป็นชุดเครื่องมือท้ายบทความนี้ กรอกอีเมลแล้วหยิบไปใช้ได้เลย ส่วนโครงแบบที่เล่าตรงนี้ก็พอให้ประกอบเองได้ทั้งหมด

ก่อนใช้เพื่อนต่างค่าย มีบทเรียนราคาเล็กๆ หนึ่งเรื่อง เราทดสอบว่า Codex ต่อติดไหมด้วยการส่งคำว่า ping ไปให้ตอบ pong กลับมา คำตอบเดียวคำนั้นกินไป 26,800 tokens เพราะ agent ระดับนี้ตื่นมาพร้อม context ของมันทั้งชุด ไม่ใช่แค่คำถามที่เราส่งไป แม้แต่ "การเช็คว่าเครื่องมือใช้ได้" ก็มีราคา ต้องนับรวมในต้นทุนด้วย

ช่วงที่ 3งานจริงงานแรก: ประเมิน migration ด้วย 4 agents

โจทย์ที่เข้ามาคือเครื่องมือ CLI (โปรแกรมที่เรียกใช้ผ่าน command line) ตัวหนึ่งที่ automation ของเราใช้อยู่บนสองเครื่อง มี Rust port ตัวใหม่ออกมา น่าย้ายไหม คำถามแบบนี้ตอบมั่วง่ายมาก เพราะคำตอบที่ฟังดูฉลาด ("Rust เร็วกว่า ย้ายเลย") กับคำตอบที่ถูก อยู่คนละที่กัน

แตกงานเป็นสามมุมมอง ยิงพร้อมกัน

หัวแตกงานสำรวจออกเป็นสามชิ้นที่ไม่ต้องรอกัน แล้ว fan-out ให้มือสามตัววิ่งขนาน

• inventory เครื่องแรก (Haiku) ไล่ว่าเครื่อง Mac ใช้เครื่องมือตัวนี้จากตรงไหนบ้าง คำสั่งไหน service ไหน cron ไหน
• inventory เครื่องที่สอง (Haiku) แบบเดียวกันกับ server อีกตัว
• อ่าน repo ของ Rust port (ตัวใหญ่กว่า) เข้าไปดูว่า port ตัวนี้ครอบคำสั่งที่เราใช้ครบไหม config เข้ากันไหม โปรโตคอลระหว่างเครื่องเข้ากันไหม

ผลที่กลับมาน่าสนใจกว่าที่คิด ส่วนที่เราใช้งานจริงเล็กนิดเดียว มีแค่ 5 จุดเชื่อมกับราวๆ 9 คำสั่ง ทั้งที่ตัวเครื่องมือมีความสามารถมากกว่านั้นมาก ส่วน repo ฝั่ง port ก็มีทั้งข่าวดีและจุดที่น่าห่วง ข่าวดีคือ config ใช้ไฟล์เดิมได้และโปรโตคอลเข้ากันได้แบบพิสูจน์จากไฟล์ทดสอบจริง ไม่ใช่แค่อ่านจากเอกสาร จุดที่น่าห่วงคือ port นี้อายุ 8 วัน มี 470 commits ที่ส่วนใหญ่เป็นโค้ดที่เครื่องเขียน (machine-generated) และ flag ตัวหนึ่งที่ระบบเราพึ่งพาอยู่ทุกวัน หายไปจาก port

หัวสังเคราะห์ แล้วตัดสินใจไม่เชื่อรายงานเปล่าๆ

ถึงตรงนี้รายงานสามฉบับบอกตรงกันว่า "น่าจะย้ายได้แบบมีเงื่อนไข" แต่ทั้งหมดมาจากการอ่าน ยังไม่มีใครแตะ binary จริงเลย หัวเลยสั่งงานชิ้นที่สี่: smoke test กับของจริง แบบที่พังแล้วเสียหายเป็นศูนย์ ติดตั้ง port ตัวใหม่คู่ขนานกับตัวเดิมโดยใช้คนละชื่อ ชี้ config เดียวกัน แล้วรันเฉพาะคำสั่งอ่านอย่างเดียว ระบบจริงไม่โดนแตะแม้แต่จุดเดียว

ผล smoke test คือจุดที่งานนี้คุ้มที่สุด เพราะมันจับสิ่งที่รายงานจากการอ่านทั้งสามฉบับมองไม่เห็น

• คำสั่งกลุ่มที่เราใช้บ่อยที่สุด ใช้ไม่ได้จริง เพราะใน port ใหม่ คำสั่งกลุ่มนั้นเป็น plugin ภาษา JS ที่ port ยังโหลดไม่ได้ ตัวเช็ค (probe) ของระบบตรวจสุขภาพเราพังไป 2 ใน 3 ทันที ที่เจ็บคือตอนอ่าน repo เราเคยสรุปว่า gap เรื่อง plugin "ไม่กระทบเรา" เพราะเช็คแล้วไม่มี plugin ใน config ทั้งสองเครื่อง ความจริงคือคำสั่งพื้นฐานที่ใช้ทุกวันนั่นแหละคือ plugin
• รูปแบบคำสั่งเปลี่ยน ตัวเดิมรับ port เป็นตัวเลขต่อท้าย ตัวใหม่บังคับใส่ flag ทุกจุดที่ automation เรียกด้วยรูปแบบเดิมจะพังเงียบๆ
• การคุยข้ามเวอร์ชันยังสรุปไม่ได้ client ตัวใหม่ยิงไปหา server ตัวเดิมแล้วได้ error ที่แยกไม่ออกว่าผิดที่ลายเซ็นหรือผิดที่รูปแบบ request ต้องทดสอบแบบจับคู่จริงก่อนถึงจะรู้

คำตัดสินเลยไม่ใช่ "ย้าย" หรือ "ไม่ย้าย" แต่เป็น ทิศทางใช่ แต่จังหวะยังไม่ใช่ พักเรื่องนี้ไว้พร้อมเงื่อนไขชัดๆ ว่าเจออะไรเมื่อไหร่ค่อยกลับมาทดสอบซ้ำ binary กับขั้นตอนทดสอบเก็บไว้พร้อมแล้ว ทั้งหมดนี้จบโดยเสียหายศูนย์บาท และหัวไม่ได้อ่าน repo เองแม้แต่ไฟล์เดียว

ช่วงที่ 4จุดที่พัง กับจังหวะที่หัวต้องลงมือเอง

test เขียวที่ไม่ได้แปลว่าผ่าน

ก่อน smoke test เรามี test suite ของระบบตรวจสุขภาพอยู่แล้ว รันกับ port ใหม่ได้ 5/5 ผ่านหมด ถ้าหยุดตรงนั้นก็คงสรุปว่าเข้ากันได้ แต่พอ smoke test กับ binary จริง probe พังไป 2 ใน 3 อ้าว ทำไมขัดกัน คำตอบคือ suite นั้น mock ชั้นที่เรียก binary ไว้ มันเลยทดสอบ logic ของตัวเองโดยไม่เคยแตะ binary จริง เขียวทั้งกระดานแต่พิสูจน์อะไรไม่ได้เลย เราเรียกอาการนี้ว่า false-green

วิธีกันที่ใช้ได้จริงคือ positive control: ก่อนเชื่อผลเขียวของ checker ตัวไหน หาเคสที่รู้อยู่แล้วว่าต้องแดง แล้วดูว่ามันแดงจริงไหม ถ้าเคสที่ควรพังยังเขียว แปลว่าสิ่งที่เรากำลังอ่านไม่ใช่ผลทดสอบ แต่เป็นภาพลวง

orchestrator ไม่ใช่คนที่ห้ามแตะทุกอย่าง

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

หลุมพรางที่เราโดนจับได้สองครั้งในวันเดียว

เรื่องสุดท้ายไม่ใช่เรื่องเทคนิค แต่เป็นพฤติกรรมของ orchestrator เอง พอมีช่องทาง "ส่งต่อ" อยู่ในมือ อะไรๆ ก็ดูควรส่งต่อไปหมด วันนั้นเราโดนจับได้สองครั้ง ครั้งแรกคือ bug ที่แก้เองได้ในสองบรรทัด แต่เรา route ไปเข้าคิวให้คนอื่นทำ ครั้งที่สองคือตั้งเกณฑ์ขึ้นมาเองว่า "ต้องมีตัวอย่างจริง 2-3 งานก่อนถึงจะเขียนบทความนี้ได้" ทั้งที่หลักฐานจาก session เดียวก็พอแล้ว เกณฑ์ที่ตั้งเองกลายเป็นข้ออ้างให้ไม่ต้องลงมือ โดยแต่งตัวมาเป็นความรอบคอบ ถ้ากำลังจะตั้ง orchestrator ของตัวเอง เผื่อใจไว้ว่าจุดที่พลาดง่ายแบบนี้มากับแพ็คเกจด้วย

agent เงียบ ไม่ได้แปลว่าตาย

เกร็ดเล็กแต่ประหยัดเงินจริง: agent ที่รับงานอ่าน repo เงียบไปนานจนใจอยากสั่ง kill แล้วเริ่มใหม่ สัญชาตญาณบอกว่าค้าง แต่ความจริงคืองานมันลึก พอสะกิดถามความคืบหน้าแทนที่จะฆ่าทิ้ง ปรากฏว่างานเดินอยู่และผลที่กลับมาลึกกว่าที่หัวจะทำเองได้ ฆ่า agent ที่กำลังทำงาน = จ่ายเงินซ้ำเพื่อได้ของช้าลง

ช่วงที่ 5เอาไปใช้กับงานของคุณ

เริ่มยังไงดี

1. สร้าง agent สามตัวแรก ไฟล์ละไม่กี่บรรทัดใน .claude/agents/ ตัวคิดลึก ตัวทำงานเร็ว ตัวค้นหา จับคู่โมเดลตามตาราง ช่วงที่ 2
2. เขียนกติกาให้หัว อย่างน้อยข้อเดียว: เจองานค้นหา/งานกลไก ให้แตกงาน ห้ามทำเอง
3. ส่งงานแรกเป็นงานอ่านอย่างเดียว งานประเมิน งานสำรวจ งาน audit พังแล้วเสียหายเป็นศูนย์ เหมาะเป็นสนามซ้อมที่สุด
4. บังคับ smoke test กับของจริงเสมอ รายงานจากการอ่านอย่างเดียวยังไม่ใช่คำตอบ และอย่าเชื่อ test เขียวจนกว่าจะเห็นมันแดงเป็น
5. จดว่าหัวแอบทำงานเองเมื่อไหร่ สัปดาห์แรกจะเจอว่าหัวเผลอทำ grunt work เองบ่อยกว่าที่คิด จดไว้แล้วปรับกติกา

ตอนไหนไม่ต้องใช้

งานเล็ก งานไฟล์เดียว งานที่รู้คำตอบอยู่แล้วครึ่งหนึ่ง เปิดโมเดลกลางตัวเดียวทำตรงๆ ถูกกว่าและเร็วกว่า orchestration มีต้นทุนคงที่ของมันเอง (แผน การส่งงาน การรอผล) จะคุ้มก็ต่อเมื่องานใหญ่พอที่การแบ่งชั้นจะได้กำไรกลับมา เหมือนที่ pong คำเดียวราคา 26,800 tokens สอนไว้

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

อัปเดตงานที่สองมาถึงบ่ายวันเดียวกัน

บทความนี้เผยแพร่ตอนเที่ยง พอบ่ายทีมเดียวกันก็เจองานที่สองเข้าจริง เลยกลับมาเล่าตามสัญญา งานคือยุบโค้ด daemon ของบอท Discord 6 ตัวที่ถูกก๊อปแยกกันไป 6 ทาง (ตัวละ 570 บรรทัด แก้อะไรทีต้องตามแก้ 6 รอบ) ให้เหลือแกนกลางชุดเดียว แต่ละตัวเหลือไฟล์สั้นราว 30 บรรทัดที่บอกแค่ว่าตัวเองต่างจากคนอื่นตรงไหน โจทย์ยากตรงที่ทั้ง 6 ตัวรันอยู่จริงและห้ามพัง

คราวนี้สายพานยาวกว่างานแรก หัววางแผนและแตกงาน ตัวคิดลึกอ่านโค้ดจริงทั้ง 6 ชุดแล้วออกแบบ ช่างต่างค่าย (Codex) ลงมือเขียน แล้วตัวคิดลึกกลับมา review งานของช่างเทียบกับ design ของตัวเอง ก่อนปล่อยของจริงแบบ canary คือ restart ทีละตัว ดูอาการ แล้วค่อยไล่ครบทั้งฝูง

ของที่อยากเล่าจริงคือ ชั้นตรวจแต่ละชั้นจับคนละอย่าง และจับได้จริงทั้งสามชั้น

• คนออกแบบจับหัวผิด brief ที่หัวส่งให้บอกว่าไฟล์สองตัว "เหมือนกันทุกตัวอักษร" เพราะเครื่องมือ diff ในเครื่องโกหก (มันถูกครอบด้วยตัวย่อผลลัพธ์เพื่อประหยัด token แล้วรายงานว่าไฟล์เหมือนกันทั้งที่ต่าง) คนออกแบบไม่เชื่อ ไปเช็ค md5 เองแล้วพบว่าต่างกันทั้ง 6 ไฟล์ ถ้าเชื่อ brief ตามนั้น design จะผิดตั้งแต่หน้าแรก
• ช่างจับคนออกแบบพลาด ตอนลงมือจริง Codex เจอว่า fork หนึ่งใช้ไฟล์ตรวจสอบคนละเวอร์ชันกับอีก 5 ตัว ที่ design ไม่ได้ระบุไว้ ถ้าเขียนตาม design ตรงตัว บอทตัวนั้นจะพังตอนเปิดเครื่อง ช่างเลยเปลี่ยนเป็นวิธีส่งของเข้าไปจากข้างนอกแทน แล้วบันทึกเหตุผลไว้ในรายงาน
• reviewer จับช่างผิดก่อนปล่อยของ รอบ review เจอ 2 จุดที่ test ทั้งกระดานมองไม่เห็น เงื่อนไข guard ตัวหนึ่งถูกสลับตรรกะจาก "หรือ" เป็น "และ" (ความหมายเปลี่ยน พฤติกรรมบอทตัวหนึ่งจะเพี้ยนแบบเงียบ) กับ try/catch ที่หายไปหนึ่งชั้นบนตัวที่จะถูก canary เป็นตัวแรกพอดี แก้รวมกัน 4 บรรทัด ก่อน restart ไม่ใช่หลัง

ผลลัพธ์ test 222/222 แบบที่ผ่าน positive control แล้ว restart ทั้ง 6 ตัวไม่มีตัวไหนล้ม งานจบใน 7 repos ภายในชั่วโมงเศษ ตัวเลขที่ชอบสุดคือ 4 บรรทัดที่ reviewer จับได้ เพราะมันคือความต่างระหว่างระบบที่นิ่ง กับพฤติกรรมเพี้ยนเงียบๆ ที่กว่าจะรู้ตัวก็อีกหลายวัน

แนวคิด "คนตรวจต้องไม่ใช่คนเขียน และต่างค่ายกันยิ่งดี" เราเขียนแยกไว้ละเอียดแล้วในเรื่องใช้ Codex review โค้ดแบบ headless ส่วนบทเรียนที่งานที่สองเพิ่มจากงานแรกมีข้อเดียว หัวที่ดีไม่ใช่หัวที่สั่งเก่ง แต่คือหัวที่วางชั้นตรวจให้ทีมจับกันเองได้ รวมถึงจับตัวหัวเองด้วย

งานที่สามสองวันถัดมา: หัวที่สร้างมือใหม่ได้เอง

ผ่านไปสองวัน (5 ก.ค.) งานที่สามก็เข้ามา และมันต่างจากสองงานแรกตรงแกนเลย สองงานที่ผ่านมาหัวแบ่งงานให้ "มือที่มีอยู่แล้ว" งานนี้หัวต้อง สร้างมือใหม่ เพิ่มบอทเข้าฝูงอีก 3 ตัวจนครบ 9 ตัว โดยไม่ต้องนั่งตั้งเองทีละขั้นแบบเดิม

คำถามที่ยากในงานนี้ไม่ใช่ "ตั้งบอทหนึ่งตัวยังไง" ตั้งเป็นอยู่แล้ว แต่คือ อะไรคือสิ่งที่คนเท่านั้นเคาะได้ ที่เหลือให้เครื่องคิดเอง พอตอบข้อนี้ได้ การเพิ่มบอทหนึ่งตัวก็เหลือมือคนอยู่ไม่กี่จุด ตั้งตัวตนให้มัน (charter) สร้างแอป Discord ให้สิทธิ์สามอย่างที่ต้องเป็นคนอนุมัติ เชิญเข้าห้อง แล้วส่ง token ที่เหลือ script กับ charter เดินเองหมด ทั้งตัวรัน พอร์ต ตัวที่คอยให้มันรันค้างตลอด การรู้จักพี่น้องตัวอื่นในฝูง ไปจนถึงกติกากลางที่ทุกตัวใช้ร่วมกัน

ของที่อยากเล่าจริงมีสามเรื่อง

• สามแนวกันชนที่ตั้งใจให้พังเสียงดัง เพราะบอทหลายตัวใช้แกนกลางชุดเดียวกัน สิ่งที่กลัวที่สุดคือตัวหนึ่งสวมรอยเป็นอีกตัว เลยวางตัวกันพลาดไว้สามจุดที่ถ้าผิดให้หยุดบูตทันที ไม่ใช่เตือนแล้วไปต่อ กติกากลางหาย ห้ามบูต ป้ายชื่อไม่ตรงกับ token ห้ามสวมรอย ห้องประจำตัวไปชนกับตัวอื่น หยุด ทุกกติกากันพลาดพิสูจน์ด้วย positive control ป้อนของเสียที่รู้อยู่แล้วว่าต้องพัง เพื่อดูว่ามันพังจริง ไม่ใช่แค่เขียนไว้ว่าจะพัง
• ราวกันตกที่โกหกทั้งฝูง ตอนทดสอบแบบ end-to-end (รันจริงตั้งแต่ต้นจนจบ) กับบอทตัวที่สอง จับได้ว่าแนวกันชนกลางตัวหนึ่งมีตัวแปรค้างชื่อผิด ผลคือทั้งฝูงกลายเป็นสิทธิ์อ่านอย่างเดียวแบบเงียบๆ ทั้งที่แต่ละชิ้นย่อยเทสต์ผ่านหมด นี่คืออีกหน้าของ false-green จากงานแรก เขียวตอนแยกชิ้น แต่พังตอนประกอบเข้าด้วยกันจริง แก้แล้วพิสูจน์ใหม่ทั้งชุด
• แม้แต่การส่ง token ก็ยังมีสิ่งที่หลอกเรา ลองส่ง token ผ่านช่องพิมพ์ใน terminal พังไปสองรอบ เพราะมีอักขระควบคุมที่มองไม่เห็นปนเข้าไปในค่า token เส้นที่เวิร์คคือส่งให้ตัวหัวเขียนลงไฟล์ตั้งค่าเอง แล้วลบข้อความทิ้ง ความลับที่ต้องส่งต่อ ก็มีวิธีที่ปลอดภัยกว่าการแปะตรงๆ

บทเรียนที่งานที่สามเพิ่มจากสองงานแรกมีข้อเดียว หัวที่โตแล้วไม่ได้เก่งแค่แบ่งงาน แต่ขยายทีมของตัวเองได้ด้วย และหัวใจของการขยายคือรู้ว่าอะไรต้องเหลือไว้ให้คนเคาะจริงๆ ที่เหลือออกแบบให้เครื่องเดินเอง

เกณฑ์เลือกว่าหัวกับมือควรเป็นโมเดลระดับไหน: Claude Opus vs Sonnet vs Fable 5 เลือกโมเดลไหนให้งานไหน