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

การย้ายโค้ด (Code migrations) หรือโปรเจกต์ที่ย้ายฐานโค้ดที่ใช้งานจริงไปยังภาษาใหม่ เคยเป็นโครงการที่กินเวลาหลายปี จนกระทั่งเมื่อไม่นานมานี้

ในเดือนที่ผ่านมา นักพัฒนารายบุคคลที่ Anthropic ได้ย้ายแพ็กเกจโค้ด 10 ชุด ซึ่งประกอบด้วยโค้ดหลายหมื่นถึงหลายแสนบรรทัด โดยใช้ Claude Fable 5, Claude Opus 4.8 และ workflows แบบไดนามิก

Jarred Sumner (@jarredsumner) ผู้ร่วมก่อตั้ง Bun และสมาชิกฝ่ายเทคนิคของ Anthropic ใช้ Claude Code เพื่อ ย้าย Bun จาก Zig ไป Rust โค้ดจำนวนหนึ่งล้านบรรทัดถูกสร้างขึ้นในเวลาไม่ถึงสองสัปดาห์ โดยชุดทดสอบที่มีอยู่ทั้งหมดของ Bun ผ่านการทดสอบใน CI ก่อนการ merge เกิด regression 19 รายการหลังการ merge และได้รับการแก้ไขทั้งหมดแล้ว การย้ายไป Rust ถูกจัดส่งภายใน Claude Code ในเดือนมิถุนายน

Mike Krieger (@mikeyk) ผู้ร่วมนำของ Anthropic Labs ย้ายฐานโค้ด Python ไปเป็น TypeScript จำนวน 165,000 บรรทัดในช่วงสุดสัปดาห์เดียว ซึ่งรวมถึง agent หลายร้อยตัว, ประตูเฟส (phase gates) แปดประตู, การทบทวนแบบ adversarial สามรอบ และการตรวจสอบความเท่าเทียมครั้งสุดท้ายที่เปรียบเทียบผลลัพธ์ของทุกคำสั่งกับต้นฉบับ Python

ความสามารถใหม่ของ Claude Code เปลี่ยนสมการสำหรับโปรเจกต์ที่ถูกเลื่อนมานานเหล่านี้ ด้านล่างนี้คือกระบวนการหกขั้นตอนที่เราใช้ในปัจจุบัน ซึ่งได้มาจากสิ่งที่การย้ายเหล่านี้สอนเรา

ข้อมูลเชิงลึกหลักคือ คุณไม่ต้องแก้ไขโค้ด แต่คุณแก้ไขกระบวนการ (ลูป) ที่สร้างโค้ดนั้น

ทำไมและเมื่อใดควรย้ายภาษา

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

ตัวอย่างเช่น Jarred เลือก Zig ในตอนแรกเพราะมันให้ประสิทธิภาพระดับ C ด้วยความเรียบง่ายที่รุนแรง ซึ่งเหมาะสำหรับผู้ก่อตั้งคนเดียวที่ "เขียน Bun ใน 1 ปี ในอพาร์ทเมนต์แคบๆ ในโอ๊คแลนด์ ก่อนยุค LLM" ความเรียบง่ายนี้มาพร้อมกับข้อแลกเปลี่ยนที่รู้จักกันดี ซึ่งเขาเขียนเกี่ยวกับเรื่องนี้ที่นี่

CLI ของ Bun มียอดดาวน์โหลดมากกว่า 10 ล้านครั้งต่อเดือน และถูกใช้อย่างกว้างขวางภายใน Claude Code

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

ตอนนี้ สถานการณ์ที่แย่ที่สุดคือคุณลบ branch และลองอีกครั้ง

ยังคงต้องมีกรณีทางธุรกิจที่สมเหตุสมผล แม้ว่าการย้ายโค้ดนับล้านบรรทัดจะไม่ต้องใช้ทรัพยากรทางวิศวกรรมมูลค่า 3 ถึง 4 ล้านดอลลาร์อีกต่อไปตลอดโปรเจกต์สี่ปี แต่ก็ยังคงมีค่าใช้จ่ายหลายหมื่นถึงหลายแสนดอลลาร์หรือมากกว่าในการดำเนินการ การย้าย Bun ตัวอย่างเช่น ใช้ token ขาเข้าที่ไม่ได้แคช 5.9 พันล้าน token และ token ขาออก 690 ล้าน token — ประมาณ 165,000 ดอลลาร์ตามราคา API ส่วนหลักของการย้ายของ Mike คือ 27 ล้าน token

PR ขนาดล้านบรรทัดของ Jarred

