حاليًا، قد يحاول بعض الأشخاص رفع إضافات أو سمات أو مكونات تم توليدها بالكامل بواسطة نماذج اللغة الكبيرة (LLMs) دون الإفصاح عن ذلك. هناك العديد من الأسباب التي تجعل من المفيد معرفة متى يكون المحتوى مُولَّدًا بالكامل بواسطة نموذج لغة كبيرة، ولا يوجد في الوقت الحالي أي التزام بالإفصاح عن هذه الإضافات على هذا النحو. شخصيًا، أودّ أن أعرف ذلك مسبقًا حتى لا أقع في فخ تثبيت إضافة منخفضة الجودة مليئة بمشاكل الأداء والتحسين وتجربة المستخدم التي تعاني منها الإضافات المولَّدة بواسطة نماذج اللغة.
من الواضح أن هذا يعتمد على صدق الناس وشفافيتهم (وقد لا يعرف أصحاب المواضيع المولَّدة بالذكاء الاصطناعي أكثر مما هو مكتوب فيها)، لكن وجود وسم مثل #ai-generated يُضاف إلى الأصول التي تم توليدها بالأساس بواسطة الذكاء الاصطناعي سيكون مفيدًا للجميع.
لا أتفق مع فكرة أن الإضافة المولّدة بواسطة نموذج لغة كبير (LLM) تكون بطبيعتها منخفضة الجودة أو تعاني حتماً من مشاكل في الأداء أو التحسين أو تجربة المستخدم. يعتمد جودة النتيجة بشكل كبير على الشخص الذي يوجّه النموذج ويراجع مخرجاته.
فخرتُ دائماً بالبرمجيات التي طوّرتها على مدار الأربعين عاماً الماضية، وقد أدّى دمج نماذج اللغة الكبيرة في سير عملي إلى تحسين جودة عملي، لا إلى تقليلها.
وعلى العكس من ذلك، رأيتُ العديد من الإضافات المكتوبة يدوياً مليئة بالثغرات الأمنية ومشاكل الأداء وقرارات تصميم سيئة، حيث تمنيتُ حقاً أن يكون المؤلف قد استخدم نموذج لغة كبيرة. في النهاية، ما يهم هو جودة المطوّر والنتيجة النهائية للكود، وليس ما إذا كان نموذج لغة كبيرة قد شارك في كتابته.
أتساءل كيف تقترحون مراجعة و/أو تحديث الأكواد المولّدة بواسطة نماذج اللغة الكبيرة (LLMs)، لأولئك منا الذين يبدأون في ممارسة “برمجة الإحساس” (vibe-coding) لتنفيذ وظائف جديدة أو تخصيص الوظائف الموجودة فعليًا.
أعلم أن المراجعة الجماعية في المستودعات العامة هي الخيار الأمثل، لكنني أودّ أولاً أن أُنجز واجباتي وأُنشر فقط الإصدارات التي استنفدت قدرتي الحالية.
أوافق على التعليق السابق، فليس الأمر ضد الذكاء الاصطناعي، ولكن في الوقت نفسه نحن على وعي بأن كل ما يولّده يجب تدقيقه والتحقق منه وتحديثه من قِبل البشر.
هذا منطقي تماماً، وفي نهاية المطاف، لا يُسمح لي إلا بالحديث عن نفسي، وهو ما استند إلى ملاحظاتي حول تطبيقات منخفضة الجودة (“سَلوب”) تبدو جميعها متطابقة وتكون عادةً ضعيفة الجودة (من حيث الوظائف والأمان)، بالإضافة إلى التطبيقات الموجودة التي تدهورت جودتها بشكل كبير منذ أن بدأت في تفويض العمل بشكل كبير لنماذج اللغة (مثل Visual Studio Code وFormbricks؛ وكلاهما توقفت عن استخدامه منذ ذلك الحين). حتى لو كان تطبيقك مثالياً، لا تزال هناك مخاوف أخلاقية، لذا سيكون من الرائع وجود شكل من أشكال التنبيه لهذه الإنشاءات كما تم اقتراحه. هذا لا يعني أن على أي شخص أن يجبر نفسه على الاعتماد على العلامة، ولكن إذا كنت ترغب في ذلك، فالخيار لطيف.
كما قلت، هذا نظام يعتمد بشكل جوهري على الثقة، ومسؤولية المطوّر الوحيد لضمان وضع العلامة المناسبة عليه. بالطبع، هناك بعض الحالات حيث يضع نموذج اللغة نفسه علامة في سجلات Git (كما يفعل معظمها)، لذا يمكن لشخص بمستوى ثقة 3+ (TL3+) اتخاذ إجراء إذا رغب في ذلك من خلال الاطلاع على GitHub.
أقدّر ردّك، شكرًا لك. استفساري موجّه أيضًا إلى الجميع، ويتعلق بالأدوات الموجودة حاليًا للتحقق من الأكواد المولّدة بواسطة نماذج اللغة (LLMs).
لست مطوّرًا، لكنني تمكنت من تنفيذ وظائف لم تكن موجودة في Discourse. وأريد أن أفعل ما هو في متناول يدي بأفضل طريقة ممكنة.
سأفكر في وضع علامة على المستودعات إذا قررت نشرها؛ فحتى الآن، هي خاصة تمامًا لأنني أختبرها، وأنا مهتم بالقيام بالأشياء بشكل صحيح قبل مشاركتها مع المجتمع.
لن أكون متفاجئًا للغاية إذا لم يكن معظم كود النواة (بما في ذلك إضافات النواة) مبنيًا حاليًا باستخدام وكلاء البرمجة، نظرًا لمدى التغير الذي طرأ على عملية التطوير.
في رأيي، أصبح من الصعب جدًا تبرير عدم استخدام وكلاء البرمجة في معظم المهام، لأن الانخفاض في الكفاءة ببساطة لن يكون منطقيًا من الناحية التجارية.
لا يقلقني إطلاقًا «كيف تم تشكيل الإضافة» أو ما إذا كان صانعها استخدم قلم رصاص أم قلم حبر.
عبارة «لا توجد ذكاء اصطناعي هنا» لا تمنحني أي ثقة إضافية، ولو بجزء يسير، عند تثبيت سمة أو إضافة.
ومع ذلك… هناك مشكلة أكثر خطورة بكثير نحتاج إلى معالجتها في CDCK.
الإضافات الأساسية وأكواد المصدر في Discourse تخضع لفحوصات أمنية بشكل منتظم، وعندما يقوم شخص بتثبيت قناة مدعومة، فإنه يثق في مدى أمان الكود.
لكن الإضافات والسمات الخاصة بالأطراف الثالثة هنا هي «غرب جدي»، حيث يمكن لأي شخص المساهمة، ولا نقوم بفحصها أمنيًا أو التأكد من أنها تتبع أفضل الممارسات. وهذا يعرّض المجتمع للخطر.
أود الوصول إلى عالم تكون فيه الإصدار «XYZ» من السمة على الأقل خاضعًا لفحص آلي، لمنح أصحاب الاستضافة الذاتية بعض الثقة على الأقل.
لذلك، رؤيتي هنا هي عكس ذلك تمامًا أن تتطلب إصدارات السمات والإضافات الخاصة بالأطراف الثالثة اجتياز نوع من الفحص بالذكاء الاصطناعي قبل الإعلان عنها هنا.
مراجعة الكود بواسطة نماذج اللغة الكبيرة (LLM) مختلفة تمامًا عن طلب «يا كلود، ابنِ لي هذه التطبيق دون ارتكاب أي أخطاء» ثم نشر المخرجات مع إجراء القليل من التحقق أو التعديلات، على الأقل من منظور أخلاقي. للأسف، لا يمكنك إجبار المستخدم النهائي على تحمل المسؤولية، مهما حاولت، فسيجد شخص ما دائمًا طريقة لتحميل شيء ضار. لكن على أي حال، مدى أخلاقيات نماذج اللغة الكبيرة هو موضوع منفصل ولا علاقة له بهذا الموضوع.
وهذا أمر رائع! أنا لا أقترح حظرًا شاملًا لأي شيء يتضمن استخدام الذكاء الاصطناعي في قسم Customization.. أود فقط أن يتم وضع الوسوم بشكل صحيح حتى لا يقع أولئك الذين لا يريدون فتح هذه «علبة الدود» في ذلك عن طريق الخطأ.
أن تتطلب إصدارات السمات والإضافات الخاصة بالأطراف الثالثة اجتياز نوع من الفحص بالذكاء الاصطناعي قبل الإعلان عنها هنا.