ระดับความเป็นอิสระของเอเจนต์

• วิศวกรรมแบบเอเจนต์กำลังขยับจากการเขียนพรอมป์ไปใกล้เคียงกับ การออกแบบการปฏิบัติการ มากขึ้น และต้องกำหนดทั้งระดับความเป็นอิสระที่อนุญาตสำหรับแต่ละงาน รวมถึง วิธีตรวจสอบ ที่รองรับระดับนั้น
• โมเดลแบบบันไดแกนเดียวมีประโยชน์ในการแทนความเชื่อมั่นต่อเอเจนต์หนึ่งตัวด้วยตัวเลข แต่ความสามารถในการจัดการเอเจนต์หลายตัวพร้อมกันควรมองแยกเป็นสองแกนคือ agency และ orchestration
• โมเดลระดับ 0~5 ไล่ตั้งแต่ Assist ที่ให้เพียงข้อเสนอ ไปจนถึง Managed-by-exception orchestration ที่มนุษย์เข้าแทรกแซงเฉพาะเมื่อเกิดกรณียกเว้น และยิ่งระดับสูงขึ้น เป้าหมาย ขอบเขต หลักฐาน สิทธิ์ และงบประมาณยิ่งต้องชัดเจน
• จากการวิเคราะห์ Claude Code ของ Anthropic พบแนวโน้มว่ามนุษย์รับผิดชอบการตัดสินใจด้านการวางแผนราว 70% และ Claude รับผิดชอบการลงมือทำราว 80% โดยอิงจากข้อมูลผู้ใช้ประมาณ 235,000 คน และประมาณ 400,000 เซสชัน
• การใช้เอเจนต์อย่างมีวุฒิภาวะไม่ได้อยู่ที่การอวดว่ามีความเป็นอิสระสูง แต่อยู่ที่การใช้ calibrated autonomy ให้เหมาะกับความเสี่ยงและระดับที่ย้อนกลับได้ พร้อมจัดการคอขวดด้านการตรวจสอบ

---

วิศวกรรมแบบเอเจนต์ที่ย้ายจากการเขียนพรอมป์สู่การออกแบบการปฏิบัติการ

• จุดศูนย์กลางของวิศวกรรมแบบเอเจนต์กำลังย้ายจากการเขียนพรอมป์ไปสู่ การออกแบบการปฏิบัติการ
• software factory, เป้าหมาย, loop, background session, subagent, hook, sandbox และวิธีที่เอเจนต์อนุมัติเอเจนต์ด้วยกันเอง กำลังขึ้นมาอยู่แถวหน้า
• Claude Code และ Codex ถูกยกเป็นผลิตภัณฑ์ตัวแทนที่แสดงให้เห็นการเปลี่ยนแปลงนี้
• วิศวกรอาจใช้ความเป็นอิสระระดับต่ำเพื่อลดความเสี่ยงและทำให้ย้อนกลับได้ง่าย และใช้ความเป็นอิสระที่สูงขึ้นกับ fleet ของเอเจนต์แบบขนานสำหรับกิจกรรมที่ชัดเจนหรือการ refactor codebase ขนาดใหญ่
• คำถามหลักคือควรอนุญาต ความเป็นอิสระระดับใด สำหรับแต่ละงาน และการตรวจสอบแบบใดจะปกป้องระดับนั้นได้

มองความเป็นอิสระเป็นสองแกนแทนบันไดแกนเดียว

• บันไดแกนเดียวที่กล่าวถึงใน “Welcome to Gas Town” ของ Steve Yegge มีประโยชน์ในการแทนความเชื่อมั่นต่อเอเจนต์หนึ่งตัวด้วยตัวเลข
• ในช่วงต้นปี 2026 แม้ในสถานการณ์ที่งานย้ายจากการมอบหมายไปสู่ orchestration แกนเดียวก็ยังทำหน้าที่เป็นตัวชี้วัดแทนโดยคร่าว ๆ สำหรับการวัดความเสี่ยงได้
• เมื่อสามารถรันเอเจนต์หลายตัวพร้อมกันได้ ลำดับขั้นเดียวไม่เพียงพอที่จะอธิบาย ความสามารถแบบหลายเอเจนต์
• การถกเถียงเรื่องความเป็นอิสระมักปนคำถามสองข้อที่ต่างกัน
  • สามารถส่งเอเจนต์เดี่ยวออกไปไกลจากมนุษย์ได้แค่ไหน
  • สามารถประสานงานเอเจนต์หลายตัวได้ดีแค่ไหน
