الذكاء الاصطناعي يكتب الكود، لكن من يفهمه؟ ما هو دين المعرفة؟
أدّت أدوات البرمجة المدعومة بالذكاء الاصطناعي إلى تسريع تطوير البرمجيات إلى مستوى غير مسبوق. يستطيع المطور اليوم إضافة ميزة جديدة، أو إصلاح خطأ، أو كتابة اختبارات، أو تعديل عشرات الملفات من خلال تقديم بضعة تعليمات فقط.
يتم إنشاء الكود، وتنجح الاختبارات، ويبدو أن التطبيق يعمل دون مشكلات.
لكن يبقى هناك سؤال مهم:
قد يعمل الكود الذي أنشأه الذكاء الاصطناعي، ولكن هل يفهم المطور حقاً سبب عمله؟
يكمن أحد المخاطر الجديدة التي تواجه فرق البرمجيات في عصر الذكاء الاصطناعي داخل هذا السؤال. ويُطلق على هذا الخطر اسم Knowledge Debt، أي دين المعرفة.
ما هو دين المعرفة؟
دين المعرفة هو فجوة معرفية تنشأ عندما لا يفهم المطور أو فريق البرمجيات بشكل كافٍ الكود أو القرارات المعمارية أو سلوك النظام الذي يتحمل مسؤوليته.
أصبح هذا المفهوم أكثر أهمية مع انتشار وكلاء البرمجة المستقلين المعتمدين على الذكاء الاصطناعي.
تصف دراسة نُشرت في يوليو 2026 دين المعرفة بأنه تراكم التغييرات التي ينفذها وكلاء الذكاء الاصطناعي دون أن يفهمها المطورون بشكل كامل.
ويرى الباحثون أن هذا التراكم يشبه الدين التقني، لكنه لا يظهر مباشرة داخل قاعدة الكود، بل يتشكل في معرفة ومهارات المطورين المسؤولين عن النظام.
لنفترض مثالاً بسيطاً.
يوجد في أحد التطبيقات خطأ يؤدي إلى انتهاء جلسات المستخدمين بشكل غير متوقع. يرسل المطور رسالة الخطأ إلى أداة ذكاء اصطناعي. تعدّل الأداة عدة ملفات، وتحدّث آلية تجديد رمز المصادقة، ثم تحل المشكلة.
يعمل التطبيق الآن. ومع ذلك، قد يكون دين المعرفة قد بدأ في التكوّن إذا لم يتمكن المطور من الإجابة عن الأسئلة التالية:
- ما السبب الأساسي للمشكلة؟
- لماذا انتهت صلاحية الرمز في وقت أبكر من المتوقع؟
- ما الملفات وسلوكيات النظام التي عدّلها الذكاء الاصطناعي؟
- هل الحل المنفذ آمن؟
- هل يستطيع المطور حل المشكلة نفسها دون ذكاء اصطناعي إذا تكررت؟
ربما تم حل المشكلة، لكن المعرفة التي كان ينبغي اكتسابها أثناء عملية الحل لم يتم اكتسابها.
الفرق بين الدين التقني ودين المعرفة
يشير الدين التقني إلى تكاليف الصيانة المستقبلية الناتجة عن قرارات تقنية تم اتخاذها لتحقيق نتائج أسرع على المدى القصير.
تعد الدوال المعقدة، وتكرار الكود، وضعف الاختبارات، والحلول المؤقتة من الأمثلة الشائعة على الدين التقني.
أما في حالة دين المعرفة، فليس من الضروري أن يكون الكود سيئاً.
قد يكون الكود منظماً، ومختبراً، ويعمل بصورة صحيحة. ومع ذلك، قد لا يفهم الفريق سبب تصميمه بهذه الطريقة أو كيفية تصرف النظام في ظروف معينة.
يمكن تلخيص الفرق الأساسي كما يلي:
يوجد الدين التقني داخل قاعدة الكود، بينما يوجد دين المعرفة في الفجوة بين قاعدة الكود والأشخاص المسؤولين عن فهمها.
يقترح نهج آخر ظهر في عام 2026 تقييم صحة البرمجيات من خلال الدين التقني، والدين المعرفي، ودين النية.
يرتبط الدين المعرفي بمدى فهم أعضاء الفريق للنظام. أما دين النية فيرتبط بمدى توثيق الأسباب الكامنة وراء القرارات المهمة.
على سبيل المثال، عندما يضيف وكيل ذكاء اصطناعي آلية تخزين مؤقت جديدة إلى المشروع:
- يظهر الدين التقني إذا كان التنفيذ معقداً دون ضرورة.
- يظهر الدين المعرفي أو دين المعرفة إذا لم يفهم الفريق كيفية عمل التخزين المؤقت.
- يظهر دين النية إذا لم يتم توثيق سبب اختيار هذا الحل.
هذه الأنواع من الديون ليست مستقلة عن بعضها. ففي كثير من الحالات، يؤدي أحدها إلى زيادة الأنواع الأخرى.
كيف ينشئ الذكاء الاصطناعي دين المعرفة؟
السبب الأساسي لدين المعرفة ليس أن الذكاء الاصطناعي يكتب الكود.
تبدأ المشكلة الحقيقية عندما يتم قبول الكود الذي أنشأه الذكاء الاصطناعي دون فهمه أو التحقق منه.
اعتبار الكود الذي يعمل كوداً صحيحاً
عمل الميزة على الشاشة لا يعني بالضرورة أنها نُفذت بصورة صحيحة.
قد يحتوي الحل الذي أنشأه الذكاء الاصطناعي على تبعيات غير ضرورية، أو ثغرات أمنية، أو مشكلات في الأداء، أو قرارات تتعارض مع معمارية المشروع.
إذا اكتفى المطور بفحص النتيجة الظاهرة وقبل الكود دون مراجعته، يصبح السلوك الداخلي للنظام أقل وضوحاً مع مرور الوقت.
تنفيذ تغييرات كبيرة دفعة واحدة
يمكن لوكلاء الذكاء الاصطناعي تعديل عشرات الملفات خلال دقائق. لكن سرعة إنشاء الكود بواسطة الذكاء الاصطناعي لا تساوي سرعة فهم الإنسان لذلك الكود.
قد تتطلب مئات الأسطر التي تم إنشاؤها خلال خمس دقائق وقتاً أطول بكثير لمراجعتها بصورة صحيحة.
كلما زاد حجم التغيير، أصبح من الصعب على المطور فهم كل قرار واكتشاف الآثار الجانبية المحتملة.
ترك عملية تصحيح الأخطاء بالكامل للذكاء الاصطناعي
تُعد عملية تصحيح الأخطاء من أكثر العمليات التي يتعلم المطورون من خلالها كيفية عمل النظام.
تساعد مراجعة السجلات، واستبعاد الأسباب المحتملة، وتتبع تدفق البيانات، ومتابعة تنفيذ الكود على بناء نموذج ذهني أقوى للنظام.
عندما يقدم الذكاء الاصطناعي الحل مباشرة، يمكن إغلاق المشكلة بسرعة أكبر. لكن المطور قد يفقد فرصة فهم سبب حدوث المشكلة وكيفية نشوئها.
تشير الأبحاث المتعلقة بدين المعرفة أيضاً إلى أن المعلومات التي كان يتم اكتسابها بصورة طبيعية أثناء حل المشكلات الصعبة قد تضيع عند تفويض المهام بالكامل إلى وكلاء الذكاء الاصطناعي.
استخدام الأداة نفسها لكتابة الكود والاختبارات
قد يؤدي استخدام أداة الذكاء الاصطناعي نفسها لكتابة اختبارات للكود الذي أنشأته سابقاً إلى شعور زائف بالثقة.
قد تكرر الأداة في الاختبارات الافتراضات نفسها التي استخدمتها أثناء تنفيذ الكود.
ونتيجة لذلك، قد تنجح جميع الاختبارات، بينما تظل سلوكيات المستخدم الحقيقية أو الحالات الحدية أو المخاطر الأمنية غير مكتشفة.
عدم توثيق القرارات المعمارية
قد يقترح الذكاء الاصطناعي مكتبة، أو نمط تصميم، أو استراتيجية لإدارة الحالة، أو طريقة لمعالجة البيانات.
حتى إذا كان الاقتراح منطقياً، فقد يجد الفريق صعوبة في فهمه لاحقاً إذا لم يتم توثيق سبب الاختيار.
عندما تضيع النية الأصلية، يصبح تعديل الكود أمراً محفوفاً بالمخاطر. لأن الفريق لن يتمكن من التمييز بين السلوك المقصود والسلوك العرضي.
لماذا يُعد دين المعرفة خطيراً؟
نادراً ما يتم ملاحظة دين المعرفة فور ظهوره. ما دام الكود يعمل، قد يعتقد الفريق أنه لا توجد مشكلة.
غالباً ما يصبح الدين واضحاً عندما يحتاج النظام إلى تغيير جديد.
يستغرق إصلاح الأخطاء وقتاً أطول
إذا لم يفهم المطورون كيفية عمل النظام، فقد يتحول خطأ صغير إلى عملية بحث طويلة.
يجب إعادة اكتشاف الكود في كل مرة تظهر فيها مشكلة جديدة.
في هذه الحالة، تتم إعادة دفع الوقت الذي تم توفيره في البداية باستخدام الذكاء الاصطناعي خلال مرحلة الصيانة.
تؤدي التغييرات الصغيرة إلى تعطيل مناطق غير متوقعة
عندما لا تكون العلاقات بين أجزاء قاعدة الكود مفهومة، قد يختبر المطور الشاشة أو الوظيفة التي قام بتغييرها فقط.
لكن التغيير قد يؤثر أيضاً في التخزين المؤقت، أو المصادقة، أو الصفحات متعددة اللغات، أو مزامنة البيانات، أو مسار آخر لواجهة API.
كلما زاد دين المعرفة، بدا النظام أكثر هشاشة.
تصبح مراجعات الأمان سطحية
لا تلغي أدوات البرمجة بالذكاء الاصطناعي الحاجة إلى التفكير في الأمان. لكنها قد تنقل مسؤولية الأمان من مرحلة كتابة الكود إلى مرحلة المراجعة.
أظهرت دراسة أُجريت في عام 2026 بمشاركة مطورين محترفين أن المشاركين لم يذكروا في كثير من الأحيان متطلبات الأمان في أوامرهم الأولى، رغم امتلاكهم معرفة أمنية.
إذا لم يفهم الشخص الذي يراجع الكود التغيير بشكل كافٍ، فقد تصبح مراجعة الأمان سطحية أيضاً.
يصبح الفريق معتمداً على أدوات الذكاء الاصطناعي
إذا كان الفريق لا يستطيع التطوير إلا باستخدام الذكاء الاصطناعي، لكنه لا يستطيع تصحيح النظام أو اتخاذ قرارات معمارية دونه، فإن الأداة لم تعد مجرد مساعد.
لقد أصبحت تبعية أساسية.
إذا تغيرت الأداة، أو فُقد سياق المشروع، أو اقترح الذكاء الاصطناعي حلاً خاطئاً، فقد يواجه الفريق صعوبة في التدخل.
تصبح عملية انضمام المطورين الجدد أكثر صعوبة
من الصعب إدخال مطور جديد إلى مشروع يفتقر إلى التوثيق، ولا يُعرف تاريخ قراراته، ولا يفهم فريقه الحالي الكود بصورة كاملة.
قد يعمل التطبيق، لكن المعرفة المهمة قد تكون موجودة فقط داخل محادثات قديمة مع الذكاء الاصطناعي أو في ذاكرة عدد محدود من أعضاء الفريق.
ماذا تقول الأبحاث؟
لا يُعد دين المعرفة حتى الآن مقياساً ناضجاً تم قياسه لعقود أو تم الاتفاق على تعريفه بالكامل في صناعة البرمجيات.
إنه مجال بحثي جديد نسبياً، ولا تزال طرق قياسه قيد التطوير.
كما حدد الباحثون الذين قدموا المفهوم الدراسات التجريبية للمستخدمين وطرق القياس بوصفها مجالات مهمة للأبحاث المستقبلية.
ومع ذلك، تقدم الدراسات الحالية المتعلقة باستخدام الذكاء الاصطناعي وجودة الكود وتعلم المطورين نتائج مهمة.
في دراسة محكومة أجرتها Anthropic في عام 2026، طُلب من المشاركين استخدام مكتبة Python لم يسبق لهم العمل بها.
حصلت المجموعة التي استخدمت مساعدة الذكاء الاصطناعي على درجات أقل بمتوسط 17% في اختبار فهم لاحق مقارنة بالمجموعة التي كتبت الكود يدوياً.
لكن المشاركين الذين طرحوا أسئلة تفسيرية على الذكاء الاصطناعي وحاولوا فهم الكود الناتج حافظوا على نتائج التعلم بصورة أفضل.
كما فحصت دراسة واسعة النطاق أخرى 304,362 عملية commit مؤكدة بمساهمة الذكاء الاصطناعي ضمن 6,275 مستودعاً حقيقياً على GitHub.
أفاد الباحثون بأن أكثر من 15% من عمليات commit المرتبطة بكل أداة من أدوات البرمجة بالذكاء الاصطناعي أدخلت مشكلة واحدة على الأقل تم اكتشافها من خلال التحليل الثابت.
كما وجدوا أن 24.2% من المشكلات المتتبعة ظلت موجودة في أحدث إصدار من المشروع ذي الصلة.
تعتمد هذه النتائج على دراسة أولية ونتائج التحليل الثابت. لذلك لا ينبغي اعتبارها أرقاماً نهائية تمثل جميع الأكواد التي ينشئها الذكاء الاصطناعي.
لكنها تُظهر الحاجة إلى مراقبة الجودة بعناية.
لا تعني هذه النتائج أنه لا ينبغي استخدام الذكاء الاصطناعي.
بل تعني أن السرعة التي يوفرها يجب أن تكون مدعومة بعمليات تحقق وتعلم مناسبة.
هل يؤدي استخدام الذكاء الاصطناعي دائماً إلى دين المعرفة؟
لا.
يمكن للذكاء الاصطناعي زيادة دين المعرفة عند استخدامه بشكل غير صحيح، لكنه يستطيع أيضاً المساعدة في تقليله عند استخدامه بصورة واعية.
بدلاً من استخدام الذكاء الاصطناعي لإنشاء الكود فقط، يمكن استخدامه أيضاً من أجل:
- شرح كيفية عمل الكود الحالي.
- تحديد المناطق التي قد تتأثر بالتغيير.
- مقارنة البدائل المعمارية.
- إعداد وصف لطلب الدمج.
- تبسيط الدوال المعقدة.
- إنشاء التوثيق.
- سرد الحالات الحدية المحتملة.
- طرح أسئلة على المطور حول الكود المكتوب.
يكمن الفرق في استخدام الذكاء الاصطناعي كأداة تعاون وتعلم، وليس كآلة آلية لإنتاج الكود.
يمكن لأدوات الذكاء الاصطناعي توفير وقت كبير، خصوصاً في المهام المتكررة، وفحص قواعد الكود الكبيرة، وتحديد الأسباب المحتملة للأخطاء.
لكن يجب التمييز بين أمرين:
الحصول على مساعدة من الذكاء الاصطناعي لا يعني تسليمه مسؤولية التفكير.
كيف يمكن تقليل دين المعرفة؟
اطلب خطة قبل طلب الكود
بدلاً من أن تطلب من الذكاء الاصطناعي تنفيذ الميزة مباشرة، اطلب منه أولاً شرح:
- الحل المقترح،
- الملفات التي ستتأثر،
- المخاطر المحتملة،
- البدائل المتاحة،
- متطلبات الاختبار.
بعد مراجعة الخطة والموافقة عليها، يمكن الانتقال إلى إنشاء الكود.
يسهّل ذلك متابعة التنفيذ وفهمه.
قسّم التغييرات إلى أجزاء صغيرة
بدلاً من السماح لوكيل الذكاء الاصطناعي بتعديل عشرات الملفات دفعة واحدة، قسّم المهمة إلى خطوات صغيرة يمكن التحكم فيها.
طلبات الدمج الصغيرة أسهل في المراجعة والاختبار والشرح والتراجع عنها.
لا تدمج كوداً لا تفهمه
يتحمل المطور مسؤولية الكود الذي يدمجه في المشروع.
يمكن تطبيق قاعدة بسيطة:
إذا لم تتمكن من شرح الكود لعضو آخر في الفريق، فهو غير جاهز للدمج بعد.
ليس من الضروري حفظ كل سطر. لكن يجب فهم تدفق البيانات الأساسي، والنهج المختار، والآثار الجانبية المحتملة، وسيناريوهات الفشل.
اسأل الذكاء الاصطناعي: لماذا؟
لا تسأل فقط عما قام بتغييره. اسأله أيضاً عن سبب اتخاذه لهذه القرارات:
- لماذا اخترت هذا النهج؟
- ما البدائل التي درستها؟
- ما عيوب هذا الحل؟
- في أي ظروف قد يفشل؟
- ما مخاطر الأمان والأداء؟
- ما الملفات أو السلوكيات الأخرى التي قد تتأثر؟
لا تجعل هذه الأسئلة إجابة الذكاء الاصطناعي صحيحة تلقائياً، لكنها تساعد المطور على إجراء مراجعة أكثر وعياً.
أنشئ الاختبارات انطلاقاً من المتطلبات
لا تنشئ الاختبارات اعتماداً على الكود المنفذ فقط.
حدد أولاً السلوكيات المتوقعة ومعايير القبول بصورة مستقلة عن التنفيذ.
يجب إجراء اختبارات يدوية ومراجعات أمنية، خصوصاً في المجالات الحرجة مثل المصادقة، والمدفوعات، والصلاحيات، ومعالجة البيانات الشخصية.
وثّق القرارات المعمارية
يمكن إعداد سجلات قصيرة للقرارات المعمارية عند اتخاذ قرارات مهمة.
يكفي أن تجيب هذه السجلات عن الأسئلة التالية:
- ما المشكلة التي كان يتم حلها؟
- ما الخيارات التي تمت دراستها؟
- لماذا تم اختيار هذا الحل؟
- ما عيوبه المعروفة؟
- في أي ظروف يجب إعادة تقييم القرار؟
بهذه الطريقة، لا تظل المعرفة المهمة محصورة في محادثة مع الذكاء الاصطناعي أو في ذاكرة المطور.
لا تتخلَّ تماماً عن حل المشكلات دون ذكاء اصطناعي
قد يؤدي تفويض كل مهمة إلى الذكاء الاصطناعي إلى زيادة السرعة على المدى القصير.
لكن قراءة التوثيق، ومراجعة السجلات، وتصحيح الأخطاء، وتتبع تنفيذ الكود تظل مهارات أساسية للمطور.
من المفيد أحياناً تحليل المشكلة بشكل مستقل أولاً، ثم مقارنة النهج الخاص بك بالحل الذي يقترحه الذكاء الاصطناعي.
يعزز ذلك التعلم والقدرة على تقييم جودة الكود الناتج.
قائمة فحص دين المعرفة قبل دمج الكود
قبل إضافة كود أنشأه الذكاء الاصطناعي أو عدّله بصورة كبيرة إلى المشروع، اطرح الأسئلة التالية:
- هل أستطيع شرح المشكلة الأساسية التي يحلها هذا التغيير؟
- هل أعرف الملفات وسلوكيات النظام التي ستتأثر؟
- هل أفهم سبب اختيار هذا النهج؟
- هل تمت مراجعة مخاطر الأمان والأداء وسلامة البيانات؟
- هل تتحقق الاختبارات من المتطلبات الحقيقية، بدلاً من التحقق من التنفيذ الحالي فقط؟
- هل يمكنني إجراء تصحيح أساسي لهذا الكود دون الذكاء الاصطناعي؟
- هل تم إعداد التوثيق اللازم للمطورين في المستقبل؟
إذا لم يكن من الممكن الإجابة عن معظم هذه الأسئلة، فقد يعمل الكود تقنياً، لكن الفريق قد يستمر في تراكم دين المعرفة.
مطور المستقبل لن يكون الشخص الذي يكتب أكبر كمية من الكود
مع إنشاء وكلاء الذكاء الاصطناعي لمزيد من الكود، لا يختفي دور المطور. لكن مركز هذا الدور يتغير.
لم يعد المطور مجرد شخص يكتب الكود.
أصبح مسؤولاً عن تعريف المشكلة، واختيار الحل المناسب، والتحقق من مخرجات الذكاء الاصطناعي، وتقييم مخاطر الأمان، والحفاظ على النظام على المدى الطويل.
كلما زادت كمية الكود التي ينشئها الذكاء الاصطناعي، ازدادت أهمية الفهم البشري.
عندما تتسارع عملية الإنتاج، يمكن للقرارات الخاطئة، والخيارات غير الموثقة، والهياكل غير المفهومة أن تنمو بالسرعة نفسها.
قد لا يكون من الممكن التخلص من دين المعرفة بالكامل. لكن يمكن جعله مرئياً، وقياسه، وسداده تدريجياً.
يمكن للذكاء الاصطناعي مساعدتنا في إنتاج الكود بسرعة أكبر. لكن تطوير البرمجيات المستدام لا يحتاج فقط إلى كود يعمل.
بل يحتاج أيضاً إلى مطورين يفهمون ذلك الكود.
لن يكون المطور الأكثر قيمة في المستقبل هو من ينتج أكبر كمية من الكود، بل من يفهم لماذا يكون الكود الذي أنشأه الذكاء الاصطناعي صحيحاً أو خاطئاً.
