تصور کنید می‌خواهید یک موتور زبان برنامه‌نویسی پیچیده بسازید، در حالی که حتی دستورات پایه زبان مقصد را نمی‌دانید و پیش از این هرگز یک تحلیل‌گر لغوی (Lexer) نساخته‌اید. این دقیقاً همان کاری است که ekinertac با پروژه Phargo انجام داد: ساخت یک مفسر کامل برای زبان پی‌اچ‌پی (PHP) از صفر، با استفاده از زبان راست (Rust) و تحت هدایت کامل هوش مصنوعی.
جای تأسف یا شاید شگفتی اینجا است که خالق این پروژه اعتراف می‌کند که نه تنها نمی‌داند چگونه با راست کد بزند، بلکه اگر کسی از او بپرسد «ارزیاب درخت‌گرد» (Tree-walking evaluator) چیست، نمی‌تواند بدون باز کردن یک تب ویکی‌پدیا آن را توضیح دهد. او حتی می‌گوید اگر کسی از او درباره نحوه عملکرد جمع‌کننده زباله (Garbage Collector) در PHP بپرسد، برای فرار از پاسخ، تظاهر به داشتن یک تماس تلفنی می‌کند. طبق گزارشی که در ۴ ژوئیه ۲۰۲۶ در وب‌سایت ekinertac.com منتشر شد، این پروژه مطالعه‌ای در «اوج تفویض اختیار» (Peak Delegation) است؛ جایی که انسان صرفاً در نقش یک کارگردان ظاهر می‌شود و کدها را مانند «یک پادشاه قرون‌وسطایی که نقشه‌های دریایی را بررسی می‌کند» بازبینی می‌کند، در حالی که کدنویسی واقعی و سخت را مدل‌های زبانی بر عهده دارند.
این آزمایش در زمانی رخ می‌دهد که اکثر پروژه‌های تولید‌شده توسط هوش مصنوعی بر دموهای شکننده یا بنچمارک‌هایی تکیه می‌کنند که توسط خودِ مدل نمره‌گذاری شده‌اند. برای اجتناب از این تله، توسعه‌دهنده یک سیستم «صداقت رادیکال» را پیاده کرد. این رویکرد دقیقاً در راستای مقابله با خطاهای رایج مدل‌های زبانی است، مشابه آنچه در ابزار VibeGuard برای شناسایی الگوهای توهم‌گونه در کدنویسی AI دیده می‌شود تا از بروز حفره‌های امنیتی و منطقی جلوگیری گردد. او مجموعه تست‌های رسمی PHP را — که شامل حدود ۲۲,۰۰۰ فایل با پسوند .phpt است و طی سه دهه توسط تیم داخلی PHP توسعه یافته — به عنوان تنها منبع حقیقت (Source of Truth) پذیرفت. این تست‌ها تمام گوشه‌های تاریک و عجیب زبان را پوشش می‌دهند؛ از فرمت‌بندی اعداد اعشاری در var_dump() گرفته تا محاسبات پیچیده ساعت‌های تابستانی در DateTime. این رویکرد تضمین می‌کند که هوش مصنوعی نمی‌تواند «برگه‌های امتحانی خودش را تصحیح کند».
اوراکل و تابلوی امتیازات
این سیستم بر اساس یک حلقه بازخورد (Feedback Loop) بسیار سخت‌گیرانه عمل می‌کند. نقش انسان در اینجا به حداقل رسیده است: هوش مصنوعی یک هیستوگرام از شکست‌ها را روی کل مجموعه تست‌ها اجرا می‌کند تا بزرگ‌ترین خوشه‌ای از تست‌های شکست‌خورده را پیدا کند که واقعاً امکان رفع آن‌ها وجود دارد. سپس AI تغییرات لازم را اعمال کرده و تابلوی امتیازات شامل ۲۲,۰۰۰ تست را مجدداً اجرا می‌کند؛ فرآیندی که معمولاً با حدود هفت دقیقه صدای بلند فن‌های سیستم همراه است.
در این چرخه، اگر نرخ موفقیت (Pass Rate) افزایش یابد، توسعه‌دهنده عبارت «خوب است، ادامه بده» (looks good, continue) را تایپ می‌کند و تغییرات در مخزن کد ثبت (Commit) می‌شوند. اما اگر تعداد تست‌های پاس‌شده کاهش یابد، توسعه‌دهنده می‌گوید: «هممم، این یک پس‌رفت (Regression) بود، دوباره بررسی کن». این فرآیند، مجموعه تست‌ها را به «اوراکل» یا پیشگویی تبدیل می‌کند که نمی‌توان با چاپلوسی، مذاکره یا تغییر لحن پرامپت، نظرش را عوض کرد. در این سیستم، یا تست خاصی مانند bug40261.phpt پاس می‌شود یا نمی‌شود و هیچ حالت میانی وجود ندارد.
تا اوایل ژوئیه ۲۰۲۶، پروژه Phargo توانسته ۳,۸۴۴ تست از ۲۲,۰۳۷ مورد را پاس کند که معادل نرخ موفقیت ۱۷.۴ درصدی است. اگرچه این عدد در ابتدا کم به نظر می‌رسد، اما توسعه‌دهنده خاطرنشان می‌کند که سقف واقع‌بینانه برای این پروژه حدود ۴۰ تا ۴۵ درصد است. دلیل این امر آن است که باقی تست‌ها مربوط به افزونه‌های زبان C هستند — مانند درایورهای MySQL، SOAP، curl، GD و intl — که صراحتاً خارج از محدوده (Out of scope) این پروژه قرار دارند. با این حال، در میدان بازی واقعی، پیشرفت از نقطه صفر تا اینجا بسیار چشمگیر بوده است.
غلبه بر شکست‌های نامرئی
پروژه زمانی با یک مانع بزرگ مواجه شد که نرخ موفقیت تست‌ها روی یک عدد ثابت ماند (Plateau). توسعه‌دهنده متوجه یک باگ «نامرئی» شد؛ دسته‌ای از تست‌های ساده مدام شکست می‌خوردند، در حالی که تفاوت خروجی (diff) کاملاً یکسان با خروجی مورد انتظار به نظر می‌رسید. او این وضعیت را به خیره شدن به دو عکس کاملاً یکسان در یک بازی «تفاوت‌ها را پیدا کنید» تشبیه کرد.
تفاوت در واقع به معنای واقعی کلمه نامرئی بود: کاراکترهای بازگشت به خط (Carriage Returns). مجموعه تست‌ها در محیط ویندوز با پایان‌خط‌های CRLF دریافت شده بود، اما تابلوی امتیازات در راست، خروجی‌ها را بایت-به-بایت مقایسه می‌کرد. از آنجایی که اجراکننده تست‌های خودِ PHP پیش از مقایسه، پایان‌خط‌ها را نرمال‌سازی می‌کند، این سیستم بدون اینکه متوجه شود، هفته‌ها تقریباً تمام تست‌های چندخطی را رد می‌کرد.
به محض اینکه یک تکه کد ساده برای نرمال‌سازی (مطابق با نحوه عملکرد run-tests.php) اضافه شد، صدها تست فوراً به رنگ سبز درآمدند. این اتفاق یک درس حیاتی را به رخ کشید: ابزار اندازه‌گیری باید به اندازه خودِ اوراکل صادق باشد. اکنون هرگاه پیشرفت پروژه متوقف می‌شود، توسعه‌دهنده همین سؤال را می‌پرسد: آیا موتور کد اشتباه است، یا تابلوی امتیازات دارد دروغ می‌گوید؟
مدیریت کدهای خصمانه
اجرای ۲۲,۰۰۰ تست قدیمی برای سخت‌افزارهای میزبان خطرناک بود. برخی از این تست‌ها در واقع «بمب» بودند؛ رگرسیون‌های تصادفی برای باگ‌های حافظه بسیار قدیمی که ساختارهای نامتعارف و عظیم تخصیص می‌دادند یا تست‌های Generatorهایی بودند که تا بی‌نهایت گسترش می‌یافتند. این تست‌ها احتمالاً فقط برای محیط‌های ایزوله و حصارکشی‌شده‌ی CI در تیم PHP طراحی شده بودند.
یکی از این Discoveries زمانی اتفاق افتاد که ماشین توسعه‌دهنده دچار یک ریبوت سخت‌افزاری (Hard-reboot) کامل شد. یک تست Generator موتور را متقاعد کرده بود که تمام بایت‌های رم را مانند «یک چرخ خرید با موتور جت و بدون ترمز» ببلعد، تا جایی که کل کامپیوتر سیاه شد. برای جلوگیری از تکرار این فاجعه، چندین حفاظ ایمنی (Guardrails) در موتور پیاده شد:
- محدودکننده جهانی تخصیص (Capped Global Allocator): موتور به صورت فیزیکی از تخصیص بیش از ۶ گیگابایت حافظه منع شده است.
- محدودیت گام‌ها (Step Limits): حلقه‌های بی‌نهایت به جای تبدیل کردن ماشین به یک بخاری، با یک پیام خطا متوقف می‌شوند.
- سقف منابع (Resource Caps): محدودیت‌های مشخصی برای اندازه رشته‌ها (String Sizes)، گره‌های آرایه، طول خروجی و گسترش ژنراتورها اعمال شده است.
- لاگ ردپای (Breadcrumb Logging): تابلوی امتیازات نام هر تست جاری را در یک فایل ذخیره می‌کند تا توسعه‌دهنده دقیقاً بداند هنگام هنگ کردن سیستم، باید به کدام فایل خیره شود.
این اقدامات باعث شد یک «پروژه تحقیقاتی» به ابزاری تبدیل شود که می‌تواند بدون نظارت، ۲۲,۰۰۰ فایل خصمانه را با خیال راحت پردازش کند.
افشای ویژگی‌های نمایشی (Potemkin Features)
مجموعه تست‌ها بی‌رحمانه «توابع داخلی پوتمکین» را برملا کرد؛ ویژگی‌هایی که در ظاهر وجود داشتند، پارس می‌شدند و بدون خطا اجرا می‌شدند، اما در واقع هیچ کاری انجام نمی‌دادند. این موارد به‌راحتی می‌توانستند از یک دمو یا بازبینی کد توسط انسانی که راست نمی‌داند، عبور کنند. مجموعه تست‌ها چندین شکست بحرانی را آشکار کرد:
- دستور
clone: این دستور به درستی پارس می‌شد اما همیشه مقدار NULL برمی‌گرداند، که باعث می‌شد تمام عملیاتDateTimeImmutableدر هر تستی به طور خاموش خراب شود. - تابع
unset($arr[$key]): این دستور عملاً یک No-op (بدون اثر) بود، به این معنی که کلید مورد نظر اصلاً از آرایه حذف نمی‌شد. - تابع
trim($str, $charlist): این تابع آرگومانcharlistرا کاملاً نادیده می‌گرفت و فقط فضاهای خالی (Whitespace) را می‌برید. - متغیرهای متغیر (
$variableVariables): این قابلیت اصلاً در موتور وجود نداشت. - متغیرهای توابع استاتیک: این موارد به طور کامل غایب بودند.
- تابع
spl_autoload_register(): موتور این اتولودر را با «لبخندی گرم» می‌پذیرفت اما هرگز آن را فراخوانی نمی‌کرد. - بخش
catch (\Throwable): این بخش با هیچ خطایی تطابق نداشت، که توسعه‌دهنده اشاره کرد داشتن چنین ویژگی برای یک Catch-all «بسیار خنده‌دار» است.
تز این آزمایش این است که اگرچه انسان نمی‌تواند کد را بازبینی (Audit) کند، اما ۲۲,۰۰۰ تست دقتی را فراهم می‌کنند که هیچ بازبین انسانی قادر به حفظ آن نیست.
نقطه عطف وردپرس
وردپرس به عنوان «غول نهایی» (Final Boss) این پروژه شناخته می‌شد، زیرا یک کدبیس قدیمی است که لایه‌های رسوبی از تمام اصطلاحات و عادت‌های برنامه‌نویسی PHP از سال ۲۰۰۳ تا به امروز را در خود دارد. برای اینکه wp-load.php بتواند بوت شود، AI مجبور بود زنجیره‌ای از موانع فنی را حل کند؛ از جمله دستورات goto (که در پارسر HTML وردپرس استفاده شده)، پارامتر ارجاعی $count در تابع str_replace و کاراکترهای گریز \xNN در کلاس‌های کاراکتری Regex.
پروژه در یک مرحله با مشکلی مواجه شد که در آن function_exists() نیمی از توابع داخلی را نمی‌دید و نصب‌کننده وردپرس پایگاه داده خودش را خراب می‌کرد. دلیل دومی، نادیده گرفتن پرچم PREG_SPLIT_DELIM_CAPTURE توسط تابع preg_split در متد wpdb::prepare بود. هوش مصنوعی این باگ را در چهار لایه عمق تشخیص داد و رفع کرد، در حالی که توسعه‌دهنده با «اعتماد کسی که جراحی قلب را از پشت شیشه‌ای مات تماشا می‌کند» نظارت می‌کرد.
در نهایت، Phargo با موفقیت تابع wp_install() را اجرا کرد، یک کاربر مدیر ساخت، جدول گزینه‌ها (Options Table) را پر کرد و سه پست را در SQLite ذخیره نمود. نتایج نهایی به شرح زیر است:
- صفحه اصلی: کاملاً با قالب اصلی، پست‌ها و پیوندهای یکتا (Permalinks) رندر می‌شود.
- پنل مدیریت: مسیر
/wp-admin/بدون هیچ مشکلی باز می‌شود. - REST API: این بخش هنوز در قلمرو ناشناخته‌ها باقی مانده و بررسی نشده است.
- عملکرد: در حال حاضر حدود ۵۵ برابر کندتر از PHP بومی است (۷.۱ ثانیه در مقابل ۱۲۶ میلی‌ثانیه). با این حال، یک ماشین مجازی (Bytecode VM) جدید در حال توسعه است که در بنچمارک‌های خرد (Micro-benchmarks)، به عملکرد ۱ تا ۳ برابر سریع‌تر از PHP 8.5 دست یافته است.
این پروژه گفتگو را از این سؤال که «آیا AI می‌تواند یک موتور زبان بسازد» به این سؤال تغییر می‌دهد که «چگونه یک غیرمتخصص می‌تواند صداقت را در کدهای تولید‌شده توسط AI حفظ کند». با تکیه بر بنچمارک‌های خارجی و تغییرناپذیر، توسعه‌دهنده موفق شد یک کدبیس ۲۴,۰۰۰ خطی در زبان راست را مدیریت کند، بدون اینکه هرگز این زبان را یاد بگیرد.
برای مشاهده روند پیشرفت نرخ موفقیت تست‌ها، می‌توانید مخزن رسمی پروژه را در آدرس github.com/ekinertac/Phargo دنبال کنید.
گفتگو