การขยายการเขียนโค้ดอัตโนมัติที่รันเป็นเวลานาน

 (cursor.com)
18 คะแนน โดย GN⁺ 2026-01-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Cursor ทดลองว่าระบบ เอเจนต์เขียนโค้ดอัตโนมัติ สามารถรันแบบขนานเป็นเวลาหลายสัปดาห์เพื่อทำโปรเจ็กต์ขนาดใหญ่ให้เสร็จได้หรือไม่
  • ในช่วงแรกใช้ โครงสร้างความร่วมมือแบบไดนามิก แต่เกิดคอขวดจากการชนกันของ lock และงานที่ซ้ำซ้อน
  • ต่อมาจึงแยกบทบาทเป็น Planner และ Worker ทำให้ความสามารถในการทำงานขนานและประสิทธิภาพดีขึ้นอย่างมาก
  • ด้วยโครงสร้างนี้ ทีมสามารถ สร้างเว็บเบราว์เซอร์ตั้งแต่ศูนย์, โดยมีเอเจนต์หลายร้อยตัวเขียนโค้ดมากกว่า 1 ล้านบรรทัด
  • ผลการทดลองชี้ว่า โครงสร้างที่เรียบง่ายและการออกแบบพรอมป์ต์ที่เหมาะสม คือหัวใจสำคัญของการขยายการเขียนโค้ดอัตโนมัติระยะยาว

ข้อจำกัดของเอเจนต์เดี่ยว

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

กระบวนการเรียนรู้ด้านการทำงานร่วมกัน

  • มีการนำโครงสร้างที่เอเจนต์ทุกตัวมี สิทธิ์เท่าเทียมกัน และประสานงานผ่านไฟล์ที่ใช้ร่วมกันมาใช้
    • เอเจนต์แต่ละตัวตรวจสอบสถานะของเอเจนต์อื่น รับมอบหมายงาน และอัปเดตสถานะ
    • เพื่อป้องกันงานซ้ำ ใช้ กลไก lock
  • ปัญหาที่พบ
    1. เอเจนต์บางตัวครอบครอง lock นานเกินไปหรือไม่ปล่อย lock ทำให้ความเร็วโดยรวมลดลงเหลือเพียงระดับ 2–3 ตัวจากทั้งหมด 20 ตัว
    2. เกิด ความไม่เสถียรของระบบ เช่น ล้มเหลวขณะถือ lock หรือแก้ไขไฟล์โดยไม่มี lock
  • เปลี่ยนไปใช้ optimistic concurrency control
    • อนุญาตให้อ่านได้อิสระ แต่ตั้งให้การเขียนล้มเหลวเมื่อมีการเปลี่ยนสถานะ
    • แม้จะเรียบง่ายและเสถียร แต่ใน โครงสร้างที่ไม่มีลำดับชั้น เอเจนต์กลับมีพฤติกรรมหลีกเลี่ยงความเสี่ยง
    • หลีกเลี่ยงปัญหายาก ๆ และวนแก้แต่เรื่องเล็กน้อย จนเกิด วงจรงานที่ไม่คืบหน้า

โครงสร้าง Planner และ Worker

  • จึงเปลี่ยนมาใช้ pipeline แบบมีลำดับชั้น ที่แยกบทบาทชัดเจน
    • Planner: สำรวจ codebase เพื่อสร้างงาน และสร้าง Planner ย่อยได้เมื่อจำเป็น
    • Worker: ทำเฉพาะงานที่ได้รับมอบหมาย และ push การเปลี่ยนแปลงเมื่อเสร็จ
  • ในแต่ละรอบจะมี judge agent ตัดสินว่าจะเดินหน้าสู่ขั้นถัดไปหรือไม่
    • โครงสร้างนี้ช่วยแก้ปัญหาความร่วมมือได้เกือบทั้งหมด ทำให้ รองรับการขยายสเกลของโปรเจ็กต์ขนาดใหญ่

การทดลองรันระยะยาว

  • เป้าหมายของการทดลอง: สร้างเว็บเบราว์เซอร์ตั้งแต่ต้น
    • รันประมาณ 1 สัปดาห์ เขียน โค้ดมากกว่า 1 ล้านบรรทัด ในไฟล์ 1,000 ไฟล์
    • มี Worker หลายร้อยตัว push เข้า branch เดียวกันพร้อมกัน แต่เกิดการชนกันน้อยมาก
    • โค้ดที่ได้ถูกเผยแพร่บน GitHub
  • การทดลองเพิ่มเติม
    • การย้ายจาก Solid → React: ใช้เวลา 3 สัปดาห์ มีการเปลี่ยนแปลง +266K/-193K และยืนยันความเป็นไปได้ในการ merge
    • การปรับปรุงการเรนเดอร์วิดีโอ: เวอร์ชัน Rust เร็วขึ้น 25 เท่า และเพิ่มฟีเจอร์ ซูม·แพน·โมชั่นเบลอ
    • โค้ดดังกล่าวมีแผนจะนำขึ้น production ในเร็ว ๆ นี้

