วิธีที่เราใช้ Claude Code ทำการย้ายโค้ดขนาดใหญ่

 (claude.com)
6 คะแนน โดย GN⁺ 2 시간 전 | ยังไม่มีความคิดเห็น | แชร์ทาง WhatsApp
  • นักพัฒนาของ Anthropic ใช้ Claude Fable 5, Claude Opus 4.8 และ dynamic workflows เพื่อย้ายแพ็กเกจ 10 รายการที่มีขนาดตั้งแต่หลายหมื่นถึงหลายแสนบรรทัดในช่วงเดือนที่ผ่านมา โดยไม่ได้แก้โค้ดทีละส่วน แต่ปรับปรุง กระบวนการวนซ้ำที่สร้างโค้ด
  • การย้าย Bun จาก Zig→Rust สร้างโค้ด 1 ล้านบรรทัด ภายในไม่ถึง 2 สัปดาห์ และผ่านชุดทดสอบเดิม 100% ก่อน merge ส่วนโปรเจกต์ Python→TypeScript ย้ายโค้ด 165,000 บรรทัดในช่วงสุดสัปดาห์ โดยใช้เอเจนต์หลายร้อยตัว ด่านตรวจ 8 ขั้น และการรีวิวแบบ adversarial 3 ครั้ง
  • การย้ายขนาดใหญ่เหมาะกับการสร้าง ลูปตรวจสอบที่เป็นวัตถุวิสัย เพราะงานสามารถขนานกันได้ โค้ดเดิมทำหน้าที่เป็นทั้งสเปกและคำตอบที่ถูกต้อง และความล้มเหลวจากการ compile/ทดสอบจะสร้างคิวงานถัดไปโดยอัตโนมัติ
  • กระบวนการดำเนินเป็นขั้น ๆ ตั้งแต่เตรียมเกณฑ์ตัดสิน จัดทำ rulebook แผนที่ dependency และรายการความต่าง stress test กฎ แปลทั้งระบบ compile รัน และเปรียบเทียบพฤติกรรม โดยข้อผิดพลาดที่เกิดซ้ำจะไม่แก้เป็นรายไฟล์ แต่ แก้กฎระดับบนแล้วสร้างใหม่
  • ค่าใช้จ่ายยังอยู่ที่หลายหมื่นถึงหลายแสนดอลลาร์ขึ้นไป แต่สามารถทิ้ง branch ที่ล้มเหลวแล้วลองใหม่ได้ การย้าย Bun ใช้เงินตามราคา API ราว 165,000 ดอลลาร์ ก่อนจะลดการใช้หน่วยความจำ ลดขนาด binary ลง 19% และเพิ่มประสิทธิภาพ workload จริง 2–5%

แนวทางปรับปรุงลูปการสร้าง ไม่ใช่ตัวโค้ด

  • AI code migration คือวิธีที่เอเจนต์ย้าย codebase ระดับ production ไปยังภาษาใหม่หรือ framework ใหม่
    • แทนที่วิศวกรจะแปลไฟล์เองโดยตรง ก็เขียนกฎการย้ายและลูปตรวจสอบ
    • เอเจนต์จะแปล compile และทดสอบซ้ำจนกว่าพฤติกรรมของโค้ดใหม่จะตรงกับต้นฉบับ
    • โปรเจกต์ที่ในอดีตต้องใช้เวลาหลายปีสามารถย่นลงเหลือระดับหลายสัปดาห์ได้
  • Anthropic ใช้ Claude Fable 5, Claude Opus 4.8 และ dynamic workflows ย้ายแพ็กเกจโค้ด 10 รายการที่มีขนาดตั้งแต่หลายหมื่นถึงหลายแสนบรรทัดในหนึ่งเดือน
  • หลักการปฏิบัติสำคัญคือไม่ซ่อมโค้ดที่ถูกสร้างขึ้นโดยตรง แต่ แก้ลูปที่สร้างโค้ดนั้น

