ในการสนทนาส่วนใหญ่เกี่ยวกับวิศวกรรมเอเจนต์ (agentic engineering) การดำเนินการได้เปลี่ยนจากการสั่งงาน (prompting) ไปเป็น การปฏิบัติการ (operating) นี่คือพรมแดนที่มองเข้าไปในหมอก: โรงงานซอฟต์แวร์ เป้าหมาย ลูป เซสชันเบื้องหลัง เอเจนต์ย่อย ฮุก แซนด์บ็อกซ์ เอเจนต์ที่ตรวจสอบเอเจนต์ สำหรับผู้สร้างอนาคตจำนวนมาก พฤติกรรมนี้จะถูกฝังอยู่ในผลิตภัณฑ์ตั้งแต่วันแรก: Claude Code และ Codex แสดงให้เห็นถึงการเปลี่ยนแปลงนี้โดยตรง
จากมุมมองของวิศวกร คุณจะใช้ อิสระต่ำ (low autonomy) เพื่อจำกัดความเสี่ยงและเพิ่มความสามารถในการย้อนกลับ แต่ใช้ อิสระสูง (higher autonomy) สำหรับกิจกรรมที่ชัดเจน และใช้กองเรือของเอเจนต์แบบขนานเพื่อปรับปรุงฐานโค้ดขนาดใหญ่อย่างปลอดภัย คำถามหลักเกี่ยวกับการดำเนินการคือ: งานนี้สมควรได้รับระดับไหน และการตรวจสอบแบบไหนที่ทำให้ระดับนั้นป้องกันได้?
ขอบของพรมแดนคือ เอเจนต์ผู้จัดการ (manager agent) ที่ตื่นขึ้นตามทริกเกอร์ของมัน มอบหมายงานให้ผู้ช่วยของมัน ในขณะที่ ตรวจสอบผลลัพธ์ของพวกเขาอย่างต่อเนื่อง และ ส่งคืนเฉพาะการตัดสินใจที่มนุษย์ต้องทำ ผู้คนที่ใช้การตั้งค่าแบบนี้อาจจะมีเอเจนต์หลายร้อยหรือหลายพันตัวกำลังทำงานอยู่แล้ว บนฐานโค้ดที่คงทนเป็นส่วนใหญ่ เช่นเดียวกับความคิดส่วนใหญ่เกี่ยวกับอิสระ วิธีการรับรู้ระดับยังคงแตกต่างกันไปในแต่ละคน
ระดับที่ถูกพูดถึงบ่อยที่สุดคือ บันไดแกนเดียวของ Steve Yegge ที่กล่าวถึงใน "Welcome to Gas Town" และใน The Pragmatic Engineer มันเป็นข้อมูลอ้างอิงที่ดีถ้าคุณต้องการตัวเลขที่บอกว่าคุณเป็น AI-native แค่ไหน: บันไดให้ตัวเลขเดียวที่ใช้วัดว่าคุณไว้ใจเอเจนต์ตัวเดียวได้แค่ไหน นี่คือเวอร์ชันหนึ่งของมัน:
ในช่วงต้นปี 2026 แม้ว่างานจะเริ่มเปลี่ยนจากการมอบหมายเป็นการประสานงาน นี่ก็ยังเป็นตัวแทนที่ดีในการวัดความเสี่ยง อย่างไรก็ตาม ทุกวันนี้ ทักษะหลายอย่างอาจมีนัยสำคัญและอำนาจต่อรองเพิ่มขึ้นเมื่อคุณสามารถรันเอเจนต์หลายตัวพร้อมกัน บันไดขั้นเดียวไม่สามารถช่วยให้คุณวางตำแหน่งทักษะหลายเอเจนต์ได้
แต่การถกเถียงเรื่องอิสระเกือบทั้งหมดที่ฉันเห็นมักจะรวมคำถามสองข้อที่ควรแยกออกจากกัน: เราปล่อยให้เอเจนต์ตัวเดียวไปไกลจากเราแค่ไหน และทักษะของเราในการประสานงานเอเจนต์หลายตัวเป็นอย่างไร?
เพื่อแยกสองมิติเหล่านี้ออกจากกัน เราจะใช้สองแกน: อิสระ (agency) และการประสานงาน (orchestration)
บนแกนอิสระ ระดับต่ำรวมถึงการแนะนำการกระทำที่เป็นไปได้และ รอการตัดสินใจ
ระดับกลางหมายถึงเอเจนต์กำลังทำงานเฉพาะอย่าง แต่ กำหนดขอบเขตสิ่งที่ทำ และ รายงานกลับอย่างต่อเนื่อง พร้อมหลักฐาน เพื่อให้คุณสามารถคอยควบคุมมันได้
ที่ปลายสูงของอิสระ เอเจนต์ ทำงานเพื่อบรรลุเป้าหมาย ทดลอง เรียนรู้ ทดสอบ หาวิธีแก้ปัญหา เจออุปสรรค ถามคำถาม ลองวิธีต่างๆ และส่งคืนงานทั้งหมดนี้เป็น หลักฐาน
บนแกนการประสานงาน ระดับต่ำหมายถึงเอเจนต์หนึ่งตัว หนึ่งเธรด ที่ระดับกลาง คุณมีเอเจนต์หลายตัว แต่ละตัวทำงานในแผนผังงาน (worktree) ของตัวเอง อาจทำงานเพื่อเป้าหมายที่แตกต่างกัน แต่แยกกัน ที่ปลายสูง คุณมีตัวประสานงานที่สามารถรับ backlog, ตัวติดตาม issue (issue tracker), ตารางงาน หรือคิวอื่นๆ และเปลี่ยนเป็นงานต่อเนื่อง คุณแค่ต้องเข้ามาเมื่อมีสิ่งผิดพลาด: "การจัดการโดยยกเว้น (management by exception)" ผลิตภัณฑ์และฟีเจอร์ที่รวมแนวคิดเหล่านี้ได้แก่:
- โหมด /plan, /goal, /loop, /background, /batch, /code-review, /security-review ของ Claude Code, เอเจนต์ย่อย, ฮุก, การเช็คพอยต์ (checkpointing), การมอบหมายและการจัดการเอเจนต์, เซสชันเบื้องหลัง, รูปแบบทีมเอเจนต์, อาร์กิวเมนต์ /schedule
- เธรด local/cloud ของ Codex, โหมด Goal, worktrees, Automations, เอเจนต์ย่อย, แผงตรวจสอบ (review panes), GitHub code review, ฮุก, การทำแซนด์บ็อกซ์ (sandboxing), Auto-review และ rerun
ความสามารถเหล่านี้ไม่สามารถใส่ลงในบันไดเส้นเดียวได้
การไต่บันได: สามยุคสมัยและสแต็กเดียว
ถ้าคุณอ่านบันไดจากล่างขึ้นบน คุณกำลังจินตนาการถึงการไต่ทั้งอิสระและการประสานงานไปพร้อมกัน โดยในทางปฏิบัติ หกระดับนี้เป็นตัวแทนของสามยุคสมัยที่เราทุกคนผ่าน:
อย่างแรก คุณอยู่ในตำแหน่งคนขับ และเอเจนต์ส่วนใหญ่แค่ช่วย รอให้คุณบังคับทิศทาง
อย่างที่สอง เอเจนต์รับผิดชอบงานหรือเป้าหมายที่มีขอบเขต แต่คุณยังคงอยู่เพื่อบังคับทิศทางและตรวจสอบสิ่งที่มันทำ
และอย่างที่สาม ในยุคของการประสานงาน ระบบสามารถดำเนินการทั้งหมด จัดส่งงานไปยังเอเจนต์หลายตัว และคุณส่วนใหญ่ต้องเข้ามาเมื่อมีสิ่งผิดพลาด: "การจัดการโดยยกเว้น"
สิ่งนี้ทำให้ง่ายขึ้น เพราะตำแหน่งแนวตั้งบนบันไดครอบคลุมสองแกนอย่างเรียบร้อย (การประสานงานเริ่มทำงานเมื่อใกล้ด้านบน) เหลือไว้เป็นการไต่ขึ้นทีละขั้นอย่างต่อเนื่อง และกระนั้น การไต่ขึ้นนี้ยังคงเป็นส่วนหนึ่งของการเปลี่ยนแปลงที่เราทุกคนกำลังผ่าน
วันดีๆ ในงานวิศวกรรมรวมถึงการแตะหลายขั้น บางครั้งมากกว่านั้น: เป็นเรื่องปกติที่จะสลับระหว่างยุคสมัยสองสามครั้งระหว่างทำงาน
หกระดับโดยละเอียด
ระดับ 0: ช่วยเหลือ (Assist)
เอเจนต์ให้คำแนะนำที่ส่วนใหญ่ดีและมักจะสมบูรณ์แบบ แต่คุณจะเป็นผู้ตัดสินใจเสมอว่าดีพอที่จะลงมือทำหรือไม่ คิดถึงการเติมข้อความอัตโนมัติ คำแนะนำแก้ไขในบรรทัด หรือการนั่งในแชทเซสชันเพื่อหารือเกี่ยวกับการเปลี่ยนแปลงที่ยังไม่มีใครรับผิดชอบ ใช้สำหรับข้อผิดพลาดที่มีค่าใช้จ่ายสูง การเปลี่ยนแปลงเล็กน้อย หรือเมื่อคุณกำลังสร้างวิจารณญาณของตัวเอง การตรวจสอบส่วนใหญ่เกิดขึ้นในเครื่อง
ระดับ 1: การดำเนินการภายใต้การดูแล (Supervised action)
เอเจนต์แก้ไขหรือรันคำสั่งในนามของคุณ โดยถามคุณก่อนที่จะดำเนินการใดๆ ที่มีผลกระทบ นี่คือท่าทางเริ่มต้นสำหรับคนส่วนใหญ่ สามารถทำได้ในแซนด์บ็อกซ์ในเครื่องพร้อมการอนุมัติก่อนใช้การเปลี่ยนแปลง - โดยที่การอนุมัติแต่ละครั้งคือการตรวจสอบอิสระว่าการเปลี่ยนแปลงนั้นใช้ได้ - หรือในเซสชันแบบโต้ตอบ โหมดล้มเหลวคือความเหนื่อยล้าจากการอนุมัติ (approval fatigue); การอนุมัติทั้งหมดรู้สึกเหมือนกันไม่ว่าจะอนุมัติอะไร คุณอาจแก้ไขได้โดยการพยายามดู diff ใช้ฮิวริสติกบางอย่าง ตรวจสอบกับคนอื่นก่อนอนุมัติ หรือแค่ตกลงให้เอเจนต์รับผิดชอบ Codex Auto-review แก้ปัญหานี้โดยมอบหมายการอนุมัติสุดท้ายของเงื่อนไขขอบเขตให้กับเอเจนต์ตรวจสอบแยกต่างหาก
ระดับ 2: การมอบหมายงานที่มีขอบเขต (Scoped task delegation)
ส่งมอบงานที่มีขอบเขตให้กับเอเจนต์ งานนั้นจะมีเป้าหมายที่ชัดเจน ข้อจำกัด และคำจำกัดความที่ใช้ได้ว่าสำเร็จแล้วเป็นอย่างไร คุณจะอยู่ใกล้ๆ สามารถขัดจังหวะได้ แต่ส่วนใหญ่ไม่ต้องมีส่วนร่วม นี่คือจุดศูนย์ถ่วงในโลกวิศวกรรมซอฟต์แวร์ การตรวจสอบกำลังเคลื่อนจากคุณ (คุณอาจต้องพักผ่อนและนอน) ไปสู่หลักฐานที่เอเจนต์สามารถสร้างได้: การทดสอบอัตโนมัติที่ผ่าน, ชนิด (types) ที่เหมาะสม, คำแนะนำ lint, ภาพหน้าจอ, ขั้นตอนการทำซ้ำ (repro steps), ที่มาโดยตัวอย่าง ฯลฯ
ระดับ 3: อิสระที่ขับเคลื่อนด้วยเป้าหมาย (Goal-driven autonomy)
เอเจนต์ทำทุกวิถีทางเพื่อให้บรรลุเป้าหมาย หยุดเมื่อตรงตามเงื่อนไขบางอย่างเท่านั้น ในโหมด prompt หมายถึง prompt กลายเป็นเป้าหมาย (เช่น "คุณช่วยลด time-to-interactive ของหน้านี้ให้ต่ำกว่า 1 วินาทีได้ไหม") ใน Codex นี่คือโหมด Goal: เอเจนต์วนรอบขั้นตอน plan->act->test->review จนกว่าจะไม่ตรงตามเกณฑ์ความสำเร็จ ใน Claude Code คือคำสั่ง /goal, /loop และ /schedule เพื่อให้ระดับนี้มีประโยชน์ เงื่อนไขการหยุดต้องวัดได้ในลักษณะที่สามารถทำให้เป็นอัตโนมัติ
อย่าขอให้เอเจนต์ของคุณช่วยเหลือเป้าหมายที่คลุมเครือและเลือนลาง เช่น "ปรับปรุงประสบการณ์ผู้ใช้โดยทั่วไป" หรือ "ทำให้ codebase ทดสอบได้มากขึ้น" เลือกสิ่งที่เจาะจง วัดผลได้ และเป็นอัตโนมัติ: ค้นหาบั๊กในโปรดักชันที่หลบเลี่ยง static analysis, ลดเวลาโหลด, ตรวจสอบให้แน่ใจว่าเรามี build TypeScript ที่เข้มงวดโดยไม่มี explicit anys, จัดการ dependencies ทั้งหมดเพื่อเก็บเฉพาะที่เราเข้าใจและผ่านการทดสอบของเรา ฯลฯ และสุดท้าย เพื่อค้นหาบั๊กในโปรดักชัน เอเจนต์จะต้องอยู่ในสภาพแวดล้อมที่เหมือนโปรดักชัน
ระดับ 4: การมอบหมายแบบขนาน (Parallel delegation)
ทำงานข้ามเอเจนต์หลายตัวแบบขนาน เอเจนต์แต่ละตัวทำงานในส่วนที่แยกออกจากกันของงาน คอขวดที่ใหญ่ที่สุดในระดับนี้คือการแยกย่อย (decomposition): การกำหนดส่วนที่เหมาะสมในการมอบหมาย สิ่งที่สนับสนุนได้แก่: เอเจนต์ย่อย, เซสชันเบื้องหลัง, /batch, worktrees, ทีมเอเจนต์ ฯลฯ โหมดล้มเหลวคือความขนานเทียม (false parallelism): รันเอเจนต์หลายตัวกับส่วนที่ทับซ้อนกันพร้อมกัน แทนที่จะได้งานมากขึ้น คุณกลับได้รับ merge conflicts และการตัดสินใจที่ซ้ำซ้อน เพื่อทำสิ่งนี้ให้ดี เอเจนต์ต้องถูกแยกออกจากกัน แต่ละตัวเป็นเจ้าของไฟล์และสถานะของตัวเอง แต่ละตัวต้องมีคิวตรวจสอบของตัวเองด้วย และสุดท้าย เอเจนต์แต่ละตัวมีต้นทุน - ในแง่ของโทเคนที่ใช้ไป - ตามสัดส่วนของจำนวนเอเจนต์ที่ทำงานพร้อมกัน ในฝั่งมนุษย์ ภาษีการประสานงาน (orchestration tax) ทำให้ต้นทุนส่วนเพิ่มของการเพิ่มเอเจนต์สูงขึ้นหลังจากไม่กี่ตัว
ระดับ 5: การประสานงานแบบจัดการโดยยกเว้น (Managed-by-exception orchestration)
กำหนดว่าความสำเร็จมีลักษณะอย่างไร และควรใช้นโยบายใด เอเจนต์ผู้จัดการจะตื่นขึ้นตามทริกเกอร์ (เช่น issue ใหม่, งานใหม่, นาฬิกา) ส่งเอเจนต์ผู้ปฏิบัติงาน ติดตามความคืบหน้า ตรวจสอบผลลัพธ์ ลองใหม่เมื่อล้มเหลว ส่งต่อให้เอเจนต์หรือมนุษย์ที่เก่งกว่าเมื่อตรงตามเงื่อนไข รวมผลลัพธ์ และสุดท้ายส่งคืนผลงาน (เช่น PR) และหลักฐานไปยังระบบภายนอก คิดถึงโรงงาน: ตัวติดตาม issue หรือ backlog คืออินพุต และผลิตภัณฑ์ของโรงงานคือเอาต์พุต (เช่น issue และบั๊กที่ถูกแก้ไขมากมาย) เอเจนต์ทำงานในสภาพแวดล้อมที่แยกตัวอย่างเหมาะสมพร้อมกำแพงมากมาย (และหากจำเป็น ช่องทางหลบหนี) และมีเพียงระบบปฏิบัติการ - ที่กำหนดโดยเอเจนต์ผู้จัดการ - ที่กำหนดว่าโรงงานควรทำอะไร
การออกแบบระบบปฏิบัติการนี้เป็นหน้าที่ของมนุษย์ OpenAI เสนอ spec สำหรับ Symphony ซึ่งมี Linear board เป็นศูนย์กลาง: แต่ละ issue ได้รับ workspace เอเจนต์ของตัวเอง และเอเจนต์จะตรวจสอบอย่างต่อเนื่องว่ากำลังก้าวหน้าไปสู่เป้าหมายตามที่กำหนดในไฟล์ spec ใน workspace ของตัวเอง การตรวจสอบโดยมนุษย์สามารถทำได้ในระดับที่หลักฐานถูกสร้างขึ้น แต่พรมแดน (คือสิ่งที่ทรงพลังที่สุดในโลกของการประสานงาน) คือการสร้างโรงงานเอเจนต์ต่อเนื่องที่มีเอเจนต์หลายร้อยหรือหลายพันตัว ณ จุดนี้ในการไต่ขึ้น การมีการตรวจสอบอิสระมีความสำคัญมากขึ้นเรื่อยๆ: ผู้ดำเนินการและผู้ตรวจสอบแยกกัน, ผู้รันทดสอบและ QA แยกกัน, การตรวจสอบความปลอดภัยแยกกัน, ประตูกระบวนการรับรองแยกกัน
ความเสี่ยงและการย้อนกลับกำหนดเพดาน
ฉันจำได้ว่าเคยอ่านงานวิจัยก่อนหน้านี้ของ Anthropic เกี่ยวกับงานที่ยากที่สุดบางงานกับ Claude Code ซึ่งมันขอคำชี้แจงบ่อยกว่าที่ผู้ใช้ขัดจังหวะถึงสองเท่า ผู้ใช้ที่มีประสบการณ์ (~750 เซสชัน เทียบกับต่ำกว่า 50) มีแนวโน้มที่จะอนุมัติอัตโนมัติและขัดจังหวะโดยจับตาดูความคืบหน้ามากกว่า
พวกเขายังทำการวิเคราะห์ที่กว้างขึ้นมากมายเกี่ยวกับวิธีที่ผู้คนใช้ Claude Code พวกเขาดู ~400K เซสชันจาก ~235K คนระหว่างตุลาคม 2025 ถึงเมษายน 2026 จากแต่ละเซสชันพวกเขาสามารถหาการตัดสินใจที่某人ทำ เช่น จำนวนการดำเนินการที่ขอในแต่ละ prompt, เลือกใดที่จะอนุมัติอัตโนมัติ, ความถี่ที่ขัดจังหวะ ฯลฯ มนุษย์ทำการตัดสินใจวางแผน ~70% แต่ Claude ดำเนินการ ~80% อิสระสูงไม่ใช่การเอาคนออกจากลูป แต่เปลี่ยนจากการให้พวกเขาทำทุกขั้นตอนเป็นการให้พวกเขาตัดสินใจว่าจะไปทิศทางไหนต่อ
ถ้าเราต้องการพิจารณาว่าระบบ AI ขนาดใหญ่ทำงานด้วยอิสระสูงหรือไม่ สามคำถามที่เราควรถามคือ:
- เราจะรู้ได้เร็วแค่ไหนว่าเราคิดผิดเกี่ยวกับสิ่งที่มันทำ?
- เราสามารถเลิกสิ่งที่มันทำได้อย่างสะอาดแค่ไหน?
- อะไรจะพิสูจน์ว่าเราคิดถูกเกี่ยวกับสิ่งที่มันทำ? ถ้าคำตอบของทั้งสามคือ: ไม่เร็ว, ด้วยความยากลำบากอย่างยิ่ง, และเชื่อถือสรุป แสดงว่าไม่ใช่อิสระสูง
การรันเอเจนต์ทุกครั้งควรมีสัญญาที่กำหนดว่ามันพยายามทำอะไร
เป้าหมาย: สิ่งที่เราพยายามบรรลุ (ไม่ใช่กิจกรรม ไม่ใช่เทคนิค แต่เป็นผลลัพธ์)
ขอบเขต: โดเมนที่เราดำเนินการอยู่ และเทคนิคใดที่อนุญาต
สิ่งที่ไม่ใช่เป้าหมาย: สิ่งที่ไม่ใช่ส่วนหนึ่งของวัตถุประสงค์
เครื่องมือและสิทธิ์: วิธีที่เอเจนต์สามารถทำงานร่วมกับโลกภายนอก
เงื่อนไขการหยุด: เมื่อใดควรหยุด; ควรเป็นตัวแปรที่วัดได้
หลักฐาน: การทดสอบเฉพาะ ภาพหน้าจอ โลห บันทึกฐานข้อมูล หรือตัวบ่งชี้อื่นๆ ที่สามารถใช้ยืนยันว่ามีบางอย่างเสร็จสิ้น (โดยอิสระจากเอเจนต์)
การส่งต่อ: ใครมีส่วนร่วมในสถานการณ์ใด (รวมถึงใครเป็นคนรันเอเจนต์)
และงบประมาณ: ข้อจำกัดด้านเวลา ความพยายาม และโทเคนที่จะทุ่มเทให้กับงาน (โทเคนคืองบประมาณของโมเดล AI ขนาดใหญ่ - คุณยังสามารถรวมข้อจำกัดจำนวนครั้งที่สามารถลองงานและข้อจำกัดระดับความขนาน)
เมตริกทำให้อิสระเชื่อถือได้มากขึ้นเล็กน้อย
การตัดสินใจเกี่ยวกับเมตริกหลังจากเหตุการณ์อาจไม่เพียงพอ เมตริกสามารถวางไว้ล่วงหน้าในเอกสารสั้นๆ และสิ่งนั้นทำให้อิสระรู้สึกเชื่อถือได้มากขึ้น และทำให้การก้าวกระโดดแห่งความเชื่อมั่นง่ายขึ้นเล็กน้อย
ในขณะที่มีหลายวิธีในการวัดความสำเร็จ ลองพิจารณาติดตามเมตริกเหล่านี้บางเวอร์ชันสำหรับแต่ละระดับของอิสระ:
- เวลาเฉลี่ยระหว่างการแทรกแซง (Mean time between interventions)
- การรันโดยไม่มีคนดูแลที่ยาวนานที่สุดที่สำเร็จและงานได้รับการยอมรับ (Longest successful unattended run with accepted work)
- สัดส่วนของการดำเนินการที่รันในแซนด์บ็อกซ์เทียบกับการส่งต่อ (Share of actions run in the sandbox vs escalated)
- เปอร์เซ็นต์ของการดำเนินการที่อนุมัติอัตโนมัติเทียบกับถูกปฏิเสธ (Percentage of actions auto-approved vs rejected)
- จำนวนเฉลี่ยของการดำเนินการเอเจนต์ต่อคำสั่งมนุษย์ (Mean number of agent actions per human instruction)
- อัตราการขอคำชี้แจง อัตราการขอขัดจังหวะ (Clarification request rate Interrupt request rate)
- เวลาตรวจสอบต่อการเปลี่ยนแปลงที่ยอมรับ (Review time per accepted change)
- อัตราการทำงานซ้ำในแต่ละระดับความมั่นใจ (Rework rate on each level of confidence)
- อัตราการหลุดรอดของข้อบกพร่องในแต่ละระดับความมั่นใจ (Defect escape rate on each level of confidence)
- ต้นทุนโทเคนต่อการเปลี่ยนแปลงที่ยอมรับ (Token cost per accepted change)
เมตริกเหล่านี้สามารถบอกเรื่องราว: เอเจนต์ตัวเดียวที่ถูกทำให้ยุ่งโดยการส่งต่อของมนุษย์คือระดับ 4 พร้อมแดชบอร์ด เอเจนต์ที่อนุรักษ์นิยม ไม่ยอมดำเนินการโดยไม่มีการ intake อัตโนมัติ การลองใหม่ และหลักฐานที่ดี คือระดับ 5 พร้อมประตูจริง
คิดถึงความพร้อม
จำแนกงานตามความเสี่ยงและความง่ายในการเลิกทำ ใช้อิสระอย่างอนุรักษ์นิยม เพิ่มขึ้นเมื่อมีหลักฐานสนับสนุนระดับที่สูงขึ้นสะสมเท่านั้น การปรับโครงสร้าง payment engine ที่ป้องกันด้วยการทดสอบที่แข็งแกร่งและเอเจนต์ตรวจสอบพร้อม path การย้อนกลับที่สะอาดสามารถรองรับอิสระที่สูงกว่ามากเมื่อเทียบกับงานระบบอัตโนมัติด้านเอกสารที่ขาดความจริงตามบัญญัติใดๆ ระดับอิสระควรเป็นไปตามกระบวนการตรวจสอบ ไม่ใช่ชื่องาน
สี่ anti-patterns
ทุกระบบสามารถตกเป็นเหยื่อของ autonomy anti-pattern ทั้งสี่นี้ได้ง่ายๆ เว้นแต่จะหลีกเลี่ยงอย่างระมัดระวัง
อิสระในฐานะสถานะ (Autonomy as status) - ระดับอิสระของเอเจนต์กลายเป็นตราสถานะที่ไร้ความหมาย อิสระที่สูงกว่าถูกปฏิบัติเป็นหลักฐานของความสามารถ ไม่ใช่ความปลอดภัย และเอเจนต์ถูกรันหนักกว่าที่การตรวจสอบรองรับ วิธีแก้: ชื่นชมและให้รางวัลแก่ผู้ที่เลือกใช้อิสระในระดับที่ถูกต้องและหลีกเลี่ยงการเกินขอบเขตอย่างไม่ลดละ
การฟอกสิทธิ์ (Permission laundering) - ทรราชย์แห่งความเหนื่อยล้าจากการอนุมัตินำเราไปสู่การให้สิทธิ์เข้าถึง AI และเครื่องมืออย่างกว้างขวางเกินความจำเป็น วิธีแก้: ขอบเขตที่ดีกว่าคือทางแก้เสมอ เช่น โปรไฟล์แซนด์บ็อกซ์, writable roots ที่มีขอบเขต, คำสั่งที่อนุญาต (allowlisted commands), ฮุก และ Auto-review
การแทนที่ด้วยสรุป (Summary substitution) - สรุปงานของเอเจนต์แทนที่การตรวจสอบ โดยสมมติว่าสรุปเพียงพอ วิธีแก้: รวมแพ็กเกจหลักฐานเดียวกันกับการตรวจสอบด้วยตนเองเต็มรูปแบบ (diff, การทดสอบ, โลห, ภาพหน้าจอ, ผลการตรวจสอบ, ความเสี่ยง, ช่องว่าง ฯลฯ) ขณะที่หลีกเลี่ยงการยอมจำนนทางความคิด (cognitive surrender)
การแต่งเป็นกองเรือ (Fleet cosplay) - เอเจนต์หลายสิบตัวทำงานแบบขนาน แต่มนุษย์ยังคงประสานงานทุก dependency ด้วยตนเอง วิธีแก้: สถานะที่ใช้ร่วมกัน, กฎความเป็นเจ้าของ, และการติดตาม dependency ที่ดีขึ้นค่อยๆ ลดความจำเป็นในการประสานงานด้วยตนเอง ข้อจำกัด WIP ที่เล็กลงบังคับให้มุ่งเน้นไปที่การเข้ารหัสและบันทึกขั้นตอนที่ประสานงานจนกว่าการประสานงานจะกลายเป็นอัตโนมัติ
แบบฝึกหัดการปรับเทียบ (A calibration exercise)
ทบทวนสิบงานล่าสุดที่คุณทำด้วยความช่วยเหลือของเอเจนต์ สำหรับแต่ละงาน บันทึกระดับอิสระที่ใช้ ความเสี่ยงที่เกี่ยวข้อง ความง่ายที่งานจะถูกเลิกทำ หลักฐานที่สร้างขึ้นเพื่อให้ตรงตามข้อกำหนดการตรวจสอบ เวลาตรวจสอบ หากต้องทำงานซ้ำ และว่าระดับอิสระที่เลือกจะยังเหมาะสมในครั้งต่อไปหรือไม่
วิธีไต่อย่างปลอดภัย (How to climb safely)
เคลื่อนที่ขึ้นทีละแกน เริ่มต้นด้วยเอเจนต์ที่ถูกดูแลตัวเดียวเพื่อทำงานที่มีขอบเขตเดียวที่สร้างหลักฐานความสำเร็จที่ป้องกันได้ (ระดับอิสระ 1 ถ้าจัดระเบียบพอ) จากนั้นค่อยๆ ขยายในสามทิศทางที่ตั้งฉากกัน ทำการสำรวจที่เน้นการอ่านแบบขนาน (ระดับอิสระ 4) เพิ่มเอเจนต์เขียนที่ทำงานบน worktrees แยกต่างหากพร้อมกฎความเป็นเจ้าของไฟล์ที่จำกัด (ระดับอิสระ 4) เพิ่มระบบอัตโนมัติที่เกิดซ้ำ จากนั้นการประสานงานที่นำโดยเอเจนต์ตาม issues, เสียง ฯลฯ ทุกก้าวขึ้นคันโยกต้องใช้ชุดกลไกความปลอดภัยใหม่ (เช่น โหมดล้มเหลวใหม่)
ตั้งชื่อพวกมัน: การรันเอเจนต์เดียวนานขึ้นอาจนำไปสู่การล่องลอย (drift), บริบทเน่า (context rot), การสื่อสารที่หลุด (dropped communication), หรือวัตถุประสงค์ที่คลาดเคลื่อน (strayed objectives) งานเบื้องหลังอาจนำไปสู่สมมติฐานที่เก่า (stale assumptions) และการส่งต่อที่อ่อนแอ (weak handoffs) งานขนานมากเกินไปอาจนำไปสู่ merge conflicts หรือการตัดสินใจที่ซ้ำซ้อน งานที่เกิดซ้ำมากเกินไปอาจนำไปสู่การใช้โทเคนเงียบ (silent token spend) หรือ prompts ที่เก่า (stale prompts) การจัดการโดยยกเว้นอาจนำไปสู่คิวตรวจสอบที่ยาวและความเหนื่อยล้าจากการแจ้งเตือน (alert fatigue) อย่าแก้ด้วยการเชื่อถือมากขึ้น แต่ให้จำกัดขอบเขต, ตรวจสอบหลักฐานที่ดีขึ้น, เปิดใช้งาน path การย้อนกลับที่ถูกกว่า, ทำให้ประตูแข็งแกร่งขึ้น, และกำหนดกฎความเป็นเจ้าของที่ชัดเจนขึ้น
ใช้ระดับอิสระ (Use the autonomy level):
- ระดับ 0 เหมาะที่สุดสำหรับงานที่ละเอียดอ่อนและเมื่อกำลังสร้างวิจารณญาณ
- ระดับ 1 เหมาะที่สุดสำหรับการสำรวจส่วนใหญ่ ถ้างานทำใกล้ขอบเขตของสิ่งที่เข้าใจดี
- ระดับ 2 เหมาะที่สุดสำหรับงานที่มีขอบเขตส่วนใหญ่ โดยรู้ว่าอาจมี dependencies ที่ไม่รู้จักและ gotchas ที่ไม่คาดฝัน
- ระดับ 3 เหมาะที่สุดเมื่อเงื่อนไขความสำเร็จสามารถระบุได้อย่างชัดเจนเพียงพอ
- ระดับ 4 เหมาะที่สุดเมื่องานสามารถแบ่งแยกอย่างสะอาดตามเงื่อนไขความสำเร็จเหล่านี้
- ระดับ 5 เหมาะที่สุดเมื่อการประสานงานและการสื่อสารที่ต้องการข้ามเงื่อนไขความสำเร็จต่างๆ ถูกเข้ารหัสอย่างสมบูรณ์
การตรวจสอบจะเป็นคอขวดเสมอ (Verification will always be the bottleneck.)
แม้จะมีความกล้าแสดงออกและเครื่องมือในปัจจุบัน ท่าทางที่成熟ของทีมวิศวกรรมที่ทำงานกับเอเจนต์ AI คือ อิสระที่ปรับเทียบแล้ว (calibrated autonomy)
คอขวดคือการประสานงาน การตรวจสอบ การบำรุงรักษา การตัดสินใจด้านผลิตภัณฑ์ และการเรียนรู้จากเหตุการณ์
ในอนาคตอันใกล้ เราจะต้องการออกแบบลูปที่รู้ว่าเมื่อใดควรทำงาน เมื่อใดควรตรวจสอบ และเมื่อใดควรถาม - แต่ ทักษะของวิศวกรจะยังคงอยู่ที่การเลือกระดับอิสระที่ถูกต้อง และการสร้างรูปแบบและหลักฐานที่ป้องกันได้ซึ่งป้องกันด้านมืดของมัน
หมายเหตุ: Pangram ติดป้ายบทความนี้ว่าเขียนโดยมนุษย์ 100%: https://www.pangram.com/history/87531e13-cd12-4cb0-9e02-9579719ddc26
