إعادة كتابة Bun المدعومة بالذكاء الاصطناعي بلغة Rust: دليل التحقق لترحيل ملايين الأسطر البرمجية

مقدمة

العنوان الرئيسي صعب التجاهل: وفقًا للتقارير، قام Bun بترحيل تنفيذ رئيسي من لغة Zig إلى Rust في 11 يومًا باستخدام سير عمل Claude Code الديناميكي. تصف الحسابات المنشورة آلاف الالتزامات البرمجية، وما يصل إلى 64 وكيل Claude، وحوالي 780,000 سطر من Rust، ومراجعين متعارضين لكل وحدة تنفيذ، وتطورًا من كود لم يكن يُجمّع إلى منفذ اجتاز مجموعة الاختبارات وتم إطلاقه.

الدرس الخاطئ هو أن إعادة كتابة اللغات أصبحت مهامًا بنقرة واحدة. الدرس المفيد هو أن إنتاجية التنفيذ وإنتاجية التحقق أصبحتا الآن مشكلتين هندسيتين منفصلتين.

يمكن لوكلاء الذكاء الاصطناعي توليد كود أسرع مما يستطيع فريق بشري قراءته. بمجرد حدوث ذلك، لم يعد مراجعة طلبات السحب التقليدية قادرًا على العمل كآلية أمان رئيسية. تحتاج الفرق إلى نظام يحول التغيير الاحتمالي الضخم إلى ادعاءات صغيرة مدعومة بأدلة قابلة للفحص آليًا.

جعل تقرير الإنتاج اللاحق لـ Bun هذا الأمر ملموسًا بشكل غير معتاد. أبلغ الفريق عن 19 تراجعًا معروفًا، جميعها تم إصلاحها لاحقًا؛ و11 جولة من مراجعة الأمان؛ واختبارًا مستمرًا موجهًا بالتغطية عبر المحللات اللغوية؛ وحوالي 27,000 سطر من Rust داخل كتل unsafe من إجمالي حوالي 780,000 سطر. لا تضعف هذه الحقائق قصة الترحيل. إنها تُظهر كيف يبدو عمل الترحيل الجاد بعد انتهاء العرض المثير للإعجاب.

يحول هذا الدليل تلك التجربة إلى دليل تحقق قابل لإعادة الاستخدام. الهدف ليس نسخ حجم Bun. بل هو تقديم طريقة لأي ترحيل - نقل اللغات، استبدال الأطر، تحديث واجهات برمجة التطبيقات، تحويل قواعد البيانات، أو إعادة هيكلة المستودعات بالكامل - حيث يمكن لوكلاء برمجة الذكاء الاصطناعي كتابة كود أكثر مما يستطيع الفريق مراجعته بشكل مسؤول سطرًا بسطر.

النقاط الرئيسية

• تُظهر إعادة كتابة Bun أن وكلاء الذكاء الاصطناعي يمكنهم ضغط وقت التنفيذ. لا تُظهر أنه يمكن إلغاء وقت التحقق.
• الأصول القابلة للنقل هي نظام الترحيل: عقود السلوك المكتوبة، خرائط المخاطر، النماذج التجريبية الصغيرة، العمال المعزولون، المراجعون المستقلون، البوابات الحتمية، والالتزامات البرمجية القابلة للاسترداد.
• تكتشف المترجمات ومجموعات الاختبار القديمة فئات فشل مختلفة. لا يكتشف أي منهما كل عدم تطابق دلالي عبر اللغات، أو اختلافات وضع الإصدار، أو تراجع الأداء، أو حدود unsafe.
• تتطلب الفروق الكبيرة مراجعة قائمة على الأدلة. يجب على البشر فحص العقود، ونقاط المخاطر الساخنة، والأمثلة المضادة، والفجوات في الاختبارات، وقرارات الطرح بدلاً من التظاهر بأن كل سطر مولّد يحصل على تدقيق متساوٍ.
• يمكن للفرق تبني نفس النمط دون محاولة إعادة كتابة مليون سطر: تتطلب من الوكلاء إثبات السلوك جزءًا واحدًا في كل مرة، ثم منح استقلالية أوسع فقط بعد نتائج مقاسة.

ما فعله Bun بالفعل - وما يتركه العنوان

بدأ الحساب الهندسي قبل توليد الكود على نطاق واسع.

وفقًا للتقارير، أمضى جاريد سومنر حوالي ثلاث ساعات في إنشاء PORTING.md، الذي رسم خرائط لأنماط Zig المتكررة إلى Rust. حلل سير عمل منفصل حقول الهياكل، واقترح أعمار Rust، وأرسل تلك الاختيارات إلى مراجعين متعارضين، وسلسل النتائج في LIFETIMES.tsv. كما تمت مراجعة هذه القطع الأثرية يدويًا.

الأول

طبقت التجربة ثلاثة ملفات، وليس المستودع بأكمله. لكل ملف:

1. نفذ أحد الوكلاء النسخة المكتوبة بلغة رست.
2. راجع وكيلان جديدان التكافؤ السلوكي والامتثال لوثائق الترحيل.
3. قام وكيل آخر بتطبيق الإصلاحات المعتمدة.

فقط بعد هذه التجربة الأولية انتشر العمل ليشمل 1,448 ملف زيغ.

فشلت أول عملية تشغيل واسعة النطاق. كان الوكلاء يتشاركون مساحة عمل ويستخدمون أوامر مثل git stash و git stash pop و git reset --hard. تداخلت تغييراتهم مع بعضها البعض. ثم تم تغيير سير العمل لمنع أوامر التنسيق غير الآمنة واستخدام أربع مساحات عمل منفصلة، لكل منها 16 وكيلاً.

تلك التفاصيل أكثر أهمية من ذروة معدل توليد الأسطر. البرمجة المتوازية هي مشكلة أنظمة موزعة. الحالة المشتركة، والكتّاب المتعارضون، والعمليات الشاملة المكلفة، والملكية، والاسترداد كلها تحتاج إلى قواعد صريحة.

لم يعمل الكود المولد فورًا. استخدم بن أخطاء المترجم كقائمة انتظار وتقدم بمكتبة واحدة في كل مرة. في مرحلة ما، تم تخصيص حوالي 16,000 خطأ مترجم للوكلاء. استخدمت الحلقة مصححًا واحدًا، ومراجعَين اثنين، ووكيل تطبيق واحد، مع الحد من عدد مرات تشغيل الأوامر المكلفة مثل cargo check وعمليات غيت.

لم تكن هذه ترجمة سحرية. بل كانت تقاربًا مرحليًا مدفوعًا بتغذية راجعة قطعية.

أعلنت أنثروبيك عن سير العمل الديناميكي بأن 99.8% من المجموعة الحالية اجتازت وقت كتابة التقرير الأولي، مع الإشارة صراحةً إلى أن النقل لم يكن قيد الإنتاج بعد. غطى مقال بن اللاحق العمل الذي تبع ذلك: مراجعات الأمان، والتجريب العشوائي، والتراجعات الإنتاجية، والإصلاحات الدلالية، وتقليل الكود غير الآمن.

عند القراءة معًا، تصف المصادر مرحلتين مختلفتين:

• اكتمال التطبيق بما يكفي للدمج
• اكتمال الأدلة بما يكفي للتشغيل الآمن

