النقاش مو خلص
كل ما زادت أدوات البرمجة بالذكاء الاصطناعي، رجع نفس السؤال: هل لازم المشروع المفتوح المصدر يمنع الكود اللي ساعد نموذج لغوي بكتابته؟ في مشرفين بيخافوا من أخطاء مخفية، ومن صعوبة معرفة مصدر الكود، ومن ضغط مساهمات سريعة ما حدا راجعها منيح. وبالمقابل، في ناس شايفين إن الأداة بحد ذاتها مو معيار جودة.
بتقرير Ars Technica عن نقاشات Linux، Linus Torvalds ردّ على مشرفين بدهم مشاريعهم ترفض رقع LLM بشكل مبدئي. الفكرة المنسوبة إله إن الكود لازم ينحكم عليه بميزته التقنية، متل أي مساهمة كمانة، مو فقط بالطريقة اللي انكتب فيها. وعبارته الحادة كانت إن اللي بيشكك بفائدة AI غالباً ما جرّبه فعلياً.
شو يعني الحكم على الرقعة؟
يعني إن عملية المراجعة ما بتتغير: هل التعديل بيحل المشكلة؟ هل الاختبارات بتمر؟ هل الكود واضح وقابل للصيانة؟ هل في آثار جانبية؟ هل في توثيق؟ وهل التغيير صغير ومحدد كفاية حتى ينراجع؟
إذا الرقعة فاشلة، ما لازم نقبلها لأن النموذج كتبها. وإذا الرقعة جيدة، رفضها فقط لأن فيها مساعدة آلية ممكن يحرم المشروع من مساهمة مفيدة. هاد مو دفاع عن ترك النماذج تكتب بلا مراقبة؛ هو دفاع عن معيار قابل للفحص بدل حكم مبني على الانطباع.
فين الخطر الحقيقي؟
الخطر مو بكلمة AI بحد ذاتها. الخطر لما المساهم يرسل كود ما فهمه، أو لما الوكيل يضيف تغييرات جانبية، أو لما المشروع ما عنده اختبارات تكشف الانحدارات. المراجعة البشرية ما بتصير أقل أهمية مع الوكيل؛ بالعكس، لازم تصير أوضح.
المشكلة كمان إن بعض المشاريع ممكن تستخدم منع AI كطريقة سهلة بدل ما تستثمر بمراجعة أفضل. وبنفس الوقت، بعض المساهمين ممكن يستخدموا كلام "الكود مولّد" حتى يبرروا إرسال رقعة كبيرة ومبهمة. بالنتيجتين، المقياس التقني بيضل أفضل من الشعارات.
كيف تستخدم هالمنطق بمشروعك؟
إذا عم تستخدم Claude Code أو Codex على مشروع مفتوح، لا تبعت النتيجة مباشرة. خلي الوكيل يشرح التغيير، شغّل الاختبارات، راجع الفرق سطر بسطر، وخلي عنوان الـ commit يصف السبب الحقيقي. إذا في جزء ما فهمته، وقّف قبل الدمج.
ولما تراجع مساهمة من شخص كمان، اسأل نفس الأسئلة بغض النظر عن الأداة: هل الكود صحيح؟ هل بيحترم أسلوب المشروع؟ هل في اختبار؟ هل التغيير ضروري؟ هاد بيحمي المشروع من الكود السيئ بدون ما يحوّل المراجعة إلى محكمة على الأدوات.
موقف Torvalds ما بيحل كل مشاكل AI بالبرمجة، بس بيحط النقاش بمكان مفيد: لا تسأل فقط "هل استخدم نموذج؟" اسأل "هل الرقعة مفهومة، قابلة للاختبار، وبتحسن المشروع؟" هاد معيار أصعب من المنع، بس هو المعيار اللي بيقدر يعيش مع أي أداة جديدة.
الشفافية بتساعد المراجعة
حتى لو المشروع ما عنده منع رسمي، المساهم لازم يكون صريح إذا استخدم وكيل. مو لأن الكود صار أقل قيمة، بل لأن المشرف ممكن يحتاج يعرف كيف يراجع التغيير أو يطلب شرح أعمق. الإفصاح ما بيغني عن الاختبارات، والاختبارات ما بتغني عن فهم الكود، بس الاثنين بيخلّوا العملية أوضح.
وفي فرق بين مساعدة صغيرة وبين تفويض مهمة كاملة. اقتراح اسم متغير مو مثل إن الوكيل يعيد كتابة نظام مصادقة. كل ما كبرت صلاحية الأداة وحجم التغيير، لازم تكبر المراجعة معه.
بالنهاية، المشروع المفتوح بيحتاج مساهمات قابلة للصيانة، سواء كتبها شخص من الصفر أو استعان بأداة. أفضل طريقة تحمي الجودة هي إنك تطلب رقع صغيرة، توثيق واضح، اختبارات، وسبب محدد لكل تغيير. هيك بتصير الأداة وسيلة ضمن العملية، مو بديل عن المسؤولية.