الطلب من وضع علامة على القوالب والإضافات المولّدة بواسطة LLM على هذا النحو

ساهم ملاحظات حول الموقع
1

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

من الواضح أن هذا يعتمد على صدق الناس وشفافيتهم (وقد لا يعرف أصحاب المواضيع المولَّدة بالذكاء الاصطناعي أكثر مما هو مكتوب فيها)، لكن وجود وسم مثل #ai-generated يُضاف إلى الأصول التي تم توليدها بالأساس بواسطة الذكاء الاصطناعي سيكون مفيدًا للجميع.

إعجابَين (2)
DiscourseSkill.md
2

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

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

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

11 إعجابًا
3

أتساءل كيف تقترحون مراجعة و/أو تحديث الأكواد المولّدة بواسطة نماذج اللغة الكبيرة (LLMs)، لأولئك منا الذين يبدأون في ممارسة “برمجة الإحساس” (vibe-coding) لتنفيذ وظائف جديدة أو تخصيص الوظائف الموجودة فعليًا.

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

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

شيء غريب يتعلق بالموضوع:

إعجاب واحد (1)
4

هذا منطقي تماماً، وفي نهاية المطاف، لا يُسمح لي إلا بالحديث عن نفسي، وهو ما استند إلى ملاحظاتي حول تطبيقات منخفضة الجودة (“سَلوب”) تبدو جميعها متطابقة وتكون عادةً ضعيفة الجودة (من حيث الوظائف والأمان)، بالإضافة إلى التطبيقات الموجودة التي تدهورت جودتها بشكل كبير منذ أن بدأت في تفويض العمل بشكل كبير لنماذج اللغة (مثل Visual Studio Code وFormbricks؛ وكلاهما توقفت عن استخدامه منذ ذلك الحين). حتى لو كان تطبيقك مثالياً، لا تزال هناك مخاوف أخلاقية، لذا سيكون من الرائع وجود شكل من أشكال التنبيه لهذه الإنشاءات كما تم اقتراحه. هذا لا يعني أن على أي شخص أن يجبر نفسه على الاعتماد على العلامة، ولكن إذا كنت ترغب في ذلك، فالخيار لطيف.

كما قلت، هذا نظام يعتمد بشكل جوهري على الثقة، ومسؤولية المطوّر الوحيد لضمان وضع العلامة المناسبة عليه. بالطبع، هناك بعض الحالات حيث يضع نموذج اللغة نفسه علامة في سجلات Git (كما يفعل معظمها)، لذا يمكن لشخص بمستوى ثقة 3+ (TL3+) اتخاذ إجراء إذا رغب في ذلك من خلال الاطلاع على GitHub.

5

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

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

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

6

لن أكون متفاجئًا للغاية إذا لم يكن معظم كود النواة (بما في ذلك إضافات النواة) مبنيًا حاليًا باستخدام وكلاء البرمجة، نظرًا لمدى التغير الذي طرأ على عملية التطوير.

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

3 إعجابات
7

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

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

ومع ذلك… هناك مشكلة أكثر خطورة بكثير نحتاج إلى معالجتها في CDCK.

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

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

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

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

8 إعجابات
8

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

وهذا أمر رائع! أنا لا أقترح حظرًا شاملًا لأي شيء يتضمن استخدام الذكاء الاصطناعي في قسم Customization.. أود فقط أن يتم وضع الوسوم بشكل صحيح حتى لا يقع أولئك الذين لا يريدون فتح هذه «علبة الدود» في ذلك عن طريق الخطأ.

9

لديّ الكثير من المشاكل مع الأدوات القائمة على نماذج اللغة الكبيرة (LLM) (والمخرجات التي تنتجها). وليس الأمر يتعلق فقط بمشاكل الأمان والقانون والموثوقية والبيئة. لكن هذا ليس هو المشكلة الرئيسية هنا.

الأمان، بالمعنى الواسع، هو القضية المهمة هنا. سواء كان الكود مُنشأً بواسطة الذكاء الاصطناعي أم لا.

ما الأدوات التي تستخدمها CDCK لفحوصات الأمان؟ ستكون العديد منها مهمة أيضاً للأنشآت التي تنشئها الأطراف الثالثة.

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

10

أوافق على ذلك بنسبة 95%. ونحن الآن نتحدث عن Discourse، فتخيلوا لو كنا في عالم ووردبريس!

(النسبة المتبقية 5%: لا أعتقد أنها “غرب برّي” - فمشاكل الأمان تُبلَّغ عنها عبر meta إلى مطوري الأطراف الثالثة، وبشكل عام يتم إصلاحها بسرعة كبيرة).

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

لقد كنت أراجع الإضافات يدوياً على مدى العقد الماضي وشهدت الكثير: حقن SQL (من أشخاص ظنوا أن ActiveRecord متعجرف)، إعدادات مفاتيح API تحتوي على client: true، انعدام تام للتفويض والتحكم في الوصول، وانعدام تحديد معدل الطلبات. جميعها تُكتشف وتُصلح بواسطة نماذج اللغة الكبيرة في وقت قصير وبدون الكثير من الجهد.

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

