AI กำลังเขียนโค้ด แต่โครงสร้างพื้นฐานของคุณสามารถรองรับได้หรือไม่?

เรากำลังอยู่ในช่วงการพลิกผันของประวัติศาสตร์ทางวิศวกรรมซอฟต์แวร์ที่แปลกประหลาดที่สุด สำหรับหลายทศวรรษที่ผ่านมา เป้าหมายคือการสร้างระบบที่มีผลลัพธ์เดียวกันทุกครั้ง แต่ตอนนี้เรากำลังวางซอฟต์แวร์เอไอที่มีแนวโน้มเป็นไปได้บนพื้นฐานนั้น โดยสร้างโค้ดในปริมาณและความเร็วที่น่าตกใจ และถ้าจะพูดตรงๆ โครงสร้างพื้นฐานส่วนใหญ่ของเราก็ไม่ได้ถูกสร้างขึ้นสำหรับสิ่งนี้

ผมใช้เวลาหลายปีในการทำงานเกี่ยวกับเครื่องมือ DevOps การเขียนร่วมวิจัย และช่วยให้ทีมวิศวกรบรรลุผลงานสูงสุด สิ่งที่ผมเห็นตอนนี้เกี่ยวกับการพัฒนาด้วยเอไอคือมากกว่าการพัฒนาที่มีพลัง มันทำให้ทุกจุดอ่อนในกระบวนการทำงานที่มีอยู่ของเราต้องเผชิญ

ปัญหาอยู่ที่นี่แล้ว

การศึกษาของ GitClear ในปี 2025 พบว่าเกือบ 7% ของการเปลี่ยนแปลงโค้ดนั้นประกอบด้วยโค้ดที่สร้างโดยเอไอ การวิเคราะห์ก่อนหน้านี้ของ โค้ด 153 ล้านบรรทัดที่เปลี่ยนแปลง เปิดเผยต้นทุน: “การเปลี่ยนแปลงโค้ด” – โค้ดที่เขียนใหม่หรือลบภายในสองสัปดาห์ – เพิ่มขึ้นสองเท่าภายในปี 2024 เมื่อเทียบกับมาตรฐานก่อนเอไอ

ผลกระทบด้านความปลอดภัยนั้นเท่าเทียมกัน การวิเคราะห์เร็วๆ นี้ ของงานเขียนโค้ด 80 งานที่เลือกอย่างดีบนโมเดลภาษาขนาดใหญ่มากกว่า 100 โมเดลพบว่าโค้ดที่สร้างโดยเอไอทำให้เกิดช่องโหว่ด้านความปลอดภัยใน 45% ของกรณี ผลกระทบในโลกแห่งความเป็นจริง? หนึ่งในห้า CISO รายงานเหตุการณ์สำคัญที่เกิดจากโค้ดที่สร้างโดยเอไอโดยตรง

ความเร็วที่เพิ่มขึ้นนั้นเป็นจริง แต่ต้นทุนด้านเสถียรภาพก็เป็นจริงเช่นกัน

ผลกระทบการขยาย

สิ่งหนึ่งที่ผมได้เรียนรู้คือ AI ขยายผลของทุกอย่าง หากคุณมีแนวปฏิบัติที่ดี AI จะทำให้มันดีขึ้นและเร็วขึ้น แต่หากกระบวนการยุ่งเหยิง AI ก็จะทำให้ความยุ่งเหยิงนั้นรุนแรงขึ้นเช่นกัน เรื่องนี้สอดคล้องกับรูปแบบที่ปรากฏซ้ำทุกปีในรายงาน DevOps ประจำปีของ DORA: ตัวแปรที่น้อยลงนำไปสู่ผลลัพธ์ที่ดีกว่า ทีมที่ประสบความสำเร็จเลือกใช้ระบบปฏิบัติการ ภาษาโปรแกรม และวิธีทำงานให้น้อยแบบและเป็นมาตรฐานเดียวกัน พวกเขาลดความซับซ้อนอย่างตั้งใจ

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

ปฏิทรรศน์ของการกำหนด

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

คำตอบของฉัน? ให้พื้นฐานของสแต็คให้กำหนดไว้มากที่สุด หากคุณสามารถรักษาโครงสร้างพื้นฐาน 80% ที่ระดับการกำหนดไว้ได้ เอเจนต์เอไอของคุณจะมีตัวแปรที่ต้องจัดการน้อยลง พวกมันไม่ได้ใช้หน้าต่างบริบทกับ “ทำไมมันไม่ติดตั้ง?” หรือ “ให้ฉันลองคำสั่งสร้างอีกครั้ง” พวกมันเน้นไปที่งานจริงที่คุณขอให้พวกมันทำ