ตัวอย่างการ migration จริง

  • การย้าย Bun จาก Zig→Rust

    • Jarred Sumner ใช้ Claude Code ย้าย Bun จาก Zig ไป Rust
    • สร้างโค้ด 1 ล้านบรรทัด ในเวลาน้อยกว่า 2 สัปดาห์
    • ผ่านชุดทดสอบเดิมของ Bun ใน CI 100% ก่อน merge
    • regression 19 รายการที่พบหลัง merge ได้รับการแก้ไขทั้งหมด
    • Rust port ถูกนำเข้าใช้ใน Claude Code เมื่อเดือนมิถุนายน
    • Bun มียอดดาวน์โหลดรายเดือนมากกว่า 10 ล้านครั้ง และถูกใช้อย่างกว้างขวางภายใน Claude Code ด้วย

  • การย้าย Python→TypeScript

    • Mike Krieger ย้าย codebase Python เป็น TypeScript 165,000 บรรทัด ในช่วงสุดสัปดาห์
    • ใช้เอเจนต์หลายร้อยตัว ด่านตรวจ 8 ขั้น และการรีวิวแบบ adversarial 3 ครั้ง
    • ทำการตรวจสอบความเท่าเทียมขั้นสุดท้าย โดยเปรียบเทียบ output ของทุกคำสั่งกับต้นฉบับ Python
    • ทำซ้ำด้วยการทิ้งผล migration ทั้งหมด แล้วแก้กฎและ workflow โดยเลือกใช้ผลจากการรันครั้งที่สาม

เงื่อนไขที่ควรกลับมาพิจารณาการย้ายภาษา

  • หากสภาพแวดล้อมทางเทคนิคเปลี่ยนไปหลังการพัฒนาครั้งแรก จน trade-off เดิมกลายเป็นข้อจำกัด มีแนวทางที่ดีกว่าเกิดขึ้น หรือ ecosystem เดิมหดตัวลง ก็อาจพิจารณาการย้ายได้
  • Zig ให้ประสิทธิภาพระดับ C และความเรียบง่าย ซึ่งเหมาะกับสภาพแวดล้อมช่วงแรกที่พัฒนา Bun เพียงลำพัง แต่ความเรียบง่ายนั้นมี trade-off ที่ทราบอยู่แล้ว
  • ในอดีต การย้ายภาษาต้องหยุด roadmap และทุ่มทรัพยากรหลายไตรมาส
    • อาจต้องดูแล codebase สองชุดคู่กันเป็นเวลาหลายไตรมาสหรือหลายปี
    • หากความตรงกันของพฤติกรรมสุดท้ายอยู่แค่ 90% ก็อาจเกิดปัญหาบำรุงรักษาใหญ่กว่าก่อนเริ่ม
    • ตอนนี้มีทางเลือกในการลบ branch ที่ล้มเหลวแล้วรันใหม่
  • การย้าย 1 ล้านบรรทัดไม่จำเป็นต้องใช้ต้นทุนวิศวกรรม 3–4 ล้านดอลลาร์ ตลอด 4 ปีอีกต่อไป แต่ก็ยังอาจมีค่าใช้จ่ายหลายหมื่นถึงหลายแสนดอลลาร์ขึ้นไป
    • การย้าย Bun ใช้ input token ที่ไม่ถูก cache 5.9 พันล้าน token และ output token 690 ล้าน token
    • ค่าใช้จ่ายตามราคา API อยู่ที่ประมาณ 165,000 ดอลลาร์
    • ส่วนหลักของ port ของ Mike ใช้ 27 ล้าน token
  • เหตุผลทางธุรกิจของการย้ายไม่จำเป็นต้องถึงขั้นชี้เป็นชี้ตายอีกต่อไป แค่การแก้ memory bug ที่เกิดซ้ำตลอดปี หรือ bottleneck เรื้อรังเพียงจุดเดียว ก็อาจเพียงพอที่จะ justify ได้

  • แก้ bottleneck ของ build ใน Python

    • เครื่องมือภายในของ Mike ถูกส่งให้ผู้ใช้เป็น binary เดี่ยว แต่การสร้าง binary รายแพลตฟอร์มด้วย Python toolchain ใช้เวลาประมาณ 8 นาที
    • ใน build matrix ทั้งหมด ต้องรอราว 30 นาที ต่อ release
    • หลังย้ายเป็น TypeScript การ compile ลดเหลือราว 2 วินาที การเริ่ม binary เร็วขึ้น 6 เท่า และยกเลิก deployment pipeline แยกต่างหากได้