บทเรียนสำคัญ

  • จากการใช้โทเคนระดับหลายพันล้าน แม้ยังไม่ถึงขั้นมีประสิทธิภาพสมบูรณ์ แต่ก็ได้ผลลัพธ์ ดีกว่าที่คาดไว้
  • การเลือกโมเดล เป็นหัวใจของงานอัตโนมัติระยะยาว
    • GPT-5.2 เด่นในด้านการรักษาสมาธิ การทำตามคำสั่ง และการ implement ได้อย่างแม่นยำ
    • Opus 4.5 มีแนวโน้มจะจบงานเร็วเกินไป
    • GPT-5.2 เหมาะกับบทบาท Planner มากกว่า GPT-5.1-codex
    • จึงเลือกใช้โมเดลที่เหมาะที่สุดตามแต่ละบทบาท
  • การตัดความซับซ้อนออก ช่วยเพิ่มประสิทธิภาพ
    • บทบาท quality integrator กลับกลายเป็นคอขวด
    • Worker สามารถจัดการความขัดแย้งได้ด้วยตัวเอง
  • โครงสร้างที่เรียบง่าย ให้ผลดีที่สุด
    • ทฤษฎีระบบกระจายหรือโมเดลการออกแบบองค์กรใช้ได้เพียงบางส่วน
    • ถ้าโครงสร้างน้อยเกินไปจะเกิดการชนกันและงานซ้ำ แต่ถ้ามากเกินไปก็เพิ่มความเปราะบาง
  • การออกแบบพรอมป์ต์ มีผลชี้ขาดต่อพฤติกรรมของระบบ
    • มีบทบาทสำคัญต่อการรักษาสมาธิระยะยาว การป้องกันพฤติกรรมผิดรูป และการส่งเสริมความร่วมมือ

