أولويات البحث للأشهر الـ 18 القادمة: إلى أين يجب أن يتجه الترميز الذاتي بعد ذلك

أولويات البحث: الأشهر الـ 18 القادمة من الترميز الذاتي

تعمل مساعدات الترميز المدعومة بالذكاء الاصطناعي بالفعل على تحويل تطوير البرمجيات. بحلول أواخر عام 2025، ستكون أدوات مثل GitHub Copilot وروبوتات الدردشة المدعومة بالذكاء الاصطناعي مستخدمة يوميًا من قبل معظم المطورين، وحتى غير المبرمجين يمكنهم إنشاء نماذج أولية للتعليمات البرمجية باستخدام مطالبات بسيطة. يشير الرئيس التنفيذي لشركة Google إلى أن هذا الاتجاه – الذي يُطلق عليه غالبًا "الترميز الوجداني" (vibe coding) – يجعل البرمجة أكثر سهولة للموظفين غير التقنيين (www.itpro.com). ومع ذلك، كشفت عمليات النشر في العالم الحقيقي عن ثغرات مهمة. غالبًا ما تحتوي التعليمات البرمجية التي يولدها الذكاء الاصطناعي على أخطاء دقيقة، وتفشل في المشاريع المعقدة، وتثير قضايا المساءلة والسياسة. للانتقال من العروض التوضيحية المختبرية إلى أنظمة إنتاج موثوقة، نحتاج إلى بحث مركز على أربع جبهات: الموثوقية، والتخطيط بعيد المدى، وقابلية التحقق، والحوكمة الاجتماعية والتقنية. نحدد أدناه المشاكل الرئيسية المفتوحة ونقترح أجندات بحثية، ومعايير، وتعاونًا لمعالجتها.

1. الموثوقية وجودة التعليمات البرمجية

تُعد الموثوقية الأساسية مشكلة رئيسية: فالتعليمات البرمجية التي كتبها مساعدو الذكاء الاصطناعي لا تزال تحتوي على أخطاء أكثر بكثير من التعليمات البرمجية البشرية. على سبيل المثال، وجد تحليل لـ 470 طلب سحب (pull requests) على GitHub أن طلبات السحب التي كتبها الذكاء الاصطناعي احتوت على أخطاء أكثر بنحو 1.7 مرة من تلك التي كتبها البشر (www.itpro.com). في المتوسط، أثارت طلبات سحب الذكاء الاصطناعي حوالي 10.8 مشكلة (أخطاء منطقية، مشاكل في التسمية أو التنسيق، عيوب أمنية، إلخ) مقابل حوالي 6.5 لطلبات سحب البشر (www.itpro.com). وتجدر الإشارة إلى أن التعليمات البرمجية التي كتبها الذكاء الاصطناعي كان بها "ذيل" أثقل من الأخطاء الخطيرة (ظهرت الأخطاء المنطقية والثغرات الأمنية بضعف تكرارها تقريبًا في التعليمات البرمجية البشرية) (www.itpro.com). في الممارسة العملية، أبلغت الفرق التي تستخدم أدوات الذكاء الاصطناعي عن مفاجآت: تعليمات برمجية تبدو صحيحة عند عزلها ولكنها تفشل في التكامل أو تحمل عيوبًا خفية. في الواقع، لاحظ استطلاع شامل لأدوات توليد التعليمات البرمجية أن المعايير الحالية لا تلتقط أنواع أنماط الفشل التي تظهر في الإنتاج – مثل استدعاءات API الوهمية، أو التسميات غير المتناسقة، أو الأخطاء المنطقية الدقيقة التي تتسلل عبر اختبارات الوحدات (doi.org). باختصار، يمكن للذكاء الاصطناعي توليد مقتطفات تعليمات برمجية عاملة، لكن هذه المقتطفات غالبًا ما تكون غير جاهزة للإنتاج (doi.org).

