สร้างคอมไพเลอร์ C ด้วยทีม Claude แบบขนาน

 (anthropic.com)
8 คะแนน โดย GN⁺ 2026-02-06 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • เอเจนต์ Claude 16 ตัว ร่วมมือกันแบบขนานจนสร้าง คอมไพเลอร์ C บนพื้นฐาน Rust สำเร็จ จนถึงระดับที่สามารถบิลด์เคอร์เนล Linux 6.9 ได้
  • ใช้ไปประมาณ 2,000 เซสชันและมีค่าใช้จ่าย 20,000 ดอลลาร์ เพื่อสร้างโค้ดขนาดราว 100,000 บรรทัด รองรับสถาปัตยกรรม x86·ARM·RISC-V
  • เอเจนต์ทำงานต่อเนื่องโดยแทบไม่ต้องมีมนุษย์แทรกแซงผ่าน ฮาร์เนสลูปอัตโนมัติ พร้อมเพิ่มประสิทธิภาพด้วยโครงสร้าง การทดสอบ·การทำงานขนาน·การแบ่งบทบาท
  • ผลลัพธ์แสดง ความเข้ากันได้กับ GCC และมีอัตราผ่านการทดสอบสูง แต่ส่วนอย่าง การสร้างโค้ด 16-bit x86·ลิงเกอร์·คุณภาพการปรับแต่งประสิทธิภาพ ยังไม่สมบูรณ์
  • การทดลองนี้เป็นกรณีศึกษาที่ตรวจสอบทั้ง ข้อจำกัดและศักยภาพของทีม LLM แบบอัตโนมัติ และทำให้ ความปลอดภัยกับการควบคุมคุณภาพในสภาพแวดล้อมการพัฒนาอัตโนมัติเต็มรูปแบบ กลายเป็นโจทย์สำคัญในอนาคต

ภาพรวมโครงการคอมไพเลอร์ C ที่ขับเคลื่อนด้วยทีมเอเจนต์

  • การทดลองที่ให้ Claude หลายอินสแตนซ์ร่วมมือกันแบบขนาน เพื่อพัฒนาโค้ดเบสเดียวกัน
    • ทำซ้ำวงจร เขียนโค้ด·ทดสอบ·แก้ไข ได้อย่างอัตโนมัติโดยแทบไม่มีการแทรกแซงแบบเรียลไทม์จากมนุษย์
  • เป้าหมายคือสร้าง คอมไพเลอร์ C ที่เขียนด้วย Rust ให้เสร็จสมบูรณ์และสามารถ บิลด์เคอร์เนล Linux ได้โดยตรง
  • ใช้ เอเจนต์ทั้งหมด 16 ตัว, ประมาณ 2,000 เซสชัน, และ โทเค็นขาเข้า 200 ล้าน·โทเค็นขาออก 140 ล้าน
  • ผลลัพธ์คือ คอมไพเลอร์ขนาด 100,000 บรรทัด, สามารถบิลด์ เคอร์เนล Linux 6.9 และโปรเจกต์โอเพนซอร์สหลัก (QEMU, FFmpeg, SQLite, Redis เป็นต้น) ได้

การออกแบบ Claude harness สำหรับการรันระยะยาว

  • เดิมที Claude Code ต้องอาศัยอินพุตจากมนุษย์ แต่สามารถทำงานแบบอัตโนมัติได้ด้วย harness สำหรับรันอัตโนมัติที่มีโครงสร้างลูปไม่สิ้นสุด
    • หลังจบงานแต่ละชิ้นจะเริ่มงานถัดไปทันทีด้วย โครงสร้างวนซ้ำอัตโนมัติ
    • ระหว่างทำงานเคยมีกรณีที่ Claude เผลอรัน pkill -9 bash จนปิดตัวเองไปด้วย
  • โครงสร้างการทำงานแบบขนาน อาศัย Docker container และการซิงก์ Git
    • เอเจนต์แต่ละตัวทำงานใน /workspace แล้ว push ไปยัง /upstream
    • ใช้ lock แบบอิงไฟล์ข้อความ เพื่อป้องกันการชนกันของงาน
    • หากเกิด merge conflict Claude จะเป็นผู้แก้ไขเอง