أنت ما زلت ترتبط بين الكود المولّد بواسطة نماذج اللغة الكبيرة بـ “علبة دود”، وهذا أمر أسود وأبيض للغاية.

4 إعجابات
11

جاك ماكداد اتبع هذا النهج مع دليل إضافات Statamic

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

يبدو أنه يمكن تنفيذ شيء مشابه هنا دون عناء كبير من قبل الفريق.

4 إعجابات
12

أنا أيضًا قلق من الإضافات والمكوّنات ذات الجودة المنخفضة، ولا أثق بها حقًا عندما تكون مُبرمجة بنسبة 99% بناءً على الحدس (Vibe Coding) من قِبل شخص لا يعرف شيئًا عن البرمجة.

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

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

على الرغم من أنني أملك بعض المعرفة الأساسية في البرمجة، إلا أنني لم أكتب أي كود منذ فترة طويلة، ولم أكن أبدًا جيدًا في ذلك. جربتُ البرمجة بناءً على الحدس (Vibe Coding) لعدة مشاريع.

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

لديّ مثال جيد يوضح كيف كان بإمكان البرمجة بناءً على الحدس أن تجعلني أنشر إضافة غير آمنة للغاية.

قبل العمل على 🖼️ Topic Gallery، عملتُ على إنشاء نموذج أولي (Proof of Concept) لإضافة مشابهة هنا: A way to monitor user-uploaded files 🖼️ - #2 by Canapin
كان يعمل بشكل رائع، والتزم الذكاء الاصطناعي بتوجيهاتي.

لكن كان هناك مشكلة: على الرغم من أن الميزة كانت بوضوح ميزة للمراقبة (Moderation)، إلا أن الذكاء الاصطناعي لم يأخذ الصلاحيات في الاعتبار: أي مستخدم، بما في ذلك الزوار، كان قادرًا على فتح هذه الصفحة وعرض جميع الملفات التي رفعها جميع المستخدمين. كان من الواضح بالنسبة لي أن يجب أن تكون هذه الصفحة للإدارة فقط، لكن الذكاء الاصطناعي لم “يفكر” في ذلك. وبما أنني لم أطلب ذلك منه، فقد أنشأ صفحة عامة افتراضيًا.

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

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

لستُ مؤيدًا بشكل خاص لوجود نوع من وسم vibe-coded (مُبرمج بالحدس) قد يضر بشكل غير ضروري بشعبية التخصيصات الآمنة والمُبرمجة جيدًا ومُؤلفيها.

أعلم أن أي شخص يمكنه الآن إنتاج تخصيصات، وقد يأتي المزيد والمزيد منها كل يوم، ولا يوجد عدد كافٍ من الأشخاص لمراجعتها.

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

ربما يمكن لبعض المطورين هنا الذين يعرفون البرمجة ونظام Discourse الإيكولوجي أن يحصلوا على لقب يُظهر صراحةً خبرتهم في هذا المجال، بحيث يمكن اعتبارهم مطورين موثوقين حتى من قِبل الزوار الذين يبحثون فقط عن تخصيصات هنا دون تسجيل. سيكون هذا عكس ما تطلبه، darkpxlz. فبدلًا من “إحراج” التخصيصات التي قد تكون غير موثوقة، سنُبرز الموثوقة منها. :slight_smile:

هذا مجرد مادة للتفكير، مع ذلك. :person_shrugging:

  1. ينبغي أن أعرف ذلك، فقد كنتُ أحد هؤلاء المبرمجين! ↩︎

5 إعجابات
13

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

إعجاب واحد (1)
14

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

ومع ذلك، أعتقد أننا سننتهي إلى وضع وسم على كل شيء تقريبًا، وهذا يُفقد الأمر جوهره إلى حد ما؟

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

5 إعجابات
15

أعتقد أن المراجعة الشاملة من قِبل البشر والذكاء الاصطناعي معًا فكرة جيدة لأي برنامج مهم، بغض النظر عما إذا كان قد كُتب في الأصل بواسطة البشر أم بواسطة الذكاء الاصطناعي. وسيكون من الرائع لو توفرت أدوات أفضل لمراجعة البرمجيات وتتبع من راجع أي إصدارات من أي حزم. هناك حاليًا أدوات تشبه ذلك إلى حد ما لـ Rust/Cargo: Crev، وcargo-vet، وThirdpass. كما أنني بدأت نقاشًا على منتديات Swift.

إعجاب واحد (1)
16

أنا من معسكر “لماذا” (التيار الذي يركّز على الأسباب). مسألة وجود التسميات مقابل عدم وجودها ليست سوى حجة مغالطة (red herring). بالنسبة لي، القضية الأهم هي ضمان جودة الكود/المنتج في دليل الإضافات، فهذه هي الأولوية القصوى. يتحمّل موقع Discourse المسؤولية النهائية في هذا المجال، لكن المجتمع يمكن أن يساعد. وفي هذا السياق، قمت أنا وأحدث صديق مقرّب لي (BFF) ببعض العمل على إنشاء ملف DiscourseSkill.md. كان هدفي الأصلي استخدامه داخليًا، لكن ربما يجد آخرون فيه فائدة. لذا، اطّلعوا على الرابط التالي: DiscourseSkill.md