من يكتشف الأخطاء عندما يكتب الذكاء الاصطناعي 80٪ من الشفرة؟

كتابة المقالة: ليو

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

هذه ليست سيناريوهات افتراضية. في فبراير 2026، شهد مطور عينيه تنفيذ أمر تيرافورم destroy بواسطة Claude Code، مما أدى إلى حذف 1.94 مليون سطر من قاعدة البيانات الإنتاجية. في يوليو 2025، قام وكيل Replit بحذف قاعدة بيانات إنتاجية خلال فترة تجميد واضحة، حيث اختفت 1206 سجل من كبار التنفيذيين و1196 سجل من الشركة، ثم اختلق 4000 سجل زائف لتغطية الخطأ، وادعى أنه يمكن استعادة البيانات. سجلت Harper Foley 10 حوادث خلال 16 شهرًا عبر 6 أدوات ترميز بالذكاء الاصطناعي، ولم يصدر أي مزود تقرير تحليل بعد الحوادث.

هذه هي العالم الذي ندخله الآن. يمكن لوكيل الذكاء الاصطناعي كتابة الشفرة، ونشر الميزات، وإصلاح المشكلات، ولكن عندما يحدث خطأ، حتى أنت لا تعرف لماذا قام بذلك. نوافذ السياق تُغلق، وعمليات الاستنتاج تتلاشى، وأنت تتعامل مع شبح. هذا يذكرني برؤية قبل سنوات من قبل طالب دكتوراه في ستانفورد، أنيميش كوراتانا، عندما كان في عمر 26 عامًا. كان يدرس تقنيات ضغط نماذج الذكاء الاصطناعي في مختبر DAWN بستانفورد، وكان قد بدأ يتعامل مع نماذج اللغة الكبيرة منذ وقت مبكر. عندما التقى بالمطورين الأوائل لأدوات المساعدة في برمجة الذكاء الاصطناعي، خطرت له فكرة: “في المستقبل، ستكتب الحواسيب الشفرة، ولن يكتبها البشر. كيف سيكون ذلك العالم؟” كان يعلم قبل ظهور كلمة “AI slop” أن هذه الوكلاء سيكتبون كودًا يضر بالنظام مثل البشر.

العيوب القاتلة في عصر برمجة الذكاء الاصطناعي

بعد دراسة عميقة، اكتشفت أن أكبر مشكلة في أنظمة وكلاء الذكاء الاصطناعي الحالية ليست في جودة النموذج، أو قدرة استدعاء الأدوات، أو حتى في سلسلة التفكير. المشكلة الحقيقية هي: لا أحد يبني طبقة ذاكرة أساسية. تتوقع Gartner أن 40% من مشاريع وكلاء الذكاء الاصطناعي ستُلغى بحلول نهاية 2027، والسبب الرئيسي ليس ضعف النموذج، بل نقص هذه الطبقة من الذاكرة.

درست جامعة كاليفورنيا في بيركلي تتبع 1600 وكيل عبر 7 أُطُر، ووجدت أن معدل الفشل يتراوح بين 41% و87%. مشروع NANDA بمعهد ماساتشوستس للتكنولوجيا اكتشف أن 95% من مشاريع الذكاء الاصطناعي التوليدية للشركات لا تؤدي إلى تأثير ملموس على الميزانية العمومية. السبب الجذري هو ما يُسمى بـ"فجوة التعلم": الأنظمة لا تحتفظ بالتغذية الراجعة، ولا تتكيف مع السياق، ولا تتحسن مع مرور الوقت. النموذج نفسه ليس المشكلة، بل البنية التحتية المحيطة به مفقودة.

دعني أوضح الأمر أكثر. عندما ينفذ وكيل الذكاء الاصطناعي 50 خطوة لحل مشكلة عميل، كل خطوة تتعلق بالسياق. ماذا استرجع؟ ماذا قرر؟ ماذا تخلى عنه؟ لماذا اختار المسار A بدلًا من B؟ وجود عمليات الاستنتاج هذه، هو الوقت الذي تظل فيه نافذة السياق مفتوحة. ثم تُغلق النافذة، وتنتهي الجلسة، ويختفي الاستنتاج. وما يتبقى هو المخرجات: PR، تحديثات التذاكر، النشر. لكن سلسلة القرارات التي أدت إلى هذه المخرجات؟ تختفي إلى الأبد.

هذه ليست مشكلة سجل الأحداث. طبقة الرصد لديك يمكنها أن تلتقط الخدمات التي تم استدعاؤها، ومدة الزمن التي استغرقتها، لكنها لا تستطيع أن تلتقط ما في كلمات التلميح، أو الأدوات المستخدمة أثناء اتخاذ القرار، أو لماذا تم اختيار عملية معينة على أخرى، أو مدى ثقة الوكيل في كل قرار عند نقطة الانقسام. تقول LangChain بدقة: في البرمجيات التقليدية، الكود يسجل التطبيق؛ أما في وكلاء الذكاء الاصطناعي، فإن التتبع هو وثيقتك. عندما تنتقل من تتبع منطقي إلى نموذج، فإن مصدر الحقيقة يتحول من الكود إلى التتبع. المشكلة أن معظم الفرق لا تلتقط هذه التتبعات. هم يلتقطون السجلات فقط. والفارق بين السجلات والتتبع هو الفرق بين معرفة “ما حدث” ومعرفة “لماذا حدث”.

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

حل PlayerZero

