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

هذا قفزة كبيرة في منطقتك.

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

  • الميزات الإضافية لا تجعل تطبيقك بالضرورة أبطأ أو أكثر استهلاكاً للذاكرة؛ هذه المشكلة تم حلها بمفهوم التحميل الديناميكي منذ 40 عاماً.

بالضبط. التأكيد مني :slight_smile:

4 إعجابات

لا، لا ينبغي إجراء هذا التمييز.

  • هل البرنامج آمن؟
  • هل يحل مشكلتي؟

ونعود مرة أخرى إلى نقطي الأصلي هنا:

إذا كان لدينا مشكلة أمنية في القوالب، فلنتحدث عن نظام للمراجعة والتدقيق.

إذا كان لدينا مشكلة في جودة القوالب، فلنتحدث عن أنظمة للمراجعة والتدقيق.

لكن لا، لن أضع ملصقًا على المواضيع يقول «طُوِّر على ماك» أو «طُوِّر بلوحة مفاتيح حمراء» أو «طُوِّر بنسبة 93.2% باستخدام الذكاء الاصطناعي»، فهذا لن يحدث.

ما مقدار الذكاء الاصطناعي الذي أستخدمه؟ يسعدني مشاركة سير عملي في موضوع منفصل، لكنني لم أعد أكتب الأكواد يدويًا في فيم (vim) بعد الآن.

8 إعجابات

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

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

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

6 إعجابات

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

هذا خارج الموضوع بعض الشيء.

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

إعجابَين (2)

يمكنني أن أقول بثقة 100% إن هذه الفكرة ليست عملية إطلاقًا، بالنسبة إلينا لمراجعة كل إضافة وقالب من طرف ثالث. (أو على الأقل، ليس يدويًا بواسطة إنسان)

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

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

طريقة بسيطة وموثوقة للقيام بذلك تبدو لي أفضل ما في العالمين.

هذا هو جوهر هذا الموضوع بالكامل:

كان من المثير للاهتمام ملاحظة آراء الجميع حول سبب أهمية هذه الشفافية، سواء من منظور أخلاقي أو أمني. شخصيًا، لا يهمني ما إذا كان شيء ما قد صنعه مهندس برمجيات بخبرة 30 عامًا يعمل بلغة Ruby منذ فجر الزمن، أم صنعه «تيمي الصغير» بلا أي خبرة في البرمجة. إذا كان الكود مكتوبًا بشكل سيئ 100%[1]، فلن أستخدمه، فسيكون من تناقضٍ مني. أنا أفهم سبب شعبيته، لكنه ببساطة ليس شيئًا سأؤيده. لو كانت هذه النماذج قد تم تدريبها بشكل أخلاقي ولم تكن تسبب نقصًا في المكونات إلى جانب وباء في الوسائط المولدة بالذكاء الاصطناعي، لربما كانت مشاعري تجاه هذه النماذج أقل سلبية، لكن هذا ليس العالم الذي نعيش فيه.

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


  1. أرفض استخدام مصطلحات مثل «البرمجة بالإحساس» أو «التطوير الوكيل» ↩︎

إعجابَين (2)

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

وإذا كانت هناك أمثلة فعلية، فهل هي كافية لتُشكّل مشكلة حقيقية؟

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

يبدو لي أنه سيكون من المفيد بنفس القدر وجود نوعٍ من القائمة ذاتية التقييم للقوالب: كم من الاختبارات أجريتها، هل أنت مستعد لاستقبال تقارير حول الجودة والأمان، وهل ستكون متجاوبًا مع الملاحظات.

أو حتى، ما هي عملية تطويرك، في ثلاث جمل كحد أقصى.

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

4 إعجابات

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

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

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

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

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

5 إعجابات

أشارككم مقالًا منسّقًا متعلقًا بهذا الموضوع:

تجادل Trail of Bits بأن وكلاء الذكاء الاصطناعي يكونون أكثر فائدة في عمليات التدقيق عند بناء أدوات مخصصة، وليس فقط في اكتشاف الأخطاء. في تدقيق zkVM الخاص بـ Miden، استخدموا Claude وCodex لإنشاء خادم LSP، وفك تشفير، ومحلل ثابت، ونموذج Lean، مما أدى إلى كشف خطأ عالي الخطورة في تزوير التواقيع و95 إثباتًا بـ Lean التقطت مشكلتين خفيتين.

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

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

7 إعجابات

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

إعجابَين (2)

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

كما أظهرت Snyk في تقرير VulnBench الخاص بها، فإن التدقيق باستخدام نماذج اللغة الكبيرة ليس موثوقًا حقًا:

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

يبدو لي أن استخدام وكلاء الذكاء الاصطناعي لكتابة قوالب Discourse مناسب للغاية.

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

إعجابَين (2)

بالطبع، سام والفريق هم المرجع غير القابل للنقاش، ويمكنهم تصحيح أي خطأ مني، ولكن بعد الكثير من التجارب من جهتي، وسعيدًا بتقديم شيء ما في المقابل، تعلمت خلال الأشهر القليلة الماضية أن استخدام Discourse Vibe والاستخدام الجيد لـ harness هما ما يُقترحان، وبفارق شاسع هما الوضع المثالي للبدء.

كما أنه من الممكن العمل مع بعض الاختبارات على GitHub أو حتى باستخدام Discourse Container، لكن القدرة على التطوير محدودة، خاصة لأولئك الذين لديهم خبرة أقل، كما هو حالتي.

من الممكن “توليد” (vibe) أكواد لـ Discourse باستخدام الذكاء الاصطناعي، وكل ما عليك فعله هو التحقق أو تفويض التحقق النهائي قبل تقديم العمل المنجز أو استخدامه في بيئة الإنتاج.

من جهتي، لست مؤهلًا تقنيًا لمراجعة الأكواد، لكنني مؤهل بما يكفي لتوجيه الوظائف، وكيف وأين يتم تكييفها، والسؤال عن ما يجب توليده أو تصقله على وجه التحديد، لذا أتخيل أن شخصًا ما سيأتي ويساهم بشكل مفتوح في أمان وموثوقية الكود (مع مراجعة بشرية دائمًا) بحيث يمكن استخدامه من قبل المجتمع بأكمله. ليس فقط في Meta بل في Discourse بشكل عام. لقد كان هذا دائمًا هدفي، منذ أوامر البدء (prompt) الأولى لي.

أمس قرأت هذا الموضوع وذهلت لكيفية تطور كل شيء: How hard would it be for non programmers to be able to use the Discourse AI - AI bot to help them create plugins and/or themes

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

4 إعجابات

نعم، تغيّرت الأمور كثيرًا خلال العام الماضي. أنا أميل إلى تفضيل البرمجة مع وكلاء الذكاء الاصطناعي، لذا فأنا منحاز.

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

5 إعجابات

الأزمنة تتغير، والنماذج مفتوحة الأوزان تسد الفجوات بسرعة. ما كان فجوة تبلغ 12 شهرًا بين النماذج الرائدة والنماذج المفتوحة قد انخفض الآن إلى 3-6 أشهر.

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

8 إعجابات