เรากำลังอยู่บนจุดเปลี่ยนแปลงของการพัฒนาซอฟต์แวร์ การอภิปรายมักเกี่ยวกับ ใด AI ที่เขียนโค้ดที่ดีที่สุด (Claude vs. ChatGPT) หรือ ที่ไหน ว่า AI ควรทำงานในสภาพแวดล้อมใด (IDE หรือ CLI) แต่สิ่งนั้นไม่ใช่คำถามที่ถูกต้อง
ปัญหาไม่ได้อยู่ที่ การสร้าง ของโค้ด. มันคือ การตรวจสอบ ของมัน.
หากเราโอบรับ AI ในฐานะ “Vibe Coders” – โดยเรากำหนดเจตนาและให้ AI ดำเนินการ – เราจะสร้างกระแสซอฟต์แวร์ใหม่อย่างมหาศาล ฝูงของเอเจนต์ AI สามารถสร้างโค้ดได้ในหนึ่งนาทีมากกว่าที่นักพัฒนาระดับอาวุโสสามารถตรวจสอบได้ในหนึ่งสัปดาห์ มนุษย์กลายเป็นคอขวด
ทางแก้ไม่ได้อยู่ที่ มากขึ้น คน. ทางแก้คือ หน่วยงานออกแบบ AI.
โดยปกติ “Design Authority” คือกลุ่มสถาปนิกที่มารวมตัวกันสัปดาห์หรือเดือนละครั้งเพื่ออนุมัติหรือปฏิเสธการออกแบบ ในโลกของ การพัฒนา AI ความเร็วสูง โมเดลนั้นล้าสมัยอย่างสิ้นเชิง มันช้าเกินไปและตอบสนองช้า
เมื่อเราย้ายไปใช้ “Disposable Code” – ซอฟต์แวร์ที่เราไม่ทำการรีแฟคเตอร์อย่างไม่มีที่สิ้นสุด แต่ทิ้งและสร้างใหม่เมื่อความต้องการเปลี่ยนแปลง – บทบาทของเราจะเปลี่ยนแปลงอย่างพื้นฐาน เราจะไม่เป็นช่างก่ออิฐที่วางอิฐต่ออิฐอีกต่อไป เราจะเป็นสถาปนิกของโรงงานที่พิมพ์กำแพง
แต่ใครเป็นผู้ตรวจสอบว่ากำแพงเหล่านั้นตั้งตรงหรือไม่?
AI Design Authority ไม่ใช่บุคคล แต่เป็นสายการทำงาน เป็น “Gauntlet” ที่โค้ดที่สร้างขึ้นทุกบรรทัดต้องผ่านเพื่อให้เข้าสู่การผลิต กระบวนการนี้ไม่ได้แทนที่การตรวจสอบโค้ดโดยมนุษย์ด้วย ไม่มี, แต่ด้วยบางอย่าง ดีกว่า.
ทำงานในสามชั้น:
1. อำนาจการดำเนินการ (การสร้างสรรค์)
เราไม่ได้ขอให้ AI หนึ่งตัวเดียวหาวิธีแก้ เราขอให้สามตัวทำงานพร้อมกัน เราให้ Gemini 3, GPT-5 และโมเดลโอเพ่นซอร์ส (เช่น Llama) ทำงานพร้อมกันบนปัญหาเดียวกัน สิ่งนี้ป้องกันการมองแคบและทำลาย “ความขี้เกียจ” ที่บางครั้ง LLMs มี วิธีการนี้ยัง ได้รับการวิจัยทางวิทยาศาสตร์ และแสดงให้เห็นว่าคุณสามารถป้องกันการหลอนของ AI และสร้างสายงานที่ยาวมากโดยไม่มีข้อผิดพลาด
2. ตัวกรองแข็ง (กฎหมาย)
ที่นี่ไม่มีการถกเถียง โค้ดต้องคอมไพล์ Linters ต้องไม่บ่น และสำคัญที่สุด: การทดสอบกล่องดำ ต้องสำเร็จ เราไม่ได้ทดสอบว่าฟังก์ชันทำงานภายในหรือไม่ (อาจทำให้ AI ถูกควบคุม) เราทดสอบว่าระบบจากภายนอกทำตามที่ควรทำหรือไม่ หากการทดสอบล้มเหลว? ทิ้งลงถังขยะทันที
3. ตัวกรองอ่อน (คณะกรรมการ AI)
นี่คือการนวัตกรรมที่แท้จริง โซลูชันที่เหลือจะถูกนำเสนอให้กับ “Voting AI” ที่เชี่ยวชาญ ตัวแทนนี้ไม่ได้เขียนโค้ด แต่ อ่าน โค้ด เขาได้รับการฝึกฝนตามหลักสถาปัตยกรรมของเรา, ข้อกำหนดด้านความปลอดภัย (OWASP, ISO) และกฎการปฏิบัติตาม (EU AI Act).
เขาโหวตว่า: “โซลูชัน A เร็วกว่า แต่โซลูชัน B ปลอดภัยกว่าและสอดคล้องกับสถาปัตยกรรมไมโครเซอร์วิสของเราดียิ่งขึ้น.”
ผู้ชนะจะเข้าสู่การผลิต.
โมเดลนี้บังคับให้มีการแยกอำนาจซึ่งหลายทีมขาดหายไป.
project-description.md, rules.md, skills.md en principles.md), ข้อกำหนดที่เข้มงวด. สถาปนิกกำหนด อะไร เราสร้าง, ใครเป็นผู้สร้าง, อย่างไรและ ทำไม.
มันช่วยเราปลดปล่อยจากการกดขี่ของข้อผิดพลาดไวยากรณ์และทำให้เรามุ่งเน้นในสิ่งที่เราทำได้ดี: การคิดเชิงระบบ การค้นหาความจริง โครงสร้างและการตัดสินใจ.
คำถามไม่ได้ว่า AI สามารถเขียนโค้ดของเราได้หรือไม่ เรื่องนี้ได้ปิดไปแล้ว โค้ดส่วนใหญ่กลายเป็นผลิตภัณฑ์ใช้ครั้งเดียว.
คำถามคือ: คุณกล้าที่จะปล่อยการควบคุมเหนือ โค้ด ให้หลุดออกไป, เพื่อที่จะควบคุมเหนือ คุณภาพ จะชนะกลับได้หรือ?
แจ้งให้ฉันทราบ