خصص عمالقة التقنية الأميركيون نحو 13 مليون دولار لحماية open source من بلاغات الأعطال التي يولدها AI

خصصت كبرى شركات التكنولوجيا الأمريكية ما يقارب 13 مليون دولار لدعم المشرفين على صيانة مشاريع open source، الذين يتلقون بشكل متزايد سيلًا من bug reports الضعيفة المكتوبة عبر AI بدلًا من بلاغات الأعطال الحقيقية. وبالنسبة إلى المنظومة ككل، فهذه ليست مضايقة صغيرة: فعندما يضيع وقت القائمين على المشاريع في فرز الضجيج، تتأخر الإصلاحات والإصدارات المهمة وتحديثات الأمان.

كيف تضاعف الضجيج

نشأت المشكلة عند تقاطع اتجاهين: فقد تعلمت المساعدات التوليدية كتابة نصوص تبدو معقولة بسرعة، واعتاد المستخدمون تمرير كل شيء عبرها، من الرسائل إلى التذاكر في issue tracker.

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

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

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

ومع ذلك، يظل على المشرف فتح هذا ticket وقراءته، ومقارنته مع issues الموجودة، ثم تقرير ما إذا كان يفوّت عطلًا حقيقيًا.

وسرعان ما يستنزف هذا الفلتر اليدوي الفريق.

لماذا تضر هذه التقارير

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

وفي open source، يكون ذلك مؤلمًا بشكل خاص: فقد يكون شخص واحد مسؤولًا في الوقت نفسه عن الكود والإصدارات والتوثيق والتواصل مع المجتمع.

وعندما يزداد تدفق tickets المشكوك فيها عند المدخل، تبدأ bugs الحقيقية بالغرق في الطابور.

ويظهر ذلك في علامات نموذجية:

• لا توجد خطوات دقيقة لإعادة الإنتاج ولا logs
• توجد عبارات عامة عن المشكلة، لكن من دون حقائق قابلة للتحقق
• يجري تكرار issues معروفة أو مغلقة بالفعل
• تُقترح تعديلات لا ترتبط بالكود الفعلي للمشروع
• لا يرد الكاتب على الأسئلة التوضيحية أو يختفي بعد النشر

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

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

وكلما انخفضت كلفة إنشاء ticket، ارتفعت كلفة مراجعته بالنسبة إلى المشروع.

ولهذا تحديدًا يبدو تخصيص ما يقارب 13 مليون دولار لدعم المشرفين أقل شبهاً بلفتة حسن نية وأكثر شبهاً بمحاولة لإنقاذ القدرة الاستيعابية لـ open source.

ويمكن أن تمنح هذه الأموال أصحاب المشاريع وقتًا لعمليات triage، ولمراجعة الرسائل الواردة، وضبط القوالب والقواعد الخاصة بـ issue tracker، وكذلك لتطوير عمليات أكثر صرامة في استقبال bug reports.

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

ماذا يعني ذلك

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

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

والخطوة التالية، على الأرجح، ستكون نماذج أكثر صرامة لتقديم issues، والتحقق الآلي من التقارير، ومعايير سلوك جديدة للمستخدمين الذين اعتادوا تفويض AI حتى في الشكاوى المتعلقة بالbugs.