OpenAI Codex ได้เขียนเกม DOS แนว Asteroids ที่ใช้ภาษา Assembly x86 แบบ 16 บิตขึ้นมาจนสมบูรณ์ โดยประกอบด้วยไฟล์ซอร์สโค้ด 18 ไฟล์ และโค้ดประมาณ 2,500 บรรทัด โดยไม่มีภาษา Assembly ที่เขียนโดยมนุษย์เลยแม้แต่บรรทัดเดียว การทดลองนี้แสดงให้เห็นว่า AI สามารถควบคุมวงจรชีวิตซอฟต์แวร์ (software lifecycle) ได้ทั้งระบบ ตั้งแต่การวางแผนไปจนถึงการดีบั๊ก โดยไม่ต้องมีการแทรกแซงจากโปรแกรมเมอร์โดยตรง ซึ่งถือเป็นก้าวที่เหนือกว่าการสาธิต "การเติมโค้ด" (code-completion) ทั่วไป

ทำไมการทดสอบนี้ถึงสำคัญ

การสาธิตการเขียนโค้ดด้วย AI ส่วนใหญ่ที่เผยแพร่ต่อสาธารณะมักจะหยุดอยู่แค่โค้ดสั้นๆ หรือยูทิลิตี้ (utility) ง่ายๆ เพื่อทดสอบขีดจำกัดสูงสุด การทดลองนี้จึงบังคับให้ Codex ทำงานในสภาพแวดล้อมที่มีข้อจำกัดมากที่สุดเท่าที่จะจินตนาการได้ นั่นคือภาษา Assembly x86 แบบ 16 บิตบน DOS โดยไม่มีเอนจินเกม (game engines), ไลบรารีกราฟิก (graphics libraries) หรือความสะดวกสบายจากภาษาระดับสูง (high-level language) เป้าหมายคือเพื่อดูว่า AI ไม่เพียงแต่จะสามารถสร้างโค้ดได้เท่านั้น แต่ยังสามารถจัดการงานด้านวิศวกรรมที่เกี่ยวข้องทั้งหมดได้ด้วยหรือไม่

การแบ่งบทบาทหน้าที่

ความรับผิดชอบของมนุษย์ ถูกจำกัดไว้เพียงสามอย่าง:

  • กำหนดเป้าหมายโดยรวมของโปรเจกต์ (เกมยิงแนว Asteroids)
  • ตอบคำถามที่เกี่ยวข้องกับเกมเพลย์ (gameplay) ที่เกิดขึ้น
  • ทดสอบการเล่น (play-test) ในแต่ละเวอร์ชันและรายงานบั๊กที่พบ

ความรับผิดชอบของ Codex ครอบคลุมส่วนที่เหลือทั้งหมด:

  • ร่างแผนงานและสถาปัตยกรรมของโปรเจกต์
  • เขียนไฟล์ซอร์สโค้ด Assembly
  • ดีบั๊ก (debug), รีแฟกเตอร์ (refactor) และปรับโครงสร้างโค้ด
  • ดูแล Git repository รวมถึงการทำ commit และการจัดการ branch
  • คอมไพล์ไฟล์ไบนารี (binary) และรันใน DOS emulator

มนุษย์ไม่เคยพิมพ์คำสั่ง Assembly แม้แต่คำสั่งเดียว ไม่เคยเรียกใช้คอมไพเลอร์ (compiler) และไม่เคยเปิดเกมระหว่างการพัฒนา การโต้ตอบสิ้นสุดลงเพียงแค่การอธิบายอาการของบั๊ก โดย AI จะเป็นผู้ระบุตำแหน่งและแก้ไขสาเหตุที่แท้จริงด้วยตัวเอง

เวิร์กโฟลว์แบบทำซ้ำ (Iterative workflow)

แต่ละรอบเริ่มต้นด้วยการที่ Codex เสนอเป้าหมายสำคัญ (milestone) (เช่น "implement player ship movement") จากนั้นจะสร้างไฟล์ซอร์สโค้ดที่เกี่ยวข้อง ทำการ commit, สร้างไฟล์ executable และส่งไฟล์ที่รันได้ให้แก่ผู้ทดสอบ Codex จะวิเคราะห์อาการ, ไล่ตรวจสอบผ่านฐานโค้ด (code base) และออกแพตช์ (patch) โดยไม่ต้องมีการชี้แนะเพิ่มเติมจากมนุษย์

สิ่งที่ผลิตภัณฑ์สุดท้ายประกอบด้วย

  • ไฟล์ซอร์สโค้ด Assembly 18 ไฟล์ จัดระเบียบตามโครงสร้าง repository มาตรฐาน
  • โค้ด Assembly ประมาณ 2,500 บรรทัด ครอบคลุมการจัดการอินพุต (input handling), การวาดสไปรต์ (sprite drawing), การตรวจจับการชน (collision detection) และระบบคะแนนสูงสุด (high-score system)
  • ไฟล์ executable สำหรับ DOS ที่สามารถเล่นได้ ซึ่งรันในสภาพแวดล้อม DOS มาตรฐานและเลียนแบบเกมเพลย์แบบ Asteroids คลาสสิก
  • ไม่มีภาษา Assembly ที่เขียนโดยมนุษย์เลย ซึ่งเป็นการยืนยันว่า AI จัดการงานโปรแกรมมิ่งระดับต่ำ (low-level programming) ทั้งหมดด้วยตัวเอง

