GitHub: وكلاء Copilot يعيدون كتابة Copilot runtime من TypeScript إلى Rust عبر 128 طلب سحب
مطوّر واحد في GitHub، Stephen Toub، استخدم Copilot app وCLI لنقل الـruntime إلى Rust جزءًا جزءًا، والوكلاء كتبوا أغلب الكود.
- الجهة
- GitHub
- المجال
- البرمجة
- الأداة
- GitHub Copilot
- المصدر
- Agent Use Cases + GitHub Blog: ترحيل Copilot runtime إلى Rust
نُشر المصدر: 17 سبتمبر 2026
وش كانت المشكلة؟
الـruntime مكتوب بـTypeScript (نحو 130 ألف سطر في خطة مايو 2026)، والنقل الكامل لـRust حسب المقال كان يحتاج فريقًا كاملًا سنة أو سنتين قبل الوكلاء.
وش سوّوا؟
نقل مكوّنًا واحدًا في كل طلب سحب: يستبدل TypeScript بطبقة رفيعة تنادي Rust ويُبقي اختبارات end-to-end شغالة. الجلسة الأم تفتح جلسات فرعية كل وحدة في worktree خاص، وهو يراجع ويعترض ويفرض بوابات الجودة.
النتيجة حسب المصدر
- بحلول 21 أغسطس صار الـruntime Rust بالكامل: نحو 832 ألف سطر Rust إنتاجي.
- 128 طلب سحب دخلت main وانشحنت تدريجيًا.
- ظهرت بعض التراجعات (regressions) وانصلحت بسرعة، والأداء تحسّن بمراتب حسب المقال.
الأرقام منقولة كما نشرها المصدر، وما تحققنا منها بشكل مستقل. وقصص العملاء غالبًا من الشركة اللي تبيع الأداة، فنتيجتك ممكن تختلف.
وش تتعلم منها؟
مقال من GitHub نفسها عن مشروعها الداخلي، ومذكور على Agent Use Cases. 15 وكيلًا يبنون في نفس الوقت جمّدوا جهاز المطوّر، فصار البناء يتم بإذن جلسة واحدة في كل مرة.
كيف تسويها بنفسك؟
- قسّم النقل لأجزاء صغيرة، جزء لكل طلب سحب.
- خلّ الاختبارات الحالية تشتغل بعد كل جزء.
- شغّل كل وكيل في worktree منفصل.
- حدّد من يبني ومتى عشان ما يتجمد الجهاز.
- راجع كل طلب سحب بنفسك قبل الدمج.
برومبت جاهز تبدأ فيه
عدّل اللي بين الأقواس [ ] على وضعك. ولا تلصق بيانات عملاء أو أرقام هويات في أداة ما تعرف سياستها.
حالات وأدلة قريبة
المصدر
آخر تحديث للصفحة: 8 نوفمبر 2026