งานที่ต้องทำต่อไป

  • การประสานงานหลายเอเจนต์ ยังเป็นปัญหาที่ยาก
    • จำเป็นต้องปรับปรุงให้ Planner วางแผนขั้นถัดไปโดยอัตโนมัติเมื่อปิดงานเสร็จ
    • เอเจนต์บางตัวรันนานเกินไป จึงต้องมี การรีสตาร์ตเป็นระยะ
  • อย่างไรก็ตาม สำหรับคำถามหลักว่า “ถ้าเพิ่มจำนวนเอเจนต์ จะสามารถขยายการเขียนโค้ดอัตโนมัติได้หรือไม่”
    • ก็ยืนยันได้ว่า เอเจนต์หลายร้อยตัวสามารถทำงานร่วมกันเป็นเวลาหลายสัปดาห์และสร้างความคืบหน้าจริงได้
  • เทคโนโลยีนี้มีแผนจะนำไปใช้กับ ความสามารถด้านเอเจนต์ของ Cursor ในอนาคต

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

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

 
GN⁺ 2026-01-16
ความเห็นบน Hacker News

  • กำลังทำงานที่เกี่ยวข้องกับบทความของ Steve Yegge Welcome to Gas Town เลยอ่านด้วยความสนใจ

  • ใน บทความคาดการณ์ LLM ที่ผมแชร์ไว้ล่าสุด ผมเคยบอกว่าราวปี 2029 การ สร้างเบราว์เซอร์ด้วย AI-assisted coding จะไม่ใช่เรื่องน่าประหลาดใจ และโปรเจกต์นี้ของ Cursor ก็เป็นความพยายามครั้งที่สองแล้ว
    ตัวอย่างอีกอันดูได้จาก โพสต์ Reddit นี้

    • ถ้าจะทำแบบฉลาด ๆ ก็น่าจะดึง ซอร์ส Chromium จาก GitHub มา แล้วตัดฟีเจอร์ที่ไม่จำเป็นออก เปลี่ยนแค่หน้าตา
    • พอถึงปี 2029 ก็ควรเป็นช่วงที่ต้อง ยกระดับมาตรฐาน จนถึงขั้นมีมุกว่า AI สร้างเบราว์เซอร์สำหรับนกกระทุงได้แล้ว
    • ผมดูโค้ดตัวอย่างจาก Reddit อยู่ประมาณ 5 นาที แล้วพบว่า การคำนวณ text layout กับ bidi (ข้อความสองทิศทาง) เละเทะมาก ถ้าไม่คำนึงถึงมาตรฐาน เบราว์เซอร์แบบนั้นก็เรียกว่าเป็นเบราว์เซอร์จริง ๆ ได้ยาก
    • มันก็น่าประทับใจอยู่ แต่ก็อดสงสัยไม่ได้ว่าโค้ดเบราว์เซอร์โอเพนซอร์สถูกใส่ไว้ใน ข้อมูลฝึก ของโมเดลหรือเปล่า
    • เขาบอกว่าคำทำนายตัวเองพลาด แต่พอผ่านไปแค่สัปดาห์เดียวก็กลับไปออกรายการพอดแคสต์เดิมเพื่อทำนายใหม่ เลยสงสัยว่าเพราะอะไร

  • ผมลองรันเทสต์ในรีโพเองแล้วพบว่า เต็มไปด้วย error และ warning แถม CI ก็ล้มมานานแล้ว ไม่แน่ใจว่าในสภาพแบบนี้จะเรียกว่าเป็น “ตัวอย่างที่ประสบความสำเร็จ” ได้ไหม ผมคิดว่าแนวทางแบบ มนุษย์เป็นศูนย์กลางและมี AI ช่วยเสริม ยังสมจริงกว่าโค้ดดิ้งอัตโนมัติเต็มรูปแบบ

    • codebase ถูกแยกเป็นไฟล์เล็ก ๆ หลายร้อยหลายพันไฟล์จน แทบมองโครงสร้างไม่ออก README ก็หละหลวม และไม่มีคำอธิบาย dependency แม้จะเป็นโค้ดที่ AI สร้าง แต่การดูแลรักษาน่าจะระดับฝันร้าย
    • ดูเหมือนผู้เขียนเองก็มองการโค้ดดิ้งอัตโนมัติเต็มรูปแบบเป็น การทดลองขีดจำกัดของ LLM มากกว่าจะเอาไปทำโปรดักต์จริง ตอนนี้ยังอยู่ในช่วงที่มันพอเขียน “โค้ดที่ใช้ได้คนเดียว” ได้แค่ระดับโปรเจกต์เล็ก ๆ
    • การที่ merge PR ที่ CI fail เข้าไปเฉย ๆ ก็ชวนให้เล่นมุกได้ว่าอย่างน้อยก็ ไปถึงคุณภาพระดับมนุษย์ แล้ว
    • คำว่า “ช้า” ก็ยังไม่ชัดว่าหมายถึงอะไรแน่ ความเร็ว GPU? หรือช้ากว่ามนุษย์? สุดท้ายเลยให้ความรู้สึกเหมือนเป็น บทความที่ช่วยเป่าฟองสบู่ AI

  • ผมสงสัยว่าทำไม PR นั้นยังไม่ถูก merge เสียที อนาคตที่ ฝูง AI agent ช่วยกันทำซอฟต์แวร์ซับซ้อนระยะยาวจนเสร็จ ฟังดูยอดเยี่ยม แต่ตัวอย่างตอนนี้ยังอ่อนเกินไป จุดที่มนุษย์จะร่วมงานด้วยสำคัญกว่า

    • จากประสบการณ์ของผม พวก agent ไม่ได้ converge แต่กลับสร้าง สัตว์ประหลาดโค้ดที่ยิ่งทำยิ่งเละ
    • การที่ยังไม่เผยแพร่โปรเจกต์ง่าย ๆ ที่ใช้งานได้จริงสักอัน ทำให้มันดูเหมือน เหยื่อล่อดึงนักลงทุน มากกว่า กระแส AI คล้ายฟองสบู่ดอตคอมก็จริง แต่รอบนี้รู้สึกว่าเน้นหาเงินมากกว่า
    • ตัวอย่างอย่างเบราว์เซอร์, Excel หรือ Windows 7 อาจมีบางส่วนอยู่ในข้อมูลฝึก แต่ก็ไม่ได้แปลว่าจะทำซ้ำทั้งระบบได้ทั้งหมด
    • โค้ดมีขนาดใหญ่เกินไปและมีปัญหาเยอะจนรีวิวแทบไม่ได้ สุดท้ายเลยเหลือทางเดียวคือ merge แบบ YOLO
    • ผมสนใจเรื่อง เงื่อนไขการลู่เข้า มากกว่า ไม่ว่าโค้ดจะเพิ่มหรือลด สิ่งสำคัญคือมันต้องนิ่งเข้าสู่สภาพที่เหมาะสมที่สุด

  • น่าเสียดายที่เขาไม่ได้ทดลองแบบค่อย ๆ เพิ่มความยาก ถ้าไล่จาก React CRUD → โคลน Paint → ตัวจัดการไฟล์ → เบราว์เซอร์ ก็น่าจะเห็นลำดับการพัฒนาได้ชัดกว่านี้

  • ผมเองก็เคยทำ tjs ด้วยแนวทางคล้ายกัน มันคือ JSON Schema Validator ที่เร็วและแม่นยำที่สุดในโลก โดยใช้แพตเทิร์น planner/delegate ผ่าน git subtree ซึ่งได้ผลดีมาก ซอฟต์แวร์ที่มีมาตรฐานและเทสต์ชัดเจน AI agent สามารถ rewrite และ optimize ได้อย่างรวดเร็ว
    คำสั่งที่เกี่ยวข้องดูได้ที่ spawn-perf-agents.md

  • การสร้างเบราว์เซอร์ตั้งแต่ศูนย์นั้นยากมากอยู่แล้ว แต่สิ่งที่บทความนำเสนอก็ยัง ขาดการวิเคราะห์รายละเอียด ถ้าหมายถึงแค่ “คอมไพล์ผ่าน” ก็มีความหมายน้อย การพิสูจน์จริงคือ มันสามารถรวมการเปลี่ยนแปลงครั้งถัดไปได้อย่างเสถียรหรือไม่

    • มาตรฐานขั้นต่ำของ agent coding คือ “คอมไพล์สำเร็จ” → “รันได้ปกติ” → “จัดการ edge case ได้” ตามลำดับ ถ้าจะเชื่อถือได้ ระบบต้องมีบั๊กน้อยกว่ามนุษย์และทำงานเสถียรเกิน 1 ปี
    • แต่ในความเป็นจริง CI ก็ยังล้มอยู่ จึงน่าสงสัยด้วยซ้ำว่าคำกล่าวที่ว่า “คอมไพล์ได้” นั้นจริงหรือไม่

  • ตามที่บล็อกเขียนไว้ เขาใช้ โทเค็นระดับล้านล้าน ถ้าคิดตามราคา OpenAI API ก็ตกเป็นเงินหลายสิบล้านดอลลาร์ ระดับนี้อาจ เอาไปบริจาคให้ทีมเบราว์เซอร์ ยังจะดีกว่า

  • ผมลอง build เองแล้วเจอ compile error เกิน 100 รายการ commit ส่วนใหญ่ก็อยู่ในสถานะ CI fail และของจริงก็เป็นการประกอบไลบรารีโอเพนซอร์สหลายตัวเข้าด้วยกัน
    ทั้ง quickjs, wgpu, winit, egui, html parser ล้วนถูกนำมาใช้เป็นชิ้นส่วนเดิม ๆ แต่ CEO กลับอ้างว่าเป็น “custom JS VM” เลย ทำให้คนเข้าใจผิด
    ถึงอย่างนั้น การที่ AI รวมทุกอย่างนี้เข้าด้วยกันได้แบบอัตโนมัติก็ยังน่าประทับใจ

    • องค์ประกอบที่ใช้คล้ายกับ blitz เบราว์เซอร์ที่เขียนด้วย Rust มาก เลยมีความเป็นไปได้ว่า อาจอยู่ในข้อมูลฝึก
    • ยังมีมุกสไตล์สตาร์ตอัปด้วยว่า “จะใช้ได้จริงไหมไม่สำคัญ ถ่าย screenshot ไปโชว์นักลงทุนก่อน”
    • มีสถิติว่าจาก workflow กว่า 60,000 ครั้ง สำเร็จจริงแค่ราว 1,000 ครั้ง เท่ากับว่ามันดูเป็น ก้อนโค้ดที่แทบยังไม่ผ่านการตรวจสอบ
    • ปิดท้ายด้วยมุกว่า “ทุกคนไปทำ Cursor เวอร์ชัน custom ของตัวเองกันเถอะ”

  • โค้ดดู เปราะบางและไม่เสถียรมาก ตัวอย่างเช่น ฟังก์ชัน render_placeholder ดูเหมือนเป็นโค้ดชั่วคราวที่มีไว้แค่เติม frame buffer
    เลยอยากรู้ว่าโค้ดแบบนี้จริง ๆ แล้วมีหน้าที่อะไร และแต่ละเทสต์มี ต้นทุนโทเค็น/เวลา เท่าไร

    • วิธีดึง attribute ของ tag ก็แปลกอยู่พอสมควรตาม ส่วนนี้
    • แต่ถ้า Cursor แก้ให้อัตโนมัติได้ ความเปราะบางแบบนี้ในระยะยาวก็อาจเป็นกลยุทธ์เพิ่มการพึ่งพาได้เหมือนกัน