วิธีใช้ Fable เพื่อจัดการโปรเจกต์ขนาดใหญ่ด้วย 40 ซับเอเจนต์

เมื่อสัปดาห์ที่แล้วที่ @HelloUntangle เราทำโปรเจกต์วิศวกรรมที่ใหญ่ที่สุดและมีความเสี่ยงมากที่สุดในประวัติศาสตร์ของเราเสร็จเรียบร้อย

• 834 ไฟล์
• การเปลี่ยนแปลงข้อมูลในระบบจริง (Prod data mutation)
• การอัปเดตโครงสร้างฐานข้อมูล (DB schema update)
• 31 Pull Requests
• เริ่มวันศุกร์ → เสร็จวันจันทร์
• ไม่มีเหตุการณ์ขัดข้องในระบบจริง (Zero prod incidents)

ทั้งหมดนี้ด้วยเซสชัน Fable orchestrator หลักเพียงเซสชันเดียว

เซสชัน @DevinAI หลักเพียงเซสชันเดียววางแผนงานทั้งหมด สร้างเซสชันย่อยอีกสี่สิบเซสชันเพื่อดำเนินการ บังคับใช้เกณฑ์การตรวจสอบการถดถอย (regression gates) และการตรวจสอบสำรองระหว่างแต่ละเฟส และนำเสนอเฉพาะการตัดสินใจที่จำเป็นต้องมีเจ้าของจริงๆ เท่านั้น ได้แก่ การตัดสินใจขอบเขตงาน และการตัดสินใจเดินหน้าหรือหยุดในขั้นตอนที่ไม่สามารถย้อนกลับได้

สิ่งที่ทำให้สิ่งนี้สำเร็จคือชุดของ รูปแบบการจัดการโปรแกรม (program-management patterns) ที่จะช่วยปรับปรุงการโยกย้ายระบบขนาดใหญ่ใดๆ ก็ตาม

นี่คือวิธีการที่เราทำ...

สถาปัตยกรรม: orchestrator หนึ่งตัว, ผู้ปฏิบัติงานหลายคน

• เซสชันหลักหนึ่งเซสชัน เป็นเจ้าของโปรแกรมตั้งแต่ต้นจนจบ หน้าที่เดียวของมันคือการวางแผน สร้างเซสชันย่อย ตรวจสอบผลลัพธ์ จัดลำดับเฟส และส่งต่อให้ฉันเมื่อจำเป็นต้องมีการตัดสินใจของมนุษย์ มันไม่ได้เขียนโค้ดแม้แต่บรรทัดเดียว
• เซสชันย่อยประมาณ 40 เซสชัน ทำงานจริงทั้งหมด: เซสชันตรวจสอบแบบขนานสิบเอ็ดเซสชันในเฟส 0, เซสชันดำเนินการสำหรับแต่ละ wave, และเซสชันเฉพาะสำหรับรันเกต (gate-runner sessions) ที่มีหน้าที่แค่รันชุดทดสอบการถดถอย (regression suites)

การแบ่งแยกนี้มีความสำคัญเพราะโหมดความล้มเหลวของโปรเจกต์ระยะยาว ไม่ว่าจะเป็น AI หรือมนุษย์ คือ การล่มสลายของบริบท (context collapse): สิ่งที่กำลังทำงานอยู่จะค่อยๆ สูญเสียภาพรวมของโปรแกรมทั้งหมด

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

เจ็ดรูปแบบที่ทำให้มันสำเร็จ

1. ตรวจสอบก่อน และตรึงผลการตรวจสอบไว้ใน manifest ไฟล์เดียว

เฟส 0 คือเซสชันตรวจสอบแบบขนานสิบเอ็ดเซสชัน แต่ละเซสชันครอบคลุมโค้ดเบสส่วนใดส่วนหนึ่ง: เส้นทางของแอป (app routes), เส้นทาง API และ crons, โครงสร้างฐานข้อมูล, ไลบรารีและเวิร์กโฟลว์ที่ใช้ร่วมกัน, สคริปต์และเอกสาร ผลการตรวจสอบถูกสังเคราะห์เป็นไฟล์เดียวและคอมมิตไปยัง repository

