หน่วยงานกำกับดูแลการออกแบบ AI

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

ปัญหาที่แท้จริงไม่ใช่ การสร้าง ของโค้ด ปัญหาที่แท้จริงคือ การตรวจสอบความถูกต้อง ของมัน

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

ทางออกไม่ใช่ เพิ่มเติม มนุษย์ ทางออกคือ ผู้มีอำนาจในการออกแบบ AI.

จากช่างฝีมือสู่ผู้อำนวยการโรงงาน

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

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

แต่ใครจะตรวจสอบว่ากำแพงเหล่านั้นตั้งตรงหรือไม่?

“The Gauntlet”: การทดสอบด้วยไฟแบบอัตโนมัติ

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

ทำงานเป็นสามชั้น:

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

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

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

ผู้ชนะจะได้เข้าสู่กระบวนการผลิต

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

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

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

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

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

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