يناقش منشور على GitHub Blog خمس فرضيات رائجة حول استخدام الذكاء الاصطناعي في تطوير البرمجيات، من بينها أن الكود المولّد لا يحتاج إلى قراءة، وأن RAG انتهى، وأن Skills ألغت Model Context Protocol (MCP). ويرى الكاتب أن قيمة هذه العبارات لا تكمن في صحتها بصيغتها المختصرة، بل في تفكيك شروطها وحدودها عند تطبيقها على العمل الفعلي.
مسؤولية الكود لا تنتقل إلى النموذج
القاعدة الأساسية التي يطرحها المقال هي أن المطور يجب أن يراجع الكود إلى النقطة التي يستطيع عندها شرح النتيجة وتحمل مسؤوليتها. ولا يعني ذلك فحص كل سطر بالعمق نفسه؛ إذ يستحق تغيير في نظام مصادقة إنتاجي مراجعة مختلفة عن تجربة بسيطة في CSS.
قد تبدأ المراجعة قبل أن يكتب الوكيل أي كود، عبر فهم التنفيذ الحالي وتحديد التبعيات والحالات الطرفية ووضع خطة. وفي حالات أخرى، يحتاج الكود الناتج إلى تدقيق مباشر في معالجة الأخطاء والصلاحيات والوصول إلى البيانات والأداء وإتاحة الاستخدام والاختبارات. ووفق المقال، الذكاء الاصطناعي يغيّر موقع الجهد، لكنه لا يلغي العمل نفسه.
المهارة الأهم هي حسن التقدير
يرفض المنشور فكرة أن الشركات لن توظف من لا يستخدم الذكاء الاصطناعي إطلاقاً، لكنه يقر بأن عدداً متزايداً من فرق العمل يسأل المرشحين عن طريقة استخدامهم لهذه الأدوات. الإشارة الأقوى، بحسب الطرح، ليست الحماس للأداة بحد ذاته، بل القدرة على شرح متى يستخدمها المطور ومتى يعمل يدوياً، وكيف يراجع مخرجاتها، وكيف يوازن بين السرعة والجودة والأمن وقابلية الصيانة.
قد يصبح تجنب الذكاء الاصطناعي عائقاً في شركة تبني منتجاته أو تعتمد عليه بكثافة، لكن الاعتماد الكامل عليه ليس حلاً أفضل. المطلوب هو إبقاء الإنسان داخل الحلقة وامتلاك تفسير واضح لما يثق به المطور وما لا يثق به.
MCP وSkills وRAG أدوار متكاملة
يقدم المقال تمييزاً بين الأدوات الثلاث. يوفّر MCP طريقة معيارية لوصول الوكلاء إلى الأدوات والبيانات واستدعائها، بينما تقدم Skills معرفة معبأة حول أسلوب عمل الفريق أو قواعد تعديل المشروع أو الاصطلاحات المتبعة. وبما أن Skills تُكتب غالباً بصيغة Markdown، فإن قابليتها للقراءة البشرية جزء من فائدتها.
أما RAG، أو التوليد المعزز بالاسترجاع، فيجلب إلى النظام معلومات ذات صلة خارج بيانات تدريب النموذج، مثل الوثائق وسجل الدعم وتفاصيل المنتجات والمعرفة الداخلية وسياق قاعدة الكود. ويساعد الاسترجاع الجيد النموذج على بدء العمل من سياق أقرب إلى الإجابة، مع تقليل مساحة البحث واحتمال تقديم رد ناقص.
لذلك لا يرى الكاتب أن Skills قتلت MCP أو أن RAG مات؛ فقد يستخدم الوكيل MCP للوصول إلى أداة، ويتبع Skill لتطبيق تعليمات خاصة بالمشروع، ويستعين بالاسترجاع لجلب السياق الداعم. الخلاف بين هذه المكونات يتجاهل الطريقة التي يمكن أن تتكامل بها في سير عمل واحد.
قابلية الصيانة تحت اختبار جديد
يناقش المنشور أيضاً فكرة أن الحاجة إلى تدريب النموذج على قاعدة كود معينة تعني بالضرورة أن الكود سيئ. توجد أسباب مشروعة للتدريب المخصص، لكن عجز النموذج عن فهم قاعدة الكود قد يكشف مشكلة سيواجهها زميل جديد أيضاً.
البنية الواضحة، والتسمية المتسقة، والاختبارات المقروءة، والتجريدات المفيدة، والوثائق المحدثة تجعل الكود أسهل للفهم من جانب الوكلاء والبشر معاً. وتتمثل القراءة التحريرية هنا في أن أدوات الذكاء الاصطناعي لا تعفي الفرق من ممارسات هندسة البرمجيات؛ بل قد تجعل عيوب قابلية الصيانة أكثر ظهوراً.
من النقاش إلى التجربة
يختتم المقال بالدعوة إلى اختبار الآراء عملياً بدلاً من استبدال كل رأي برأي مضاد. ويستشهد بمشروع Pollinations AI، حيث يمكن للمساهمين كسب أرصدة تسمى pollen عبر تحسين المشروع، وبمشروع Avian Visitors الذي يوثق شاشة حبر إلكتروني تستمع إلى الطيور وتحوّل زياراتها إلى لوحات متغيرة باستخدام ميكروفون وRaspberry Pi ومكونات مطبوعة ثلاثياً وصور مولدة.
لا تحسم هذه المشاريع كل نقاشات الذكاء الاصطناعي، لكنها تنتج أدلة وتكشف المقايضات. أما القيد الأساسي في المادة فهو أنها تقدم إطاراً إرشادياً عاماً وأمثلة، لا نتائج قياس مقارنة تثبت تفوق سير عمل محدد. لذلك ينبغي التعامل مع توصياتها كنقاط اختبار للممارسة، لا كقواعد نهائية.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.