• หากจะแยกสองเรื่องนี้ จำเป็นต้องมีสองแกน
  • agency: เอเจนต์หนึ่งตัวสามารถเสนอ ลงมือทำงานที่จำกัดขอบเขต หรือทำเป้าหมายให้สำเร็จได้อย่างอิสระแค่ไหน
  • orchestration: สามารถประสานงานได้ตั้งแต่เธรดเดียว ไปจนถึง tree ของงานหลายชุด และงานต่อเนื่องที่อิง backlog, issue tracker และ schedule ได้แค่ไหน

ความหมายของ agency และ orchestration

• ในระดับต่ำของแกน agency เอเจนต์จะเสนอ candidate action แล้วรอการตัดสินใจจากมนุษย์
• ในระดับกลาง เอเจนต์จะทำงานเฉพาะอย่างโดยจำกัดขอบเขต และรายงานสิ่งที่ทำพร้อมหลักฐานอย่างต่อเนื่องเพื่อให้มนุษย์ปรับทิศทางได้
• ในระดับ agency สูง เอเจนต์จะทดลอง เรียนรู้ ทดสอบ รับมือกับสถานการณ์ติดขัด ตั้งคำถาม และลองแนวทางอื่นเพื่อไปสู่เป้าหมาย แล้วส่งกลับมาพร้อม หลักฐาน
• ระดับต่ำของแกน orchestration คือเอเจนต์หนึ่งตัวกับเธรดหนึ่งเส้น
• ในระดับกลาง เอเจนต์หลายตัวจะทำเป้าหมายต่างกันใน worktree ที่แยกจากกัน
• ในระดับสูง orchestrator จะเปลี่ยน backlog, issue tracker, schedule และ queue ให้เป็นงานต่อเนื่อง โดยมนุษย์จะเข้าแทรกแซงเฉพาะเมื่อเกิดความล้มเหลว ในรูปแบบ management by exception
• ตัวอย่างฟีเจอร์และผลิตภัณฑ์ที่เกี่ยวข้องมีดังนี้
  • Claude Code: /plan, /goal, /loop, /background, /batch, /code-review, /security-review, subagent, hook, checkpoint, วิธีมอบหมายและจัดการเอเจนต์, background session, agent team pattern, อาร์กิวเมนต์ /schedule
  • Codex: เธรดแบบ local และ cloud, Goal mode, worktree, Automations, subagent, review panel, GitHub code review, hook, sandbox, Auto-review, rerun

สามยุคและหกระดับ

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

Level 0: Assist

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

Level 1: Supervised action

• เอเจนต์แก้ไขหรือรันคำสั่งแทน แต่ก่อนการดำเนินการสำคัญจะขออนุญาตจากมนุษย์
• ใกล้เคียงกับท่าทีพื้นฐานที่คนส่วนใหญ่ใช้งาน
• สามารถทำได้ใน local sandbox โดยขออนุมัติก่อนใช้การเปลี่ยนแปลง หรือทำใน session แบบโต้ตอบ
• การอนุมัติแต่ละครั้งทำหน้าที่เป็นการตรวจสอบอิสระว่าเปลี่ยนแปลงนั้นนำไปใช้ได้หรือไม่
• โหมดความล้มเหลวหลักคือ ความล้าจากการอนุมัติ
  • ไม่ว่าจะอนุมัติอะไร การอนุมัติทุกอย่างอาจเริ่มรู้สึกคล้ายกัน
  • อาจรับมือด้วยการกวาดตาดู diff แบบคร่าว ๆ ทำตาม heuristic ให้คนอื่นช่วยตรวจ หรืออนุญาตให้เอเจนต์รับผิดชอบ
• Codex Auto-review จัดการปัญหานี้ด้วยการมอบหมายการอนุมัติสุดท้ายของเงื่อนไขขอบเขตให้เอเจนต์ reviewer แยกต่างหาก

Level 2: Scoped task delegation

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

Level 3: Goal-driven autonomy