ทำไม AI agent จึงเหมาะกับการย้าย

  • สามารถทำงานแบบ ขนาน ได้
    • แบ่งเป็นหน่วยอิสระหลายพันหน่วย เช่น ไฟล์และ crate แล้วให้เอเจนต์หลายตัวจัดการพร้อมกันได้
  • โค้ดเดิมทำหน้าที่เป็น สเปก ที่ชัดเจนและครอบคลุม
    • ยังใช้เป็นแหล่งอ้างอิงหลักในการสร้างคำสั่งสำหรับเอเจนต์แปลได้ด้วย
  • ชุดทดสอบทำหน้าที่เป็นตัวตัดสินที่มีอยู่ในตัว
    • หากการตรวจสอบเป็นวัตถุวิสัย โมเดลสามารถทำงานซ้ำหลายวันโดยยึดคำตอบที่ถูกต้องได้ โดยไม่ต้องให้มนุษย์คอยไกล่เกลี่ยคุณภาพตลอดเวลา
  • ความล้มเหลวจากการ compile หรือทดสอบจะกลายเป็นงานถัดไปโดยอัตโนมัติ จึงลดความจำเป็นในการเขียนคิวงานแยก
  • สามารถใส่ความสม่ำเสมอและการจัดการข้อยกเว้นไว้ในลูปได้
    • ผู้รีวิวเชื่อมแต่ละปัญหากับกฎที่ถูกละเมิด
    • วิธีแก้ข้อยกเว้นจะกลายเป็นกฎที่เอเจนต์ทั้งหมดปฏิบัติตามภายหลัง
    • แทนที่จะเกิดพฤติกรรมไม่ตรงกันแบบเงียบ ๆ การละเมิดกฎจะกลายเป็นรายการงานที่ชัดเจน
  • Fable และ Opus 4.8 ถูกใช้เพื่อมอบหมาย ควบคุม และตรวจสอบงานขนานของ sub-agent รวมถึงค้นหาเส้นทางหลายแบบในการไปถึงเป้าหมาย
  • ใช้ รูปแบบที่ปรึกษา ที่ผสมโมเดลหลายระดับเพื่อ optimize การใช้ token

เงื่อนไขตั้งต้น: ตัดสินความเท่าเทียมระหว่างต้นฉบับกับ port

  • ก่อนเริ่มย้าย ต้องมี ตัวตัดสิน ที่แข็งแรงเพื่อประเมินโค้ดต้นฉบับและโค้ดปลายทางด้วยเกณฑ์เดียวกัน
    • หากไม่มีตัวตัดสิน ก็ไม่มีเกณฑ์ความสำเร็จและเงื่อนไขจบงาน
    • การทดสอบที่พึ่งพาฟังก์ชันภายในของภาษาต้นฉบับอาจรันบนโค้ดปลายทางตามเดิมไม่ได้
  • แบ่งการทดสอบเดิมออกเป็นการทดสอบที่แสดงเป็นการเรียกภายนอกได้ และการทดสอบที่พึ่งพา implementation ภายในซึ่งจะไม่ถูก port
  • เขียนการทดสอบพฤติกรรมภายนอกใหม่ให้เป็น assertion ที่รันได้ทั้งบนต้นฉบับและ port
    • เอเจนต์ adversarial ตรวจสอบว่าระหว่างเขียนใหม่ assertion ไม่ถูกทำให้อ่อนลง
  • รันตัวตัดสินกับโค้ดต้นฉบับเพื่อยืนยันว่าผ่าน จากนั้นตรวจด้วยว่าโค้ดที่จงใจทำให้เสียจะล้มเหลวหรือไม่
  • Jarred มีชุดทดสอบขนาดใหญ่ที่เขียนด้วยภาษาเครื่องที่สามคือ TypeScript
  • Mike สร้าง equivalence harness จากสถานการณ์ใช้งานจริง 7 แบบ และถือว่าการเปลี่ยนแปลงพฤติกรรมทั้งหมดเป็น bug ที่ต้องแก้