อย่างไรก็ตาม กรณีการย้ายไม่จำเป็นต้องเป็นเรื่องของความอยู่รอดอีกต่อไป การแก้ไขบั๊กหน่วยความจำใน changelog หนึ่งปี หรือคอขวดเรื้อรังหนึ่งจุด สามารถเป็นเหตุผลที่เพียงพอแล้วในตอนนี้

ขั้นตอนการคอมไพล์เป็นแรงผลักดันสำหรับโปรเจกต์ของ Mike เครื่องมือภายในที่ทีมของเขาทำงาน ส่งถึงผู้ใช้เป็นไบนารีไฟล์เดียว การผลิตไบนารีนั้นด้วยชุดเครื่องมือ Python ใช้เวลาประมาณแปดนาทีต่อแพลตฟอร์ม รวมเป็นเวลารอ 30 นาทีใน build matrix ทุกครั้งที่มีการเผยแพร่ หลังจากการย้าย การคอมไพล์แบบเดียวกันใช้เวลาประมาณสองวินาที ไบนารีเริ่มต้นเร็วขึ้น 6 เท่า และทีมสามารถเลิกใช้ไปป์ไลน์การปรับใช้แยกต่างหากได้

ทำไม AI ถึงเปลี่ยนสมการการย้ายโค้ด

Fable และ Opus 4.8 มีความสามารถพิเศษในการมอบหมาย กำกับ และตรวจสอบงานสตรีมคู่ขนานกับ subagent ขณะเดียวกันก็ค้นหาเส้นทางหลายเส้นทางไปสู่เป้าหมายที่ระบุไว้

การย้ายโค้ดขนาดใหญ่เป็นกรณีการใช้งานที่มีประสิทธิภาพโดยเฉพาะสำหรับโมเดลขั้นสูงเหล่านี้ เพราะ:

• งานเป็นแบบขนาน งานสามารถดำเนินการได้ในหน่วยอิสระหลายพันหน่วย เช่น ไฟล์และ crate ดังนั้น agent สามารถทำงานพร้อมกันแทนที่จะต้องรอกัน
• บริบทชัดเจนและครอบคลุม โค้ดเก่าทำหน้าที่เป็นสเปกที่ดีเยี่ยมสำหรับโมเดล
• มีผู้ตัดสินในตัว ฐานโค้ดขนาดใหญ่จำนวนมากจะมีชุดทดสอบที่ agent สามารถใช้ตรวจสอบงานของตนได้
• คิวเขียนตัวเอง เมื่อคอมไพเลอร์หรือการทดสอบล้มเหลว นั่นกลายเป็นรายการถัดไปสำหรับ agent ที่จะแก้ไข
• ต้องการความสอดคล้องและการจัดการกรณีขอบ: ผู้ตรวจทานอ้างถึงกฎเบื้องหลังทุกสิ่งที่พบ ดังนั้นการละเมิดจึงกลายเป็นรายการคิวแทนที่จะเป็นการเบี่ยงเบนเงียบ

หกขั้นตอนสำหรับการย้ายโค้ดขนาดใหญ่

สำหรับรายละเอียดเพิ่มเติม คุณสามารถอ่านบล็อกของ Jarred.

ข้อกำหนดเบื้องต้น

ข้อกำหนดเบื้องต้นก่อนเริ่มโปรเจกต์การย้ายของคุณคือการมีผู้ตัดสินที่แข็งแกร่ง มิฉะนั้นคุณจะไม่มีเงื่อนไขการออกหรือมาตรวัดความสำเร็จ

ในการสร้างผู้ตัดสินนี้:

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

ส่วนใหญ่เป็นไปตามวิธีการของ Jarred โดยมีการทบทวนและประตูในแต่ละขั้นตอน Mike ปฏิบัติตามโครงสร้างโดยรวมที่คล้ายกันโดยใช้ workflow แบบลูปที่คล้ายกัน แต่เขาดำเนินการย้ายทั้งหมดตั้งแต่ต้นจนจบ ปรับปรุงกฎและ workflow ตามผลลัพธ์ และทำอีกครั้ง — ทิ้งผลลัพธ์ในแต่ละครั้งจนกระทั่งการรันครั้งที่สาม

ขั้นตอนที่ 1 — สร้างกฎเกณฑ์ แผนที่การพึ่งพา และรายการช่องว่าง

ลำดับมีความสำคัญ: กฎเกณฑ์ต้องมาก่อนรายการช่องว่าง รายการช่องว่างถูกกำหนดโดยสิ่งที่ค่าเริ่มต้นของกฎเกณฑ์ไม่ครอบคลุม และทั้งสองจะถูกทดสอบร่วมกันในการตรวจสอบร่วม

