تصور کنید مدیری هستید که می‌خواهد تمام زیرساخت فنی شرکتش را فقط برای اینکه «سریع‌تر» باشد، به یک زبان جدید منتقل کند، بدون اینکه بداند چرا کد قبلی خراب بود. این دقیقاً همان gamble یا قماری است که Anthropic در بازنویسی Bun انجام داده است.
این شرکت با جذب سرمایه‌گذاری ۱۳۲ میلیارد دلاری و ارزش احتمالی بیش از ۱ تریلیون دلار در زمان عرضه اولیه (IPO)، روی این ادعا شرط‌بندی کرده که هوش مصنوعی می‌تواند جایگزین مهندسی نرم‌افزار شود. طبق گزارش‌های تحلیل‌گران، این روایت صرفاً یک پیش‌بینی فنی نیست، بلکه یک ضرورت تجاری است؛ چراکه شرکت در حال حاضر نمی‌تواند سودآوری خود را ثابت کند و در نتیجه، ارزش‌گذاری آن به فروش «آینده‌ای فرضی» از تأثیر مدل‌هایش وابسته است. آن‌ها در حال انجام یک کمپین گسترده هستند تا مدیران ارشد (C-Suite)، رهبران جهان و مدیران صندوق‌های بازنشستگی را متقاعد کنند که کدنویسی در حال ناپدید شدن است و پس از آن، سایر بخش‌های مهندسی نرم‌افزار و در نهایت، اکثر مشاغل انسانی از بین خواهند رفت. این رویکرد تهاجمی در جایگزینی انسان با AI با استراتژی‌های متفاوتی مانند طرح‌های حمایتی برای ارتقای سواد AI در سازمان‌ها را به چالش می‌کشد که سعی دارند پلی میان توانمندی‌های فعلی و نیازهای آتی ایجاد کنند.
از منظر ادبی، Anthropic مانند یک «راوی غیرقابل اعتماد» عمل می‌کند. وقتی این مقدار سرمایه پشت یک داستان خاص قرار می‌گیرد، فارغ از اینکه آن داستان حقیقت داشته باشد یا خیر، تأثیرات واقعی در دنیای فیزیکی ایجاد می‌کند. مردم تصمیمات مربوط به معماری، محصول و استخدام خود را بر اساس این روایت‌ها می‌گیرند. بسیاری از این تصمیمات در حال حاضر تحت تأثیر ترس هستند؛ ترس از تعدیل نیرو یا هشدارهای «رستاخیصی» مبنی بر اینکه مبادا از قافله عقب بمانند (Left Behind) و همچنین تأثیر «ترول‌های فناورانه» (Doom Trolling). برای تصمیم‌گیری درست، ما به تفکر شفاف نیاز داریم، چیزی که در چرخه فعلی هیجانات (Hype Cycle) بسیار دشوار است.
من این تحلیل را از جایگاه غوطه‌وری حرفه‌ای ارائه می‌دهم. به مدت سه سال، تمرکز شغلی من بر سواد عمومی در مورد AI در نرم‌افزار و بهبود خود این فناوری بوده است. نیمی از این مدت، من به عنوان معمار ارشد (Chief Architect) یک استارتاپ عامل‌های کدنویسی فعالیت می‌کردم. این جایگاه باعث شد من همزمان هم مشتری مدل‌های Anthropic باشم و هم رقیب مستقیم برای عامل آن‌ها یعنی Claude Code. پروژه فعلی من نیز The Coding Agency است.
این روایت زمانی با یک تست استرس عمومی مواجه شد که جزئیات مربوط به مهاجرت Runtime مدل Bun از زبان Zig به Rust برملا شد. با تکیه بر پوشش قبلی ما در مورد نحوه دیباگ کردن Claude Code، این وضعیت یک تنش رو به رشد را برجسته می‌کند: آیا هوش مصنوعی واقعاً در حال حل مسائل پیچیده مهندسی است یا صرفاً در حال ایجاد یک خط لوله با سرعت بالا برای تولید «بدهی فنی» (Technical Debt) است؟ برای یک رهبر کسب‌وکار متوسط، این تفاوت معادل تفاوت بین یک محصول مقیاس‌پذیر و یک «کارخانه نرم‌افزاری تاریک» است که با سرعتی بی‌سابقه، کدهایی پر از باگ تولید می‌کند.
بازنویسی بزرگ
Bun، یک محیط اجرای TypeScript با کارایی بالا که به عنوان جایگزینی سریع‌تر برای NodeJS طراحی شده است، در ابتدا با زبان Zig (یک زبان برنامه‌نویسی سیستمی شبیه به نسخه مدرن C) نوشته شده بود. Bun یکی از بزرگ‌ترین پایگاه‌های کد (Codebase) در زبان Zig بود. ادعا می‌شود که Bun تقریباً ۱۰۰٪ از مشارکت‌های کدنویسی خود را به AI مدیون است، در حالی که فلسفه اصلی زبان Zig اجازه ۰٪ مشارکت AI را می‌دهد.
پس از تصاحب توسط Anthropic (آزمایشگاه پیشرو در مدل‌های AI)، تیم Bun یک بازنویسی گسترده‌ی عامل‌محور (Agentic Rewrite) را برای انتقال کد از Zig به «Rust ناامن» (Unsafe Rust) اجرا کرد. طبق گزارشی از raymyers.org، این مهاجرت در مه ۲۰۲۶ با خط اصلی کد ادغام شد، اما توضیحات رسمی دو ماه بعد منتشر گشت. این فاصله زمانی اجازه داد تا تیترهای خبری، این اتفاق را به عنوان پیروزی سرعت AI قاب‌بندی کنند. رسانه‌هایی مانند The Register داستان‌هایی با عناوینی چون «بازنویسی Rust در Bun با سرعت AI ادغام شد» منتشر کردند و بر جنبه‌های خیره‌کننده و «بسیار سرمایه‌گذاری شده» این دستاورد تأکید کردند.
در یک پروژه زیرساختی، توضیح مسیر حرکت پیش از ادغام کد (Merge) یک رویکرد سنتی و درست است، اما این تأخیر اجازه داد تیترهای «جذاب‌تر» زده شود. این زمان‌بندی برای پیشبرد روایت Anthropic راحت بود و به جای یک بحث فنی، یک نمایش (Spectacle) ایجاد کرد. در پاسخ، اندرو کلی، خالق Zig، نقدی تند و صریح منتشر کرد. در حالی که برخی واکنش او را یک «از کوره در رفتن» (Meltdown) نامیدند، برخی دیگر از جمله من، آن را تحسین کردیم. او آداب «سخن درست» را کنار گذاشت تا وارد محدوده «حقیقت‌های تلخ» شود و روندی مشکل‌ساز را افشا کند.
تضاد روایت‌ها
سه تفسیر متمایز از این اتفاق ظهور کرده است که قضاوت بنیان‌گذار Bun (جارد سامنر) را در مقابل دیدگاه‌های اندرو کلی قرار می‌دهد:
- روایت Anthropic: Bun تمام مسیرهای معقول را امتحان کرد، اما تیم همچنان با باگ‌های حافظه دست و پنجه می‌زد چون Zig اساساً برای این وظیفه مناسب نبود.
- روایت اندرو کلی (خالق Zig): کد Bun به دلیل تصمیمات مهندسی ضعیف به یک آشفتگی تبدیل شد. این شامل اتکای سیستماتیک بیش از حد به عامل‌های AI برای نوشتن و بازبینی تقریباً ۱۰۰٪ مشارکت‌هاست.
- روایت تجاری: مدیریت در مواجهه با باگ‌های واقعی حافظه، چندین گزینه پیش رو داشت. آن‌ها با اشتیاق بازنویسی به Rust را تأیید کردند زیرا این کار ویترینی عالی برای نمایش قدرت مدل جدیدشان به نام Fable بود. این مدل به دلیل توانمندی‌های گسترده، حتی در لایه‌های امنیتی، مورد توجه دولت‌ها قرار گرفته و برخی از آن به عنوان تهدیدی برای امنیت ملی یاد کرده‌اند. علاوه بر این، Anthropic در حال حاضر از Rust استفاده می‌کند و Zig آشکارا با استفاده از محصولات Anthropic مخالف است. این یک تصمیم تجاری بود که لباس ضرورت فنی به تن کرد.
از دیدگاه بازاریابی، داستان باید بر این تمرکز می‌کرد که AI آن‌ها آن‌قدر قدرتمند است که می‌تواند این بازنویسی را انجام دهد، حتی اگر همان AI نتواند یک باگ ساده از نوع use-after-free را شناسایی کند. این وضعیت باعث می‌شود هر اغراق برای حفظ ظاهر که از بلندگوی Anthropic پخش شود، بتواند ناخواسته به شهرت Zig آسیب بزند. جارد سامنر در میانه این بحث‌های متا قرار گرفته است، جایی که Anthropic از اعتبار او برای فروش یک روایت گسترده‌تر درباره توانمندی‌های AI استفاده می‌کند.
شکست‌های مکانیکی و راهنمای سبک (Style Guides)
یکی از توجیه‌های اصلی برای بازنویسی، حضور مکرر باگ‌های حافظه بود (تقریباً چهار کامیت اصلاحی در هفته). در هر تصمیم فنی، باید انگیزه، گزینه‌های بررسی شده و مزایا و معایب را دید. این رویکرد در تصمیم ریچارد فلدمن برای انتقال کامپایلر Roc از Rust به Zig دیده شد که تحلیلی منطقی از Trade-offها ارائه داد.
در حالی که گزارش Bun انگیزه‌ها را پوشش داد، اما در ارائه مقایسه واقعی مزایا و معایب شکست خورد. برای مثال، تیم تأثیر بر زمان‌های ساخت (Build Times) را نادیده گرفت؛ معمولاً انتخاب Rust برای یک codebase بزرگ به معنای خرید امنیت در ازای پرداخت هزینه‌ی کامپایل کندتر است. Bun قبلاً کامپایلر Zig را فقط برای بهبود سرعت ساخت فورک (Fork) کرده بود، اما افشا نکرد که آیا پورت Rust این زمان‌ها را افزایش داده است یا خیر. آن‌ها همچنین فهرست بهبودهای خود را با گنجاندن تغییرات نامرتبطی که بعد از بازنویسی اعمال شد (مانند اجرای یک راهنمای سبک یا Style Guide که قبلاً سعی در اجرای آن نداشتند) پر کردند.
پروژه‌های بزرگ دیگر در زبان Zig از طریق فلسفتهای مهندسی سخت‌گیرانه از این مشکلات اجتناب می‌کنند:
جایگزین‌های مهندسی:
- TigerBeetle: یک پایگاه داده تراکنش مالی که یکی از قابل‌اعتمادترین‌ها در جهان است. آن‌ها از طریق رویکرد «TigerStyle» و استراتژی‌های نوآورانه تست، از باگ‌های حافظه اجتناب می‌کنند.
- اصول TigerStyle:
- تمام حافظه باید در هنگام شروع برنامه به صورت استاتیک تخصیص یابد.
- هیچ حافظه‌ای نباید پس از مقداردهی اولیه به صورت دینامیک تخصیص، آزاد یا بازتخصیص یابد.
- این کار از رفتارهای غیرقابل پیش‌بینی جلوگیری کرده و خطاهای use-after-free را حذف می‌کند.
- این منجر به طراحی‌های ساده‌تر و performantتر می‌شود که نگهداری و استدلال درباره آن‌ها راحت‌تر است.
- نمونه گوگل: گوگل یک راهنمای سبک ۳۱,۰۰۰ کلمه‌ای برای C++ دارد تا پیچیدگی‌های مشابه را مدیریت کند.
تیم Bun در گزارش خود استفاده از راهنماهای سبک را رد کرد و مدعی شد که اجرای آن‌ها بیش از حد دشوار است. این ادعا از نظر منطقی متناقض است. تیم همزمان ادعا کرد که از عامل‌های AI برای اجرای دستورالعمل‌های مهاجرت (که در فایل PORTING.md آمده بود) در طول بازنویسی استفاده کرده است. اگر بازبینی عامل‌محور می‌تواند یک راهنمای مهاجرت را برای یک بازنویسی میلیون‌خطی اجرا کند، می‌توانست یک راهنمای سبک مدیریت حافظه را نیز اجرا کند. این نشان می‌دهد آن‌ها بیشتر از آنکه به دنبال «بازمعماری» (Re-architecture) باشند، هیجان‌زده‌ی «بازنویسی» (Rewrite) بوده‌اند.
تله ارگونومی
تیم Anthropic استدلال کرد که برخی الگوهای Zig (مانند انتقال صریح اشاره‌گرها یا Pointer Handoffs) بیش از حد دست‌وپاگیر هستند و به خوانایی آسیب می‌زنند. آن‌ها مثالی زدند که در آن یک راهنمای سبک سخت‌گیرانه مستلزم استفاده از wrapperهای SharedPtr و فراخوانی‌های صریح .get() و .deref() است که چندین خط کد اضافه می‌کند (مثلاً fn foo(a_ptr: SharedPtr(TCPSocket)) !void) در حالی که در اصطلاحات استاندارد Zig ساده‌تر است (fn foo(a: *TCPSocket) !void).
این موضوع یک پارادوکس برای جنبش «اول-هوش مصنوعی» ایجاد می‌کند:
۱. شرکت ادعا می‌کند انسان‌ها دیگر نیازی به تایپ کد ندارند، زیرا عامل‌ها کار را انجام می‌دهند. در واقع، آن‌ها اعلام کرده‌اند که ماه‌هاست خودشان کدی تایپ نکرده‌اند.
۲. با این حال، آن‌ها علیه چند خط کد اضافی استدلال می‌کنند چون ممکن است چشم خواننده انسانی را اذیت کند.
اگر کد دیگر برای انسان‌ها نیست، خوانایی بی‌معنی است. و اگر هنوز برای انسان‌هاست، پس روند فعلی ارسال Pull Requestهای میلیون‌خطی تولید شده توسط AI که هیچ انسانی نمی‌تواند به طور معقول بازبینی کند، یک فاجعه معماری است. نگرانی برای «ارگونومی» یک راحتی است که با پیش‌گویی آن‌ها مبنی بر پایان مهندسی نرم‌افزار در تضاد است. آن‌ها در این مورد مبهم پاسخ می‌دهند زیرا قابلیت نگهداری (Maintainability) با روایتی که در آن AI جایگزین مهندس می‌شود، ناسازگار است. این تناقض بین نیاز به ارگونومی انسانی و اتوماسیون کامل، دقیقاً همان جایی است که شهود و تجربه مهندسین ارشد در برابر مهارت‌های جونیور اهمیت حیاتی پیدا می‌کند؛ چرا که تشخیص کیفیت معماری همچنان فراتر از توانایی‌های فعلی مدل‌هاست.
هزینه انسانی
فراتر از کد، فرهنگ داخلی در Bun به عنوان یک «سایش» یا Grind توصیف شده است. هشدارهای جذب نیروی اولیه در سال ۲۰۲۲ صراحتاً به کاندیداها می‌گفت که «Oven (تیم Bun) قرار است یک محیط سخت و فرسایشی باشد»، به ویژه در نه ماه اول، و کسانی که اولویتشان تعادل بین کار و زندگی (Work-Life Balance) است، احتمالاً گزینه مناسبی نیستند. این فرهنگ «زمان فشار» (Crunch Time) که با هفته‌های کاری ۹۰ ساعته شناخته می‌شود، طبق بخش عوامل انسانی در کتاب Empirical Software Engineering نوشته هیلل، یک شکست قطعی در کارهای دانش‌محور است.
پاسخ اندرو کلی به این وضعیت صریح بود و تجربه تیم Bun را یک «نمایش افتضاح» (Total Shit Show) توصیف کرد که شامل ارتباطات ضعیف، انتظارات غیرواقع‌بینانه، همدلی پایین و فقدان تجربه بود. در حالی که برخی این را «از کوره در رفتن» نامیدند، این یک نقد لازم است. همانطور که دکس (Dax) اشاره کرد، وقتی رهبر یک زبان به این شکل به یک codebase واکنش نشان می‌دهد، تکان‌دهنده است. با این حال، این نقد به ایده‌آل‌های «تک‌برادرهای فناوری» (Tech Bro) حمله می‌کند که تصور می‌کنند میان‌بر زدن یک ترفند برای بهره‌وری است. این ترتیب برای کسانی که بابت اصلاح نتایج چنین محیط‌هایی پول می‌گیرند سودآور است، اما برای سلامت مهندسین درگیر در آن مضر است.
معنای این اتفاق برای صنعت
این رویداد نشان می‌دهد که اگرچه عامل‌های AI می‌توانند عمل مکانیکی پورت کردن کد را انجام دهند، اما نمی‌توانند جایگزین «قضاوت انتقادی» شوند. انتخاب زبان Rust یک توری نجات (Safety Net) فراهم کرد — یعنی borrow-checker — که عامل‌های AI فاقد آن هستند. در واقع، Bun از یک زبان امن‌تر استفاده کرد تا بی‌ثباتی منطق تولید شده توسط AI را جبران کند.
همانطور که عامل‌ها به ما اجازه می‌دهند حرکات بیشتری با کدهای قدیمی انجام دهیم، می‌توانیم از تکنیک‌های خودکار استفاده کنیم، اما همچنان به نوعی قضاوت نیاز داریم که در کتاب‌هایی مانند Kill It With Fire اثر ماریان بلوتی یافت می‌شود. وضعیت فعلی اتوماسیون بازنویسی می‌تواند با «متدهای رسمی» (Formal Methods) یا تحقیقاتی مانند برنامه TRACTOR دارپا (ترجمه تمام کدهای C به Rust) که گزارش خود را امسال منتشر کرد، تقویت شود.
روند فعلی، جایگزینی مهارت با توکن است:
- به جای یادگیری مهارت‌ها، یک فایل
SKILL.mdرا کپی می‌کنیم. - به جای مطالعه روان‌شناسی تیم‌های نرم‌افزاری، جلسات موازی عامل‌ها را «تیم» می‌نامیم.
- نگهدارندگان متن‌باز (Open Source) اکنون غرق در تفکیک مشارکت‌های مفید از «آشغال‌های AI» (AI Slop) کم‌تلاش هستند.
من در حین تحقیق روی این موضوع و با استفاده از یک رویکرد ترکیبی (پروژه Bunsen)، دقیقاً به همین دلیل که AI کافی نیست، ۵۰ باگ در نسخه Zig شرکت Bun پیدا کردم. برای کسانی که گذار به AI را مدیریت می‌کنند، درس روشن است: توکن‌ها جایگزین مهارت نمی‌شوند. تکیه بر بازبینی‌های عامل‌محور بدون یک فلسفه مهندسی سخت‌گیرانه تحت هدایت انسان — مانند آنچه در TigerBeetle دیده شد — صرفاً باگ‌ها را از کامپایلر به زمان اجرا (Runtime) منتقل می‌کند. در حباب AI، ما تحت فشار هستیم تا چیزهایی بسازیم که هیچ‌کس نمی‌خواهد، و آن هم به شکلی ضعیف. ما باید این حباب را بترکانیم و به ساخت چیزهایی بازگردیم که مردم واقعاً می‌خواهند، و آن‌ها را به درستی بسازیم.
گام بعدی شما
- اگر در حال مدیریت مهاجرت کد با AI هستید، به جای بازنویسی کامل، متدهای رسمی (Formal Methods) را برای اعتبارسنجی بررسی کنید.
- استانداردهای سخت‌گیرانه حافظه (مانند TigerStyle) را جایگزین تکیه بر ابزارهای بررسی خودکار کنید.
- به یاد داشته باشید که توکن‌ها جایگزین مهارت نمی‌شوند؛ نظارت انسانی روی معماری کلید بقای محصول است.
اما چالش‌های سخت‌افزاری در اجرای این مدل‌های عظیم حتی پیچیده‌تر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو