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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

สิ่งนี้หมายถึงการเปลี่ยนจุดควบคุม หากเราไม่สามารถควบคุมทุกอย่างที่เวลาในการพัฒนา เราต้องการการควบคุมที่เข้มงวดกว