กฎเกณฑ์

รูปร่างที่แน่นอนของกฎเกณฑ์ ขึ้นอยู่กับการตัดสินใจทางสถาปัตยกรรมที่สำคัญที่คุณต้องทำตั้งแต่เริ่มต้น สิ่งสำคัญที่สุดคือ โค้ดใหม่จะใช้โครงสร้างเดียวกันหรือไม่ หรือจะถูกออกแบบใหม่ทั้งหมด

ถ้าเป็นแบบแรก (Jarred) กฎเกณฑ์จะเป็นตารางค้นหาที่แปลประเภทและสำนวนระหว่างภาษาเป็นหลัก ในขณะที่ชี้ไปที่รายการช่องว่างสำหรับส่วนประกอบที่ยากต่อการแปล ถ้าเป็นแบบหลัง (Mike) มันจะเป็นเอกสารการออกแบบ

Jarred สร้างกฎเกณฑ์ของเขาโดยการแชทกับ Claude โดยสร้างนโยบายสำหรับแต่ละพื้นที่ที่มีความคลุมเครือ เขายังใช้ subagent แปดตัวที่ออกแบบมาโดยเฉพาะเพื่อตรวจสอบความล้มเหลวทั่วไป 8 ประเภทตามสัญชาตญาณของเขาเอง

แผนที่การพึ่งพา

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

รายการช่องว่างและผู้ตรวจสอบแบบสงสัย

ภาษาใหม่มีข้อกำหนดที่แตกต่างจากภาษาเก่าที่ต้องปฏิบัติตาม สำหรับ Zig ไป Rust ความแตกต่างคือการจัดการหน่วยความจำด้วยตนเอง (C และ C++ ทำงานในลักษณะเดียวกัน) ตัวอย่างเช่น:

1// Zig
2
3fn readConfig(allocator: std.mem.Allocator) ![]u8 {
4    const buf = try allocator.alloc(u8, 1024);
5    // ...fill buf...
6    return buf; // ผู้เรียกต้อง free นี้ — แต่มีแค่คอมเมนต์ที่บอก
7}
8
9// ผู้เรียกที่ลืม 'defer allocator.free(buf)' ยังคงคอมไพล์ — การรั่วไหลจะปรากฏที่รันไทม์เท่านั้น

1fn read_config() -> Vec<u8> {
2    let buf = vec![0u8; 1024];
3    // ...fill buf...
4    buf // ความเป็นเจ้าของย้ายไปยังผู้เรียก; หน่วยความจำถูกปล่อยอัตโนมัติ
5}
6
7// ใช้หลังจากที่ถูกย้าย? ปล่อยสองครั้ง? ไม่มีทางคอมไพล์
8// ลืมปล่อย? ไม่มีการเรียก free ที่จะลืม — drop เป็นอัตโนมัติ

สำหรับ Python ไป TypeScript ช่องว่างคืออินเทอร์เฟซและสัญญา Python ไม่ต้องการสัญญาที่ประกาศว่ารูปร่างของอ็อบเจกต์ที่จะยอมรับหรือส่งคืน แต่ TypeScript ต้องการ

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

ดูตัวอย่างพรอมต์ Claude Code เพื่อสร้างไฟล์รายการช่องว่าง

ขั้นตอนที่ 2 — ทดสอบกฎอย่างหนัก

ในขั้นตอนนี้ Jarred ใช้ agent หนึ่งตัวเพื่อแปลสามไฟล์โดยใช้กฎเกณฑ์ agent หนึ่งตัวเพื่อแปลสามไฟล์ "เหมือนวิศวกร Rust อาวุโส" และ agent หนึ่งตัวเพื่อใช้ diff เพื่อสร้างกฎการแปลใหม่ ในขั้นตอนนี้ เขาจับประเด็นวิกฤตสองประเด็นที่จะสร้างปัญหามากมายหากกระจายไปทั่วไฟล์ทั้งหมด 1,448 ไฟล์

การทดสอบอย่างหนักประเภทนี้ใช้ได้เฉพาะกับการย้ายที่รักษาโครงสร้างเท่านั้น ซึ่งการแปลสองครั้งของไฟล์เดียวกันสามารถเปรียบเทียบกันทีละบรรทัดได้ หากกฎเกณฑ์ของคุณคือการออกแบบใหม่ — เช่นของ Mike — การทดสอบที่เทียบเท่าคือการโจมตีเอกสารการออกแบบโดยตรงด้วยผู้ตรวจสอบแบบ adversarial จากนั้นตรวจสอบด้วยการรันแบบ end-to-end ที่ใช้แล้วทิ้ง

