คณะผู้กำหนดการออกแบบ AI

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

ปัญหาไม่ใช่ การสร้าง ของโค้ด แต่เป็น การตรวจยืนยัน ของมัน

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

ทางออกไม่ใช่ มากขึ้น การเพิ่มจำนวนคน ทางออกคือ หน่วยงานออกแบบ AI.

จากช่างฝีมือสู่ผู้จัดการโรงงาน

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

เมื่อเราย้ายไปสู่ "โค้ดแบบใช้แล้วทิ้ง" — ซอฟต์แวร์ที่เราไม่ทำการรีแฟกเตอร์ไม่รู้จบ แต่ทิ้งแล้วสร้างใหม่เมื่อข้อกำหนดเปลี่ยน — บทบาทของเราจะเปลี่ยนไปอย่างลึกซึ้ง เราไม่ใช่ช่างก่ออิฐที่วางก้อนทีละก้อนอีกต่อไป แต่เป็นสถาปนิกของโรงงานที่พิมพ์กำแพง

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

"การทดสอบหนัก": การพิสูจน์ด้วยระบบอัตโนมัติ

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

มันทำงานในสามชั้น:

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

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

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

ผู้ชนะจะถูกนำขึ้นใช้งานจริง

อำนาจทั้งสามของซอฟต์แวร์

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

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

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

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

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

แจ้งให้ฉันทราบ