• เอเจนต์ทำสิ่งที่จำเป็นเพื่อบรรลุเป้าหมายจนกว่าเงื่อนไขที่กำหนดจะเป็นจริง
• ใน prompt mode ตัวพรอมป์เองจะกลายเป็นเป้าหมาย
  • ตัวอย่าง: “สามารถลด time-to-interactive ของหน้านี้ให้ต่ำกว่า 1 วินาทีได้หรือไม่?”
• ใน Codex สิ่งนี้คือ Goal mode โดยเอเจนต์จะวนซ้ำขั้นตอน plan -> act -> test -> review และหยุดเมื่อไม่สามารถทำให้เป็นไปตามเกณฑ์ความสำเร็จได้อีก
• ใน Claude Code คำสั่ง /goal, /loop, /schedule สอดคล้องกับระดับนี้
• เพื่อให้ระดับนี้มีประโยชน์ เงื่อนไขการหยุดต้อง วัดได้ ในแบบที่ทำอัตโนมัติได้
• เป้าหมายคลุมเครืออย่าง “ปรับปรุงประสบการณ์ผู้ใช้โดยรวม” หรือ “ทำให้ codebase ทดสอบได้มากขึ้น” ไม่เหมาะ
• เป้าหมายที่เหมาะกว่าควรเฉพาะเจาะจง วัดได้ และทำอัตโนมัติได้
  • ค้นหา production bug ที่หลุดจาก static analysis
  • ลดเวลาโหลด
  • รับประกัน strict TypeScript build ที่ไม่มี any แบบ explicit
  • จัดหมวดหมู่ dependency ทั้งหมดให้เหลือเฉพาะ dependency ที่เข้าใจได้และผ่านการทดสอบ
• หากต้องการค้นหา production bug เอเจนต์ต้องอยู่ใน สภาพแวดล้อมที่คล้าย production

Level 4: Parallel delegation

• เป็นระดับที่เอเจนต์หลายตัวทำงานแบบขนาน
• เอเจนต์แต่ละตัวรับชิ้นส่วนของงานที่แยกจากกัน
• คอขวดที่ใหญ่ที่สุดคือ การแยกย่อย ว่าจะมอบหมายชิ้นส่วนใด
• ฟีเจอร์ที่รองรับ ได้แก่ subagent, background session, /batch, worktree และ agent team
• โหมดความล้มเหลวหลักคือความขนานแบบปลอม
  • หากเอเจนต์หลายตัวจัดการชิ้นส่วนที่ซ้อนทับกันพร้อมกัน อาจสร้าง merge conflict และการตัดสินใจซ้ำซ้อนแทนที่จะได้งานเพิ่ม
• หากจะดำเนินงานให้ดี เอเจนต์ต้องถูกแยกออกจากกัน
  • แต่ละตัวควรมีไฟล์และสถานะที่ตนเองเป็นเจ้าของ
  • แต่ละตัวควรมี review queue ของตนเองด้วย
• เอเจนต์แต่ละตัวมีต้นทุน token และแปรผันตามจำนวนเอเจนต์ที่รันพร้อมกัน
• ฝั่งมนุษย์ หลังจากจำนวนหนึ่ง ต้นทุนส่วนเพิ่มของการเพิ่มเอเจนต์จะสูงขึ้นเพราะ ภาษี orchestration

Level 5: Managed-by-exception orchestration

• มนุษย์กำหนดนิยามของความสำเร็จและนโยบายที่จะใช้ จากนั้น manager agent จะตื่นขึ้นมาตาม trigger และกระจายงาน
• ตัวอย่าง trigger คือ issue ใหม่ งานใหม่ และเวลา
• manager agent จะจัดวาง worker agent, monitor ความคืบหน้า, ตรวจสอบผลลัพธ์ และ retry เมื่อเกิดความล้มเหลว
• เมื่อเงื่อนไขเป็นจริง จะ escalate ไปยังเอเจนต์ที่มีความสามารถสูงกว่าหรือมนุษย์ และรวบรวมผลลัพธ์กลับไปยังระบบภายนอกในรูปของผลงานอย่าง PR พร้อมหลักฐาน
• ระดับนี้เปรียบได้กับ factory
  • input คือ issue tracker หรือ backlog
  • output คือ issue หรือ bug หลายรายการที่ถูกแก้แล้ว