ขั้นที่ 1: rulebook, แผนที่ dependency และรายการความต่าง

  • ผลลัพธ์พื้นฐานไม่ใช่แค่ผลการแปลง่าย ๆ แต่เป็นรายการตำแหน่งที่ต้อง refactor, rulebook ของวิธีแปล และแผนที่ dependency สำหรับกำหนดลำดับงาน
  • ลำดับการเขียนมีความสำคัญ
    • ต้องกำหนดค่า default ของ rulebook ก่อน จึงจะนิยามรายการที่ default นั้นจัดการไม่ได้เป็นรายการความต่างได้
    • rulebook และรายการความต่างต้องถูกตรวจสอบร่วมกันผ่านการ audit ร่วม

  • Rulebook

    • รูปแบบของ rulebook ขึ้นอยู่กับว่าโค้ดใหม่จะคงโครงสร้างเดิมไว้หรือออกแบบใหม่ทั้งหมด
    • หากคงโครงสร้างแบบ Jarred จุดหลักจะเป็น ตาราง mapping ของ type และ idiom ระหว่างภาษา และ component ที่แปลยากจะอ้างอิงรายการความต่าง
    • หากออกแบบใหม่แบบ Mike rulebook จะทำหน้าที่เป็น design document
    • Jarred สนทนากับ Claude เพื่อสร้าง policy สำหรับทุกพื้นที่ที่กำกวม และตั้ง sub-agent 8 ตัวให้รีวิวข้อผิดพลาดที่คาดไว้ 8 หมวดหมู่แยกกัน

  • แผนที่ dependency

    • ในการย้ายแบบขนาน ต้องเข้าใจ dependency ระหว่างไฟล์เพื่อกำหนดว่าจะย้ายไฟล์ใดก่อน และไฟล์ใดควรอยู่ batch เดียวกัน
    • สำหรับโค้ด legacy ที่ไม่มี manifest ชัดเจน และ codebase อย่าง C/C++, Python ต้องค้นหาและทำแผนที่ dependency เอง
    • เอเจนต์ Claude Code สามารถสร้างแผนที่ได้ผ่านลูปที่เขียนและรันสคริปต์แบบ deterministic แล้วรีวิวและแก้ไข
    • ดูตัวอย่างทั่วไปได้ที่ dependency map prompt

  • รายการความต่างของภาษาและผู้รีวิวที่ตั้งข้อสงสัย

    • รายการความต่าง บันทึกความรู้ที่ซ่อนอยู่โดยนัยในโค้ดเดิม แต่ต้องทำให้ชัดเจนในภาษาปลายทาง
    • สำหรับ Zig→Rust ความต่างหลักคือวิธีจัดการหน่วยความจำ
    • ใน Zig ข้อเท็จจริงที่ว่าผู้เรียกต้อง free buffer อาจมีอยู่แค่ใน comment และแม้ลืม free ก็ยัง compile ได้ โดย leak จะพบตอน runtime
    • ใน Rust ownership จะย้ายไปยังผู้เรียกและ memory จะถูก free อัตโนมัติ ส่วนการใช้หลัง move หรือ double free จะ compile ไม่ผ่าน
    • สำหรับ Python→TypeScript ความต่างหลักคือ interface และ contract
    • Python ไม่จำเป็นต้องประกาศรูปทรงของ object ที่รับเข้ามาและค่าที่ return
    • TypeScript ต้องเขียน contract ของ method, argument และ return shape จึงจะ compile ได้
    • Jarred ทำรายการความต่างก่อนแปล ส่วน Mike แปลก่อนแล้วค่อยสร้างรายการระหว่าง audit ดังนั้นใช้ได้ทั้งสองแนวทางตามโปรเจกต์
    • ดูตัวอย่างทั่วไปได้ที่ gap inventory prompt