مصطلحات تحتاج إلى معرفتها: النقل، والمقياس، والاختبار التفاضلي، والسطح غير الآمن

هذه التعريفات مهمة لأن الفريق لا يمكنه التحقق من صحة الترحيل حتى يتفق على ما يجب أن تثبته الأدلة. كما أنها تفصل بيان ثقة الوكيل عن نتيجة قابلة للتحقق خارجيًا.

النقل (Port)

النقل هو إعادة تنفيذ برنامج بلغة، أو وقت تشغيل، أو منصة، أو إطار عمل جديد مع الحفاظ على مجموعة محددة من السلوكيات.

"الحفاظ على السلوك" يحتاج إلى حدود. قد يحافظ النقل على واجهات برمجة التطبيقات العامة والمخرجات مع تغيير الهندسة الداخلية، أو خصائص الأداء، أو رسائل الخطأ، أو حالات الحافة غير المدعومة عن قصد.

عقد السلوك (Behavior Contract)

عقد السلوك هو قائمة صريحة من الخصائص التي يجب أن يحافظ عليها التنفيذ الجديد.

قد يشمل:

• المدخلات والمخرجات
• سلوك الخطأ
• الترتيب
• الآثار الجانبية
• دلالات التزامن
• حدود الموارد
• المنصات المدعومة
• ميزانيات الأداء
• متطلبات المراقبة

الكود الموجود يحتوي على سلوك، ولكن ليس كل سلوك موجود مقصود. العقد يفصل المتطلبات عن الحوادث التاريخية.

مقياس الاختبار (Test Oracle)

مقياس الاختبار يحدد ما إذا كان المخرَج صحيحًا أم لا.

تأكيد اختبار الوحدة هو أحد المقاييس. يمكن أيضًا أن يعمل التنفيذ المرجعي، أو مواصفات البروتوكول، أو الملف الذهبي، أو ثابت قاعدة البيانات، أو القاعدة التي أنشأها الإنسان كمقياس.

توجيه أنثروبيك للتشغيل الطويل

إليك الترجمة العربية الطبيعية والدقيقة للنص المطلوب:

البرمجة العلمية تؤكد أن العمل المستقل يحتاج إلى مراجع، وأهداف قابلة للقياس، أو مجموعات اختبار حتى تتمكن الوكلات (العوامل) من تحديد ما إذا كانت تحرز تقدمًا.

الاختبار التفاضلي

الاختبار التفاضلي يُرسل نفس المدخلات إلى التنفيذ القديم والجديد، ثم يقارن النتائج الملحوظة.

هو مفيد بشكل خاص عندما يكون التنفيذ القديم موثوقًا ولكن لا توجد مواصفات رسمية كاملة. لا يثبت الاتفاق أن كلا التنفيذين صحيحان، ولكن الخلاف يُنشئ قائمة انتظار دقيقة للتحقيق.

الاختبار التحولي

الاختبار التحولي يتحقق من العلاقات بين عمليات تنفيذ متعددة عندما يكون من الصعب كتابة المخرجات المتوقعة الدقيقة.

تشمل الأمثلة:

• تسلسل قيمة وتحليلها يجب أن يحافظ عليها.
• إعادة ترتيب المدخلات المستقلة يجب ألا يغير النتيجة المحددة كمجموعة.
• تشغيل ترحيل متكافئ (idempotent) مرتين يجب ألا يغير الحالة في المرة الثانية.
• إعادة محاولة نفس المفتاح التكافؤي يجب ألا يُنتج تأثيرًا جانبيًا مكررًا.

السطح غير الآمن

السطح غير الآمن هو الكود الذي يتم فيه إضعاف أو تجاوز الضمانات الطبيعية للغة الهدف.

في لغة Rust، قد يكون unsafe ضروريًا عند حدود FFI (واجهة الوظائف الأجنبية) مع C أو C++، أو داخل المخصصات المخصصة (custom allocators)، أو للتكامل المنخفض المستوى في بيئة التشغيل. العدد الأولي ليس حكمًا. الفريق يحتاج إلى الملكية، والثوابت (invariants)، والاختبارات، وخطة صريحة لكل حدود غير آمنة.

العيب المتسرب

العيب المتسرب هو خطأ ناتج عن الترحيل تم اكتشافه بعد البوابة التي كان يجب أن تكتشفه—بعد الدمج، النشر التجريبي (canary deployment)، اختبار المرشح للإصدار، أو طرح الإنتاج.

العيوب المتسربة هي تغذية راجعة حول نظام التحقق، وليس فقط حول التنفيذ.

السلسلة السببية: لماذا يتطلب التوليد الأسرع تحققًا أقوى

توازي الوكيل يغير اقتصاديات التنفيذ. إذا قام 64 عاملًا بترجمة الملفات في نفس الوقت، يمكن أن يتقلص وقت توليد الكود بشكل كبير. الرسم البياني للتبعيات، ودلالات اللغة الهدف، وبيئة الاختبار المشتركة لا تختفي. الإنتاجية ببساطة تنقل الاختناق إلى أسفل السلسلة.

الاختناق 1: التكامل

قد تفشل الملفات المعقولة بشكل فردي عند تجميعها معًا.

حوالي 16,000 خطأ في المترجم (compiler errors) في مشروع Bun وتبعيات الكرت الدائرية (cyclic crate dependencies) توضح الفجوة بين الترجمة المحلية والاتساق العالمي. المترجم هو مُخبر حتمي ممتاز للأنواع، والملكية (ownership)، وأعمار المتغيرات (lifetimes)، والأسماء، وبعض خصائص تدفق التحكم. لكنه ليس مُخبرًا لسلوك المنتج.

الاختناق 2: التكافؤ الدلالي

وثّق مشروع Bun أخطاءً حيث بدا الكود متطابقًا تقريبًا عبر اللغات لكنه تصرف بشكل مختلف.

شملت الأمثلة:

• الآثار الجانبية الموضوعة داخل debug_assert! في Rust تختفي في الإصدارات النهائية، بينما تأكيد (assertion) مماثل في Zig لا يزال يُقيّم وسائطه.
• تعبير unwrap_or الاستعجالي (eager) يُحفّز سلوكًا كان يجب أن يبقى كسولًا (lazy).
• دلالات شريحة البايت والحدود تختلف بين التنفيذات.
• مدخلات UTF-16 ذات الطول الفردي تفضح تعطلًا (crash).

هذه تحديدًا هي الإخفاقات التي يفتقدها المراجعة السطحية لأن الكود المُترجم يبدو معقولًا.

الاختناق 3: ارتباط المراجعة

إذا كان نفس النموذج يكتب ويراجع تغييرًا باستخدام نفس السياق والافتراضات، فقد يُعيد إنتاج...

خطأ أصلي.

توثيق أفضل الممارسات الخاص بـ Claude Code من Anthropic يوصي باستخدام سياق مراجع جديد. يرى المراجع الفرق والمعيار دون وراثة منطق المؤلف. الاستقلال لا يضمن الصحة، لكنه يقلل من التحيز المشترك في السياق.

الاختناق الرابع: الأدلة التشغيلية