• เอเจนต์ทำงานในสภาพแวดล้อมที่แยกออกและมีขอบเขตเพียงพอ พร้อมทางออกเมื่อจำเป็น
• สิ่งที่ factory นี้ควรทำถูกกำหนดโดย operating system ที่ manager agent นิยามไว้
• OpenAI เสนอ spec สำหรับ Symphony โดยมีบอร์ด Linear เป็นศูนย์กลาง
  • แต่ละ issue มี agent workspace ของตนเอง
  • เอเจนต์ตรวจสอบว่าตนเองกำลังก้าวหน้าไปสู่เป้าหมายที่กำหนดไว้ในไฟล์ spec ของ workspace ตนเองหรือไม่
• แนวหน้าของ orchestration คือการสร้าง agent factory ต่อเนื่องที่มีเอเจนต์หลายร้อยหรือหลายพันตัวทำงาน
• ในระดับนี้ การตรวจสอบอิสระยิ่งสำคัญขึ้น
  • แยก implementer กับ reviewer
  • แยก test runner กับ QA
  • แยก security check
  • แยก process gate สำหรับการยอมรับ

ความเสี่ยงและระดับที่ย้อนกลับได้กำหนดเพดานของความเป็นอิสระ

• ใน งานวิจัย ของ Anthropic เกี่ยวกับ Claude Code พบว่าในงานบางส่วนที่ยากที่สุด Claude Code ถามคำถามเพื่อความชัดเจนบ่อยกว่าการถูกผู้ใช้หยุดมากกว่าสองเท่า
• ผู้ใช้ที่มีประสบการณ์ ซึ่งหมายถึงผู้ใช้ที่มีประมาณ 750 session มีแนวโน้มใช้การอนุมัติอัตโนมัติและการหยุดบ่อยกว่าผู้ใช้ที่มีน้อยกว่า 50 session พร้อมกับเฝ้าดูความคืบหน้า
• การวิเคราะห์ ที่กว้างขึ้นของ Anthropic ครอบคลุมประมาณ 400,000 session จากผู้ใช้ประมาณ 235,000 คน ตั้งแต่เดือนตุลาคม 2025 ถึงเมษายน 2026
• ในแต่ละ session สามารถระบุการตัดสินใจอย่างจำนวนการกระทำที่ผู้ใช้ร้องขอต่อหนึ่งพรอมป์ รายการที่อนุมัติอัตโนมัติ และความถี่ในการหยุดได้
• มนุษย์ตัดสินใจด้านการวางแผนประมาณ 70% และ Claude ทำการลงมือปฏิบัติประมาณ 80%
• ความเป็นอิสระสูงไม่ได้หมายถึงการเอามนุษย์ออกจาก loop แต่เป็นการย้ายจากการที่มนุษย์ทำทุกขั้นตอนไปสู่การกำหนดทิศทางถัดไป
• หากจะตัดสินว่าระบบ AI ขนาดใหญ่ทำงานด้วยความเป็นอิสระสูงหรือไม่ ต้องถามสามคำถาม
  • รู้ได้เร็วแค่ไหนว่ากำลังทำอะไรผิด
  • ย้อนกลับสิ่งที่กำลังทำได้สะอาดแค่ไหน
  • อะไรพิสูจน์ว่าสิ่งที่ทำอยู่นั้นถูกต้อง
• หากคำตอบคือ “รู้เร็วไม่ได้ ย้อนกลับยาก และต้องเชื่อสรุป” นั่นไม่ใช่ความเป็นอิสระสูง

รายการที่ควรอยู่ในสัญญาก่อนรันเอเจนต์

• ก่อนรันเอเจนต์ทุกครั้งต้องมี สัญญา ที่นิยามว่าจะทำอะไร
• สัญญาควรมีรายการต่อไปนี้
  • เป้าหมาย: ผลลัพธ์ที่ต้องการบรรลุ ไม่ใช่กิจกรรมหรือเทคนิค
  • ขอบเขต: โดเมนที่จะทำงานและเทคนิคที่อนุญาต
  • สิ่งที่ไม่ใช่เป้าหมาย: สิ่งที่ไม่รวมอยู่ในวัตถุประสงค์
  • เครื่องมือและสิทธิ์: วิธีที่เอเจนต์โต้ตอบกับโลกภายนอก
  • เงื่อนไขการหยุด: จะหยุดเมื่อใด และถ้าเป็นไปได้ให้เป็นตัวแปรที่วัดได้
  • หลักฐาน: test, screenshot, log, database record ฯลฯ ที่ยืนยันการเสร็จงานได้อย่างอิสระ
  • การ escalate: ในสถานการณ์ใด ใครจะเข้ามาเกี่ยวข้อง และใครเป็นผู้รันเอเจนต์
  • งบประมาณ: เวลา ความพยายาม และขีดจำกัด token
• token คือ budget ของโมเดล AI ขนาดใหญ่ และอาจรวมถึงข้อจำกัดด้านจำนวนครั้งที่ลองและระดับความขนานด้วย

เมตริกทำให้ความเป็นอิสระน่าเชื่อถือขึ้นอีกเล็กน้อย

• การกำหนดเมตริกหลังจบงานอย่างเดียวอาจไม่เพียงพอ
• เมตริกสามารถวางไว้ล่วงหน้าในเอกสารสั้น ๆ และทำให้ความเป็นอิสระน่าเชื่อถือขึ้น
• ตัวอย่างเมตริกที่ติดตามได้ตามระดับความเป็นอิสระมีดังนี้
  • เวลาเฉลี่ยระหว่างการแทรกแซง
  • เวลารันแบบไม่มีคนดูแลที่ยาวที่สุดตามเกณฑ์งานที่ได้รับการยอมรับ
  • สัดส่วนของ action ที่รันใน sandbox ต่อ action ที่ถูก escalate
  • สัดส่วนของ action ที่อนุมัติอัตโนมัติต่อ action ที่ถูกปฏิเสธ
  • จำนวน action เฉลี่ยของเอเจนต์ต่อหนึ่งคำสั่งจากมนุษย์
  • อัตราการขอความชัดเจน
  • อัตราการขอหยุด
  • เวลารีวิวต่อการเปลี่ยนแปลงที่ได้รับการยอมรับ
  • อัตราการทำงานซ้ำตามระดับความเชื่อมั่น
  • อัตราข้อบกพร่องที่หลุดรอดตามระดับความเชื่อมั่น
  • ต้นทุน token ต่อการเปลี่ยนแปลงที่ได้รับการยอมรับ
• เอเจนต์เดี่ยวที่ยุ่งอยู่ตลอดกับงานที่มนุษย์ส่งต่อให้นั้นใกล้กับ Level 4 ที่มี dashboard ติดอยู่ ส่วนเอเจนต์เชิงอนุรักษ์ที่มีการรับงานอัตโนมัติ retry อัตโนมัติ และไม่เดินหน้าหากไม่มีหลักฐานเพียงพอ จะใกล้กับ Level 5 ที่มี gate จริง

ความพร้อมและการเลือกระดับความเป็นอิสระ

• งานควรถูกจัดประเภทตามความเสี่ยงและระดับที่ย้อนกลับได้
• ควรใช้ความเป็นอิสระอย่างระมัดระวัง และเพิ่มระดับเมื่อมีหลักฐานสะสมที่รองรับระดับสูงขึ้นเท่านั้น
• การ refactor payment engine ที่มี test แข็งแรง reviewer agent และเส้นทาง rollback ที่สะอาด อาจรองรับความเป็นอิสระสูงกว่างาน document automation ที่ไม่มีเกณฑ์คำตอบที่ถูกต้อง
• ระดับความเป็นอิสระควรตาม กระบวนการตรวจสอบ ไม่ใช่ชื่อของงาน

แอนติแพตเทิร์นของความเป็นอิสระสี่แบบ

• Autonomy as status

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

• Permission laundering

  • เพราะความล้าจากการอนุมัติ จึงมอบสิทธิ์เข้าถึงให้ AI agent และเครื่องมือกว้างเกินจำเป็น
  • ควรเสริมขอบเขตให้แข็งแรงขึ้น เช่น sandbox profile, write root ที่จำกัดขอบเขต, allowlist ของคำสั่ง, hook และ Auto-review

• Summary substitution

  • สรุปงานของเอเจนต์เข้ามาแทนการรีวิว
  • ควรผูก evidence packet แบบเดียวกับการรีวิวด้วยตนเองเข้าไว้ด้วยกัน
  • อาจรวม diff, test, log, screenshot, สิ่งที่ reviewer พบ, ความเสี่ยง และช่องโหว่