ขั้นที่ 2: stress test กฎ

  • ก่อนย้ายทั้งหมด ให้ใช้ trial migration ขนาดเล็กเพื่อเขย่า rulebook และหาปัญหา
  • Jarred เปรียบเทียบงานของเอเจนต์สามแบบ
    • เอเจนต์แรกแปลไฟล์ 3 ไฟล์ตาม rulebook
    • เอเจนต์ที่สองแปลขนาดเดียวกันเหมือนวิศวกร Rust ที่มีประสบการณ์
    • เอเจนต์ที่สามเขียนกฎการแปลใหม่จากความต่างระหว่างผลลัพธ์ทั้งสอง
  • กระบวนการนี้พบปัญหาร้ายแรง 2 เรื่องก่อนที่จะลุกลามไปทั้ง 1,448 ไฟล์
  • วิธีนี้ใช้ได้เฉพาะกับ การย้ายแบบคงโครงสร้าง ที่เปรียบเทียบผลแปลสองแบบของไฟล์เดียวกันทีละบรรทัดได้
  • หากออกแบบใหม่แบบ Mike ผู้รีวิว adversarial ต้องโจมตี design document และตรวจสอบด้วยการรัน end-to-end ที่ทิ้งได้
  • ไฟล์ทั้งหมดที่แปลในการทดลองควรถูกทิ้ง เพราะเป้าหมายคือปรับปรุงกฎ ไม่ใช่ความคืบหน้าของโค้ดแบบค่อยเป็นค่อยไป
  • ดูตัวอย่างงานทั่วไปได้ที่ stress test prompt

ขั้นที่ 3: แปลโค้ดทั้งหมด

  • ขั้นต่อจากนี้ทั้งหมดใช้ลูป multi-agent แบบ implement→review→fix
  • การ implement จำนวนมากอาจมอบให้โมเดลเล็ก และให้โมเดลใหญ่รับหน้าที่ review
    • Mike ใช้ sub-agent Claude Sonnet 12 ตัวเมื่อขนานงานย้ายหลัก
  • จัดการคิวงานแบบกลไก
    • batch script ตัดสินสถานะเสร็จจากการมีไฟล์แปลอยู่บนดิสก์
    • แบ่งไฟล์ที่เหลือเป็น batch สำหรับเอเจนต์ implement
    • ทุกครั้งที่รันจะสร้างคิวใหม่จากสถานะบนดิสก์ จึงโดยพื้นฐานแล้วหยุดแล้วทำต่อได้
  • หากเอเจนต์ระมัดระวังเกินไปจนจัดการได้น้อย ให้สั่งอย่างตรงขึ้นพร้อมบริบทว่า compiler จะจับ error ในขั้นถัดไป
  • รายการที่ยังจัดการอย่างมั่นใจไม่ได้ให้ทำเครื่องหมายเป็น // TODO(port): <reason> และแก้ในขั้นที่ 4
  • รายการงานหลังจากนั้นจะถูกสร้างอัตโนมัติจาก compile error, smoke test crash และ test failure

  • การรีวิวแบบ adversarial และการอัปเดตกฎ

    • ผู้รีวิว adversarial 2 ตัวที่มี context แยกกันประเมินผล implement และหากเห็นต่างกัน ให้เอเจนต์ที่สามตัดสิน
    • หาก error เดิมเกิดซ้ำในหลายไฟล์ จะไม่แก้ทีละไฟล์
    • เพิ่มประโยคหนึ่งใน rulebook แล้วสร้าง batch ที่ได้รับผลกระทบใหม่
    • แม้ในขั้นแปล rulebook ก็ยังขยายต่อไป และไม่ patch โค้ดที่ผิดกฎด้วยมือ

  • ตำแหน่งการวาง compiler

    • หาก compile เร็ว สามารถใส่ไว้ในลูปการแปลได้
    • Mike รันในทุกลูป เพราะ TypeScript compile เสร็จภายในไม่กี่วินาทีต่อหน่วย
    • หาก compile ใช้เวลานาน ให้ย้ายไปขั้นถัดไป
    • Jarred ห้ามใช้ compiler ในลูปแปล เพราะการรัน cargo ใช้เวลาหลายนาที
    • ตั้งแต่ขั้นนี้ prompt จะสั้นลง ดูตัวอย่างได้ที่ translation kickoff prompt