قد تنجح الاختبارات بينما يتضاعف زمن الاستجابة، ويزداد استخدام الذاكرة، أو يتعطل هدف نظام تشغيل واحد، أو تختفي قابلية المراقبة.

كلما كان التغيير أكبر، زادت احتمالية اكتشاف الفريق لمتطلب مخالف فقط بعد النشر. لهذا السبب يجب أن تتضمن خطة الترحيل أنظمة الاختبار التجريبي (canaries)، وآليات الاسترجاع، ومقارنة القياس عن بعد، وعملية تحول كل عيب يفلت إلى قاعدة تعاقدية جديدة أو اختبار.

الاستنتاج السببي بسيط:

الذكاء الاصطناعي لا يلغي تكلفة الترحيل. إنه ينقل التكلفة من الكتابة نحو المواصفات، وتصميم الحزام، ومراجعة الأدلة، والتحكم في النشر.

الفريق الذي يتجاهل هذا التحول قد ينهي توليد الكود بسرعة ثم يقضي شهورًا في تحديد ما إذا كانت إعادة الكتابة تعمل فعليًا.

بنية تحقق للترحيلات المدعومة بالذكاء الاصطناعي

تتكون البنية من أربع مستويات.

1. المستوى التعاقدي

يقوم المستوى التعاقدي بتخزين:

• السلوك العام
• وعود التوافق
• التغييرات المقصودة
• مصفوفة المنصات المدعومة
• ميزانيات الأداء
• قيود الأمان
• متطلبات قابلية المراقبة

يحافظ البشر على هذا المستوى، ويقوم المستودع بإدارة إصداراته.

2. مستوى التنفيذ

يحتوي مستوى التنفيذ على وكلاء تنفيذ معزولين.

يتلقى كل وكيل:

• وحدة ترحيل واحدة
• ملفات المصدر ذات الصلة
• التعاقد المعتمد
• الخريطة الدلالية
• أدوات محدودة النطاق
• فحوصات مستهدفة

لا يمكن للوكيل تغيير التعاقد أو الاختبارات العالمية. يقوم فقط بتحرير النطاق المخصص له ويعيد كلاً من الالتزام والأدلة.

3. مستوى التحقق

مستوى التحقق مستقل عن التنفيذ.

يمكنه:

• تجميع المرشح
• تشغيل الاختبارات المستهدفة والعالمية
• تنفيذ فحوصات تفاضلية بين القديم والجديد
• إختبار التحليل التلقائي لحدود المحللين والبروتوكولات
• فحص الكود الحساس للأمان
• قياس أداء أحمال العمل التمثيلية
• طلب مراجعين جدد للبحث عن الأمثلة المضادة

قد يقترح وكلاء التحقق اختبارات، لكن التكامل المستمر الحتمي (CI) هو من يقرر ما إذا كان الباب يمر.

4. مستوى الإصدار

يتحكم مستوى الإصدار في التكامل والتعرض للإنتاج.

يقوم بـ:

• الدمج بترتيب التبعيات
• إنتاج قطع أثرية قابلة للتكرار
• تحديد البنيات بإصدارات أو تجزئات (hashes) غير قابلة للتغيير
• تشغيل حركة المرور الظلية حيثما أمكن
• توسيع الاختبار التجريبي تدريجيًا
• مراقبة مؤشرات مستوى الخدمة
• الحفاظ على مسار استرجاع مُختبر

يمكن لـ We0 AI الجلوس بين هذه المستويات كطبقة تنسيق وأدلة. يمكن للفرق استخدام المهام لتعيين شرائح الترحيل، وعزل أشجار العمل، وإرفاق التعاقدات، وجمع مخرجات الاختبار، وطلب المراجعة قبل تقدم العمل.

الحد المهم هو أن التنسيق ينسق الأدلة. إنه لا يحول ادعاء الوكيل بالنجاح إلى إذن بالإصدار.

سيناريو مثال: ترحيل خدمة دفع من بايثون إلى جو

لنفترض ترحيل خدمة دفع بلغة بايثون مكونة من 120,000 سطر إلى لغة جو. الهدف التجاري هو تقليل

حجم التأخير النهائي (tail latency) وتبسيط النشر.

مثال على المطالبات الخطيرة:

أعد كتابة هذه الخدمة بلغة Go واجعل جميع الاختبارات تنجح.

هذه المطالبة تترك معاني المعاملات، وسلوك الأخطاء، والدقة المالية، والتسوية (Idempotency)، وطريقة التوزيع (Rollout) غير محددة.

الخطوة 1: كتابة العقد (Write the Contract)

لكل نقطة وصول (Endpoint)، يسجل الفريق:

• مخططات الطلب والاستجابة (Request and response schemas)
• قواعد التفويض (Authorization rules)
• سلوك مفتاح التسوية (Idempotency-key behavior)
• تقريب العملات (Currency rounding)
• دلالات إعادة المحاولة (Retry semantics)
• معاملات قاعدة البيانات (Database transactions)
• ترتيب الأحداث (Event ordering)
• أكواد الأخطاء (Error codes)
• متطلبات القياس عن بُعد (Telemetry requirements)

كما يحدد التغييرات المتعمدة، مثل إزالة رأس تصحيح أخطاء خاص بلغة Python. يحدد الفريق المنصة المدعومة ومصفوفة التبعيات (Dependency matrix)، ثم يحدد ميزانيات الكمون للنسب المئوية p95 وp99 وسقف الذاكرة القصوى (Peak-memory ceiling).

الخطوة 2: اختيار شرائح نموذجية (Pilot Slices)

يختار الفريق:

1. وحدة خالصة لتنسيق العملات (Pure currency-formatting module)
2. مستودع تسوية مع آثار جانبية لقاعدة البيانات (Idempotency repository with database side effects)
3. نقطة وصول HTTP للقراءة فقط (Read-only HTTP endpoint)

الأولى تختبر الترجمة الآلية (Mechanical translation). الثانية تختبر المعاملات والتزامن (Transactions and concurrency). الثالثة تختبر توافق HTTP (HTTP compatibility).

يتولى وكيل تنفيذ واحد كل شريحة. يتلقى المراجعون الجدد العقد فقط، والشفرة المصدرية القديمة، والفرق المقترح (Diff)، وأوامر التحقق من الصحة.

الخطوة 3: استخدام الخدمة القديمة كمرجع تفاضلي (Differential Oracle)

يتم إعادة تشغيل مجموعة من الطلبات التاريخية المنظفة (Sanitized corpus) ضد كلا الإصدارين.

يتم تطبيع الردود فقط حيثما يسمح العقد بالاختلافات، ثم تتم المقارنة. بالنسبة لمسارات الكتابة (Write paths)، يتم تشغيل كلا التنفيذين مقابل لقطات قاعدة بيانات قابلة للاستبدال (Disposable database snapshots). تتم مقارنة الصفوف الناتجة والأحداث المنبعثة.

ثم تقوم الاختبارات التحولية (Metamorphic tests) بما يلي:

• تكرار نفس مفتاح التسوية
• تغيير ترتيب مفاتيح JSON غير الضارة
• إدخال اختلافات في توقيت إعادة المحاولة
• اختبار القيم المالية الحدودية

الخطوة 4: اختبار الظل والكناري (Shadow and Canary) للخدمة الجديدة