รูปแบบการทำงานของ Claude แบบขนาน

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

บทเรียนที่ได้จากการเขียนโปรแกรมด้วยทีม Claude

ความสำคัญของการทดสอบคุณภาพสูง

  • Claude ทำงานอัตโนมัติโดยอิงจากการทดสอบที่มีให้ ดังนั้น ความแม่นยำของตัวตรวจสอบ จึงเป็นหัวใจสำคัญ
    • หากมี false positive การพัฒนาก็อาจเดินไปในทิศทางที่ผิด
  • จัดทำไปป์ไลน์ continuous integration (CI) เพื่อ บังคับตรวจสอบว่าฟังก์ชันเดิมไม่พัง
  • ใช้สคริปต์บิลด์โอเพนซอร์สและ compiler test suite เพื่อรักษาคุณภาพ

การออกแบบสภาพแวดล้อมจากมุมมองของ Claude

  • เอเจนต์แต่ละตัวเริ่มจาก container ใหม่ที่ไม่มีคอนเท็กซ์ จึงจำเป็นต้อง จัดทำเอกสารความคืบหน้า
    • มีคำสั่งให้คอยอัปเดต README และไฟล์ความคืบหน้าอย่างต่อเนื่อง
  • ป้องกันการปนเปื้อนของบริบท: ลด log ให้เหลือน้อยที่สุด และบันทึกข้อผิดพลาดให้ค้นหาได้ด้วยคีย์เวิร์ด ERROR
  • เพื่อชดเชย การขาดการรับรู้เรื่องเวลา จึงใช้ตัวเลือก --fast เพื่อรัน การทดสอบแบบสุ่มตัวอย่าง 1~10%

ข้อจำกัดของการทำงานขนานและวิธีแก้

  • เมื่อมีการทดสอบอิสระจำนวนมาก การทำงานขนานทำได้ง่าย แต่ การบิลด์เคอร์เนล Linux เป็นงานเดี่ยวขนาดใหญ่จึงเกิดการชนกันได้
  • แนวทางแก้คือใช้ GCC เป็น compiler oracle อ้างอิง
    • บางไฟล์บิลด์ด้วย GCC และที่เหลือบิลด์ด้วยคอมไพเลอร์ของ Claude
    • เมื่อเกิดความล้มเหลวจะค่อย ๆ แคบขอบเขตไปยังไฟล์ที่มีปัญหาเพื่อดีบักแบบขนานได้
    • จากนั้นใช้ delta debugging เพื่อตรวจหาข้อผิดพลาดที่พึ่งพากันข้ามส่วน

การแยกบทบาทของเอเจนต์

  • แบ่งหน้าที่แบบเฉพาะทาง เช่น การลบโค้ดซ้ำ การปรับปรุงประสิทธิภาพ การสร้างโค้ดอย่างมีประสิทธิภาพ การปรับโครงสร้าง Rust และการจัดทำเอกสาร
  • การผสาน ความขนานกับความเชี่ยวชาญเฉพาะด้าน ช่วยเพิ่มประสิทธิภาพในการดูแลโค้ดเบสขนาดใหญ่

การประเมินประสิทธิภาพของโมเดล Opus 4.6

  • จนถึง Opus 4.5 ยังไม่สามารถบิลด์โปรเจกต์ขนาดใหญ่ได้ แต่ Opus 4.6 เป็นเวอร์ชันแรกที่ไปถึงระดับใช้งานจริง
  • เป็น การพัฒนาแบบ clean room โดยไม่มีการเข้าถึงอินเทอร์เน็ตและใช้เพียง Rust standard library
  • ผ่าน GCC torture test suite ได้ 99% และ สามารถรัน Doom ได้
  • ข้อจำกัด:
    • ยังสร้างโค้ด 16-bit x86 ไม่ได้ จึงยังต้องเรียก GCC ในช่วงบูต
    • assembler·linker ยังไม่สมบูรณ์ และยังมีบั๊กบางส่วน
    • ประสิทธิภาพของโค้ดที่สร้างยังต่ำ ไม่มีประสิทธิภาพยิ่งกว่าระดับที่ปิดการปรับแต่งของ GCC
    • คุณภาพโค้ด Rust อยู่ในระดับใช้ได้ แต่ยังไม่ถึงระดับผู้เชี่ยวชาญ

