مهاجرت کد در مقیاس میلیونی با ایجنتهای Claude Code
هوش مصنوعیخلاصهٔ کاملتر
تو بلاگ آنتروپیک اومده که مهاجرت کد — پورت کردن یه کدبیس پروडاکشن به زبون دیگه — تا همین اواخر پروژهای چندساله بود، ولی تو یه ماه گذشته مهندسهای خود شرکت ۱۰ پکیج با دهها تا صدها هزار خط کد رو با Claude Fable 5، Claude Opus 4.8 و dynamic workflows پورت کردن.
شاخصترین نمونه مال جرد سامنر، همبنیانگذار Bun ـه که Bun رو از Zig به Rust برد: یک میلیون خط کد در کمتر از دو هفته، با قبولی صددرصدی مجموعه تست موجود تو CI قبل از مرج. بعد از مرج ۱۹ رگرسیون پیدا شد که همهشون رفع شدن. نمونهٔ دوم مال مایک کریگره که یه کدبیس پایتون رو تو یه آخر هفته به ۱۶۵ هزار خط تایپاسکریپت برد، با صدها ایجنت، هشت گیت مرحلهای و سه دور بازبینی تخاصمی.
نویسنده میگه حالا دیگه لازم نیست دلیل مهاجرت وجودی و حیاتی باشه؛ یه سال وصله زدن به باگهای حافظه یا یه گلوگاه مزمن کافیه. انگیزهٔ مایک مرحلهٔ کامپایل بود: ساخت باینری با ابزار پایتون حدود هشت دقیقه برای هر پلتفرم طول میکشید، یعنی ۳۰ دقیقه انتظار تو هر ریلیز؛ بعد از پورت، همون کامپایل حدود دو ثانیه شد و باینری ۶ برابر سریعتر بالا میاد.
البته هزینه صفر نیست: مهاجرت Bun حدود ۵.۹ میلیارد توکن ورودی کشنشده و ۶۹۰ میلیون توکن خروجی مصرف کرد که با قیمت API حدود ۱۶۵ هزار دلار میشه. در مقابل، برآورد قدیمی برای همچین پروژهای ۳ تا ۴ میلیون دلار طی چهار سال بود و بدترین سناریوی امروز اینه که برنچ رو پاک کنی و از نو شروع کنی.
به گفتهٔ نویسنده، این کار برای مدلهای جدید مناسبه چون ذاتاً موازیه، کد قدیمی خودش بهترین اسپکه، مجموعه تست نقش داور عینی رو بازی میکنه و صف کار خودشو مینویسه: هر خطای کامپایلر یا تست شکستخورده میشه آیتم بعدی. پیشنیاز کل ماجرا هم داشتن یه داور معتبره — تستهایی که هم روی کد اصلی هم روی پورت اجرا میشن، و باید روی کد عمداً خراب هم شکست بخورن وگرنه داور نیستن.
قدم اول ساختن قانوننامه، نقشهٔ وابستگی و فهرست شکافهاست؛ ترتیبش مهمه چون فهرست شکاف رو دقیقاً چیزی تعریف میکنه که پیشفرضهای قانوننامه پوشش نمیدن. شکاف Zig به Rust مدیریت دستی حافظه بود و شکاف پایتون به تایپاسکریپت، قرارداد و اینترفیس. قدم دوم یه مهاجرت کوچیک آزمایشیه: جرد سه فایل رو با قانوننامه و سه فایل رو «مثل یه مهندس ارشد Rust» ترجمه کرد و از تفاوتشون قانون جدید ساخت — و همونجا دو مشکل بحرانی رو قبل از پخش شدن روی ۱۴۴۸ فایل گرفت. فایلهای این مرحله دور ریخته میشن.
از قدم سوم به بعد همهچی یه حلقهٔ چندایجنتیه: پیادهسازی، بازبینی، رفع. کار حجیم ترجمه رو میشه به مدلهای کوچیکتر سپرد — مایک برای فناوت اصلی از Sonnet با ۱۲ سابایجنت استفاده کرد — و مدل بزرگ رو برای بازبینها و هر چیزی که قانون مینویسه نگه داشت. صف کار باید مکانیکی باشه: «انجامشده» یعنی فایل خروجی روی دیسک هست، برای همین کل مهاجرت ذاتاً از سر گرفتنیه. دو بازبین تخاصمی با کانتکست جدا کار پیادهسازها رو میسنجن و اختلافشون میره پیش ایجنت سوم.
قدمهای چهارم تا ششم — کامپایل، اجرا و تطبیق رفتار — همون معماری حلقه رو دارن و به قضاوت انسانی کمتری نیاز دارن. نکتهٔ کلیدی اینه که وقتی یه بازبین مدام یه اشتباه رو تو فایلهای مختلف میگیره، راهحل وصله زدن به تکتک فایلها نیست: یه جمله به قانوننامه اضافه میکنی و همون بچ رو از نو تولید میکنی. نتیجهٔ نهایی برای Bun هم قابل اندازهگیریه: مصرف حافظه تو یه بنچمارک ۲۰۰۰ بیلدی از ۶۷۴۵ مگابایت به ۶۰۹ رسید، باینری روی لینوکس و ویندوز ۱۹٪ کوچیکتر شد و ۲ تا ۵ درصد سرعت بیشتر گرفت — هرچند حدود ۴٪ کد Rust هنوز داخل بلوکهای unsafe ـه.
نکات کلیدی:
- ایدهٔ مرکزی: کد رو دستی درست نکن، حلقهای که کد رو تولید کرده اصلاح کن
- بدون داور معتبر شروع نکن؛ داوری که خرابی رو نگیره داور نیست
- قانوننامه و تست فشار، وقتگیرترین و انسانیترین بخش کارن؛ بقیه صفسوزیه
- بازبینی تخاصمی باشه و راستیآزمایی مکانیکی: کامپایلر، دیف و تست داورن
- برای همهچی از بزرگترین مدل استفاده نکن؛ مدل بزرگ برای بازبین و قانوننویسی
- صف کار باید مکانیکی و از سر گرفتنی باشه: «انجامشده» یعنی فایل روی دیسک هست
- نبود مجموعه تست مانع نیست؛ میشه با چند سناریوی واقعی و دیف گرفتن از خروجی، داور ساخت