قبل تمكين عمليات الكتابة في بيئة الإنتاج، تتلقى خدمة Go حركة مرور الظل مع تعطيل عمليات الكتابة أو توجيهها إلى مصرف معزول (Isolated sink).

يقوم الفريق بمقارنة:

• توزيعات زمن الاستجابة (Latency distributions)
• تصنيفات الأخطاء (Error classifications)
• استدعاءات التبعيات (Dependency calls)
• أشكال التتبع (Trace shapes)
• استخدام الذاكرة (Memory use)
• سلوك الأحداث (Event behavior)

ثم يرسل الفريق 1% من حركة مرور الكناري من مجموعة تجار منخفضي المخاطر.

يتطلب التوسع (Expansion) ما يلي:

• عدم وجود اختلافات مالية غير مفسرة
• تكافؤ معدلات الأخطاء
• زمن استجابة ضمن الميزانية المتفق عليها
• تجربة ناجحة للتراجع (Rollback drill)

قد يظل التنفيذ سريعًا. تأتي السلامة من تحويل "إعادة كتابة الخدمة" إلى ادعاءات قابلة للمراقبة (Observable claims).

يوضح هذا المثال أيضًا لماذا تبقى الخبرة في المجال (Domain expertise) ضرورية. يمكن للوكلاء ترجمة الكود، لكن خبراء المدفوعات يعرفون أن الأحداث المكررة، واختلافات التقريب، وسلوك إعادة المحاولة هي متطلبات عمل.

المرحلة 0: تعريف عقد الهجرة (Migration Contract) وشروط الإيقاف

قبل أن يقوم أي وكيل بتعديل الكود، يجب تحديد ما يعتبر نفس المنتج.

الجرد (Inventory):

• واجهات برمجة التطبيقات العامة (APIs)
• سلوك واجهة سطر الأوامر (CLI behavior)
• تنسيقات الملفات (File formats)
• تأثيرات قاعدة البيانات (Database effects)
• متغيرات البيئة (Environment variables)
• القياس عن بُعد (Telemetry)
• رسائل الأخطاء المرئية للمستخدم (User-visible error messages)
• المنصات المدعومة (Supported platforms)
• خصائص الأداء (Performance characteristics)

قم بتحديد كل خاصية كواحدة مما يلي:

• الحفظ (Preserve)
• التغيير عمدًا (Intentionally change)
• الإهمال (Deprecate)
• غير معروف (Unknown)

غير المعروف لا يعني الإذن بالتخمين. تصبح هذه مهام اكتشاف (Discovery tasks).

قم بتشغيل النظام القديم، وابحث في المشكلات وسجلات التغيير (Changelogs)، وتفقد آثار الإنتاج (Production traces)، أو اسأل المشرفين (Maintainers). هذا هو شجرة المصدر قبل هجرة Bun.

أعادت عملية إعادة التنظيم الحفاظ على تاريخ Git من خلال الالتزامات التي تقتصر على نقل الملفات، مما جعل تتبع المصدر مطلبًا مقصودًا وليس ضررًا جانبيًا.

حدد شروط التوقف الصارمة. أوقف التوسع عندما:

• تتجاوز معدلات عدم تطابق النموذج الأولي الحد المسموح.
• يقوم العمال بتعديل الاختبارات العالمية المحمية بشكل متكرر.
• ينمو قائمة انتظار أخطاء المترجم بشكل أسرع من حلها.
• يخفق الأداء المستهدف في تحقيق الميزانية.
• يتعذر بناء أثر استرجاع.
• يكون الدليل غير مكتمل أو غير قابل للقراءة.

يحمي التوقف المشروع من تصاعد التكاليف الغارقة.

يجب التحكم في العقد بشكل منفصل عن التنفيذ. لا يُسمح للوكيل "بإصلاح" اختبار فاشل عن طريق إضعاف المتطلب. تتطلب تغييرات العقد تعديلًا يراجعه بشري يشرح لماذا السلوك القديم قديم أو خاطئ.

المرحلة 1: بناء خريطة دلالية قبل التوليد على نطاق واسع

أنشئ تعيينات واضحة للأنماط الشائعة أو الدقيقة أو الخطيرة من المصدر إلى الهدف.

قم بتغطية مجالات مثل:

• قواعد الملكية ومدى الحياة
• قابلية القيمة null
• الاستثناءات ومعالجة الأخطاء
• تجاوز الأعداد الصحيحة
• حسابات الوقت
• ترميز السلاسل النصية
• أساسيات التزامن
• ملكية الموزع
• FFI (واجهة الوظائف الأجنبية)
• سلوك التصحيح مقابل الإصدار
• الكود الخاص بالمنصة

خدمت ملفات PORTING.md و LIFETIMES.tsv الخاصة بـ Bun هذا الغرض.

لم تكن قيمتها مقتصرة على تحسين المطالبات (prompts). لقد أعطت مئات العمال استراتيجية دلالية مشتركة. بدون مثل هذه الخريطة، يخترع كل وكيل أسلوب ترجمة خاص به، ويصبح عدم الاتساق مشكلة تكامل.

اطلب من وكلاء مستقلين نقد الخريطة:

• أعط مراجعًا واحدًا دلالات اللغة المصدر.
• أعط آخر مخاطر اللغة الهدف.
• أعط ثالثًا أمثلة كود تمثيلية.
• اشترط أمثلة مضادة ملموسة.

يجب على البشر فحص القواعد الأعلى خطرًا، خاصة تلك المتعلقة بملكية الذاكرة، والتزامن، وحدود الأمان، والاستمرارية، والسلوك الخاص بالإصدار فقط.

قم بإصدار الخريطة. كل عدم تطابق جديد يجب أن يحدث القواعد، ويحدد وحدات الترحيل المتأثرة، ويطلق إعادة تحقق مستهدفة.

الخريطة الدلالية هي مواصفات حية، وليست مطالبة تُلصق مرة واحدة في البداية.

المرحلة 2: تصميم نماذج أولية صعبة عمدًا

لا تختر أسهل الملفات فقط.

يتضمن النموذج الأولي المفيد ثلاثة أشكال:

1. وحدة بسيطة تمثيلية
2. وحدة ذات تبعيات كثيفة
3. نقطة ساخنة دلالية

استخدم Bun ثلاثة ملفات للتحقق من حلقة التنفيذ-المراجعة-الإصلاح قبل ترجمة 1448 ملفًا. لا يهم العدد الدقيق بقدر ما يهم نطاق أنماط الفشل المغطاة.

قم بقياس عملية النموذج الأولي، وليس مخرجاتها فقط:

• هل احترم العمال ملكية الملفات؟
• هل كانت الالتزامات ذرية؟
• هل وجد المراجعون عيوبًا حقيقية أم أنتجوا ضوضاء في الغالب؟
• هل استطاع المصلح تطبيق الاقتراحات دون انتهاك العقد؟
• هل كان الدليل لا يزال قابلاً للقراءة؟
• كم من السياق والحوسبة استهلكت كل وحدة مقبولة؟

قم بزرع العيوب عمدًا. أضف فرقًا دقيقًا في وضع الإصدار، أو اختبار حالة حدية، أو حد أداء وتأكد من أن نظام التحقق يكتشفه.

النظام الذي اجتاز فقط أمثلة نظيفة لم يتم اختباره بعد.

يجب أن يبدأ التوسع فقط عندما ينتج النموذج الأولي دليلاً ثابتًا وقابلاً للتكرار. إذا تغيرت المطالبات أو النماذج أو سياسات الأدوات بشكل جوهري لاحقًا، أعد تشغيل النموذج الأولي الصغير. سير العمل

التكوين هو كود إنتاجي ويستحق اختبارات الانحدار.

المرحلة 3: التفرع مع العزل والملكية والالتزامات الذرية

أنشئ وحدات ترحيل متوافقة مع الرسم البياني للتبعيات.

تجزئة الملفات مريحة، لكنها قد تكون الحدود الخاطئة عندما يتجاوز السلوك الوحدات النمطية. عيِّن كاتبًا واحدًا لكل وحدة واجعل الملكية قابلة للقراءة آليًا. قد يقرأ العمال التبعيات لكن يمكنهم تعديل نطاقهم فقط ما لم يطلبوا تغييرًا منسقًا.

استخدم أشجار عمل منفصلة أو حاويات أو أجهزة افتراضية مؤقتة حيثما كان ذلك عمليًا.

يُظهر فشل مساحة العمل المشتركة لـ Bun السبب. قيِّد أوامر Git المدمرة وأوامر البناء العالمية المكلفة للعمال الطرفيين. دع المنسق يقوم بالتكامل المرتب.

تقلل بيانات الاعتماد قصيرة العمر وقوائم السماح الشبكية من تأثير حقن الأوامر أو تسريب التبعيات. يصف دليل الحماية الخاص بـ Anthropic حدود نظام الملفات والشبكة كأساس لاستقلالية أكثر أمانًا.

يجب أن ينتج كل وحدة مقبولة التزامًا ذريًا يحتوي على:

• معرف المصدر
• قواعد العقد القابلة للتطبيق
• الأوامر المنفذة
• مخرجات الاختبارات والفحوصات
• نتائج المراجعة
• الاستثناءات المعتمدة

يصبح Git آلية للتنسيق والاسترداد معًا.

يوصي دليل سير العمل طويل الأمد لـ Anthropic بالالتزامات الهادفة والاختبار قبل كل التزام، لأن التاريخ القابل للاسترداد يمنع تشغيل الوكيل الطويل من التحول إلى قطعة أثرية معتمة.

لا تحسن لعدد الأسطر في الدقيقة. حسّن لعدد الوحدات الموثقة في الساعة.

الإنتاجية العالية للتوليد مع قائمة تكامل متزايدة هو تقدم سلبي.

المرحلة 4: التعامل مع أخطاء المترجم والاختبارات كقوائم انتظار، وليس كدليل

مخرجات المترجم تخلق عملاً منظمًا.

جمّع الأخطاء حسب وحدة الملكية أو طبقة التبعية، وأزل التتابعات المكررة، وأصلح الأسباب الجذرية قبل الأعراض الطرفية.

امنع الاختصارات ما لم يسمح العقد بذلك صراحةً، بما في ذلك:

• النماذج الفارغة
• النتائج المُتجاهلة
• سماحيات allow الواسعة
• التأكيدات المُعطلة
• التطبيقات البديلة
• الاختبارات التي تم تغييرها فقط لجعل المرشح يمر

اختبر في دوائر متسعة:

1. اختبارات الوحدة للوحدة المعدلة
2. اختبارات العقد عند الحدود العامة
3. اختبارات التكامل عبر التبعيات
4. مجموعات متعددة المنصات
5. اختبارات الانحدار الكاملة

احتفظ بالمخرجات الفاشلة كقطع أثرية. تشغيل أخضر نهائي بدون تاريخ قد يخفي ما إذا كان العمال قد أضعفوا الفحوصات مرارًا على طول الطريق.

حيثما أمكن، افصل تأليف الاختبار عن التنفيذ.

يمكن لوكيل واحد استخلاص الحالات الحدودية من العقد والتنفيذ القديم، بينما يكتب آخر المنفذ. أقفل اختبارات التوافق المعتمدة بحيث لا يمكن للعمال التنفيذيين تعديلها. يجب أن يسأل المراجعون الجدد عما إذا كان الكود يمر للسبب المقصود.

توضح الانحدارات الإنتاجية لـ Bun الفجوة بين مجموعة خضراء والاكتمال الدلالي.

فشل HMR خاص بالإصدار جاء من تأثير جانبي داخل debug_assert!. تعطل UTF-16 ذو الطول الفردي عكس سلوكًا مختلفًا للشرائح. يجب أن يصبح كل خلل هارب اختبار انحدار دائم وقاعدة جديدة للخريطة الدلالية.

المرحلة 5: إضافة الاختبار التفاضلي والفحص العشوائي وميزانيات الأداء

شغّل التطبيقات القديمة والجديدة على نفس النصوص.

قارن:

• رموز الخروج

• المخرجات المعيارية

• فئات الأخطاء

• التأثيرات الجانبية

• حالة قاعدة البيانات

• الأحداث المنبعثة

• التتبعات

بناء مولّدات القيم الحدّية لما يلي:

• المدخلات الفارغة
• الأحجام القصوى
• الترميزات المشوّهة
• الأوقات المحيطة بعصر يونكس
• التسابقات المتزامنة
• المسارات الخاصة بالمنصة
• استنزاف الموارد

اختبر المحلّلات وحدود البروتوكولات باستمرار.

ذكرت Bun أن محلّلاتها الموجهة بالتغطية نفذت كود المحلل اللغوي حوالي 100 مليار مرة وأسفرت عن حوالي 15 طلب سحب للإصلاح. يعتمد العدد المطلق على حجم العمل. النمط القابل للتحويل هو ربط اكتشاف الأعطال باختبارات قابلة للتكرار، وإصلاحات مقترحة من الوكيل، وطلبات سحب يراجعها البشر.

عندما يعتمد المستخدمون على الأداء، يصبح الأداء جزءًا من السلوك.

القياس المرجعي:

• بدء التشغيل البارد
• الإنتاجية
• زمن الكمون p50
• زمن الكمون p95
• زمن الكمون p99
• الذروة في استخدام الذاكرة
• حجم الثنائي
• وقت البناء
• استخدام وحدة المعالجة المركزية تحت أعباء عمل ممثلة

قارن التوزيعات بدلاً من المتوسطات. حدد الميزانيات قبل الترحيل حتى لا يتمكن الفريق من تبرير الانحدار بعد استثمار كبير في إعادة الكتابة.

نفّذ أيضًا اختبارات التشغيل المطول. قد تستغرق تسريبات الذاكرة، وتسريبات الواصفات، ونمو قائمة الانتظار، وتجزئة المخصص، والتسابقات النادرة ساعات أو أيامًا لتظهر.

يمكن للغة ذات ضمانات أقوى لسلامة الذاكرة أن تزيل فئات كاملة من الأخطاء مع إدخال سلوكيات تخصيص أو جدولة أو أداء مختلفة.

مراجعة الكود غير الآمن، وواجهة الربط مع اللغات الأجنبية، وحدود الأمان بشكل منفصل

تعامل مع كل مما يلي كصنف مراجعة منفصل:

• كتل unsafe
• استدعاءات FFI
• المؤشرات الأولية
• المخصصات المخصصة
• الحدود التشفيرية
• المحلّلات
• مزيلات التجميع
• فحوصات الصلاحيات
• منطق المصادقة
• حدود الاستمرارية

في وقت التقرير المصدر، وصفت Bun حوالي 27,000 سطر داخل كتل unsafe من حوالي 780,000 سطر من Rust، معظمها يتعلق بتكامل C و C++.

هذا السطح يحتاج إلى أكثر من مراجعة كود عادية.

اطلب تعليقًا على الثابت بالقرب من كل حد غير آمن:

• ما الذي يجب أن يكون صحيحًا؟
• من يثبت الثابت؟
• كم تبقى المؤشر صالحًا؟
• أي خيط يملك القيمة؟
• أي اختبار يُمارس الشرط؟

جمّع الأنماط غير الآمنة المتكررة خلف أدوات تغليف تمت مراجعتها. تتبع الأسطر والكتل غير الآمنة حسب المالك بدلاً من معالجة المجموع كمقياس زائف.

استخدم:

• التحليل الثابت
• أدوات التعقيم
• تدقيق التبعيات
• الفازينغ
• المراجعة اليدوية للأمان

جولات مراجعة الأمان الـ 11 لـ Bun هي دليل على التحسين المستمر، وليس دليلاً على غياب العيوب.

يجب أن تكمل المراجعة الآلية للأمان مراجعة المجال، خاصة حول المصادقة، وهروب الصندوق الرملي، والأسرار، وتغييرات سلسلة التوريد.

راجع آلية الترحيل نفسها. الوكلاء ينفذون محتوى المستودع، وملفات البناء، ومخرجات الأدوات. يمكن لتبعية مخترقة أو تعليمات مخفية في الكود المصدر أن تؤثر على التشغيل.

عزل نظام الملفات، وتقييدات الشبكة، والرموز المحددة النطاق، وفحوصات CI غير القابلة للتغيير تقلل من هذا الخطر.

الإصدار على مراحل وممارسة التراجع قبل أن تحتاج إليه

الدمج ليس إصدارًا.

ابنِ مصنوعات ذات إصدارات من عمليات ارتكاز معروفة، وسلاسل أدوات، وأقفال تبعيات، وبيانات إثبات. حافظ على إمكانية بناء التطبيق القديم.

إذا كان بإمكان الثنائيات القديمة والجديدة التعايش، أضف مفتاح تشغيل في وقت التنفيذ أو طبقة توجيه.

بدلاً من استبدال المسار بشكل لا رجعة فيه.

ابدأ بالتنفيذ الظلي عندما يمكن عزل التأثيرات الجانبية.

ثم جرّب باستخدام:

• المستخدمين الداخليين
• المستخدمين ذوي المخاطر المنخفضة
• المنصة
• المنطقة
• نسبة المرور

حدد عتبات التراجع التلقائي لـ:

• عدم تطابق الصحة
• معدل الأعطال
• زمن الاستجابة
• الذاكرة
• فئات الأخطاء
• إشارات الدعم

يجب أن يحتفظ البشر بالقدرة على إيقاف التوسع حتى عندما لا يتم تفعيل العتبات التلقائية.

مارس التراجع.

تأكد من:

• بدء التشغيل القديم بنجاح.
• بقاء المخططات متوافقة.
• إمكانية تصريف العمل المنتظر.
• قدرة المراقبة على تحديد التنفيذ الذي خدم كل طلب.
• استيفاء وقت التراجع المقاس للهدف التشغيلي.

الوثائق الخاصة بالتراجع التي لم يتم تنفيذها قط هي مجرد فرضية.

بعد كل عيب تم تجنبه، قم بتحديث العقد وخريطة الدلالات ومجموعة الاختبارات ونموذج المخاطر.

التراجعات التسعة عشر المعروفة في Bun مفيدة لأنها تكشف عن مخاطر الترجمة المتكررة. يكتمل الترحيل عندما يكون التنفيذ الجديد قابلاً للتشغيل ويكون الفريق قد تعلم منه—وليس عند دمج التغيير المُنشأ.

سياسة الترحيل القابلة لإعادة الاستخدام وبيان الأدلة

تم تصميم YAML التالي كأداة فريق قابلة لإعادة الاستخدام. قم بتكييف الأوامر والعتبات والمالكين حسب المستودع.

يمكن لنظام We0 AI أو أي نظام تنسيق آخر إرفاق هذه السياسة بمهام الترحيل وطلب بيان الأدلة قبل المراجعة.

ai_migration:
  name: payments-python-to-go
  contract: docs/MIGRATION_CONTRACT.md
  semantic_map: docs/PORTING_RULES.md
  old_reference: artifacts/payments-python@sha256:OLD
  new_candidate: artifacts/payments-go@sha256:NEW

  worker_policy:
    isolation: ephemeral_worktree
    one_writer_per_unit: true
    forbidden_commands:
      - "git reset --hard"
      - "git stash"
      - "git push --force"
    editable_paths: ["cmd/", "internal/", "tests/migration/"]
    protected_paths: ["tests/contracts/", "docs/MIGRATION_CONTRACT.md"]

  required_gates:
    compile: "go build ./..."
    unit: "go test ./..."
    contracts: "./scripts/run-contract-tests.sh"
    differential: "./scripts/compare-old-new.sh --corpus fixtures/replay"
    fuzz: "./scripts/fuzz.sh --hours 24 --unique-crashes 0"
    security: "./scripts/security-scan.sh --severity high"
    performance:
      p99_latency_regression_pct: 5
      peak_memory_regression_pct: 10
    platforms: [linux-amd64, linux-arm64]

  independent_review:
    fresh_context: true
    reviewers_per_unit: 2
    require_counterexample_search: true

  rollout:
    shadow_hours: 48
    canary_percentages: [1, 5, 20, 50, 100]
    rollback_artifact_required: true
    rollback_drill_required: true

  evidence_manifest:
    include:
      - contract_version
      - source_and_target_commits
      - changed_units
      - commands_and_exit_codes
      - differential_mismatches
      - fuzzing_summary
      - benchmark_distributions
      - unsafe_or_ffi_inventory
      - reviewer_findings
      - approved_exceptions
      - rollback_drill_result

تمنع هذه السياسة عمدًا عمال التنفيذ من تعديل العقد أو اختبارات العقد المعتمدة.

تتطلب:

• الأجزاء المرجعية
• المراجعة المستقلة
• المقاييس الكمية

حدود الأداء

• أدلة على الترحيل
• مسار عودة مُختبر

الاستثناءات ممكنة، لكن يجب توثيقها والموافقة عليها بدلاً من إخفائها داخل تعليمات النموذج.

قياس التقدم المُوثق، لا حجم المخرجات المُنشأة

عدد أسطر التعليمات البرمجية، وعدد الوكلاء، والأيام المنقضية هي مقاييس قدرة مثيرة للاهتمام. لكنها لا تقيس نجاح المنتج.

استخدم بطاقة أداء متوازنة للترحيل.

إنتاجية الوحدة المُوثقة

تتبع وحدات الترحيل التي:

• يتم تجميعها
• تجتاز فحوصات العقود المستهدفة
• تحصل على مراجعة مستقلة
• تتكامل دون تراجع