ข้อจำกัดและศักยภาพของทีมเอเจนต์อัตโนมัติ

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

แนวโน้มในอนาคต

  • พัฒนาการของโมเดลภาษาได้ก้าวจาก IDE autocomplete → เติมเต็มฟังก์ชัน → pair programming → ดำเนินโครงการแบบอัตโนมัติ
  • Agent teams แสดงให้เห็นถึงความเป็นไปได้ของการพัฒนาอัตโนมัติเต็มรูปแบบ
  • ท่ามกลางความเร็วของความก้าวหน้าทางเทคโนโลยี มีทั้งความทึ่งและการเน้นย้ำถึง ความจำเป็นของกรอบจริยธรรมและความปลอดภัยรูปแบบใหม่
  • แม้คาดหวังว่าการใช้งานเชิงบวกจะชดเชยความเสี่ยงด้านลบได้ แต่ก็ยัง จำเป็นต้องเตรียมพร้อมต่อกระบวนทัศน์การพัฒนาแบบใหม่

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
mammal 2026-02-06

เพราะเป็นโปรเจกต์ที่สร้างขึ้นด้วย Rust standard library ล้วน ๆ ไม่ใช่คอมไพเลอร์ที่เขียนด้วย C ผมเลยรู้สึกว่าคำวิจารณ์ที่บอกว่ามีโค้ด C ของ gcc/clang อยู่ในข้อมูลฝึกนั้นค่อนข้างเหมือนการย้ายเสาประตูไปหน่อย อย่างไรก็ตาม น่าทึ่งมากครับ
 