ไม่ว่าจะอย่างไร ให้ทิ้งไฟล์ที่แปลแล้วใดๆ เป้าหมายคือการปรับปรุงกฎ ไม่ใช่การสร้างความคืบหน้าแบบค่อยเป็นค่อยไป

ขั้นตอนที่ 3 — แปลทุกอย่าง

สำหรับขั้นตอนที่เหลือ คุณใช้สถาปัตยกรรมลูปหลาย agent เดียวกัน: ดำเนินการ ทบทวน และแก้ไข

คุณสามารถโอนงานดำเนินการให้โมเดลขนาดเล็ก และให้ผู้ตรวจทานอยู่บนโมเดลขนาดใหญ่ ตัวอย่างเช่น Mike ใช้ Claude Sonnet เมื่อเขากระจาย subagent 12 ตัวสำหรับการย้ายหลัก

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

สิ่งใดที่นักแปลไม่สามารถดำเนินการได้อย่างมั่นใจ จะถูกทำเครื่องหมายด้วย "// TODO(port): <reason>" เพื่อจัดการในขั้นตอนที่ 4

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

การตัดสินใจออกแบบที่สำคัญที่ควรทราบในขั้นตอนนี้คือตำแหน่งของคอมไพเลอร์ Mike รันคอมไพเลอร์ TypeScript ภายในทุกๆ ลูป เพราะมันตรวจสอบหน่วยในไม่กี่วินาที Jarred ห้ามคอมไพเลอร์ออกจากลูปโดยสิ้นเชิงและเลื่อนไปยังขั้นตอนถัดไป เพราะ cargo ใช้เวลาหลายนาที

ขั้นตอนที่ 4, 5, 6 — คอมไพล์ รัน และจับคู่พฤติกรรม

สามขั้นตอนนี้ใช้สถาปัตยกรรมลูปเดียวกันและต้องการการตัดสินใจของมนุษย์น้อยลงเรื่อยๆ ดังนั้นเราจึงครอบคลุมร่วมกัน

Jarred ดำเนินการนี้ด้วยสคริปต์ orchestrator ที่เรียกใช้คอมไพเลอร์ครั้งเดียวทั่วทั้ง workspace จากนั้น "agent แก้ไข" จะทำงานผ่านรายการข้อผิดพลาดแบบขนานพร้อมกับการทบทวนแบบ adversarial การ build ทำงานอีกครั้ง ทำซ้ำไปเรื่อยๆ

การทบทวนรายการข้อผิดพลาดมีประโยชน์ในการจับปัญหาระบบที่อาจต้องปรับเปลี่ยน ตัวอย่างเช่น Jarred พบข้อผิดพลาดโมดูล Rust หลายพันรายการที่ปรากฏขึ้นหลังจากแก้ไขการนำเข้าแบบวนซ้ำที่ Zig คอมไพล์แบบขี้เกียจยอมรับ เขาแก้ไขลูปโดยการเข้ารหัสตรรกะเพื่อจำแนกว่าจะลบ ย้าย หรือปรับโครงสร้างขอบเขตการพึ่งพาใด

ขั้นตอนที่ 5 ยังมีแหล่งความจริงแบบกลไกที่คล้ายกับรายการข้อผิดพลาดของคอมไพเลอร์: การล่มจากการทดสอบควัน (smoke test) อีกครั้ง การแก้ไขลูปคือการจัดกลุ่มปัญหาออกเป็นหมวดหมู่ ในกรณีนี้คือการจัดกลุ่มสาเหตุตามสาเหตุหลักที่ได้รับการทบทวนโดย subagent แบบ adversarial

ขั้นตอนที่ 6 และจุดสิ้นสุดของเรื่องราวของเราคือการเปรียบเทียบพฤติกรรมของโปรแกรมทั้งสองฐานโค้ด

ไฟล์ของเราได้รับการแปล คอมไพล์ และทดสอบควันแล้ว

ตอนนี้ถึงเวลาแบ่งไฟล์ออกเป็นส่วนๆ และรันชุดทดสอบ (จากขั้นตอนข้อกำหนดเบื้องต้น) กับพวกมัน จัดการความล้มเหลวด้วย "agent แก้ไข" ที่ทบทวนการทดสอบที่ล้มเหลวกับทั้งสองฐานโค้ด ผู้ตรวจสอบแบบ adversarial ตรวจสอบการแก้ไขของพวกมัน

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