تعكس تجربة المطورين عدم الثقة هذا. وجد استطلاع كبير أجرته SonarSource (وذكرته الصحافة الصناعية) أنه بينما يستخدم 72% من المهندسين أدوات الذكاء الاصطناعي يوميًا لكتابة ما يصل إلى 42% من التعليمات البرمجية، فإن 96% منهم يعترفون بأنهم لا يثقون بالكامل في مخرجات الذكاء الاصطناعي (www.itpro.com). ومع ذلك، فإن أقل من نصف الفرق تقوم دائمًا بمراجعة التعليمات البرمجية التي يولدها الذكاء الاصطناعي قبل الالتزام بها (www.itpro.com). هذه الفجوة – الاستخدام العالي ولكن الثقة المنخفضة – تؤدي إلى ما يسميه الخبراء "دين التحقق". بدون موثوقية أفضل، تخاطر المؤسسات بإدخال أخطاء يصعب اكتشافها وديون تقنية كلما اعتمدت اختصارات الترميز بالذكاء الاصطناعي (www.itpro.com).

أجندة البحث: نحتاج إلى دراسة منهجية لأنماط الأخطاء في التعليمات البرمجية للذكاء الاصطناعي وطرق جديدة للتخفيف منها. تشمل الأفكار التحقق التلقائي من الذكاء الاصطناعي (automated AI-proofing): دمج محللات ثابتة أو نماذج ثانوية تفحص مخرجات الذكاء الاصطناعي بحثًا عن الأخطاء الشائعة (على غرار مراجع ثانٍ). يمكن لأهداف تدريب نماذج اللغات الكبيرة (LLM) الأفضل أن تركز على الاستقرار – على سبيل المثال، التدريب على أمثلة تعليمات برمجية بها أخطاء مقابل أمثلة تعليمات برمجية نظيفة لتعليم النموذج تفضيل الحلول الأكثر أمانًا. يجب على الباحثين تحليل أنواع التعليمات البرمجية (الخوارزميات، الإدخال/الإخراج، التعليمات البرمجية الحساسة للأمان) التي تعرقل الاستدلالات الداخلية للذكاء الاصطناعي، وتطوير دفاعات متخصصة. على سبيل المثال، أشارت أعمال سابقة إلى أن أدوات الذكاء الاصطناعي تفرط في استخدام اختصارات محفوفة بالمخاطر (كلمات مرور مشفرة، حلقات غير فعالة، إلخ) (www.businesswire.com) (www.infoworld.com). يجب علينا تدوين أنماط الفشل هذه.

يمكن أن تساعد الحلول التعليمية أيضًا: فكما تؤكد إرشادات المجتمع، أدوات الذكاء الاصطناعي يمكنها فقط المساعدة – يجب على البشر التحقق (firefox-source-docs.mozilla.org) (chromium.googlesource.com). لتشجيع ذلك، يمكن للأدوات المستقبلية أن تُنشئ تحذيرات تلقائية أو حتى ترفض التعامل مع المهام بدون موافقة بشرية. يجب أن تتحول معايير الأداء: تجاوز "هل يتم تجميع هذا الكود" إلى "كم عدد المشكلات الدقيقة المتبقية". على سبيل المثال، تظهر نماذج الذكاء الاصطناعي لمراجعة التعليمات البرمجية التي تقيس أداء اكتشاف الأخطاء بشكل خاص (docs.factory.ai). من شأن جهد مجتمعي لإنتاج مجموعة بيانات عامة لتغيرات التعليمات البرمجية الحقيقية بين الذكاء الاصطناعي والبشر (مع عيوب مشروحة) – على غرار دراسة CodeRabbit لطلبات السحب – أن يسمح للباحثين بتتبع التقدم في الموثوقية.

2. التخطيط بعيد المدى والصيانة

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

• RoadmapBench (مايو 2026) يقيم ترقيات "بعيدة المدى" على مشاريع مفتوحة المصدر حقيقية. تمنح كل مهمة العامل نسخة أساسية من المشروع وقائمة من الميزات لتنفيذها، مع تغيير حوالي 3,700 سطر عبر أكثر من 50 ملفًا. حتى Claude-Opus-4.7، وهو أحد أقوى النماذج، حل حوالي 39% فقط من المهام، وانخفضت نماذج أخرى إلى 5% (papers.cool). على النقيض، ترى إصلاحات الأخطاء البسيطة بلقطة واحدة أداءً شبه مثالي للذكاء الاصطناعي. ويخلص مؤلفو RoadmapBench إلى أن "تطوير البرمجيات بعيد المدى لا يزال مشكلة غير محلولة إلى حد كبير." (papers.cool)

• SlopCodeBench (2026) يفحص التطوير التكراري. تم إعطاء الوكلاء مهمة وشكلوا تعليمات برمجية، ثم على مدار 20 جولة تغيرت مواصفات المهمة، مما أجبر التعليمات البرمجية على التطور. النتيجة: على الرغم من أن جميع الإصدارات الوسيطة اجتازت الاختبارات الحالية، أصبحت قواعد التعليمات البرمجية التي أنتجها الذكاء الاصطناعي أكثر تفصيلاً 2.2 مرة وأصعب بكثير في الصيانة من التعليمات البرمجية التي يتم صيانتها بواسطة البشر (www.techradar.com). في الواقع، لم يحل أي من النماذج العليا التسلسل الكامل: انخفضت معدلات النجاح إلى حوالي 0.5% بحلول نقطة التفتيش النهائية. يوضح هذا أن الأخطاء التصميمية الصغيرة تتراكم بمساعدة الذكاء الاصطناعي، مما يعيق التعديلات المستقبلية (www.techradar.com).

تشير هذه النتائج إلى تركيز البحث على التخطيط والتقسيم. يجب ألا تقتصر أنظمة الذكاء الاصطناعي على "كتابة التعليمات البرمجية" لكل مطالبة، بل يجب أن تخطط لاستراتيجيات متعددة الخطوات. إحدى الأفكار الناشئة هي التخطيط والتنفيذ (plan-and-execute): دع النموذج يحدد أولاً تصميمًا أو تسلسلًا من الخطوات، ثم يولد التعليمات البرمجية لكل خطوة (crabtalk.ai). في الواقع، وجدت تحليلات لعملاء الترميز (Claude Code، GitHub Copilot، إلخ) أن فصل التخطيط عن التنفيذ (وكشف الخطة للمستخدم) يحسن الأداء بشكل كبير في المهام المعقدة (crabtalk.ai). يجب أن يطور البحث هياكل جديدة: على سبيل المثال، وكلاء متداخلون حيث يقوم نموذج لغوي كبير (LLM) "مدير" بتقسيم مشكلة كبيرة إلى مهام فرعية لوكلاء LLM عاملين. آليات الذاكرة طويلة المدى ضرورية أيضًا: يجب أن تتذكر النماذج المستقبلية التعليمات البرمجية التي تم إنشاؤها سابقًا في جلسة حتى خارج نافذة السياق.

معايير الأداء: يجب على المجتمع تحديد معايير أداء تعكس أعمال التطوير الحقيقية. بما يتجاوز RoadmapBench، نحتاج إلى مهام تغطي لغات متعددة وتحديات تكامل (الواجهة الأمامية/الخلفية، قواعد البيانات، إلخ). المشاريع الجماعية المحاكية ستختبر كيفية تعاون الذكاء الاصطناعي والبشر عبر الإصدارات. استعارة الأفكار من هندسة البرمجيات، يمكن أن تقيس معايير الأداء ليس فقط الصحيح بل قابلية الصيانة (مدى سهولة إضافة ميزة جديدة؟)، الأداء (هل تتدهور التعليمات البرمجية للذكاء الاصطناعي مع تطورها؟)، والتكامل (هل تتناسب مع اصطلاحات الأنماط الموجودة؟). على سبيل المثال، يمكن أن تبدأ معايير الأداء بقاعدة بيانات موجودة وتطلب من العميل تنفيذ سلسلة من طلبات الميزات أو إعادة الهيكلة، مع اختبارات دورية. على مدار الـ 18 شهرًا القادمة، سيؤدي إنشاء مثل هذه التحديات المفتوحة (ربما عبر مسابقات أكاديمية-صناعية) إلى توجيه البحث في الترميز متعدد المراحل.