لهذا السبب أسس كوراتانا شركة PlayerZero. كان مرشده في ستانفورد، Matei Zaharia، شخصية أسطورية في مجال قواعد البيانات، ومؤسس مشارك في Databricks، الذي أنشأ تقنيات أساسية للشركة أثناء دراسته للدكتوراه. بدعم من مرشد كهذا، بدأ كوراتانا يبني حلاً: باستخدام وكيل ذكاء اصطناعي مدرب، يكتشف ويصلح المشكلات قبل أن يُدخل الشفرة في الإنتاج.

أعلنت PlayerZero مؤخرًا عن إتمام جولة تمويل من الفئة A بقيمة 15 مليون دولار بقيادة Ashu Garg من Foundation Capital، وهو أيضًا من داعمي Databricks الأوائل. هذه الجولة تأتي بعد جولة تمويل أولي بقيمة 5 ملايين دولار بقيادة Green Bay Ventures. كما أن قائمة المستثمرين الملائكة مذهلة: إلى جانب Zaharia، هناك Drew Houston، المدير التنفيذي لـ Dropbox، وDylan Field، المدير التنفيذي لـ Figma، وGuillermo Rauch، المدير التنفيذي لـ Vercel.

ما أدهشني هو كيف يتحقق كوراتانا من فكرته. الحصول على Zaharia كمستثمر ملاك كان خطوة أولى، لكن الاختبار الحقيقي كان عندما عرض على مطور آخر مشهور، Rauch. Rauch هو مؤسس شركة أدوات التطوير Vercel، التي تقدر قيمتها بثلاثة أضعاف، وهو أيضًا منشئ إطار العمل JavaScript الشهير Next.js. شاهد Rauch العرض بفضول لكن مع بعض الشك، وسأل عن مدى “واقعية” ما يُعرض. رد كوراتانا أن هذا “رمز يعمل في بيئة الإنتاج، وهو مثال حقيقي”. ثم، سرعان ما أصبح Rauch، الذي سيصبح مستثمر ملاك، هادئًا، وأجاب: “إذا استطعت حقًا حل المشكلة بالطريقة التي تتصورها، فسيكون ذلك إنجازًا كبيرًا.”

الهيكل الأساسي لـ PlayerZero

المكون الأساسي لديهم هو ما يسمونه “نموذج العالم” (World Model)، وهو مخطط سياقي يربط كل تغييرات الشفرة، والأحداث القابلة للملاحظة، وتذاكر الدعم، والحوادث السابقة، في بنية حية واحدة. عندما تظهر مشكلة، يُرجعها PlayerZero إلى السطر المحدد في الشفرة، ويولد إصلاحًا، ويوجهه عبر Slack إلى المهندس المسؤول، الذي يمكنه الموافقة بنقرة واحدة. دورة الكشف عن المشكلة والإصلاح تعمل بشكل مستقل خلال دقائق. كل حادثة تم حلها تُعاد بشكل دائم إلى نموذج العالم، بحيث عندما يتم إصدار رمز مشابه في المستقبل، يكون النظام على علم بالمشكلة السابقة.

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

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

لماذا هذا النظام فعال

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

نظامهم Sim-1 يتقدم خطوة أخرى. يحاكي قبل النشر كيف ستؤدي تغييرات الشفرة في أنظمة معقدة، مع الحفاظ على التناسق عبر أكثر من 100 حالة انتقال و50 عبورًا لحدود الخدمات. على أكثر من 2770 سيناريو لمستخدم حقيقي، حقق دقة محاكاة بلغت 92.6%، مقابل 73.8% للأدوات المقارنة. هذا ليس تحليلًا ثابتًا مزينًا بنماذج اللغة، بل محاكاة تعتمد على سلوك الإنتاج الملاحظ. يزود مخطط السياق Sim-1 بمعرفة عن سلوك النظام الحقيقي، وليس فقط أدائه على الورق.

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

النتائج من حالات العملاء مذهلة حقًا. شركة Zuora، التي تقدم خدمات الفوترة بالاشتراك، تدعم بنية تحتية لمؤسسات من فئة Fortune 500، وتستخدم التقنية عبر فريقها الهندسي، بما في ذلك مراقبة أهم رموزها — نظام الفوترة. شركة Nylas، التي توفر واجهات برمجة تطبيقات موحدة للبريد الإلكتروني والتقويم والجدولة، كانت من أوائل العملاء. كلاهما يمثل فئة حيث الفشل في الاعتمادية يمكن أن يسبب خسائر مالية وعقود مباشرة. تدعي PlayerZero أن النظام أنهى في دقائق عمل استغرق أسابيع لفرق QA مكونة من 300 شخص، وقلل من مشاكل الإنتاج بنسبة النصف، ووفّر أكثر من مليوني دولار لكل عميل.

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

تأثير عميق على هندسة البرمجيات

أعتقد أن PlayerZero لا يمثل مجرد أداة تصحيح أخطاء، بل هو تحول جذري في نمط هندسة البرمجيات. تخيل أن كل قرار يتخذه الوكيل يُسجل ويُعاد تشغيله بشكل دائم، ماذا سيحدث لمستودع الشفرة الخاص بك؟

تغيّر تدريب الموظفين. عند انضمام مهندس جديد، لن يقرأ وثائق قديمة أو يعكس تاريخ git، بل سيتحقق من سجل القرارات. لماذا قُسمت الخدمة؟ ماذا فشل قبل إعادة الهيكلة؟ ما التوازنات التي تم تقييمها عند اختيار الهيكلية؟ الإجابات موجودة لأن الوكيل الذي أنجز العمل ترك تتبعًا، وليس مجرد مخرجات.

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

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

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

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

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

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

نحن على مفترق طرق

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

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

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

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

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

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