• Fleet cosplay

  • รันเอเจนต์หลายสิบตัวแบบขนาน แต่มนุษย์ยังต้องประสาน dependency ทั้งหมดด้วยมืออยู่ตลอด
  • shared state, กฎ ownership และการติดตาม dependency ที่ดีขึ้นช่วยลดความจำเป็นในการประสานงานด้วยมือ
  • WIP limit ที่เล็กลงช่วยให้มุ่งเน้นการ encode และจัดทำเอกสารขั้นตอนการประสานงาน ซึ่งอาจนำไปสู่ automation ของ orchestration

วิธีไต่ระดับอย่างปลอดภัย

• มีการเสนอแบบฝึกปรับเทียบโดยทบทวนงาน 10 งานล่าสุดที่ได้รับความช่วยเหลือจากเอเจนต์
  • ระดับความเป็นอิสระของแต่ละงาน
  • ความเสี่ยง
  • ระดับที่ย้อนกลับได้ง่าย
  • หลักฐานที่สร้างขึ้นเพื่อตอบโจทย์ข้อกำหนดการตรวจสอบ
  • เวลารีวิว
  • มีการทำงานซ้ำหรือไม่
  • ครั้งต่อไป ระดับความเป็นอิสระเดิมยังเหมาะสมหรือไม่
• ควรไต่ขึ้นทีละแกน
• จุดเริ่มต้นคือเอเจนต์ supervised ตัวเดียวทำงานจำกัดขอบเขตหนึ่งงานที่สร้างหลักฐานความสำเร็จที่ปกป้องได้
• จากนั้นค่อย ๆ ขยายในสามทิศทาง
  • ทำให้งานสำรวจที่เน้นการอ่านเป็นแบบขนาน
  • เพิ่มเอเจนต์เขียนใน worktree แยกต่างหากที่มีกฎ ownership ของไฟล์จำกัดขอบเขต
  • เพิ่ม automation แบบวนซ้ำ แล้วเพิ่ม orchestration ที่เอเจนต์ขับเคลื่อนโดยอิง issue หรือเสียง เป็นต้น
• การเพิ่มระดับแต่ละครั้งต้องมี guardrail ใหม่เพื่อรับมือโหมดความล้มเหลวใหม่
• โหมดความล้มเหลวมีดังนี้
  • การรันเอเจนต์เดี่ยวนาน ๆ: drift, context corruption, การสื่อสารที่ตกหล่น, การหลุดจากเป้าหมาย
  • background task: สมมติฐานเก่า, handoff ที่อ่อน
  • งานขนานมากเกินไป: merge conflict, การตัดสินใจซ้ำซ้อน
  • งานวนซ้ำมากเกินไป: การใช้ token อย่างเงียบ ๆ, พรอมป์ที่ล้าสมัย
  • managed-by-exception: review queue ยาว, ความล้าจากการแจ้งเตือน
• ไม่ควรใช้วิธีเชื่อใจมากขึ้น แต่ควรจำกัดขอบเขตให้แคบลง หาหลักฐานที่ดีกว่า สร้างเส้นทาง rollback ที่ถูกกว่า เสริม gate ให้แข็งแรง และทำให้กฎ ownership ชัดเจนขึ้น

การใช้งานที่เหมาะตามแต่ละระดับ

• Level 0 เหมาะที่สุดกับงานละเอียดอ่อนและสถานการณ์ที่ยังอยู่ระหว่างสร้างดุลยพินิจ
• Level 1 เหมาะกับการสำรวจส่วนใหญ่ที่อยู่ใกล้ขอบเขตซึ่งเข้าใจดีแล้ว
• Level 2 เหมาะกับงานจำกัดขอบเขตส่วนใหญ่ที่อาจมี dependency ที่ยังไม่รู้และปัญหาที่คาดไม่ถึง
• Level 3 เหมาะเมื่อสามารถบอกเงื่อนไขความสำเร็จได้ชัดเจนเพียงพอ
• Level 4 เหมาะเมื่อสามารถแบ่งงานได้สะอาดตามเงื่อนไขความสำเร็จ
• Level 5 เหมาะหลังจากการประสานงานและการสื่อสารที่จำเป็นระหว่างเงื่อนไขความสำเร็จหลายข้อถูก encode ไว้อย่างครบถ้วนแล้ว

การตรวจสอบยังคงเป็นคอขวด

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