هذا قفزة كبيرة في منطقتك.
لو وظّفت متدرباً أو قضيتَ 10 ليالٍ بنفسك، لكان بإمكانك أيضاً إضافة مشغل FLAC إلى تطبيقك التخيلي. اتخاذ قرارات سيئة في المنتج ليس شيئاً متأصلاً في استخدام نماذج اللغة الكبيرة (LLMs)، وهل إضافة ميزة غير مفيدة تُعدّ إهداراً لجهد التطوير أم لا كان دائماً موضع نقاش.
الميزات الإضافية لا تجعل تطبيقك بالضرورة أبطأ أو أكثر استهلاكاً للذاكرة؛ هذه المشكلة تم حلها بمفهوم التحميل الديناميكي منذ 40 عاماً.
بالضبط. التأكيد مني 
لا، لا ينبغي إجراء هذا التمييز.
ونعود مرة أخرى إلى نقطي الأصلي هنا:
إذا كان لدينا مشكلة أمنية في القوالب، فلنتحدث عن نظام للمراجعة والتدقيق.
إذا كان لدينا مشكلة في جودة القوالب، فلنتحدث عن أنظمة للمراجعة والتدقيق.
لكن لا، لن أضع ملصقًا على المواضيع يقول «طُوِّر على ماك» أو «طُوِّر بلوحة مفاتيح حمراء» أو «طُوِّر بنسبة 93.2% باستخدام الذكاء الاصطناعي»، فهذا لن يحدث.
ما مقدار الذكاء الاصطناعي الذي أستخدمه؟ يسعدني مشاركة سير عملي في موضوع منفصل، لكنني لم أعد أكتب الأكواد يدويًا في فيم (vim) بعد الآن.
سيكون من الخطأ المنطقي (وهو ما يُعرف بالخطأ الوراثي) رفض جميع الإضافات المولّدة بالذكاء الاصطناعي لمجرد أنها كُتبت بواسطة الذكاء الاصطناعي. فقد كان يُعدّ كون المحتوى مولّدًا بالذكاء الاصطناعي مؤشرًا معقولًا سابقًا على أنه محتوى رديء، لكن مع تحسّن النماذج، قد يصبح من الصعب بشكل متزايد التمييز بين مخرجات البشر ومخرجات الذكاء الاصطناعي. إذا كان القلق يدور حول الجودة أو الأمان، فأعتقد أنه سيكون أكثر أمانًا افتراض أن جميع الأكواد غير آمنة حتى يتم مراجعتها من خلال نوع من نظام المراجعة الجماعية بين الأقران.
أعتقد أن مشاركة كيفية عمل الفريق مع الذكاء الاصطناعي في الوقت الحاضر، بدءًا من المصممين والمبرمجين وصولًا إلى مجالات القانون والتسويق وغيرها، ستثير اهتمام العديد من الناس.
فالمعرفة القليل بالذكاء الاصطناعي، مثلي، لا تعني بالضرورة فهم كيفية عمل الشركة فعليًا مع الذكاء الاصطناعي على أساس يومي.
لقد قرأت كل ما هو موجود هنا، وأستطيع رؤية الجانبين. أعتقد أنه أمر جيد، وفي الوقت نفسه سيء، أن يتمكن الأشخاص ببساطة من إنشاء إضافات هنا ونشرها، حتى لو كانت تحتوي على ثغرات أمنية “محتملة” قد تُعرّض تثبيت Discourse للخطر.
هذا خارج الموضوع بعض الشيء.
هناك مزوّد آخر لبرامج المنتديات (WoltLab) لديه متجر لإضافات، على سبيل المثال. قبل أي إصدار، تُراجع الإضافات والقوالب من قبل الفريق. ربما كانت هذه فكرة جيدة لتنفيذ شيء مشابه هنا. ومع ذلك، فإن السؤال الذي يطرح نفسه دائمًا هو من سيتولى عملية المراجعة، وأتخيل أن ذلك سيتطلب استثمارًا كبيرًا في الوقت والموارد البشرية.
يمكنني أن أقول بثقة 100% إن هذه الفكرة ليست عملية إطلاقًا، بالنسبة إلينا لمراجعة كل إضافة وقالب من طرف ثالث. (أو على الأقل، ليس يدويًا بواسطة إنسان)
ما رأيك في مجموعة من الأدوات المختارة لاختبار الإضافات أو حالات الاختبار المولّدة بواسطة نماذج اللغة الكبيرة (LLM)، تحت إشراف الفريق وصيانته وتحديثه؟
أعلم أن الجميع يمكنه تنفيذ الاختبارات بشكل فردي، لكن بصراحة، لا يعرف الجميع كيفية القيام بذلك.
طريقة بسيطة وموثوقة للقيام بذلك تبدو لي أفضل ما في العالمين.
هذا هو جوهر هذا الموضوع بالكامل:
كان من المثير للاهتمام ملاحظة آراء الجميع حول سبب أهمية هذه الشفافية، سواء من منظور أخلاقي أو أمني. شخصيًا، لا يهمني ما إذا كان شيء ما قد صنعه مهندس برمجيات بخبرة 30 عامًا يعمل بلغة Ruby منذ فجر الزمن، أم صنعه «تيمي الصغير» بلا أي خبرة في البرمجة. إذا كان الكود مكتوبًا بشكل سيئ 100%[1]، فلن أستخدمه، فسيكون من تناقضٍ مني. أنا أفهم سبب شعبيته، لكنه ببساطة ليس شيئًا سأؤيده. لو كانت هذه النماذج قد تم تدريبها بشكل أخلاقي ولم تكن تسبب نقصًا في المكونات إلى جانب وباء في الوسائط المولدة بالذكاء الاصطناعي، لربما كانت مشاعري تجاه هذه النماذج أقل سلبية، لكن هذا ليس العالم الذي نعيش فيه.
المخاوف الأمنية المتعلقة بالإضافات (Plugins) على نطاق عالمي هي أيضًا مشروعة ولا تقتصر على «هذا مصنوع بالذكاء الاصطناعي». هذه مشكلة صعبة التعامل معها وتخرج عن نطاق هذا الموضوع، فهذا الموضوع مجرد اقتراح بضرورة وضع وسم على الأصول المولدة بالكامل بواسطة نماذج اللغة الكبيرة.
أرفض استخدام مصطلحات مثل «البرمجة بالإحساس» أو «التطوير الوكيل» ↩︎
ما زلت لا أرى المشكلة التي يحاول هذا الحل معالجتها. هل يمكن لأحد أن يعطيني مثالًا على إضافة (plugin) مكتوبة بناءً على “الإحساس” (vibe coded) كانت رديئة، أو غير آمنة، أو تستهلك موارد النظام بشكل مفرط؟ إضافة كان يجب ألا تُروَّج هنا أصلًا لأنها كانت بلا قيمة وتضييعًا لوقت الجميع؟
وإذا كانت هناك أمثلة فعلية، فهل هي كافية لتُشكّل مشكلة حقيقية؟
يبدو لي أنه سيكون من المفيد بنفس القدر وجود نوعٍ من القائمة ذاتية التقييم للقوالب: كم من الاختبارات أجريتها، هل أنت مستعد لاستقبال تقارير حول الجودة والأمان، وهل ستكون متجاوبًا مع الملاحظات.
أو حتى، ما هي عملية تطويرك، في ثلاث جمل كحد أقصى.
قيمة الحقيقة في الإجابات لن تكون ذات أهمية كبيرة، لكن الفرق بين القوالب ذاتية التقييم وتلك التي ليست كذلك قد يكون إشارة تستحق شيئًا، للشخص الذي يفكر في تثبيت البرنامج.
أنا شخصيًا، لا أستخدم البرمجة بالإحساس أبدًا في أي تطبيق أو مشروع أو برنامج أُنشئه. أستخدم محادثات الذكاء الاصطناعي لتبادل الأفكار أو التوضيح، لكنني لا أستخدمها أبدًا للمشاريع كاملة. الأمر يدوي أكثر بالتأكيد، لكن على الأقل أعرف ما أفعله ولا أستسلم بشكل أعمى لكيان آخر.
لكنني رأيت البرمجة المدعومة بالذكاء الاصطناعي تنمو كثيرًا خلال الأشهر القليلة الماضية. ربما كانت في الأصل مكتوبة بشكل سيء أو مليئة بالثغرات الأمنية، لكنني أقول إنها تحسنت بشكل هائل منذ ذلك الحين. تصاميم «البرمجة بالإحساس» لا تزال معروفة إلى حد كبير (التدرجات اللونية، الحدود، الرموز التعبيرية، إلخ)، حتى في بعض الإضافات التي رأيتها على ميتا. لكن المهم هو أن المؤلف شاركها من أجل اهتماماته الخاصة، واهتمامات المجتمع. ليس لأن شخصًا ما سيحتقرها ويصفها بأنها «مُتسخة»، بل لأنه وجد نجاحًا حقيقيًا في تلك الإضافة ويريد مشاركتها مع منتديات أخرى تبحث عن تحقيق نفس الوظيفة.
أرى وجهة نظرك بشأن المخاوف الأخلاقية المتعلقة بالذكاء الاصطناعي، لكن يبدو أنها موجهة نحو الذكاء الاصطناعي بشكل عام، مثل الشركات التي تقطع الكتب، والاستخدام الضخم للماء والكهرباء، إلخ. ذكرتَ:
لكن كيف يرتبط ذلك باستخدام الإضافات أو قوالب المحادثة (TCs) المصنوعة بالذكاء الاصطناعي؟ إذا لم يعجبك الذكاء الاصطناعي، حسنًا، لا تستخدمه. لكن المشهد البرمجي تغيّر بشكل درامي مع إدخال الذكاء الاصطناعي، وبالتالي فإن الأشياء مثل الإضافات وقوالب المحادثة ستتغير أيضًا. هل ستتوقف عن استخدام Discourse بالكامل الآن، مع علمك بأن بعض الكود كُتب بمساعدة الذكاء الاصطناعي؟ لن أفعل ذلك، لأنني أعلم أن هناك أشخاصًا لا يزالون وراءه.
إذن، هل لا يزال من الدقيق تسميتها «مُبرمجة بشكل رديء» ومقاطعة استخدام مصطلح «البرمجة بالإحساس» (شخصيًا، لا أرى أي مشكلة في المصطلح الأخير)؟ ربما لا. هل هو قاسٍ جدًا؟ نعم. على الرغم من أنني أعتقد أنك ستكره هذا، أحيانًا يجب علينا أن نتكيف. هل يعني ذلك أنني سأقوم الآن بإنشاء قوالب محادثة مولدة بالذكاء الاصطناعي ومشاركتها؟ بالنسبة لي، لا. لكن هل يعني ذلك أنني سأنظر إليها كبديل، لا يجب أن يُنظر إليها بازدراء أو يُستخف بها؟ نعم. وأنا أحاول ألا أفعل ذلك. لذا آمل أن تستطيع أنت أيضًا.
أشارككم مقالًا منسّقًا متعلقًا بهذا الموضوع:
تجادل Trail of Bits بأن وكلاء الذكاء الاصطناعي يكونون أكثر فائدة في عمليات التدقيق عند بناء أدوات مخصصة، وليس فقط في اكتشاف الأخطاء. في تدقيق zkVM الخاص بـ Miden، استخدموا Claude وCodex لإنشاء خادم LSP، وفك تشفير، ومحلل ثابت، ونموذج Lean، مما أدى إلى كشف خطأ عالي الخطورة في تزوير التواقيع و95 إثباتًا بـ Lean التقطت مشكلتين خفيتين.
وبما أن الوكلاء يجعلون المشاريع الجانبية الطموحة رخيصة التكلفة، فقد تحوّلت اقتصاديات التدقيق نحو مراجعات تقودها الأدوات، والتي يمكنها تأمين الأنظمة المعقدة بشكل أكثر شمولاً بكثير مما كان عليه في السابق.
أستخدم الذكاء الاصطناعي للمساعدة في تطوير الإضافات والمكوّنات الخاصة بي. استخدمها على مسؤوليتك الخاصة، لكنني لن أضع عليها أي إخلاء مسؤولية أو وسم، تمامًا كما تفعل نواة Discourse. أنا من يتحكم في الوكلاء، وأراجع الكود (أحيانًا بمساعدة وكيل آخر أو مجموعة عيون من نموذج لغوي كبير للمساعدة)، وأختبرها. أنت حر في عدم استخدامها، لكنني رأيت في كثير من الأحيان كودًا رديئًا مكتوبًا بالكامل بواسطة إنسان أكثر مما رأيته من كود مكتوب بواسطة الذكاء الاصطناعي.
في الواقع، أعتقد أن النهج التقليدي لمعرفة جودة شيء ما هو التحقق من سمعة الجهة التي صنعته. تعمل السمعة الشخصية بشكل جيد عندما يكون الشخص نشطًا في مجال المصادر المفتوحة. بشكل عام، إذا كان شخص ما قد أنجز عملًا جيدًا سابقًا وكان سريع الاستجابة، فسيستمر على هذا المنوال.