ขั้นที่ 4–6: compile, รัน และทำให้พฤติกรรมตรงกัน

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

  • ขั้นที่ 4: Compile

    • Jarred ตั้งค่าให้ orchestrator script รัน compiler หนึ่งครั้งใน workspace ทั้งหมด
    • เอเจนต์แก้ไขประมวลผลรายการ error แบบขนาน ผ่านการรีวิว adversarial แล้ว build ซ้ำ วนเช่นนี้ต่อไป
    • การรีวิวรายการ error ใช้เพื่อค้นหาปัญหาเชิงระบบ ไม่ใช่ error รายตัว
    • หลังแก้ circular import ที่ delayed compilation ของ Zig อนุญาตไว้ ก็เกิด error ของ Rust module หลายพันรายการ
    • เพิ่ม logic ในลูปเพื่อจัดหมวดหมู่ว่าจะลบหรือย้าย dependency ใด หรือปรับโครงสร้าง boundary อย่างไร

  • ขั้นที่ 5: การรันและ smoke test

    • crash ที่เกิดใน smoke test ทำหน้าที่เป็น คำตอบเชิงกลไก เช่นเดียวกับรายการ compile error
    • ไม่จัดการปัญหาทีละรายการ แต่จัดกลุ่มตาม root cause แล้วให้ sub-agent adversarial รีวิว

  • ขั้นที่ 6: เปรียบเทียบพฤติกรรมกับต้นฉบับ

    • แบ่งโค้ดที่ผ่านการแปล compile และ smoke test แล้ว จากนั้นรันชุดทดสอบที่เตรียมไว้ในขั้นก่อนหน้ากับทั้งต้นฉบับและ port
    • เอเจนต์แก้ไขตรวจสอบ test ที่ล้มเหลวพร้อม codebase ทั้งสองฝั่ง และผู้รีวิว adversarial ตรวจผลการแก้ไข
    • จำกัดให้มีเพียง build daemon ที่สามารถ build binary ใหม่ได้
    • เอเจนต์แก้ไขเขียน patch และ daemon จะรวบรวม patch แล้ว rebuild เพียงครั้งเดียว
    • รัน test ที่ได้รับผลกระทบซ้ำแล้วคืนผลลัพธ์
    • ทำให้งานเป็นลำดับเพื่อไม่ให้เอเจนต์หลายตัวรัน build ราคาแพงแยกกัน
    • หาก failure เดิมเกิดซ้ำในหลาย test ให้แก้กฎระดับบนที่สร้าง bug นั้น แล้วสร้างใหม่เฉพาะไฟล์ที่กฎนั้นส่งผล

  • กรณีไม่มีชุดทดสอบ

    • Mike ให้ Claude สร้างสคริปต์เล็ก ๆ ที่รันสถานการณ์จริง 7 แบบกับโค้ด Python ต้นฉบับและ port ใหม่ แล้วเปรียบเทียบผล
    • มอบหมายเอเจนต์แก้ไขแยกกันสำหรับแต่ละ scenario ที่ล้มเหลว และวนซ้ำจนทั้ง 7 แบบผ่านทั้งหมด
    • Claude ยังออกแบบชุดทดสอบ end-to-end ของตนเองและรันอัตโนมัติข้ามคืน
    • ทำซ้ำการแก้ error แล้วรันใหม่เป็นเวลา 4 คืน
    • รายการ scenario ที่เขียนไว้ล่วงหน้าช่วยพบแม้แต่ปัญหา usability เล็ก ๆ ที่คาดเดายาก
    • แม้ไม่มี test เดิม ก็สามารถใช้ codebase ต้นฉบับเป็นคำตอบที่ถูกต้องเพื่อให้ Claude สร้างตัวตัดสินได้