3. قابلية التحقق والواجهات الرسمية

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

إحدى الفرص هي التوليد "ذو الحلقة المغلقة". تقترح الأعمال الحديثة ضرورة التحقق من اتساق التعليمات البرمجية التي يولدها الذكاء الاصطناعي، وسلسلة مستنداتها (docstring)، وأي تعليقات توضيحية رسمية. على سبيل المثال، يولد نهج Clover تلقائيًا مواصفات رسمية (باستخدام لغات مثل Dafny) جنبًا إلى جنب مع التعليمات البرمجية، ثم يستخدم أدوات الإثبات لرفض الحلول غير المتسقة (theory.stanford.edu). في الاختبارات الأولية، اكتشف هذا جميع البرامج غير الصحيحة على مجموعة بيانات بمستوى كتاب دراسي. وبالمثل، يستخدم AutoACSL التحليل الثابت لمطالبة نموذج لغوي كبير (LLM) بكتابة عقود دقيقة للدوال (شروط مسبقة/لاحقة) ثم يتحقق منها باستخدام Frama-C (papers.cool). من خلال إعادة الشروط غير المستوفاة، فقد حسن بشكل كبير نسبة التعليمات البرمجية التي يمكن إثبات صحتها. توضح هذه الأمثلة أن دمج الطرق الرسمية في خطوة توليد التعليمات البرمجية يمكن أن يحول تخمين الذكاء الاصطناعي غير المتحكم فيه إلى برنامج متحقق منه.

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

معايير الأداء: يجب أن تتضمن معايير الأداء الجديدة مشاكل التحقق الرسمي. على سبيل المثال، يمكننا إضافة مهام حيث يتم التحقق من "الصحة" بواسطة مبرهن نظري أو مدقق رمزي، وليس فقط اختبارات الوحدات. ستكون مجموعات البيانات لقصص المستخدم مع مواصفات LTL/TLA+ أو Alloy والتعليمات البرمجية المقابلة ذات قيمة. في التعليم، تُظهر المسابقات مثل تحدي فحص نماذج TLA+ أن التحديد صعب – وجدت دراسة أن نماذج LLM الحالية تحقق حوالي 8% فقط من الصلاحية الدلالية على مواصفات TLA+ المباشرة (papers.cool). قد تصدر المشاريع مفتوحة المصدر لغات مواصفات على نطاق أوسع (نوع من إقرار الترميز). يمكن للذكاء الاصطناعي الاستفادة من التنسيقات الموحدة (YAML، JSON) لمواصفات API أو مخططات البيانات لمواءمة التعليمات البرمجية مع السلوك المقصود.

4. الحوكمة الاجتماعية-التقنية والثقة

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

ممارسات المطورين: كما ذكرنا، تُظهر استطلاعات الصناعة فجوة في الثقة. يعلم المطورون أنه يجب عليهم مراجعة مخرجات الذكاء الاصطناعي ولكنهم غالبًا ما يتجاهلونها إذا كان الأمر أسهل، مما يؤدي إلى مخاطر غير مدارة (www.itpro.com). استجابة لذلك، وضعت المشاريع الكبرى قواعد صريحة. على سبيل المثال، تسمح مؤسسة OpenInfra بمساعدة الذكاء الاصطناعي فقط إذا تم تمييز الالتزامات (commits) بعلامة "Assisted-By:" أو "Generated-By:" (openinfra.org). مشروع Chromium التابع لـ Google يطلب بالمثل أن يفهم المؤلفون تمامًا أي تعليمات برمجية اقترحها الذكاء الاصطناعي وإلا يفقدون امتيازات الالتزام (chromium.googlesource.com). تنص سياسة Firefox من Mozilla بوضوح: "يمكن للذكاء الاصطناعي المساعدة، لكن المسؤولية تظل دائمًا على عاتق الإنسان الذي يقف وراء التغيير" (firefox-source-docs.mozilla.org). حتى مشروع NumPy يحذر من أنه يجب أن تكون قادرًا على شرح أي تعليمات برمجية يتم تقديمها، بغض النظر عما إذا كان الذكاء الاصطناعي كتبها (numpy.org). تؤكد هذه السياسات أن الأدوات التقنية وحدها لا تكفي – نحن بحاجة أيضًا إلى سير عمل وثقافة واضحة.

