กระบวนการเขียนโค้ดใหม่เกิดขึ้นได้อย่างไร

Anthropic ซื้อ Bun ในเดือนธันวาคม 2025 และตั้งเป้าที่จะเปลี่ยนฐานโค้ด (codebase) จาก Zig เป็น Rust บริษัทได้รัน Claude Fable 5 เวอร์ชันก่อนเปิดตัว ซึ่งเป็น LLM ที่ยังไม่มีใครสามารถเข้าถึงได้ในขณะนั้น โมเดลจำนวน 64 ชุดทำงานขนานกัน โดยผลิตโค้ดออกมาได้รวมประมาณ 1,300 บรรทัดต่อนาที

Jarred Sumner หัวหน้าวิศวกร ไม่ได้โยนปัญหาให้เอเจนต์ (agents) แล้วเดินจากไปเสียทีเดียว ขั้นแรกเขาใช้เวลาหลายชั่วโมงในการร่างคู่มือที่จับคู่รูปแบบภาษา (idioms) ของ Zig กับสิ่งที่เทียบเท่าใน Rust การทดลองรันด้วยไฟล์ 3 ไฟล์ช่วยให้เขาปรับจูนผลลัพธ์ของเอเจนต์ได้ก่อนที่จะเริ่มจัดการกับ repository ทั้งหมด สำหรับทุกการเปลี่ยนแปลงที่เอเจนต์เสนอ จะมีเอเจนต์ "ฝ่ายตรงข้าม" (adversarial agents) สองตัวคอยตรวจสอบ และ Sumner ก็เฝ้าดูกระบวนการทั้งหมดแบบสดๆ ตลอดระยะเวลา 11 วัน

บัญชีภายในของ Anthropic บันทึกค่าใช้จ่ายในการใช้ token ไว้ที่ 165,000 ดอลลาร์ ตัวเลขนี้สะท้อนถึงเพียงการเรียกใช้ API ดิบๆ ก่อนที่โค้ดจะถูกรวม (merge) เข้ากับ branch หลักเท่านั้น

ค่าใช้จ่ายที่ซ่อนอยู่

ตัวเลข 165,000 ดอลลาร์นี้ยังไม่รวมค่าประมวลผล (compute) ที่จำเป็นในการทำให้โค้ด Rust ใหม่มีความเสถียร จากการวิเคราะห์ภายในพบว่า การแก้ไขหลังการ merge, การรัน continuous-integration และการทดสอบเพิ่มเติม อาจทำให้ยอดใช้จ่ายรวมสูงขึ้นกว่านี้ การประมาณการนี้ใช้ราคา API สาธารณะ เนื่องจาก Claude Fable 5 เป็นเวอร์ชันทดลองใช้ส่วนตัว ราคาที่จ่ายจริงอาจแตกต่างออกไป

ความเร็วเทียบกับความปลอดภัย

การเขียนโค้ดใหม่นี้ทำให้ได้ Rust runtime ที่ทำงานได้เร็วกว่าเวอร์ชัน Zig เดิม แต่ก็ทิ้งภาระงานตรวจสอบ (audit backlog) จำนวนมากไว้ด้วย ประมาณ 4% ของไฟล์ Rust ที่สร้างขึ้นใหม่มีบล็อก “unsafe” ซึ่งเป็นโค้ดที่ข้ามผ่านการรับประกันความปลอดภัยที่เข้มงวดของ Rust โดยปกติแล้วโปรเจกต์ Rust ที่เขียนด้วยมือจะมีเปอร์เซ็นต์ที่ต่ำกว่านี้มาก ซึ่งหมายความว่าผู้ตรวจสอบจะต้องตรวจสอบว่าบล็อกเหล่านั้นไม่ทำให้เกิดบั๊กการคอร์รัปชันของหน่วยความจำ (memory-corruption bugs)

ผลลัพธ์จากเอเจนต์จะไม่มีความหมายเลยหากขาดความเชี่ยวชาญของ Sumner แม้จะผลิตโค้ดได้ถึง 1,300 บรรทัดต่อนาที แต่โค้ดก็ยังต้องการผู้ดูแลที่มีความรู้เพื่อตรวจจับข้อผิดพลาดทางตรรกะ (logical errors) ตรวจสอบความสอดคล้องทางสถาปัตยกรรม (architectural coherence) และยืนยันว่าชุดการทดสอบ (test suite) ครอบคลุมการทำงานใหม่ทั้งหมดจริงๆ

เมื่อไหร่ที่ AI ทำงานได้ดี และเมื่อไหร่ที่ไม่ใช่

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

ผู้สนับสนุนการพัฒนาที่เสริมด้วย AI ชี้ให้เห็นถึงตัวเลขผลิตภาพดิบๆ เช่น การสร้างโค้ดหลายพันบรรทัดในไม่กี่นาที เพื่อเป็นหลักฐานว่าโมเดลภาษาขนาดใหญ่สามารถแทนที่ทีมงานขนาดใหญ่ได้ แต่กรณีของ Anthropic ช่วยเตือนสติมุมมองนั้น เพราะค่า token ที่เห็นในพาดหัวข่าวไม่ได้รวมค่าประมวลผลจำนวนมหาศาลที่จำเป็นสำหรับการตรวจสอบหลังการ merge และหนี้ด้านความปลอดภัย (safety debt) ที่เกิดจากโค้ด “unsafe” ก็ยังต้องใช้ความพยายามของมนุษย์ในการแก้ไข

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

Anthropic ยังไม่ได้เปิดเผยว่ามีแผนที่จะใช้เวิร์กโฟลว์ที่ขับเคลื่อนด้วย Claude แบบเดียวกันนี้กับฐานโค้ดอื่นๆ หรือไม่ หากทำเช่นนั้น บริษัทจะต้องคำนึงถึงต้นทุนตลอดวงจรชีวิต (total lifecycle cost) ไม่ใช่แค่ค่า token เท่านั้น สิ่งที่ผู้สังเกตการณ์ควรจับตามองคือ:

  • ความรวดเร็วในการลดภาระงานตรวจสอบ และสัดส่วนของ “unsafe” จะลดลงหรือไม่เมื่อผู้ตรวจสอบทำการปรับปรุงโค้ด (refactor)
  • การรันในอนาคตจะใช้โมเดลที่มีความสมบูรณ์มากขึ้นซึ่งสามารถซื้อได้ทั่วไปหรือไม่ ซึ่งอาจทำให้การประมาณการต้นทุนมีความโปร่งใสมากขึ้น
  • ผลกระทบต่อการใช้งาน Bun: runtime ที่เร็วขึ้นอาจดึงดูดผู้ใช้ แต่ความกังวลด้านความปลอดภัยใดๆ อาจหักล้างประโยชน์นั้นได้

บทสรุป

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