manifest จะกำหนดคำตัดสิน (verdict) และหมายเลข wave ให้กับโค้ดทุกหน่วย กฎสองข้อทำให้มันทรงพลัง:

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

2. จัดลำดับงานตามความเสี่ยง ไม่ใช่ตามความสะดวก

wave ต่างๆ ถูกจัดลำดับจากปลอดภัยที่สุดไปจนถึงย้อนกลับไม่ได้มากที่สุด

Wave

อะไร

ความเสี่ยง

0

ตรวจสอบ + manifest + git tag จุดคืนค่า

ไม่มี

1

การเปลี่ยนแปลงที่ยืนยันแล้วว่าไม่มี dependents ในระบบจริง

ใกล้เป็นศูนย์

2

การผ่าตัดการพัวพัน (Entanglement surgery) บนโครงสร้างพื้นฐานที่ใช้ร่วมกัน

ปานกลาง

3–4

การเปลี่ยนแปลงโค้ดส่วนใหญ่

ปานกลาง

5

การเปลี่ยนแปลงข้อมูลในระบบจริง (พร้อม dry-run inventory + snapshot)

สูง

6

การย้ายโครงสร้างฐานข้อมูล (Schema migrations)

สูง

7

การตัดแต่ง dependency, การเขียน agents.md ใหม่, การตรวจสอบฐานความรู้ของ agent

ต่ำ

การเปลี่ยนแปลงข้อมูลในระบบจริง (Wave 5) เกิดขึ้น ก่อน การเปลี่ยนแปลงโครงสร้างฐานข้อมูล (Wave 6) และทั้งสองอย่างจะเกิดขึ้นหลังจากที่ทุกเส้นทางโค้ดที่แตะต้องตารางที่ได้รับผลกระทบได้รับการอัปเดตอย่างตรวจสอบได้แล้วเท่านั้น เมื่อถึงเวลาที่ migrations ทำงาน ก็ไม่มีอะไรที่ยังคงขึ้นอยู่กับสถานะเก่าได้อีก

3. ขอบเขตที่ไม่ทับซ้อนกันของไฟล์ทำให้การทำงานแบบขนานปลอดภัย

ภายใน wave เดียวกัน เซสชันย่อยทำงานแบบขนาน — wave หนึ่งมีสี่เซสชันที่ทำงานในส่วนต่างๆ ของโครงสร้างพร้อมกัน หลักการคือ: ทุกพรอมต์รวมขอบเขตของไฟล์ที่ชัดเจน และขอบเขตเหล่านั้นไม่ทับซ้อนกัน ไม่มีความขัดแย้งในการ merge, ไม่มี agent สองคนแก้ไขไฟล์เดียวกัน, ไม่จำเป็นต้องมีการประสานงานระหว่างเซสชันย่อยเลย

นี่คือการ分解งานแบบคลาสสิก — สิ่งเดียวกับที่คุณทำเมื่อแบ่งงานให้วิศวกรหลายคน — แต่ agent ต้องการให้ระบุ อย่างชัดเจน ในพรอมต์ ทุกครั้ง

4. ประตูความปลอดภัย (Safety gates) ระหว่าง wave

ไม่มี wave ใดเริ่มต้นจนกว่า wave ก่อนหน้าจะผ่าน gate ได้ gate เองก็เป็นเซสชันย่อยเช่นกัน:

• ชุดทดสอบการถดถอยแบบ end-to-end ที่ขับเคลื่อนโดยเบราว์เซอร์ ซึ่งครอบคลุมเวิร์กโฟลว์หลักของลูกค้าบนแพลตฟอร์ม ทำงานหลังจาก Wave 2 และอีกครั้งหลังจาก Wave 3–4 บนสาขาฐานข้อมูลที่แยกออกมาใหม่
• ก่อนการเปลี่ยนแปลงข้อมูลในระบบจริง: เซสชันเฉพาะตรวจสอบสินค้าคงคลังการสำรองข้อมูลฐานข้อมูลของเรา (จำนวน, ช่วงวันที่, การเก็บรักษา) และเราถ่าย snapshot แบบ point-in-time ใหม่
• ขั้นตอนการทำงานในระบบจริงนั้น รัน dry-run ก่อน, สร้างจำนวนแถวเพื่อให้เจ้าของอนุมัติ, และตรวจสอบจำนวนอีกครั้งหลังจากการดำเนินการ
• git tag ทำเครื่องหมายจุดคืนค่าสำหรับทุกบรรทัดที่เปลี่ยนแปลง

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

