فرآیند بازنویسی چگونه انجام شد
Anthropic در دسامبر ۲۰۲۵ شرکت Bun را خریداری کرد و تصمیم گرفت پایگاه کد Zig خود را با Rust جایگزین کند. این شرکت نسخه پیشانتشار Claude Fable 5 را اجرا کرد—یک LLM که در آن زمان در دسترس هیچکس دیگری نبود. ۶۴ نسخه از این مدل بهصورت موازی کار میکردند و در مجموع حدود ۱۳۰۰ خط کد در دقیقه تولید میکردند.
مهندس ارشد، Jarred Sumner، مسئله را به عاملها (agents) واگذار نکرد و کنار نرفت. او ابتدا ساعتها وقت صرف تدوین راهنمایی کرد که اصطلاحات Zig را به معادلهای Rust نگاشت میکرد. یک اجرای آزمایشی با سه فایل به او اجازه داد تا پیش از پرداختن به کل مخزن (repository)، خروجی عاملها را کالیبره کند. برای هر تغییری که عاملها پیشنهاد میدادند، دو عامل «خصمانه» (adversarial) آن را بازبینی میکردند و Sumner تمام این فرآیند را در طول ۱۱ روز بهصورت زنده زیر نظر داشت.
حسابداری داخلی Anthropic مبلغ ۱۶۵,۰۰۰ دلار هزینه مصرف توکن را ثبت کرد. این رقم تنها نشاندهنده فراخوانیهای خام API است که پیش از ادغام کد در شاخه اصلی (main branch) انجام شده است.
هزینههای پنهان
عدد ۱۶۵ هزار دلاری، هزینه محاسباتی (compute) مورد نیاز برای پایدارسازی کد جدید Rust را نادیده میگیرد. طبق یک تحلیل داخلی، اصلاحات پس از ادغام، اجراهای یکپارچهسازی مداوم (CI) و تستهای اضافی میتواند کل هزینهها را افزایش دهد. این برآورد از قیمتگذاری عمومی API استفاده میکند؛ از آنجایی که Claude Fable 5 یک پیشنمایش خصوصی بود، قیمت واقعی پرداختشده ممکن است متفاوت باشد.
سرعت در برابر ایمنی
این بازنویسی یک زماناجرای (runtime) Rust تولید کرد که سریعتر از نسخه اصلی Zig است، اما در عین حال حجم قابلتوجهی از کارهای بازبینی (audit backlog) را نیز به جای گذاشت. حدود ۴٪ از فایلهای Rust جدید شامل بلوکهای «unsafe» هستند—کدهایی که تضمینهای سختگیرانه ایمنی Rust را دور میزنند. پروژههای Rust که بهصورت دستی نوشته میشوند معمولاً درصد بسیار کمتری دارند، به این معنی که بازبینها اکنون باید تأیید کنند که آن بلوکها باعث بروز باگهای فساد حافظه (memory-corruption) نمیشوند.
خروجی عاملها بدون تخصص Sumner بیمعنا بود. حتی با سرعت ۱۳۰۰ خط در دقیقه، کد به یک ناظر آگاه نیاز دارد تا خطاهای منطقی را شناسایی کند، انسجام معماری را تضمین نماید و تأیید کند که مجموعه تستها واقعاً پیادهسازی جدید را پوشش میدهند.
زمانی که هوش مصنوعی میدرخشد و زمانی که نمیدرخشد
پورت کردن Bun یک ترجمه نمونه و کلاسیک بود: انتقال از یک زبان به زبان دیگر، در حالی که یک مجموعه تست جامع از قبل آماده بود. این مرز مشخص، هدف روشنی را در اختیار LLM قرار داد و نیاز به حل مسئله خلاقانه را محدود کرد. با این حال، بیشتر کارهای نرمافزاری شامل تغییر قوانین تجاری، مدیریت الزامات مبهم یا ساخت ویژگیهای جدید از صفر است. در آن سناریوهای پیچیدهتر، بعید است که همان سطح از کمک هوش مصنوعی، سرعت یا مزایای هزینه مشابهی ایجاد کند.
طرفداران توسعه تقویتشده با هوش مصنوعی به اعداد خام بهرهوری—تولید هزاران خط کد در چند دقیقه—به عنوان مدرکی بر اینکه مدلهای زبانی بزرگ میتوانند جایگزین تیمهای بزرگ شوند، اشاره میکنند. مورد Anthropic این دیدگاه را تعدیل میکند: هزینه اصلی توکنها، محاسبات قابلتوجه مورد نیاز برای اعتبارسنجی پس از ادغام را شامل نمیشود و بدهی ایمنی ایجاد شده توسط کدهای «unsafe»، برای حل شدن به تلاش انسانی نیاز خواهد داشت.
آنچه باید در آینده زیر نظر داشت
Anthropic فاش نکرده است که آیا قصد دارد همان گردش کار مبتنی بر Claude را برای سایر پایگاههای کد اعمال کند یا خیر. اگر چنین شود، شرکت باید هزینه کل چرخه حیات را در نظر بگیرد، نه فقط صورتحساب توکنها را. ناظران باید موارد زیر را زیر نظر داشته باشند:
- چقدر سریع حجم کارهای بازبینی کاهش مییابد و آیا با بازنویسی (refactor) کد توسط بازبینها، نسبت بخشهای «unsafe» کاهش مییابد یا خیر.
- آیا اجراهای آینده از مدل بالغتری استفاده میکنند که بهصورت عمومی قابل خرید باشد، که میتواند برآوردهای هزینه را شفافتر کند.
- تأثیر بر پذیرش Bun: زماناجراهای سریعتر ممکن است کاربران را جذب کند، اما هرگونه نگرانی امنیتی میتواند این دستاورد را خنثی کند.
نتیجهگیری
هوش مصنوعی میتواند ترجمه کدهای مستقیم را با سرعت بسیار بالا انجام دهد، اما هزینههای محاسباتی پاییندستی و تأیید انسانی میتواند صرفهجویی حاصل از صورتحساب توکن را از بین ببرد. بازنویسی Bun نشان میدهد که اگرچه مدلهای زبانی بزرگ میتوانند حجم عظیمی از کد را بهسرعت تولید کنند، اما تخصص انسانی برای ایمنی، صحت و کارهای ظریفی که پیشران اکثر پروژههای نرمافزاری هستند، همچنان ضروری است.