GN⁺ 2026-02-06
ความคิดเห็นจาก Hacker News

  • ฉันทำงานด้าน การ build Linux kernel ด้วย Clang ที่ Google มาเกือบ 10 ปี โปรเจกต์นี้(clangbuiltlinux.github.io)บอกว่า LLM ทำงานแบบเดียวกันได้ด้วย 2,000 เซสชันและค่า API 20,000 ดอลลาร์ แถมบูตได้จริงด้วยก็น่าทึ่งอยู่ แต่ ประสิทธิภาพ ของโค้ดที่สร้างออกมายังต่ำ และไม่มีประสิทธิภาพยิ่งกว่าตอนปิด optimization ของ GCC เสียอีก ถึงอย่างนั้นก็ยังเป็นโปรเจกต์ที่เจ๋งมาก

    • มันเจ๋งก็จริง แต่ก็อาจเป็นผลลัพธ์แบบ ลอกการบ้านคนอื่น มาก็ได้
    • เขาว่า Opus ทำ code generator สำหรับ x86 แบบ 16 บิตไม่ได้ เลยใช้ ทางลัด โดยไปเรียก GCC ตอนขั้นบูต ทำให้สงสัยว่าเรียกว่าบูตได้จริงไหม
    • นี่ให้ความรู้สึกเหมือนยุคของ “Trusting Trust” ของ Ken Thompson กำลังกลับมา AI อาจจะฝังตัวเองลงไปในคอมไพเลอร์ได้ในไม่ช้า
    • ถ้าใช้เงินไป 20,000 ดอลลาร์ เงินจำนวนนั้นก็อาจจ้าง นักพัฒนา senior 8 คน ได้ช่วงสั้น ๆ เหมือนกัน ดูเหมือนจะมีต้นทุนด้านการตลาดสูงเกินไป และโมเดลรายได้จริงก็ยังไม่ชัดเจน

  • นี่เป็นแนวทางที่ใช้งานได้จริงกว่าโปรเจกต์เบราว์เซอร์ของ Cursor มาก เขาบอกว่าเป็น การพัฒนาแบบ clean-room โดยไม่เข้าถึงอินเทอร์เน็ตและใช้แค่ Rust standard library คอมไพเลอร์ขนาด 100,000 บรรทัดสามารถ build ได้ทั้ง Linux 6.9, QEMU, FFmpeg, SQLite, Postgres และ Redis
    Opus 4.5 เพิ่งเป็นครั้งแรกที่ผ่านการทดสอบขนาดใหญ่ได้ และผลลัพธ์ครั้งนี้ก็ดูเหมือนจะใช้ขีดจำกัดนั้นไปเกือบหมดแล้ว
    แม้จะมีข้อจำกัดหลายอย่าง แต่ก็คิดว่าเป็น การทดลองที่น่าประทับใจ

    • คำว่า “การพัฒนาแบบ clean-room” ดูจะพูดเกินไปหน่อย เพราะตัวโมเดลก็เรียนรู้จากคอมไพเลอร์ภาษา C ทั่วทั้งอินเทอร์เน็ตมาแล้ว จึงไม่จำเป็นต้องใช้คำนั้นเลย
    • ถ้าจะประเมินผลแบบนี้จากระดับปัจจุบันอย่างเดียวก็น่าเสียดาย เมื่อดู ความเร็วของพัฒนาการในช่วงไม่กี่เดือนที่ผ่านมา อีก 1 ปีข้างหน้าอาจไปไกลเกินคาดมาก
    • ถ้าพูดให้ตรงกว่านี้ มันไม่ใช่ clean-room เท่าไร แต่ใกล้เคียงกับผลลัพธ์ที่ LLM คลี่ความรู้ที่ถูกบีบอัดระหว่างการฝึกออกมาผ่านการทดสอบ มากกว่า
    • ยังไงโมเดลก็น่าจะถูกฝึกจากโค้ดของ GCC หรือ Clang อยู่ดี เลยสงสัยว่าความคล้ายกับโค้ดจริงมีมากแค่ไหน
    • ส่วนตัวมองว่าน่าทึ่งก็จริง แต่สำหรับ ผู้ใช้จริง แล้วกลับน่าสนใจน้อยกว่า การเพิ่ม ISA ใหม่เข้า LLVM หรือสร้างคอมไพเลอร์สำหรับภาษาใหม่ดูมีความหมายกว่า

  • ตอนแรกฉันคิดว่า “ว้าว สุดยอด” แต่ไม่นานก็เปลี่ยนใจ เพราะคอมไพเลอร์ภาษา C เป็น ซอฟต์แวร์ที่มีสเปกเข้มงวดมาก จึงเป็นงานที่ LLM จัดการได้ค่อนข้างง่าย
    แต่สิ่งที่เราทำกันส่วนใหญ่กลับอยู่ในสภาพแวดล้อมที่ความต้องการคลุมเครือ และเป้าหมายก็เปลี่ยนตลอด เลยสงสัยว่ามันจะทำงานได้ดีในพื้นที่แบบนั้นไหม

    • พอเห็นคนพูดว่า “คอมไพเลอร์ C ชัดเจน” แล้วก็อดขำไม่ได้ มี “unspecified behavior” ตั้งเยอะแยะ
    • การสร้างโค้ดให้ตรงกับชุดทดสอบก็คล้ายกับ การฟิตโมเดล ML มนุษย์ก็ยังต้องเป็นคนออกแบบและตรวจสอบการทดสอบอยู่ดี

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

    • ฉันก็คิดเหมือนกัน ไม่ใช่ว่า “หมาเต้นเก่งแค่ไหน” แต่เป็นการที่มัน เต้นได้ ต่างหากที่น่าทึ่ง
    • ช่วงนี้กระแสต้าน generative AI แรงมาก จน มีข้อบกพร่องนิดเดียวก็ถูกเหมารวมว่าเป็น ‘ขยะ AI’ ซึ่งน่าเสียดาย เพราะนี่ก็เป็นแค่เดโมและการพิสูจน์แนวคิดเท่านั้น

  • โปรเจกต์นี้บอกว่าสามารถ build ได้ทั้ง Linux kernel, QEMU, FFmpeg, Redis ไปจนถึง Doom น่าทึ่งจริง ๆ
    แต่ ระบบเอเจนต์ แบบนี้ทำงานได้ดีในโดเมนที่ทดสอบได้ ทว่าในงานอย่างการตัดสินใจทางธุรกิจที่ต้องอาศัยบริบทกลับยังมีข้อจำกัด

    • ก็ยังสงสัยอยู่ดีว่าคำว่า “clean-room implementation” จะมีความหมายไหมกับโมเดลที่ถูกฝึกจากทั้งอินเทอร์เน็ตอยู่แล้ว
    • ขั้นต่อไปคือให้ AI เข้าใจและดำเนินงานในบริบทธุรกิจจริง ตัวอย่างเช่นถ้าดูเบนช์มาร์กอย่าง Vending-Bench วันที่ AI product manager ทำทั้งสัมภาษณ์ผู้ใช้ การทดลอง และเสนอ roadmap แบบอัตโนมัติ อาจอยู่ไม่ไกลแล้ว

  • เป็นโปรเจกต์ที่เจ๋ง แต่ไม่น่าพูดถึงคำว่า “clean-room” เลย เพราะเป็น โมเดลที่ฝึกจากโค้ดที่มีลิขสิทธิ์ จึงแทบจะตรงกันข้ามมากกว่า

    • แต่มนุษย์เองก็เรียนรู้จากโค้ดเบสที่มีอยู่ก่อน แล้วค่อยเอาความรู้นั้นไปทำ clean-room implementation ได้เหมือนกัน
    • เหมือนกับที่มนุษย์เอาความรู้ที่เรียนมาจากบริษัทหนึ่งไปใช้ซ้ำที่อื่น LLM ก็แค่ นำข้อมูลที่เรียนมาไปประกอบใหม่ในเชิงแปลงรูป ถ้าไม่ได้คัดลอกตรง ๆ ปัญหาก็ถือว่าเป็นอีกแบบหนึ่ง

  • ตาม GitHub issue ปัญหาเกิดจาก include path ที่หายไป ตัวคอมไพเลอร์เองปกติดี

    • ดูเหมือนแค่ขาดแพ็กเกจอย่าง glibc-devel
    • ตัวบทความยาวเกินไปและหลักฐานไม่แน่นพอ รู้สึกเหมือนพลาดประเด็นสำคัญไป
    • AI คืออนาคต
    • เป็นผลลัพธ์ที่น่าทึ่งจริง ๆ

  • ฉันอยากให้เปิดเผย พรอมป์ทั้งหมดและโครงสร้างของเอเจนต์ ออกมาด้วย มันจะเป็นประโยชน์ต่อการเรียนรู้มาก แต่ถ้าจะให้จ่าย 20,000 ดอลลาร์เพื่อทำซ้ำเองก็หนักเกินไป

    • ช่วงนี้น่าเสียดายที่คนมักดูแค่ผลลัพธ์ และ ไม่ค่อยสนใจว่ากระบวนการเป็นอย่างไร

  • นี่เหมือนเวอร์ชันที่ใช้งานได้จริงของบล็อก Cursor หลักฐานว่า มัน build Linux kernel ได้จริง น่าเชื่อถือกว่ามาก

    • เดิมทีตั้งใจจะทำภาษาเบา ๆ สำหรับ April Fools แต่ตอนนี้กลับได้ผลลัพธ์ระดับนี้ออกมา ก็น่าทึ่งดี ถึงอย่างนั้นก็ยังคิดว่าจะลองต่อไป

  • นี่เป็นแนวทางแบบ “สร้างพีระมิดได้ แต่สร้างมหาวิหารไม่ได้” (บทความที่เกี่ยวข้อง)
    เท่ากับว่าอัดทรัพยากรคอมพิวต์มหาศาลเข้าไปเพื่อฝืนให้ฟังก์ชันนี้ใช้งานได้ และจะบอกว่าเผาเงิน 20,000 ดอลลาร์ทิ้งไปก็ไม่ผิดนัก
    การได้ ผลลัพธ์เชิงเส้นจากคอมพิวต์แบบเอ็กซ์โพเนนเชียล มีความหมายก็จริง แต่ในระยะยาวดูเป็นทิศทางที่ไม่มีประสิทธิภาพ

    • 20,000 ดอลลาร์น่าจะเป็นราคาแบบ API แต่ถ้าคิดแบบ subscription ก็น่าจะประมาณ แพลน Max 5-6 ชุด
    • ถึงอย่างนั้นมันก็ยังเป็นแค่ ค่าแรงวิศวกร FAANG ประมาณ 2 สัปดาห์ แต่มนุษย์คงสร้างคอมไพเลอร์ไม่ได้ภายใน 2 สัปดาห์อยู่แล้ว ดังนั้นในฐานะงานสาธิตก็ยังมีคุณค่ามากพอ