قم بقياس الوحدات المقبولة لكل وحدة زمنية.

إغلاق التباين

تتبع الاختلافات المكتشفة وما إذا كان كل منها:

• مُفسرًا
• مُصححًا
• معتمدًا كقصد
• لا يزال دون حل

العيوب المُتسربة

تتبع العيوب التي تجتاز بوابة كان من المفترض أن تمنعها.

يجب أن يحدد كل عيب متسرب قاعدة عقد مفقودة، أو اختبارًا، أو مرجعًا، أو خطوة مراجعة، أو حدًا للترحيل.

الاهتمام البشري

قياس الوقت الذي يقضيه البشر في:

• تعريف العقود
• حل الغموض
• مراجعة التعليمات البرمجية عالية المخاطر
• التحقيق في التباينات
• تشغيل النشر

قد يقلل الذكاء الاصطناعي من وقت التنفيذ مع تحسين جودة المواصفات. هذا مقايضة جيدة، وليس فشلًا في الأتمتة.

تكلفة الحوسبة والأدوات

قياس إجمالي تكلفة النموذج، والحوسبة، والأدوات لكل وحدة مقبولة.

قد تستهلك سير العمل الديناميكية رموزًا أكثر من الجلسات العادية. التوزيع المتوازي مُبرر عندما يقلل وقت انتظار العمل عالي القيمة دون إنشاء تراكم أكبر في التحقق.

قابلية الصيانة بعد الترحيل

تتبع:

• وقت بدء التشغيل
• سرعة البناء
• معدل فشل التغيير
• زمن المراجعة
• كثافة العيوب
• ملكية الوحدات غير الآمنة
• سهولة التصحيح
• جودة التوثيق التشغيلي

النقل الذي يُنفذ بسرعة لكنه يظل غامضًا للفريق قد نقل الدَين بدلاً من إزالته.

كيف يمكن لفريق أن يبدأ دون إعادة كتابة مليون سطر

اختر ترحيلًا محدودًا مع تنفيذ مرجعي مباشر، مثل:

• تغيير إصدار واحد من SDK
• نظام فرعي واحد للإطار
• أمر CLI واحد
• نقطة نهاية خدمة واحدة

اكتب عقد سلوك من صفحة واحدة وثلاث حالات تجريبية تركز على المخاطر.

استخدم مهام وكيل منفصلة للتنفيذ والمراجعة بحيث تظل سياقاتها مستقلة.

قبل التنفيذ:

1. أقفل فحوصات القبول.
2. اطلب من المنفذ إعادة إيداع ودليل، وليس ادعاءً نصيًا.
3. اطلب من المراجع إيجاد أمثلة مضادة وتحديد الاختبارات المفقودة.
4. شغّل الفحوصات في CI خارج النموذج.
5. توسع فقط إلى طبقة التبعية التالية بعد نجاح التجربة.

احتفظ بسجل كامل للتشغيل:

• التعليمة
• النموذج
• نطاق الأداة
• الإيداع المصدر
• الإيداع الهدف
• المسارات المتغيرة
• الفحوصات
• الإخفاقات
• نتائج المراجعة
• الاستثناءات
• التكلفة
• القرار النهائي

يسمح هذا السجل للفريق بمقارنة إصدارات الأدوات والتحقيق في العيوب دون تخمين ما شاهده الوكيل.

استخدم قاعدة اعتماد بسيطة:

الاستقلالية يجب أن تُكتسب.

سير العمل الذي ينتج وحدات مُوثقة بشكل متكرر قد يحصل على نطاق ملفات أوسع أو وقت تشغيل أطول دون مراقبة. لكنه لا يحصل تلقائيًا على إذن النشر.

القدرة، والأدلة، والسلطة تبقى منفصلة.

القيود: ما لا يُثبته حالة Bun

Bun هو مشروع غير معتاد.

قائده قاد

الهجرة، كانت لديها معرفة عميقة بقاعدة الشيفرات، وتمتلك سلطة معمارية مباشرة. كان التنفيذ القديم يحتوي على مجموعة اختبارات كبيرة، ووفّر لغة (راست) ردود فعل قوية من المترجم، وكان بإمكان المشروع استخدام قدرة حوسبة متوازية كبيرة.

لن تتشارك معظم الفرق كل هذه المزايا.

كما تم عرض الحالة من خلال (أنثروبيك)، ويذكر المقال المصدر أن العمل استخدم نموذج (كلود فابل 5) قبل الإصدار. إنه دليل أولي قيم، لكنه ليس مقارنة مستقلة بين البائعين.

الادعاءات حول المدة التي كانت ستستغرقها الفرق البشرية هي تقديرات تخمينية معاكسة للواقع. لا ينبغي للفرق اتخاذ قرارات شرائية بناءً على عملية هجرة ناجحة واحدة.

الـ 19 تراجعًا مبلغ عنها هي تراجعات معروفة، وليست ضمانًا للعدد الكامل. عمليات الفحص بالتشويش وجولات المراجعة الأمنية تقيس الجهد المبذول، لا غياب العيوب.

الاستنتاج الأقوى الذي يمكن الدفاع عنه متواضع:

عمليات الهجرة الواسعة المدعومة بالذكاء الاصطناعي ممكنة عندما تقترن بردود فعل قوية وحتمية وتنسيق خبير، لكن خطرها يظل مشكلة هندسية بعد اكتمال توليد الشيفرات.

هذا الاستنتاج لا يزال ذا معنى. يمكن للفرق محاولة القيام بمشاريع تحديث كانت متأخرة سابقًا بسبب التكلفة، بشرط أن تخصص ميزانية للمواصفات والتحقق والنشر المتحكم به بنفس مقياس التنفيذ.

قائمة الممارسة العملية للهجرة

• تحديد السلوكيات المحفوظة والمعدلة والمهملة وغير المعروفة.
• حصر المنصة والأداء والقياس عن بُعد والأخطاء والعقود الجانبية.
• بناء خريطة دلالية للأنماط الخطرة بين المصدر والهدف.
• حماية العقود والاختبارات المعتمدة من عمال التنفيذ.
• تشغيل وحدات تجريبية صعبة قبل التوسع على مستوى المستودع.
• عزل الكُتاب وتقييد عمليات Git التدميرية وعمليات الشبكة.
• طلب التزامات ذرية مع الأوامر والمخرجات ومراجع العقود.
• استخدام مراجعين خصوميين بسياقات جديدة للوحدات عالية المخاطر.
• تشغيل بوابات المترجم والاختبارات الوحدوية والعقود والتكامل وعبر المنصات.
• مقارنة التنفيذين القديم والجديد على مجموعة تمثيلية من البيانات.
• إضافة فحوصات تحولية وتشويشية ومسحات وأداء.
• حصر حدود unsafe و FFI والمصادقة والمعالجات اللغوية والثبات.
• الحفاظ على أثر عمل قابل لإعادة البناء والرجوع وتنفيذ تدريب على الرجوع.
• النشر عبر مراحل الظل والقناري مع عتبات إيقاف تلقائية.
• تحويل كل عيب يتسرب إلى تحسين في العقد أو التحقق.
• قياس الوحدات التي تم التحقق منها وعدم التطابق والجهد البشري والتكلفة وقابلية الصيانة.