ลองคิดดูว่า เมื่อเอเจนต์พยายามคอมไพล์บางอย่างแล้ว native binding ล้มเหลวเพราะไม่ได้ติดตั้ง ImageMagick นั่นคือทางอ้อมที่สิ้นเปลืองโทเค็น หากสภาพแวดล้อมมีทุกอย่างที่ต้องใช้แล้ว ทั้งคอมไพเลอร์ ไลบรารี และสายการพึ่งพาทั้งหมดลงไปถึง libc เอเจนต์ก็ทำงานได้ทันที ไม่มีการแก้จุดบกพร่อง ไม่มีการลองผิดลองถูก มีแต่ความคืบหน้า

การกำหนดรายละเอียดและตรวจสอบเป็นกุญแจ

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

ผมสังเกตเห็นสิ่งที่น่าสนใจ: คนที่มีพื้นหลังด้านการจัดการผลิตภัณฑ์หรือวิศวกรรมผลิตภัณฑ์มักจะประสบความสำเร็จกับเอเจนต์เอไอในขณะนี้ พวกเขามีการฝึกอบรมที่คิดในแง่ของความต้องการ มาตรฐานความสำเร็จ และการแลกเปลี่ยน พวกเขาสบายใจที่จะถาม “ทำไมคุณเลือกสิ่งนั้น?” และปรับเปลี่ยนตามเหตุผล

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

เชื่อใจ แต่ตรวจสอบ (และควบคุม)

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

นั่นหมายความว่าเราต้องย้ายจุดควบคุม หากไม่สามารถตรวจทุกอย่างในขั้นพัฒนาได้ เราต้องมีการควบคุมที่เข้มแข็งกว่าในขณะรัน ผู้ปฏิบัติการ วิศวกร SRE ทีมแพลตฟอร์ม หรือผู้ที่รับผิดชอบระบบผลิต ต้องมองเห็นสิ่งที่กำลังทำงานได้ดีขึ้น ติดตามการพึ่งพาได้ครบถ้วน และรู้ที่มาของอาร์ติแฟกต์ทุกชิ้นอย่างชัดเจน

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

สิ่งที่จะเกิดขึ้นต่อไป

เราอยู่ที่จุดเปลี่ยน ทีมที่มีแนวปฏิบัติที่ดีอยู่แล้วกำลังเห็นผลิตภาพเพิ่มขึ้นอย่างมหาศาลจาก AI ส่วนทีมที่เคยมีปัญหาก็กำลังมีปัญหาเร็วขึ้น

โครงสร้างพื้นฐานที่รองรับการพัฒนาด้วย AI ต้องสร้างขึ้นเพื่อความสามารถในการทำซ้ำตั้งแต่ต้น ไม่ใช่ติดเครื่องมือสแกนและการตรวจสอบเพิ่มภายหลัง แต่ต้องฝังอยู่ในวิธีทำงานของนักพัฒนาตั้งแต่วันแรก เมื่อสภาพแวดล้อมพัฒนาเหมือนกันทั้งบน Mac และ Linux การพึ่งพาทุกตัวถูกติดตามและล็อกไว้ และอาร์ติแฟกต์ทุกชิ้นมีที่มาครบถ้วน เอเจนต์ AI จะกลายเป็นตัวทวีคูณกำลัง แทนที่จะเป็นตัวสร้างความโกลาหล

คำแนะนำสำคัญที่สุดของผมสำหรับทีมที่ต้องการประสบความสำเร็จในยุค AI คือ:

• กำหนดมาตรฐานอย่างจริงจัง ตัวแปรที่น้อยลงสัมพันธ์กับประสิทธิภาพที่สูงขึ้น กำหนดเทคโนโลยีหลักให้ชัด บังคับใช้สภาพแวดล้อมที่สอดคล้องกันในทุกแพลตฟอร์ม และขจัดการเบี่ยงเบนของการกำหนดค่าก่อนที่ AI จะขยายปัญหา หากเวอร์ชัน Python ไม่ตรงกันสร้างปัญหาในวันนี้ ปัญหาจะรุนแรงขึ้นสิบเท่าเมื่อ AI สร้างโค้ดในวงกว้าง

• ฝังการตรวจสอบไว้ในเวิร์กโฟลว์ ไม่ใช่ไว้ท้ายกระบวนการ เมื่อ AI สร้างโค้ดเร็วกว่าที่มนุษย์จะตรวจได้ คุณไม่อาจพึ่งการตรวจโค้ดด้วยคนเพียงอย่างเดียว ใช้การทดสอบอัตโนมัติที่ตรวจทั้งว่าโค้ดทำงานและแก้ความต้องการจริง ทำให้สายงาน CI/CD เป็นตาข่ายนิรภัย พร้อมด่านควบคุมที่เข้มแข็งก่อนนำขึ้นระบบผลิต

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

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