أبقت IETF Tools مراجعة شيفرة الذكاء الاصطناعي سطرًا بسطر، لكن الحد التالي لم يُكتب بعد

الخلاصة

• في 6 أغسطس 2026 حذّر فريق IETF Tools من أن طلبات السحب الكبيرة المكتوبة بمساعدة الذكاء الاصطناعي قد تجعل قراءة كل سطر نوعًا من حجب الخدمة لقدرة الفريق على المراجعة. كان ذلك توقعًا لمشكلة سعة، لا بلاغًا عن هجوم أو توقف وقع بالفعل.
• الإرشادات المشتركة التي دُمجت في 25 أغسطس لم تعتمد مسار المراجعة الأخف. فما زالت كل مساهمة تدخل طابورًا يقرأ فيه مسؤول واحد أو أكثر عن الصيانة كل سطر، ويُقبل الكود المولد بالذكاء الاصطناعي إذا استوفى المتطلبات العامة نفسها.
• تنقل القاعدة بعض كلفة الفهم إلى صاحب المساهمة: شرح بشري يناسب حجم التغيير، وعمليات إيداع صغيرة قابلة للفحص، واختبارات مناسبة، وتبرير للتبعيات، وشخص يفهم الغرض والتوافق ويلتزم بإصلاح المشكلات لاحقًا.
• إذا خُفّضت المراجعة البشرية مستقبلًا لشيفرة مصنفة منخفضة الأثر، فينبغي أن يصاحب كل استثناء «إيصال لحدود المراجعة» يحدد المصنِّف، والسطح المتأثر، والأدلة، وما قرأه البشر فعلًا، ودور الأداة الآلية، وصاحب قرار الدمج، ومسؤول الصيانة، وشروط التصعيد والتراجع.

قد يُستنزف المراجع من دون أن يتعطل أي خادم

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

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

قالت النشرة إن الاستمرار في قراءة كل سطر قد يصير حجبًا للخدمة. لا ينبغي تحميل العبارة أكثر مما تحتمل. فهي لا تثبت وجود مساهمة خبيثة، ولا تصف اختراقًا، ولا تقول إن خدمة Datatracker توقفت أو إن بيانات IETF تضررت. إنها تشخّص عدم تماثل: توليد الطلب رخيص، بينما استيعابه الآمن باقٍ مكلفًا.

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

طرحت مناقشة أغسطس مسارين ولم يتحول سوى أحدهما إلى قاعدة

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

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

النص الذي أصبح نافذًا أكثر تحفظًا.

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

يثبت سجل الإيداع 6d3b1c5 تاريخ 25 أغسطس 2026، ويصف الإضافة بأنها متطلبات اتُّفق عليها في خلوة الفريق. وعند إعداد هذه المادة كان الملف الحالي على الفرع الرئيسي مطابقًا له بايتًا ببايت.

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

إذن فالتسلسل الصحيح هو: مشكلة معلنة، بديل ما زال مطروحًا، ومتطلبات دخول طُبقت مع بقاء قاعدة قراءة كل سطر.

القاعدة الجديدة تجعل المساهم يهيئ مادة قابلة للرفض

لا تضمن المتطلبات صحة الشيفرة، لكنها تجعل قرار الرفض ممكنًا قبل أن تتراكم كلفة ضخمة.

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

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

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

لماذا لا يكفي لون الاختبار الأخضر

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

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

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

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

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

الإنسان يقدّم ضمان صيانة لا مسرحية تأليف

إرشاد مستخدمي وكلاء البرمجة محدد بعناية.

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

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

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

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

الثقة سجل علاقة وليست خاصية في الشيفرة

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

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

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

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

«منخفض الأثر» حكم يمنح مسارًا مختلفًا

المراجعة المتناسبة فكرة سليمة من حيث الأصل.

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

لكن الأثر ليس رقمًا يستخرج تلقائيًا من عدد الأسطر.

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

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

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

إيصال يصف ما لم يراجعه الإنسان

يمكن لمسار منخفض الأثر أن يحمي الأسرار ويظل قابلًا للتدقيق.

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

ثم يسجل الشخص الداعم، والمصنِّف، والتاريخ، ونسخة السياسة. وينظر منفصلًا إلى الأمن، وسلامة البيانات، والخصوصية، والأداء، والتوافر، وحفظ سجلات المعايير، وقابلية التراجع. الدرجة الواحدة تخفي الافتراضات.

يربط قسم الأدلة كل خطر بما قُدم: خطة بشرية، واستراتيجية الاختبارات وتغطيتها، والتبعيات، ونتائج الأداء، وفحوص الأمن، وترحيل البيانات، والنشر المرحلي، وتجربة التراجع. إذا كان سبب تخفيض القراءة هو قوة الاختبارات، فلا تكفي عبارة «نجحت الاختبارات»؛ يجب بيان ما أثبتته وما لم تختبره.

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

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

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

قد تعارض أداة آلية أداة أخرى، لكنها لا تتحمل الخسارة

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

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

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

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

لذلك يُسجل ناتجه كدليل محدود النطاق، وتبقى سلطة القرار منسوبة إلى إنسان.

تشغيل أدوات المعايير لا يمنح سلطة صناعة المعايير

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

هذه الأهمية التشغيلية لا تساوي سلطة معيارية.

يوكل RFC 8711 إلى IETF LLC العمليات والدعم الإداري، ويؤكد في الوقت نفسه أنه لا يملك سلطة على أنشطة تطوير المعايير. وتعكس إرشادات المساهمة ذلك حين تطلب حل قرار السياسة الجماعية قبل تقديم كود يعتمد عليه.

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

تفيد فكرة أولوية الشيفرة العاملة عند Heng Lu هنا إذا استُخدمت بحدود: يجب أن يضبط الواقع التشغيلي القابل للتحقق الرواية المؤسسية. وهذا لا يعني أن الكود المنشور يتغلب على عملية معايير IETF؛ بل يعني ألا يخفي الوصف الإداري من جعل الكود يعمل، وبأي دليل، وتحت أي مسؤولية.

ويكشف تحليله لـمشكلة الوكالة في حوكمة الإنترنت اختلاف الحوافز. يريد المساهم القبول. وينتج الوكيل حلًا مقنعًا. ويريد مدير الطابور تقليص التراكم. ويريد المراجع إنهاء العمل. أما المنظمة والمستخدمون فيرثون الذيل الطويل. لا يوحّد الإيصال المصالح، لكنه يمنع اختفاء أصحابها داخل عبارة «شيفرة ذكاء اصطناعي».

كتابة الاستثناء قبل أن يفرضه ضغط الطابور

لا تثبت السجلات المفحوصة أن IETF Tools خفّض المراجعة بالفعل، أو تعرض لمساهمة آلية خبيثة، أو خالف دليله، أو أعطى أداة حق الدمج.

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

لا تكفي عبارة «سيظل الإنسان داخل الحلقة». قد يكون الإنسان داخلها لأنه قرأ ملخصًا وضغط زرًا. السؤال النافع هو: أي إنسان، وفي أي خطوة، وما الذي قرأه، وما الذي لم يقرأه، وبأي دليل آلي، وتحت أي نسخة من القاعدة، وبأي التزام لاحق؟

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