หลักการปฏิบัติที่พบจากการรันซ้ำ

  • ควรวางแผนการย้ายกับ Claude ให้เหมาะกับลักษณะโปรเจกต์ก่อนเริ่ม ไม่ใช่ทำตามคู่มือแบบตรงตัว
  • ปล่อยให้เอเจนต์แก้ไขจัดการ failure รายตัว ส่วนมนุษย์ควรโฟกัสที่ รูปแบบ error ที่เกิดซ้ำ
  • จัดให้การรีวิวเป็นแบบ adversarial และการตรวจสอบเป็นแบบกลไก
    • การรีวิว adversarial มีประโยชน์กับงานระยะยาว และอาจคุ้มกับ token เพิ่มเติม
    • ใช้สคริปต์ เช่น compiler, diff และ test suite เป็นตัวตัดสินสุดท้าย
  • ไม่ใช้โมเดลใหญ่ที่สุดกับทุกงาน
    • ใช้โมเดลเล็กเพื่อขนานงาน implement จำนวนมาก
    • ให้โมเดลใหญ่ที่สุดโฟกัสที่การ review และการเขียนกฎให้เอเจนต์อื่นทำตาม
  • เวลาทำงานของมนุษย์ควร ลงทุนล่วงหน้า กับ rulebook และ stress test ส่วนกระบวนการหลังจากนั้นส่วนใหญ่เป็นงานระบายคิว
  • สถานะเสร็จต้องตัดสินได้แบบกลไก เช่น “ไฟล์ output มีอยู่บนดิสก์” และคิวงานต้องทำต่อจากเดิมได้

ผลลัพธ์และข้อจำกัดของการย้าย Bun

  • Rust port ของ Bun ทำงานอยู่ใน production แล้ว แต่โค้ด Rust ประมาณ 4% อยู่ใน block unsafe
    • ส่วนใหญ่เป็น pointer operation บรรทัดเดียวตรง boundary ของ C/C++
  • แก้ memory leak ทั้งหมดที่เครื่องมือตรวจจับได้
    • ใน benchmark ที่รัน build ซ้ำ 2,000 ครั้ง การใช้หน่วยความจำลดจาก 6,745MB เหลือ 609MB
  • ขนาด binary บน Linux และ Windows ลดลง 19%
  • การ optimize ข้ามภาษาช่วยให้ประสิทธิภาพ workload จริง เช่น HTTP service, next build และ tsc ดีขึ้น 2–5%
  • ในการย้ายขนาดใหญ่ ควรรีวิว ผลลัพธ์ที่ลูปสร้างขึ้นและรูปแบบการวนซ้ำ มากกว่าโค้ดที่ถูกสร้างทีละบรรทัด

เนื้อหาที่เกี่ยวข้อง

  • Migration starter kit: template ที่ทำให้กระบวนการในบทความเป็นรูปแบบทั่วไป โดย port จริงทั้งสองงานไม่ได้รันด้วย kit นี้
  • Code-modernization plugin: plugin สำหรับ modernize legacy และ upgrade framework ไม่ใช่การ port ภาษา
  • Dynamic workflows in Claude Code: แนะนำ dynamic workflows ของ Claude Code

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

ยังไม่มีความคิดเห็น

ยังไม่มีความคิดเห็น