5. มนุษย์อนุมัติ; agent เสนอ

ฉันไม่เคยเขียนโค้ด รัน migration หรือดำเนินการสคริปต์ในระบบจริงในโปรเจกต์นี้ แต่ทุกขั้นตอนที่ไม่สามารถย้อนกลับได้ต้องการการอนุมัติอย่างชัดเจนจากฉัน: การ merge แต่ละครั้งไปยัง main branch, การเปลี่ยนแปลงข้อมูลในระบบจริง, การย้ายโครงสร้างฐานข้อมูล, และคำตัดสินแต่ละครั้งเกี่ยวกับรายการ UNKNOWN ในขอบเขตงาน

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

6. โปรโตคอลการยกระดับ (Escalation protocol) สำหรับเรื่องเซอร์ไพรส์

เซสชันย่อยได้รับคำสั่งว่าต้องทำอย่างไรเมื่อความเป็นจริงไม่ตรงกับ manifest: หยุด, รายงานไปยังเซสชันหลัก, อย่าแก้ไขเฉพาะหน้า ตัวอย่างจริง:

• โมดูลที่การตรวจสอบบอกว่าปลอดภัย กลับกลายเป็นว่ามี live dependent อยู่ที่อื่น → เซสชันย่อยแจ้งเตือน และหน่วยนั้นถูกเลื่อนไปยัง wave ที่หลังกว่า พร้อมบันทึกการพัวพันไว้
• รอบการตรวจสอบรอบที่สองกลับคำตัดสินของรอบแรกในห้าพื้นที่ทั้งหมด → การกลับคำตัดสินถูกเขียนลงใน manifest เป็นการแทนที่อย่างชัดเจน แทนที่จะแก้ไขเฉพาะหน้าตามที่เซสชันใดก็ตามที่เจอ

เซสชันหลักดูดซับเรื่องเซอร์ไพรส์เหล่านี้เข้าไปในแผน ผู้ปฏิบัติงานแต่ละคนไม่เคยตัดสินใจเกี่ยวกับขอบเขตงาน

7. ทิ้งแคมป์ให้สะอาดกว่าเดิม: สอนระบบถึงสิ่งที่เปลี่ยนแปลงไป

Wave 7 อาจเป็นเฟสที่ถูกประเมินค่าต่ำที่สุด หลังจากการเปลี่ยนแปลงถูกนำไปใช้ เซสชันต่างๆ ได้เขียน AGENTS.md, ทักษะของ repository, และฐานความรู้ของ agent ใหม่เพื่ออธิบายสถาปัตยกรรมใหม่ — เพื่อให้ทุก เซสชัน agent ในอนาคต เริ่มต้นจากความจริง ไม่ใช่จากคำแนะนำที่ล้าสมัย หากงานวิศวกรรมของคุณขับเคลื่อนโดย agent เอกสารของคุณคือโครงสร้างพื้นฐานที่รับน้ำหนัก (load-bearing infrastructure)

ค่าใช้จ่าย

ทุกเซสชันในโปรแกรมถูกแท็ก ดังนั้นบัญชีจึงสมบูรณ์: เซสชันหลักหนึ่งเซสชันและเซสชันย่อยสามสิบเก้าเซสชัน ทั้งหมดบน Devin's Ultra Agent ตั้งแต่บ่ายวันศุกร์ถึงเช้าวันจันทร์ นี่คือต้นทุนที่วัดได้จริงจากแดชบอร์ดการใช้งานของเรา

เฟส

เซสชัน

ค่าใช้จ่าย

Parent orchestrator (หลายวัน)

1

$115.26

การตรวจสอบเฟส 0 (สองรอบ) + การสังเคราะห์ manifest

12

$85.56

Wave 1

4

$37.55

Wave 2 (การผ่าตัดการพัวพัน)

4

$299.34

Gates การถดถอย Wave 2–4 + การแก้ไข

4

$244.69

Wave 3–4

5

$130.84

Wave 5 (ระบบจริง) + การตรวจสอบสำรอง