التنظيم والمعايير: على نطاق أوسع، بدأت الحكومات وهيئات المعايير في اللحاق بالركب. يضع الاتحاد الأوروبي اللمسات الأخيرة على مدونة قواعد الممارسة للذكاء الاصطناعي للأغراض العامة، والتي ستتطلب الشفافية وتدابير السلامة من مزودي نماذج الذكاء الاصطناعي (digital-strategy.ec.europa.eu). بينما هذا ليس خاصًا بالترميز، فإنه يشير إلى تدقيق أكثر صرامة على تراخيص بيانات التدريب وقابلية شرح النموذج – وكلاهما ذو صلة عالية إذا كان مساعد الترميز الخاص بك قد سحب من تعليمات برمجية محمية بحقوق الطبع والنشر. وبالمثل، بدأت ISO و IEEE في وضع معايير للذكاء الاصطناعي للحوكمة والأخلاقيات، على الرغم من أن عددًا قليلاً فقط يتناول توليد التعليمات البرمجية بشكل مباشر. من المرجح أن يؤثر قانون الذكاء الاصطناعي (الاتحاد الأوروبي) والمبادئ التوجيهية الأمريكية القادمة على كيفية قيام الشركات بفحص التعليمات البرمجية للذكاء الاصطناعي داخليًا.

الحاجة إلى التعاون: سيتطلب سد هذه الفجوات الاجتماعية والتقنية جهودًا مشتركة. يمكن للأوساط الأكاديمية دراسة كيفية تأثير أدوات الذكاء الاصطناعي على إنتاجية الفريق، واكتشاف الثغرات الأمنية، والترخيص؛ ويمكن للصناعة مشاركة بيانات مجهولة المصدر حول الحوادث الحقيقية المتعلقة بالذكاء الاصطناعي؛ ويمكن لهيئات المعايير (مثل W3C، IEEE) دمج سيناريوهات الترميز في إرشادات الذكاء الاصطناعي الأخلاقية. على سبيل المثال، يمكن لورش العمل أن تجمع خبراء SAT-EL (ضمان جودة البرمجيات) مع خبراء التعلم الآلي لتحديد معايير التقييم لسلامة التعليمات البرمجية للذكاء الاصطناعي. يمكن أن تتطور المبادئ التوجيهية إلى معايير (مثل "IEEE 8201: عملية البرمجيات المدعومة بالذكاء الاصطناعي")، مما يمنح المنظمات إطار عمل مشترك. على مدار الـ 18 شهرًا القادمة، سيساعد بناء التوافق حول أفضل الممارسات – من خلال الأوراق البيضاء، أو الاتحادات، أو قوالب السياسات مفتوحة المصدر – الفرق على تبني هذه الأدوات بمسؤولية.

5. أجندة البحث ومعايير الأداء

للتلخيص، نقترح الخطوات الملموسة التالية للمجتمع البحثي:

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

• دراسة تصنيف الأخطاء: تصنيف منهجي لأنواع الأخطاء التي يقدمها الذكاء الاصطناعي. قدم تقرير CodeRabbit تفصيلاً أوليًا (أخطاء منطقية، مشاكل تسمية، إلخ) (www.infoworld.com). يمكن لدراسة أكاديمية أكبر جمع بيانات طلبات السحب (PR) وتصنيف الأخطاء بين الذكاء الاصطناعي والبشر. سيؤدي هذا إلى توجيه خسائر النماذج الجديدة (مثل وزن إضافي على الأمان) والكاشفات الآلية (الأدوات التي تشير إلى الأنماط النموذجية للذكاء الاصطناعي الخاطئ).

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

