تصور کنید مهندسی که تنها نقش معمار را دارد و هرگز یک خط کد را بازبینی نمی‌کند، اما در نهایت یک زبان برنامه‌نویسی کامل و یک بازی کلاسیک را تحویل می‌گیرد. این دقیقه‌ی همین اتفاقی است که در پروژه bet رخ داد و مرز بین «نوشتن تکه‌های کد» و «ساخت سامانه‌های پیچیده» را جابه‌جا کرد.
در ۱۶ ژوئیه ۲۰۲۶، این پروژه به عنوان یک اثبات مفهوم (Proof-of-Concept) منتشر شد تا نشان دهد عامل‌های هوش مصنوعی (AI Agents) — که شبیه دستیارهای متخصصی هستند که می‌توانند به‌طور مستقل برنامه‌ریزی کرده و ابزارها را اجرا کنند — در پروژه‌های معماری سنگین و با مشخصات دقیق، زمانی که انسان از پیاده‌سازی فاصله بگیرد، تا چه حد پیش می‌روند. طبق گزارش منتشر شده در betlang.dev، این زبان برخلاف بسیاری از زبان‌های تفننی (Joke Languages) که صرفاً پوسته‌ای برای ترجمه به زبان‌های دیگرند، یک زبان میزبانی شخصی (Self-hosting) است و دارای یک کامپایلر جدی است که از طریق LLVM کد بومی (Native Code) تولید می‌کند. در این فرآیند، سازنده صرفاً به عنوان یک معمار عمل کرد؛ او معیارهای پذیرش و تست‌ها را تعیین کرد اما هیچ بازبینی دستی کدی انجام نداد. یک تغییر تنها زمانی ارسال می‌شد که تمام تست‌های خود را پاس کرده، با معیارهای پذیرش مطابقت داشته باشد و از فیلتر مجموعه داده‌های مرجع (Corpus) عبور کند.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی پایداری کد تولید شده توسط مدل‌های زبانی اشاره کردیم، چالش اصلی همیشه در مقیاس‌بندی و حفظ منطق در پروژه‌های بزرگ بوده است. در bet، سازنده صرفاً معیارهای پذیرش و تست‌ها را تعریف کرد؛ هر تغییر تنها زمانی اعمال می‌شد که تمام تست‌ها را پاس کرده و با مجموعه داده‌های مرجع مطابقت داشت.
فلسفه و ریشه‌های پروژه
به نقل از سازنده، این پروژه در دوران استراحتی از تلاش برای ساخت محصولات تجاری آغاز شد. او به دنبال پروژه‌ای بود که «مرزهای مشخصی» داشته باشد تا بتوان آن را واقعاً به پایان رساند و از آن‌جا که ساخت یک کامپایلر مدت‌ها بود در لیست علاقه‌مندی‌های او قرار داشت، تصمیم به این کار گرفت. برای اینکه پروژه جذاب‌تر شود، وی یک ظاهر «تفننی» برای آن انتخاب کرد: کلمات کلیدی زبان به گونه‌ای طراحی شدند که گویی در حال خواندن یک چت گروهی هستید.
برای محافظت از چشم‌انداز اصلی و اصالت ایده، سازنده یک قانون سختگیرانه را دنبال کرد: عدم تحقیق. او هرگز بررسی نکرد که آیا زبان‌های مشابهی وجود دارند یا خیر و این کار را تنها پس از تکمیل کامل پروژه انجام داد. در این مرحله بود که او متوجه شد جفری هانتلی (Geoffrey Huntley) پیش از این چیزی مشابه ساخته بود. این استراتژی تضمین کرد که پروژه به جای اینکه یک تکرار تحت تأثیر جریانات اینترنت باشد، بیان خالص و مستقیم ایده‌ی اولیه سازنده باقی بماند.
جزئیات فنی: سیستم Arena
برای اینکه bet بتواند نرم‌افارهای واقعی و سطح بالا را اجرا کند، سازنده بر روی یک مسئله حیاتی در عملکرد بالا تمرکز کرد: مدیریت حافظه. در حالی که روش‌های سنتی جمع‌آوری زباله (Garbage Collection) یا حسابداری دستی حافظه می‌تواند باعث افت فریم (Frame Drop) در بازی‌ها شود، bet مفهومی به نام «cribs» را پیاده‌سازی می‌کند؛ این‌ها در واقع تخصیص‌دهنده‌های Arena هستند که محدوده آن‌ها به یک تک‌فریم محدود شده است.
- سازوکار: با استفاده از یک کلمه کلیدی اختصاصی به نام
evictاست، زبان می‌تواند کل محدوده حافظه را در زمان ثابت O(1) آزاد کند. - کارایی: با اجتناب از ردیابی تک‌تک اشیاء، هیچ توقفی در میانه یک فریم رخ نمی‌دهد و اجرای برنامه روان می‌ماند.
- زمینه: اگرچه زبان‌هایی مانند Zig و Odin از الگوهای مشابه Arena و Temp-allocator استفاده می‌کنند، اما bet این قابلیت را به عنوان یک ویژگی درجه‌یک (First-class feature) با کلمات کلیدی مخصوص خود تعریف کرده است تا این سیستم به عنوان یک طراحی متمایز به نظر برسد و نه صرفاً یک تغییر پوسته.
آزمون سخت: بازسازی DOOM
سخت‌ترین و دقیق‌ترین محک برای اعتبارسنجی این فرآیند هدایت‌شده توسط هوش مصنوعی، پورت کامل سورس‌کد اصلی زبان C شرکت id Software بود. این تلاش عظیم شامل بازنویسی بیش از ۵۶,۰۰۰ خط کد بود که بخش‌های رندرینگ (Renderer)، منطق بازی، سیستم بارگذاری فایل‌های WAD و سیستم‌های صوتی را پوشش می‌داد.
به دلیل اینکه شبیه‌سازی بازی بر پایه محاسبات ممیز ثابت (Fixed-point math) است، دقت در این سطح حیاتی است؛ زیرا حتی انحراف در یک گام محاسباتی باعث می‌شود بازیکن به جای حرکت در مسیر، به دیوارها برخورد کند. به جای تکیه بر شانس، bet ورودی‌ها را دقیقاً هم‌گام (Lockstep) با نسخه مرجع C بازپخش می‌کند؛ یعنی فریم به فریم، تا شبیه‌سازی بیت‌به‌بیت یکسان باشد. این موضوع با اجرای بازی در حالت Attract Mode به نمایش گذاشته شد، جایی که ورودی‌های ضبط‌شده اصلی به‌طور کامل و بدون خطا از طریق شبیه‌سازی بازپخش شدند.
تحلیل زمان‌بندی تلاش (Effort)
بررسی گزارش زمانی پروژه (Timelog) که زمان‌های بیکاری را حذف کرده و تنها تلاش فعال را محاسبه کرده است، حجم بالای کار را آشکار می‌کند. مجموع تلاش عملیاتی حدود ۲۲ ساعت تخمین زده می‌شود (پس از تعدیل یک وقفه ۱۲ ساعته که به دلیل رسیدن عامل‌های هوش مصنوعی به سقف محدودیت‌های استفاده در حین پورت بازی رخ داد):
- پورت بازی‌ها: ۱۸ ساعت (شامل DOOM، Oregon Trail و Pong)
- میزبانی شخصی کامپایلر: ۴ ساعت (زمانی که bet شروع به کامپایل کردن خودِ bet کرد)
- بازبینی امنیتی: ۳ ساعت (پرداختن به مشکلات CWAGE در شماره‌های ۳۰ تا ۴۸)
- زیرساخت و ابزارها: ۳ ساعت (شامل CI، داکر، سیستم freeze و مستندات)
- فرانت‌اند: ۲ ساعت (شامل Lexer، Parser و گرامر زبان)
- زبان و مجموعه‌ها: ۲ ساعت (تعریف کلمات کلیدی، انواع داده‌ها و کانتینرها)
- بک‌اند LLVM: ۱ ساعت (که سازنده آن را «بخش واقعاً سخت کار» نامیده است)
- حافظه Arena: ۲۹ دقیقه (پیاده‌سازی مفاهیم crib و evict)
این نتیجه، گفتگو درباره عامل‌های هوش مصنوعی را از «نوشتن تکه‌های کد کوچک» به «ارائه سامانه‌های کامل» تغییر می‌دهد. با حذف انسان از حلقه بازبینی کد و تکیه کامل بر یک مجموعه تست (Test Corpus)، سازنده ثابت کرد که یک عامل می‌تواند منطق سخت‌گیرانه‌ای که برای یک کامپایلر و اجرای باینری بومی لازم است را حفظ کند.
برای یک توسعه‌دهنده معمولی، این اتفاق به آینده‌ای اشاره دارد که در آن نقش مهندس به یک «معمار خالص» تکامل می‌یابد. در این مدل، ارزش افزوده از دانستن اینکه نقطه-ویرگول کجا قرار می‌گیرد، به سمت تعریف دقیق معیارهای پذیرشی منتقل می‌شود که مانع از انحراف سیستم از مسیر هدف گردد.
پروژه bet قرار نیست به یک محصول تجاری تبدیل شود. سازنده صراحتاً اعلام کرده است که هیچ نقشه‌راه (Roadmap) یا نسخه دوم در راه نیست؛ این پروژه صرفاً به عنوان یک آزمایش تکمیل‌شده در مورد توانمندی‌های هوش مصنوعی و یک اثبات شخصی مبنی بر اینکه او هر چه را شروع کند به پایان می‌برد، وجود دارد.
شما می‌توانید برای مشاهده نحوه عملکرد عملی کلمات کلیدی crib و evict و بررسی کل پیاده‌سازی و مستندات، به سایت رسمی پروژه مراجعه کنید.
گام بعدی شما
- مطالعه مستندات bet برای درک نحوه عملکرد کلمات کلیدی
cribوevictدر مدیریت حافظه. - بررسی نحوه تعریف «معیارهای پذیرش» (Acceptance Criteria) برای هدایت عامل‌های کدنویس در پروژه‌های بومی.
- تست قابلیت‌های LLVM در زبان‌های سفارشی برای کاهش هزینه استنتاج.
اما تأثیر این رویکرد بر امنیت کدهای تولید شده توسط هوش مصنوعی موضوعی پیچیده‌تر است — به بررسی ما درباره استانداردهای امنیت در کدنویسی عامل‌محور مراجعه کنید.
گفتگو