الأسئلة الشائعة

ماذا أعاد (بان) كتابته بلغة (راست)؟

قام (بان) بترحيل تنفيذ رئيسي كان مكتوبًا سابقًا بلغة (زيغ) إلى لغة (راست). يصف الحساب المنشور ما يقرب من 780,000 سطر من شيفرة (راست) وسير عمل مدعوم بالذكاء الاصطناعي شديد التوازي، تبعته اختبارات مكثفة ومراجعة أمنية وتشويش وتقوية إنتاجية.

هل أكمل الذكاء الاصطناعي إعادة كتابة (بان) بلغة (راست) دون مراجعة بشرية؟

لا. لعبت قواعد الهجرة التي كتبها البشر، ومراجعة القطع الأثرية يدويًا، وسير العمل المعزول، وردود فعل المترجم، ومراجعي الوكلاء المستقلين، والمراجعة الأمنية، والتشويش، وعناصر التحكم في النشر الإنتاجي أدوارًا مهمة. من الأفضل فهم الحالة على أنها هندسة مسرعة بالذكاء الاصطناعي وليس تحويل شيفرات دون مراقبة.

لماذا لا تكفي الاختبارات الحالية لعملية

هجرة اللغة؟

عادةً ما تغطي الاختبارات الحالية جزءًا فقط من السلوك الملحوظ. قد تفتقر إلى دلالات الإصدار فقط، أو الاختلافات بين المنصات، أو تراجع الأداء، أو الحدود غير الآمنة، أو تغييرات القياس عن بُعد، أو الحالات الهامشية التي لم تُدرج مطلقًا في مجموعة الاختبارات.

ما هو الاختبار التفاضلي في هجرة الكود؟

يقوم الاختبار التفاضلي بتشغيل التطبيقات القديمة والجديدة بنفس المدخلات ومقارنة مخرجاتها الملحوظة وآثارها الجانبية. وهو مفيد بشكل خاص عندما يُعتد بالنظام القديم ولكن لا توجد مواصفات رسمية كاملة.

لماذا يجب أن يستخدم منفذو التطبيق والمراجعون سياقات منفصلة؟

من غير المرجح أن يرث المراجع الجديد افتراضات المؤلف وأخطاء الاستدلال. يمكن للمراجع التركيز على العقد، والفرق، والأدلة، والأمثلة المضادة بدلاً من الدفاع عن مسار التطبيق الذي أنتج التغيير.

كيف يجب على الفرق مراجعة كود unsafe في Rust أثناء الهجرة؟

يجب أن يكون لكل كتلة unsafe أو حدود FFI مالك معين، وثوابت موثقة، واختبارات مستهدفة، وشرح واضح لصلاحية المؤشر، والعمر الزمني، وملكية الخيط. يجب تطبيق التحليل الثابت، وأدوات التعقيم، والاختبار العشوائي، ومراجعة التبعيات، والمراجعة الأمنية اليدوية بشكل منفصل عن مراجعة الكود العادية.

ما المقاييس التي يجب أن يتتبعها هجرة الكود بمساعدة الذكاء الاصطناعي؟

تتبع إنتاجية الوحدات المُتحقق منها، وإغلاق عدم التطابق، والعيوب الهاربة، والانتباه البشري، وتكلفة الحوسبة، وصحة الطرح، وقابلية الصيانة بعد الهجرة. عدد الأسطر المولدة وعدد العوامل هي مقاييس للسعة، وليست دليلاً على الصحة.

هل يمكن لفريق صغير استخدام هذا الدليل دون تشغيل عشرات العوامل؟

نعم. ابدأ بمكون واحد محدد، وعقد سلوك مكتوب، وثلاث تجارب تجريبية تركز على المخاطر، وسياقات منفصلة للتطبيق والمراجعة، وبوابات CI حتمية، ومسار تراجع مُختبر. قم بتوسيع سير العمل فقط بعد أن ينتج نتائج قابلة للتحقق بشكل متكرر.

الأدوات ذات الصلة

• Bun: مجموعة أدوات شاملة لجافا سكريبت وتايب سكريبت توفر هجرتها إلى Rust دراسة الحالة الرئيسية لهذا الدليل.
• Rust: لغة برمجة أنظمة توفر ضمانات أمان قوية في وقت الترجمة وحدود unsafe صريحة.
• Claude Code: بيئة البرمجة الوكيلية من Anthropic، المستخدمة في سير العمل الديناميكي الموصوف في المصدر.
• GitHub Actions: منصة CI/CD مناسبة للبوابات الحتمية للتجميع، والاختبار، والأمان، والقياس، والأدلة.
• cargo-fuzz: أداة اختبار عشوائي قياسية لمشاريع Rust مبنية على libFuzzer.
• Miri: مترجم Rust يمكنه اكتشاف أشكال معينة من السلوك غير المحدد في الكود غير الآمن.

الروابط ذات الصلة

• Bun: إعادة كتابة Bun في Rust: السرد الهندسي الرسمي لـ Bun لعملية إعادة الكتابة، والتقوية الإنتاجية، والاختبار العشوائي، والتراجعات المعروفة.
• مستودع مصدر Bun: مستودع Bun الرسمي الذي يحتوي على تطبيق Rust، والمشكلات، والاختبارات، وتاريخ الهجرة.
• [Anthropic: تقديم سير العمل الديناميكي](https://claude.

(https://code.claude.com/docs/en/best-practices): إرشادات رسمية حول هيكلة المهام، وسياقات المراجعة الجديدة، والاختبار، وسير عمل البرمجة الطويلة.

• عزل بيئة Claude Code: شرح من Anthropic لعزل نظام الملفات والشبكة لتحقيق برمجة ذاتية أكثر أمانًا.
• The Rustonomicon: لقاء بين الآمن وغير الآمن: إرشادات Rust الرسمية حول الحدود بين الكود الآمن وغير الآمن.
• وثائق GitHub CODEOWNERS: وثائق GitHub للملكية القابلة للقراءة آليًا وسير عمل المراجعة الإلزامية.

الخلاصة

يُظهر إعادة كتابة Bun بلغة Rust أن وكلاء البرمجة بالذكاء الاصطناعي يمكنهم ضغط وقت التطوير بشكل كبير، ولكنه يوضح أيضًا لماذا يجب أن يصبح التحقق نظامًا هندسيًا من الدرجة الأولى. تعد العقود، والخرائط الدلالية، والعمال المعزولون، والمراجعة المستقلة، والاختبار التفاضلي، والاختبار العشوائي، وميزانيات الأداء، والنشر المرحلي هي ما يحول الكود المولد إلى دليل موثوق على نجاح الترحيل.

الدرس العملي ليس في نسخ عدد الوكلاء أو سطور الكود. بل في تقسيم الترحيل إلى ادعاءات محددة، وطلب دليل قاطع على كل ادعاء، وتوسيع الاستقلالية فقط بعد أن يُنتج سير العمل نتائج موثوقة بشكل متكرر.

لا تكتمل إعادة الكتابة المدعومة بالذكاء الاصطناعي على نطاق واسع إلا بعد التحقق من النظام الجديد، وقابليته للتشغيل، والاسترداد، والفهم - وليس عند دمج الكود المُولّد.