แนวทางของ Mike มีความสำคัญที่นี่ เนื่องจากนักพัฒนาจำนวนมากจะไม่มีชุดทดสอบที่สร้างขึ้นหรือถูกย้าย Mike ให้ Claude สร้างสคริปต์ขนาดเล็กเพื่อรันสถานการณ์จริง 7 สถานการณ์กับทั้งโค้ดที่ย้ายใหม่และฐานโค้ด Python ดั้งเดิม และเปรียบเทียบผลลัพธ์ แต่ละสถานการณ์ที่ล้มเหลวได้รับ agent แก้ไขของตัวเอง และลูปทำงานจนกว่าทั้งเจ็ดจะผ่าน

จากนั้นเขาก้าวไปอีกขั้น Claude ออกแบบชุดทดสอบ end-to-end ของตัวเองและรันโดยอัตโนมัติข้ามคืน โดยแก้ไขสิ่งที่เสียและรันซ้ำสี่คืนติดต่อกัน ผลที่ได้คือมันจับปัญหายิบย่อยที่ไม่มีรายการสถานการณ์ใดคาดการณ์ได้

บทเรียนคือการไม่มีชุดทดสอบไม่ได้ขัดขวางขั้นตอนนี้ หากคุณไม่สามารถรับผู้ตัดสินที่สืบทอดมาได้ ให้ Claude สร้างหนึ่งให้คุณ ฐานโค้ดดั้งเดิมของคุณคือความจริงพื้นฐานไม่ว่าจะด้วยวิธีใดก็ตาม

แนวทางปฏิบัติที่ดีที่สุดสำหรับการย้ายโค้ด

แต่ละการรันสอนบางสิ่งที่การรันก่อนหน้านี้ไม่ได้สอน แต่แนวปฏิบัติบางประการยังคงใช้ได้ในทุกโปรเจกต์:

• อย่าปฏิบัติตามคู่มือนี้อย่างมืดบอด การย้ายแต่ละครั้งแตกต่างกัน ถือว่านี่เป็นจุดเริ่มต้น และวางแผนการย้ายเฉพาะของคุณกับ Claude ก่อนที่จะลงมือทำ
• อย่าโฟกัสที่ความล้มเหลวรายบุคคล ความล้มเหลวรายบุคคลเป็นงานของลูป ความสนใจของคุณควรอยู่ที่รูปแบบ
• ทำให้การทบทวนเป็นแบบ adversarial และการตรวจสอบเป็นกลไก ปล่อยให้สคริปต์ — คอมไพเลอร์, diff, ชุดทดสอบ — เป็นผู้ตัดสิน
• อย่าใช้โมเดลที่ใหญ่ที่สุดสำหรับทุกอย่าง โมเดลขนาดเล็กจัดการการกระจายงานที่มีปริมาณมากได้ดี เก็บโมเดลที่ใหญ่ที่สุดของคุณไว้สำหรับผู้ตรวจสอบและสำหรับสิ่งใดก็ตามที่เขียนกฎที่ agent อื่นจะปฏิบัติตาม
• โหลดชั่วโมงมนุษย์ไว้ล่วงหน้า กฎเกณฑ์และการทดสอบอย่างหนักเป็นสิ่งที่ใช้เวลามากที่สุด ทุกอย่างหลังจากนั้นส่วนใหญ่เป็นคิวที่ลดลง

ทบทวนผลลัพธ์ของลูป ไม่ใช่โค้ด

การย้าย Bun ของ Jarred ตอนนี้อยู่ในระบบการผลิตแล้ว แม้ว่าการย้ายทุกครั้งจะมีข้อแลกเปลี่ยน ตัวอย่างเช่น ประมาณ 4% ของโค้ด Rust อยู่ในบล็อก "unsafe" ซึ่งส่วนใหญ่เป็นการดำเนินการพอยน์เตอร์บรรทัดเดียวที่ขอบเขต C/C++

แต่ฐานโค้ดใหม่ดีขึ้นอย่าง measurable การรั่วไหลของหน่วยความจำทุกครั้งที่เครื่องมือของทีมสามารถตรวจจับได้ได้รับการแก้ไขแล้ว: เกณฑ์มาตรฐานหนึ่งของการ build 2,000 ครั้งซ้ำๆ ลดลงจาก 6,745 MB ของหน่วยความจำเหลือ 609 ไบนารีมีขนาดเล็กลง 19% บน Linux และ Windows และการเพิ่มประสิทธิภาพข้ามภาษาทำให้มันเร็วขึ้น 2–5% ในการให้บริการ HTTP และ workload ในโลกจริง เช่น next build และ tsc

เลือกฐานโค้ดที่คุณกำลังทนอยู่และถาม Claude ว่ากระบวนการย้ายสำหรับมันเป็นอย่างไร