2

$15.20

Wave 6 (การย้ายโครงสร้างฐานข้อมูล)

3

$118.83

Wave 7 (dependencies, เอกสาร, ความรู้) + gate สุดท้าย

4

$96.64

การแก้ไขโครงสร้างพื้นฐาน

1

$11.47

รวม

40

$1,155.38

สามสิ่งที่โดดเด่นจากการแยกย่อยนี้

1. เฟสการตรวจสอบทั้งหมดสิบสองเซสชันที่สร้าง manifest มีค่าใช้จ่ายต่ำกว่า $90 — เป็นประกันที่ถูกที่สุดที่เราเคยซื้อ
2. รายการที่มีค่าใช้จ่ายสูงที่สุดอยู่ตรงจุดที่ต้องใช้ความคิดหนักๆ: การผ่าตัดการพัวพัน ($299) และ gates การถดถอย ($245) ที่ทำให้ทุกอย่างซื่อสัตย์
3. ขั้นตอนที่มีความเสี่ยงสูงที่สุด — การเปลี่ยนแปลงข้อมูลในระบบจริง — มีค่าใช้จ่าย $15 เพราะเมื่อถึงเวลาที่มันทำงาน ความเสี่ยงทั้งหมดถูกขจัดออกไปทางวิศวกรรมแล้ว

หมายเหตุ: โปรเจกต์ทั้งหมดนี้อาจมีราคาถูกกว่านี้มากหาก Devin อนุญาตให้ฉันเลือกโมเดลอื่นสำหรับ sub-agent ได้ งานเขียนโค้ดส่วนใหญ่สามารถทำได้สำเร็จด้วย gpt 5.5 หรือ opus 4.8 การสั่ง Fable ให้เลือกโมเดลที่เหมาะสมกับงานของ sub-agent ก็คงเป็นเรื่องง่าย

ถึงแม้จะไม่มีสิ่งนั้น: $1K ก็ถูกอย่างไม่น่าเชื่อสำหรับงานที่เราทำเสร็จ - และ ความเร็ว ที่มันทำและตรวจสอบได้ - ว้าว

https://x.com/ryancarson/status/2072694425365426344

ข้อสรุป

ประเด็นสำคัญไม่ใช่การที่ AI เขียนโค้ดจำนวนมาก — agent ที่ดำเนินการเปลี่ยนแปลงที่ระบุไว้อย่างดีนั้นเป็นเรื่องปกติในตอนนี้

ประเด็นสำคัญคือ การจัดการโปรแกรมเองก็ถูกมอบหมาย: การ分解, การจัดลำดับ, การทำขนาน, การตั้ง gate, และการยกระดับ ทั้งหมดทำงานภายใน orchestrator และบทบาทของมนุษย์ถูกบีบอัดให้เหลือเพียงการตัดสินใจที่จำเป็นต้องมีเจ้าของเท่านั้น

หากคุณจะลองทำสิ่งนี้ ให้ลอกเลียนรูปแบบ ไม่ใช่เครื่องมือ:

1. ตรวจสอบก่อน; ตรึงผลการตรวจสอบใน manifest ที่ไม่มีผู้ปฏิบัติงานคนไหนโต้แย้งได้
2. จัดลำดับ wave ตามความเสี่ยง; ขั้นตอนที่ย้อนกลับไม่ได้อยู่ท้ายสุด
3. ให้ขอบเขตไฟล์ที่ไม่ทับซ้อนกันอย่างชัดเจนแก่ผู้ปฏิบัติงานแบบขนาน
4. ตั้ง gate ทุก wave ด้วยชุดทดสอบการถดถอยจริงและการสำรองข้อมูลจริง
5. กำหนดให้มีสินค้าคงคลังที่เสนอ ก่อนการเปลี่ยนแปลงที่ทำลายล้าง; อนุมัติรายการ ไม่ใช่แค่ความคิด
6. กำหนดเส้นทางการยกระดับ ก่อนที่เรื่องเซอร์ไพรส์จะมาถึง
7. อัปเดตเอกสารและความรู้ของ agent ของคุณเป็นส่วนหนึ่งของโปรเจกต์ ไม่ใช่หลังจากนั้น

ขอให้มีความสุขกับการ orchestrating! :)