ความสำคัญและผลกระทบ

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

การทดลองนี้ยังชี้ให้เห็นถึงข้อจำกัดด้วย สภาพแวดล้อมในการทดสอบถูกกำหนดให้แคบอย่างตั้งใจ นั่นคือเป็นเกม DOS แบบผู้เล่นคนเดียวที่มีกลไกเกมที่เข้าใจกันดีอยู่แล้ว การขยายแนวทางนี้ไปสู่ระบบขนาดใหญ่ที่มีหลายโมดูล (multi-module systems) ซึ่งมีทั้งการพึ่งพาภายนอก (external dependencies), ข้อจำกัดด้านความปลอดภัย หรือเส้นทางการทำงานของโค้ดที่เน้นประสิทธิภาพสูง (performance-critical code paths) ยังคงเป็นเรื่องที่ต้องพิสูจน์ต่อไป นอกจากนี้ ผู้ทดสอบที่เป็นมนุษย์ยังคงทำหน้าที่เป็นด่านตรวจคุณภาพขั้นสุดท้าย หากมีข้อผิดพลาดทางตรรกะ (logic error) ที่ตรวจไม่พบ ก็อาจหลุดรอดไปได้หากไม่มีการตรวจสอบดังกล่าว

ข้อโต้แย้งและคำถามที่ยังไม่มีคำตอบ

  • ความน่าเชื่อถือ (Reliability): การเขียนโปรแกรมด้วยภาษา Assembly นั้นไม่มีที่ว่างให้ความผิดพลาด แม้แต่ข้อผิดพลาดแบบ off-by-one เพียงจุดเดียวก็อาจทำให้โปรแกรมทั้งหมดพังได้ Codex แก้ไขบั๊กที่มันเห็น แต่ก็อาจพลาดปัญหาเรื่องจังหวะเวลา (timing issues) ที่ละเอียดอ่อนซึ่งจะปรากฏขึ้นเฉพาะตอนทดสอบภายใต้สภาวะกดดัน (stress testing) เท่านั้น
  • ความสามารถในการบำรุงรักษา (Maintainability): โค้ดที่สร้างขึ้นโดยไม่มีแนวทางสไตล์ (style guidelines) ของมนุษย์อาจทำให้นักพัฒนาในอนาคตอ่านหรือขยายต่อได้ยาก โดยเฉพาะอย่างยิ่งหากรูปแบบการตั้งชื่อ (naming conventions) ของ AI แตกต่างจากมาตรฐานของทีม
  • ทรัพย์สินทางปัญญา (Intellectual property): ใครเป็นเจ้าของโค้ดเมื่อ AI เป็นคนเขียน? กรอบการอนุญาตใช้งาน (licensing frameworks) ในปัจจุบันตั้งอยู่บนสมมติฐานว่ามนุษย์เป็นผู้สร้างสรรค์ ทำให้เกิดพื้นที่สีเทาสำหรับผลงานที่สร้างโดย AI

สิ่งที่ต้องจับตามองต่อไป

  • การทดสอบมาตรฐานที่กว้างขึ้น (Broader benchmarks): การนำเวิร์กโฟลว์แบบอัตโนมัติเดียวกันนี้ไปใช้กับแอปพลิเคชันเครือข่าย (networked applications), แอปมือถือ หรือโปรเจกต์ C/C++ สมัยใหม่ จะเป็นการทดสอบว่าแนวทางนี้สามารถขยายขอบเขตไปไกลกว่าเกมแนวเรโทรได้หรือไม่
  • การรวมเครื่องมือ (Tool integration): การฝัง Codex ลงใน CI/CD pipelines อาจช่วยให้การทำงานอัตโนมัติไม่ได้หยุดอยู่แค่การสร้างโค้ด แต่รวมถึงการทดสอบ, การสแกนความปลอดภัย และการติดตั้งใช้งาน (deployment) ด้วย
  • วิวัฒนาการของนโยบาย (Policy evolution): เมื่อโค้ดที่สร้างโดย AI แพร่หลายมากขึ้น นโยบายทางกฎหมายและนโยบายขององค์กรจะต้องจัดการเรื่องความเป็นเจ้าของ, ความรับผิดชอบ (liability) และการปฏิบัติตามข้อกำหนด (compliance)

บทสรุปนั้นชัดเจน: AI สามารถทำหน้าที่เป็นวิศวกรซอฟต์แวร์เพียงลำพังสำหรับโปรเจกต์ที่มีขอบเขตและคำจำกัดความที่ชัดเจน โดยสามารถส่งมอบโค้ดระดับ low-level ที่ใช้งานได้จริงโดยไม่ต้องอาศัยการเขียนโค้ดด้วยมือโดยมนุษย์ การที่ความสามารถนี้จะเข้ามาเปลี่ยนโฉมการพัฒนาซอฟต์แวร์กระแสหลักหรือไม่นั้น ขึ้นอยู่กับว่าระบบนิเวศจะสามารถจัดการกับประเด็นด้านความน่าเชื่อถือ ความสามารถในการบำรุงรักษา และข้อกังวลทางกฎหมายได้รวดเร็วเพียงใด