ผู้มีอำนาจในการออกแบบ AI

เรากำลังอยู่ในจุดเปลี่ยนของการพัฒนาซอฟต์แวร์ การอภิปรายมักจะวนเวียนอยู่กับ คำถามที่แท้จริงคือ AI เขียนโค้ดได้ดีที่สุด (Claude เทียบกับ ChatGPT) หรือ ที่ไหน AI ควรจะทำงานที่ไหน (IDE หรือ CLI) แต่นั่นไม่ใช่คำถามที่ถูกต้อง

หากเรายอมรับ AI ในฐานะ "Vibe Coders" ซึ่งเราเป็นผู้กำหนดเจตจำนงและให้ AI เป็นผู้ดำเนินการ เราจะสร้างซอฟต์แวร์ใหม่ๆ ออกมาได้อย่างมหาศาล ฝูง AI-agents สามารถสร้างโค้ดได้มากกว่าที่นักพัฒนาระดับอาวุโสจะตรวจสอบได้ในหนึ่งสัปดาห์ภายในเวลาเพียงหนึ่งนาที มนุษย์จึงกลายเป็นคอขวดไปแล้ว

ทางออกไม่ใช่ มากขึ้น การเพิ่มจำนวนคน แต่ทางออกคือ ผู้มีอำนาจตัดสินใจด้านการออกแบบ AI.

จากช่างฝีมือสู่ผู้บริหารโรงงาน

โดยปกติแล้ว "Design Authority" คือกลุ่มสถาปนิกที่ประชุมกันสัปดาห์ละครั้งหรือเดือนละครั้งเพื่ออนุมัติหรือปฏิเสธการออกแบบ แต่ในโลกของ การพัฒนา AI ด้วยความเร็วสูง (high-velocity AI development) รูปแบบดังกล่าวล้าสมัยไปแล้ว มันช้าและตอบสนองไม่ทันการณ์

หากเราเปลี่ยนไปใช้แนวคิด "Disposable Code" หรือซอฟต์แวร์ที่เราไม่ต้องรีแฟคเตอร์อย่างไม่สิ้นสุด แต่ทิ้งและสร้างใหม่เมื่อความต้องการเปลี่ยนไป บทบาทของเราจะเปลี่ยนไปอย่างสิ้นเชิง เราไม่ใช่ช่างก่ออิฐที่วางอิฐทีละก้อนอีกต่อไป แต่เราคือสถาปนิกของโรงงานที่พิมพ์ผนังเหล่านั้นออกมา

แต่ใครจะเป็นผู้ตรวจสอบว่าผนังเหล่านั้นตั้งตรงหรือไม่?

"Gauntlet": บททดสอบความพร้อมแบบอัตโนมัติ

AI Design Authority ไม่ใช่บุคคล แต่เป็นไปป์ไลน์ (Pipeline) หรือ "ด่านทดสอบ" (Gauntlet) ที่โค้ดทุกบรรทัดที่สร้างขึ้นต้องผ่านการตรวจสอบอย่างเข้มงวดก่อนจะนำไปใช้งานจริง กระบวนการนี้ไม่ได้เข้ามาแทนที่การตรวจสอบโค้ดโดยมนุษย์ด้วย ไม่มีอะไรแต่เข้ามาแทนที่ด้วยสิ่งที่ ดีกว่า.

มันทำงานผ่านสามระดับ:

1. ฝ่ายปฏิบัติการ (การสร้างโค้ด)
เราไม่ได้ขอให้ AI เพียงตัวเดียวหาทางออก แต่เราใช้ AI ถึงสามตัว เราให้ Gemini 3, GPT-5 และโมเดลโอเพนซอร์ส (เช่น Llama) ทำงานแก้ปัญหาเดียวกันแบบขนาน วิธีนี้ช่วยป้องกันภาวะมองมุมเดียว (Tunnel Vision) และขจัดความ "ขี้เกียจ" ที่ LLM มักประสบ แนวทางนี้ยัง ได้รับการวิจัยทางวิทยาศาสตร์รองรับ และแสดงให้เห็นว่าคุณสามารถป้องกันการหลอนของ AI (Hallucination) และสร้างห่วงโซ่การทำงานที่ยาวมากได้โดยปราศจากข้อผิดพลาด

2. ตัวกรองขั้นเด็ดขาด (กฎระเบียบ)
ในขั้นนี้ไม่มีการโต้แย้ง โค้ดต้องคอมไพล์ผ่าน Linters ต้องไม่แจ้งเตือน และที่สำคัญที่สุดคือ การทดสอบแบบกล่องดำ (Black Box Tests) ต้องผ่านการทดสอบ เราไม่ได้ทดสอบว่าฟังก์ชันทำงานภายในอย่างไร (เพราะ AI อาจปรับแต่งผลลัพธ์ได้) แต่เราทดสอบว่าระบบทำงานได้ตามที่ต้องการจากภายนอกหรือไม่ หากการทดสอบล้มเหลว ให้ทิ้งลงถังขยะทันที

3. ตัวกรองแบบซอฟต์ (คณะลูกขุน AI)
นี่คือนวัตกรรมที่แท้จริง โซลูชันที่เหลือจะถูกส่งต่อไปยัง "AI ผู้ตัดสิน" (Voting AI) ที่มีความเชี่ยวชาญเฉพาะทาง เอเจนต์ตัวนี้ไม่ได้เขียนโค้ด แต่ทำหน้าที่ อ่าน ตรวจสอบโค้ด โดยได้รับการฝึกฝนตามหลักการสถาปัตยกรรม ข้อกำหนดด้านความปลอดภัย (OWASP, ISO) และกฎระเบียบด้านการปฏิบัติตามข้อกำหนด (EU AI Act) ของเรา
เขาลงคะแนนว่า: “โซลูชัน A ทำงานได้เร็วกว่า แต่โซลูชัน B ปลอดภัยกว่าและสอดคล้องกับสถาปัตยกรรมไมโครเซอร์วิสของเรามากกว่า”

ผู้ชนะจะถูกนำไปใช้งานจริง

หลักการแบ่งแยกอำนาจ (Trias Politica) ของซอฟต์แวร์

โมเดลนี้บังคับให้เกิดการแบ่งแยกอำนาจซึ่งมักขาดหายไปในหลายทีม

• อำนาจนิติบัญญัติ (สถาปนิก): สถาปนิกเป็นผู้เขียน "รัฐธรรมนูญ" ไม่ว่าจะเป็นพรอมต์ เอกสารสถาปัตยกรรม (project-description.md, rules.md, skills.md en principles.md) และข้อกำหนดที่เข้มงวด สถาปนิกเป็นผู้กำหนดว่า อะไร เราจะสร้างอะไร ใครเป็นผู้สร้าง อย่างไร และ ทำไม.
• อำนาจบริหาร (Coding Agents): พวกเขาเป็นผู้ดำเนินการอย่างรวดเร็ว ต้นทุนต่ำ และอยู่ภายใต้การกำกับดูแลของนักพัฒนาที่เป็นมนุษย์
• อำนาจตุลาการ (Design Authority): ชั้น AI อิสระที่ทำหน้าที่ตรวจสอบความถูกต้องตามกฎเกณฑ์

บทสรุป: บทบาทใหม่ของสถาปนิก

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

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

บอกให้ฉันรู้