วิธีที่ผมใช้ AI Councils เพื่อแก้ปัญหาทางวิศวกรรมที่มีความคลุมเครือ

ผู้ช่วย AI เพียงตัวเดียวอาจมีประโยชน์ แต่ยังไม่เพียงพอสำหรับสถาปัตยกรรมซอฟต์แวร์ที่ซับซ้อน

หากคุณใช้ AI มากกว่าแค่การเติมคำอัตโนมัติ (autocomplete) คุณจะเริ่มเห็นรูปแบบบางอย่าง โมเดลเพียงตัวเดียวจะเสนอทางออก ซึ่งดูเหมือนจะดี คุณนำไปใช้งาน แต่แล้วสามวันต่อมา คุณกลับพบข้อบกพร่องทางสถาปัตยกรรมที่ร้ายแรง

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

เพื่อแก้ปัญหาที่มีความคลุมเครือ คุณจำเป็นต้องมี AI Council นี่ไม่ใช่แพลตฟอร์มใหม่ แต่มันคือเวิร์กโฟลว์ที่ใช้บริบท (context) ของ AI หลายตัวมาช่วยกันตรวจสอบข้อเสนอจากบทบาทที่แตกต่างกัน

เป้าหมายคือการเปลี่ยนการใช้งาน AI ให้กลายเป็นเวิร์กโฟลว์ทางวิศวกรรมที่มีการกำกับดูแล

นี่คือเวิร์กโฟลว์:

• Problem Statement: คุณกำหนดขอบเขตของปัญหา • Architect Agent: เอเจนต์ที่อ้างอิงจากแหล่งข้อมูล (source-grounded agent) จะสร้างข้อเสนอพร้อมข้อดีและข้อเสีย (trade-offs) • AI Council Critique: บทบาท AI ที่แตกต่างกันจะช่วยกันตรวจสอบข้อเสนอ • Feedback Synthesis: เอเจนต์จะประเมินคำติชมทั้งหมดและระบุจุดที่ขัดแย้งกัน • Objection Ledger: คุณติดตามข้อโต้แย้งทั้งหมด ระดับความรุนแรง และการแก้ไข • Human Governance: คุณตัดสินใจว่าแผนพร้อมแล้วหรือยัง หรือต้องทำอีกรอบ • Executor Agent: บริบทที่แยกต่างหากจะทำหน้าที่นำแผนไปใช้งานจริง • Auditor Agent: บริบทที่สามจะตรวจสอบโค้ดเทียบกับข้อกำหนด (spec) เริ่มต้น

พลังของมันมาจาก "การแยกบทบาท" อย่าถามแค่ว่า "คุณคิดอย่างไร?" แต่จงมอบหมายบทบาทเฉพาะเจาะจงให้กับเซสชัน AI ที่ต่างกัน:

  • System Thinker: ประเมินความเสี่ยงเชิงระบบและขอบเขตต่างๆ
  • Critical Reviewer: ท้าทายสมมติฐานและค้นหาช่องโหว่ทางตรรกะ
  • Simplifier: ค้นหาความซับซ้อนที่ไม่จำเป็น
  • Alternatives Reviewer: เสนอแนวทางที่แตกต่างออกไป

ส่วนที่สำคัญที่สุดคือ Objection Ledger หากไม่มีสิ่งนี้ คำติชมจะกลายเป็นเพียงความเห็นที่เลื่อนลอย การมีบันทึก (ledger) จะบังคับให้คุณต้องจัดการกับทุกข้อกังวล คุณสามารถระบุสถานะข้อโต้แย้งเป็น Open (เปิดอยู่), Accepted (ยอมรับ), Rejected (ปฏิเสธ) หรือ Resolved (แก้ไขแล้ว) สิ่งนี้จะสร้างบันทึกการตัดสินใจที่สามารถตรวจสอบได้ (auditable decision record)

คุณจะไม่กลายเป็นคอขวดในการคัดลอกและวาง (copy-paste bottleneck) เพราะเอเจนต์ที่อ้างอิงจากแหล่งข้อมูลจะเป็นผู้ทำการสังเคราะห์ข้อมูล (synthesis) ส่วนคุณจะทำหน้าที่เป็นผู้กำกับดูแล (Governor) คุณไม่ได้ทำงานด้วยมือ แต่คุณเป็นเจ้าของ "ประตูควบคุม" (gates)

คุณคือเจ้าของการตัดสินใจ:

  • เมื่อไหร่ควรหยุดการทำซ้ำ (iterating)
  • เมื่อไหร่ควรอนุมัติข้อกำหนด (spec)
  • เมื่อไหร่ควรยอมรับความเสี่ยงสุดท้าย

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

เริ่มจากจุดเล็กๆ ใช้ผู้ตรวจสอบ (critic) หนึ่งคนและผู้ทำให้เรียบง่าย (simplifier) หนึ่งคน แล้วคุณจะเห็นคุณค่าของมันทันที

Source: https://dev.to/j3nnning/how-i-use-ai-councils-to-solve-ambiguous-engineering-problems-4dii