• دمج الطرق الرسمية: الاستثمار في الأبحاث مثل Clover و AutoACSL التي تربط بين تركيب البرامج والأدلة. تشجيع باحثي الطرق الرسمية على الشراكة مع مجموعات معالجة اللغات الطبيعية/التعلم الآلي. على سبيل المثال، يمكن للمسابقات الأكاديمية أن تجمع مساعدات الترميز من نماذج اللغات الكبيرة (LLM) مع برهانات (provers) في مهام مشتركة. إنشاء مسابقات للأدلة التي يولدها الذكاء الاصطناعي أو استنتاج العقود.

• أطر الحوكمة: دراسات العلوم الاجتماعية حول ممارسات الفريق والمسؤولية. على سبيل المثال، إجراء دراسات للمطورين: تزويد الفرق بأدوات الذكاء الاصطناعي ومراقبة كيفية مراجعتهم وتصحيحهم للأخطاء. بحث قانوني حول الملكية الفكرية: كما تشير إحدى المدونات، فإن "مشكلة حقوق الطبع والنشر في Copilot" (التعليمات البرمجية غير المرخصة) هي قضية مفتوحة (www.systemshardening.com). يجب على هيئات المعايير صياغة إرشادات واضحة حول ترخيص البيانات والنسب للتعليمات البرمجية للذكاء الاصطناعي.

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

من خلال تحديد معايير الأداء المجتمعية وعقد تحديات متعددة المؤسسات (مثل هاكاثون لترميز الذكاء الاصطناعي لتلبية أهداف معينة للأمان أو قابلية الصيانة)، يمكننا تتبع التقدم. فكر في الأمر كما قاد ImageNet الرؤية: نحن بحاجة إلى "ImageNet للتعليمات البرمجية" مشترك يعكس التطوير الحقيقي. تشير الجهود المبكرة (RoadmapBench, SlopCodeBench, Sigmabench (sigmabench.com)) إلى الطريق، ولكن بعد ذلك يجب أن نقوم بتوسيع نطاقها وجعلها متاحة على نطاق واسع.

6. الواجهات الرسمية: المواصفات، الاختبارات، والتعليمات البرمجية

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

على الجانب البحثي، يمكن تعريف تنسيق قياسي للمواصفات (مثل مخطط YAML أو JSON يصف الوظائف) ومطالبة أنظمة الذكاء الاصطناعي باستهلاكه. يمكن دمج جهود مثل TLA+ أو Alloy أو أدوات على غرار BDD (Cucumber): تخيل أن تخبر الذكاء الاصطناعي، "يرجى توليد تعليمات برمجية تفي بنموذج TLA+ هذا." على الرغم من أن نماذج اللغات الكبيرة (LLMs) اليوم ليست رائعة في كتابة TLA+ من الصفر (papers.cool)، فإن الجمع بين مواصفة مجردة كتبها البشر مع توليد التعليمات البرمجية المعزز بالذكاء الاصطناعي يستحق الاستكشاف. الهدف هو تسهيل على الفرق إنتاج مواصفة قابلة للتشغيل (حتى لو كانت غير رسمية) يحترمها الذكاء الاصطناعي. يمكن بعد ذلك توليد الاختبارات الرسمية تلقائيًا: تُظهر الأعمال الحديثة أن نماذج GPT يمكنها إنتاج اختبارات قائمة على الخصائص بناءً على وصف سلوك الدالة.

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

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

7. التعاون: الأوساط الأكاديمية، الصناعة والمعايير

يتطلب تحقيق هذه الأهداف تعاونًا واسعًا:

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

• يجب على الصناعة توفير حلقات ردود الفعل. يجب على الشركات التي تنشر أدوات ترميز الذكاء الاصطناعي مشاركة إحصائيات الأخطاء، وتجارب المساهمين، وطلبات الميزات بشكل مجهول. يمكن لشركات التكنولوجيا أيضًا تمويل ورش عمل أو مسارات "الذكاء الاصطناعي للترميز" في المؤتمرات (مثل ICSE، FSE). يمكنهم فتح أجزاء من سياساتهم (كما فعلت Google مع سياسة الذكاء الاصطناعي لـ Chromium (chromium.googlesource.com)) حتى يتمكن الآخرون من التعلم.

• يجب على هيئات المعايير (IEEE، ISO، W3C، إلخ) دمج الترميز في معايير أخلاقيات وسلامة الذكاء الاصطناعي الحالية. على سبيل المثال، يمكن لعمل ISO الجاري بشأن حوكمة الذكاء الاصطناعي (ISO/IEC 38507) ودورة حياة الذكاء الاصطناعي (ISO/IEC 5338) أن يشير صراحة إلى توليد التعليمات البرمجية. لدى W3C مسودة مبادئ أخلاقية لتعلم الآلة على الويب (www.w3.org) – يمكن توسيع هذا ليشمل قسمًا عن استخدام البرمجة. يجب أن تظهر "مدونة قواعد ممارسة" خفيفة الوزن لفرق التطوير التي تعتمد على الذكاء الاصطناعي، تمامًا كما توجد معايير تطوير آمنة (مثل OWASP) للأمان.

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

8. من يستفيد وكيف تبدأ

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

للبدء في استخدام هذه الأدوات، اتبع نفس سير العمل المرن والمتكرر الذي تستخدمه الفرق الاحترافية:

1. حدد هدفًا أو مواصفة واضحة. ابدأ بذكر ما تريده بمصطلحات ملموسة. يمكن أن يكون هذا وصفًا بلغة طبيعية لميزة أو رسمًا بسيطًا للخطوات. بالنسبة للمبرمجين، حتى قائمة نقاط أو قصص المستخدم يمكن أن تفي بالغرض.
2. استخدم مساعدًا للذكاء الاصطناعي لصياغة التعليمات البرمجية. قم بتشغيل أداة ترميز بالذكاء الاصطناعي (العديد منها متوفرة: روبوتات الدردشة عبر الإنترنت أو ملحقات بيئة التطوير المتكاملة IDE) واطلب منها تنفيذ المواصفة. على سبيل المثال، قد تكتب "إنشاء دالة بايثون تقرأ ملف CSV وترسم نقاط البيانات." سيقوم الذكاء الاصطناعي بإنشاء نسخة أولى.
3. تحقق وصقل. الأهم من ذلك، خذ مخرجات الذكاء الاصطناعي واختبرها. إذا كانت تعليمات برمجية، قم بتشغيلها في بيئتك. اكتب أو قم بتوليد بعض الاختبارات البسيطة تلقائيًا: هل تعطي نتائج صحيحة في الحالات الأساسية؟ إذا فشل شيء ما (وغالبًا ما يحدث ذلك في المحاولة الأولى)، قدم ملاحظات للذكاء الاصطناعي: على سبيل المثال، سلط الضوء على الحالة الفاشلة واطلب منه إصلاح التعليمات البرمجية. تتيح العديد من الأدوات المطالبة التكرارية أو التعديل "متعدد الدورات".
4. اطلب الشروحات والتوثيق. استخدم الذكاء الاصطناعي لإنتاج سلاسل مستندات (docstrings) أو تعليقات بعد الواقع. هذا يساعدك، أنت (المبرمج الجديد)، على فهم ما تم إنجازه. يمكنك أيضًا أن تطلب من الذكاء الاصطناعي الإشارة إلى المشكلات المحتملة أو اقتراح تحسينات.
5. زيادة التعقيد تدريجيًا. بمجرد أن تعمل البرامج النصية البسيطة، يمكنك محاولة تنفيذ مشروع صغير (مثل تطبيق قائمة مهام، أو خط أنابيب لتحليل البيانات). قسّم المشروع إلى أجزاء: اطلب من الذكاء الاصطناعي كل مكون (مخطط قاعدة البيانات، الواجهة الأمامية، منطق الأعمال) واحدًا تلو الآخر. تعامل معه وكأنه برمجة زوجية، حيث يكون الذكاء الاصطناعي هو شريكك المبتدئ.

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

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

الخلاصة

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

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

**`