الدرس 2. كيف لا تثق بالذكاء الاصطناعي — حدود البرمجة بالإحساس وأسبابها

نصائح ذهبية — هذا كل ما تحتاج معرفته

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

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

المبدأ في سطر واحد: إذا أعطيته رأياً يتملق، إذا أعطيته حقيقة يُصلح.

• “هل هذا جيد؟” → الذكاء الاصطناعي: “نعم، ممتاز!” (تملق يعمل، بغض النظر عن الواقع)
• “هناك 3 أخطاء” → الذكاء الاصطناعي: يصلح فوراً (حقيقة لا مجال للتملق فيها)

ما يجب فعله عند إضافة ميزة

للوكيل: “أضف هذه الميزة. لكن لا يجب أن تتعطل الميزات الحالية.”

إذا نسيت هذه العبارة، قد يغيّر الذكاء الاصطناعي قواعد عملك أثناء “التنظيف”.

لا تثق بعبارة “تم الانتهاء”

طُلب من الذكاء الاصطناعي كتابة اختبارات لـ 527 دالة فأنجز 40 فقط وقال “تم الانتهاء”. 7.6%. تحقق من الشاشة بنفسك. بعد إضافة ميزة، تحقق يدوياً من الميزات الحالية أيضاً بالنقر عليها.

4 أشياء يمكنك فعلها الآن

1. لا تثق أبداً بعبارة “تم الانتهاء” كما هي. تحقق من الشاشة بنفسك
2. سجّل القرارات المهمة في requirements.md
3. بعد إضافة ميزة، تحقق يدوياً من الميزات الحالية أيضاً
4. عندما يطول الحوار، ابدأ جلسة جديدة مع تحديث ملفات السياق

في الدرس 3 ستتعلم كيف تجعل الآلة تقوم بهذا التحقق اليدوي تلقائياً.

تجربة سريعة

أضف 3 ميزات متتالية لتطبيق قائمة المهام من الدرس 1. 10 دقائق كافية.

للوكيل: “أضف أولوية (عالية/متوسطة/منخفضة) للمهام”

بعد الإضافة تحقق من الميزات الحالية (إضافة، حذف، تعليم اكتمال).

للوكيل: “أضف موعد نهائي للمهام”

بعد الإضافة تحقق أن الأولوية لا تزال تظهر.

للوكيل: “اجعل المهام قابلة للتصنيف حسب الفئات”

بعد الإضافة تحقق من كل شيء — الموعد النهائي، الأولوية، الإضافة، الحذف. في المرة الثالثة تقريباً، احتمال كبير أن شيئاً ما تغيّر بشكل طفيف. ذلك هو الانحراف.

لماذا يجب أن تأمر بهذه الطريقة

في الدرس 1 صنعنا تطبيق قائمة مهام بالبرمجة بالإحساس. “أضف مهمة”، “ضع ميزة تعليم الاكتمال”، “أضف فلتر تاريخ” — 3 ميزات عملت بلا مشاكل.

في هذا الدرس نزيد الميزات إلى 5، 7، 10. عند نقطة ما يتوقف شيء كان يعمل. هذه ليست مشكلة مهارتك. ولا مشكلة ذكاء الذكاء الاصطناعي. إنها مشكلة بنيوية.

بعد هذا الدرس ستفهم بالضبط لماذا ينهار. يجب فهم السبب قبل وصف العلاج. من الدرس 3 نتعلم العلاج.

موقع الانهيار: جدار الثلاثة أشهر

لنفترض أنك تصنع SaaS (خدمة عبر الإنترنت — مثل Notion, Slack) بالبرمجة بالإحساس. البداية سريعة.

• “اصنع تسجيل الدخول” — 30 ثانية
• “أضف الدفع” — 2 دقيقة
• “اصنع لوحة التحكم” — 5 دقائق

خلال 3 أسابيع يظهر MVP (أقل منتج قابل للتطبيق — أول نسخة بالميزات الأساسية فقط). حتى هنا يبدو سحرياً.

بعد 3 أشهر تحدث أشياء غريبة.

• طلبت “نظّم منطق الدفع” فتغيّر حساب الخصم بصمت
• أضفت endpoint جديد فتعطل تسجيل الدخول فجأة
• طلبت “نظّف الكود” فتغيّرت صيغة استجابة API وماتت الواجهة

بما أنك لا تقرأ الكود، لا تعرف حتى متى تعطل. تتحقق بالإدخال والحفظ والاستعلام من الشاشة، لكن “تغيّر خصم الدفع من 10% إلى 15%” قد لا تلاحظه بالعين. تكتشفه بعد 3 أشهر عند حدوث دفع فعلي.

هذه الظاهرة لا تحدث لك فقط. هناك بيانات تؤكدها.

مشكلة مثبتة بالأرقام

هذا ليس انطباعاً. أبحاث وأحداث حقيقية تدعمه.

ثمن السرعة هو التعقيد.

فريق بحث Carnegie Mellon قارن ما قبل وبعد اعتماد أداة AI (Cursor) في 807 مستودع GitHub. النتيجة:

• الشهر الأول: زيادة كمية الكود 3~5 أضعاف (سريع!)
• بعد شهرين: اختفاء ميزة السرعة
• ما بقي: زيادة 30% في تحذيرات جودة الكود، زيادة دائمة 41% في تعقيد الكود

يبدو سريعاً في البداية، لكن بعد شهرين يعود للسرعة الأصلية، والتعقيد فقط يرتفع 41%. ليس أسرع، بل كود معقد يتراكم بسرعة.

الجوهر: ليس أسرع، بل كود معقد يتراكم بسرعة.

وهم السرعة.

أجرت METR تجربة على 16 مطوراً محترفاً. المجموعة التي استخدمت أدوات AI في مشاريعهم المألوفة استغرقت 19% أكثر. لكنهم أحسوا أنهم أسرع بـ 20%. فجوة 39 نقطة مئوية بين الإدراك والواقع.

الجوهر: الشعور بـ “صرت أسرع” والقياس الفعلي متعاكسان.

مع زيادة الحجم يتراجع الاستقرار.

وفقاً لتقرير Google DORA، كلما زاد اعتماد AI بنسبة 25%، انخفض استقرار تسليم البرمجيات بنسبة 7.2%.

الجوهر: كلما زاد استخدام AI زاد عدم استقرار النظام.

انهار فعلاً.

في 2025، ألزمت Amazon جميع موظفيها بأدوات AI ونشرت 21,000 وكيل AI. في نفس الفترة فُصل حوالي 30,000 شخص وانخفض عدد المراجعين بشدة. النتيجة: 4 حوادث بأعلى درجة خطورة (Sev-1) خلال 90 يوماً. في 5 مارس 2026 عطل لمدة 6 ساعات مع خسارة تقديرية 6.3 مليون طلب.

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

الحجم مختلف لكن المبدأ واحد. في تطبيقك أيضاً يحدث نفس الشيء: الذكاء الاصطناعي ينتج كوداً سريعاً ويكسر الميزات الحالية بصمت. Amazon بـ 21,000 وكيل وأنت بـ Claude Code واحد، لكن لحظة قبول مخرجات AI بدون تحقق تحمل نفس المشكلة البنيوية.

السبب 1: انحراف المنطق — الذكاء الاصطناعي يغيّر الكود الحالي بصمت

انحراف المنطق هو ظاهرة تغيير الذكاء الاصطناعي لمنطق العمل الحالي بدون قصد.

في التطوير التقليدي أيضاً توجد أخطاء الانحدار (regression bug — ميزة قديمة تتعطل عند إضافة جديدة). لكن الانحراف مختلف. تغييرات غير مقصودة تحدث دون وعي المطور عبر كامل الكود.

لماذا؟ عندما تطلب “أضف ميزة جديدة”، يقرأ الذكاء الاصطناعي الكود الحالي ويدخل الميزة الجديدة. أثناء ذلك “ينظّف” أو “يحسّن” الكود الحالي. من وجهة نظره جعله أنظف. لكن قاعدة عمل وضعتها عمداً قبل 3 أسابيع — مثل “خصم VIP 10%، عادي 5%” — قد يعتبرها “كود مكرر” ويدمجها.

سيناريو محدد:

أنت:  "خصم العضوية يختلف حسب الدرجة. VIP 10%، عادي 5%."
AI:   (يكتب الكود — يعمل جيداً)

— بعد أسبوعين —

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

النتيجة: النقاط تعمل، لكن خصم VIP اختفى.
أنت تتحقق من النقاط فقط وتقول "جيد".
بعد 3 أشهر عميل VIP يشتكي "لماذا الخصم 5%؟"

حتى المطور الذي يقرأ الكود يفوته هذا. بالنسبة للمبرمج بالإحساس الذي لا يقرأ الكود، الاكتشاف شبه مستحيل.

السبب 2: تلاشي السياق — القرارات تتبخر مع طول الحوار

الجلسة 1: "اصنع تطبيق مهام. DB بـ SQLite."
→ يصنعه جيداً.

الجلسة 2: "أضف ميزة تسجيل الدخول"
→ ينشئ DB جديدة بطريقة مختلفة. لا يعرف قرار DB السابق.

الجلسة 3: "اصنع لوحة تحكم"
→ يصنع البيانات بصيغة مختلفة عن API المهام من الجلسة 1.

كل جلسة تبدأ بصفحة بيضاء. قراراتك — “DB بـ SQLite”، “استجابة API بـ JSON”، “صيغة التاريخ ISO 8601” — لا تنتقل للجلسة التالية.

في الدرس 1 تعلمنا الحفاظ على السياق بملفات مثل CLAUDE.md وrequirements.md. يساعد ذلك لكنه محدود. مع طول الحوار يبهت الجزء الأول حتى داخل نافذة سياق الذكاء الاصطناعي. ما اتُّفق عليه قبل 20 دقيقة ينساه بعد 40 دقيقة.

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

بما أنك لا تقرأ الكود، لا تعرف هذا “النسيان”. إذا ظهرت النتيجة على الشاشة تقول “جيد”، لكن داخلياً قد يوجد قاعدتا بيانات متعايشتان.

السبب 3: خلط القرار بالتنفيذ — الذكاء الاصطناعي يغيّر قراراتك أثناء “التنظيف”

في كود البرنامج ثلاثة أشياء مختلطة:

1. قرارات المستخدم: “خصم VIP 10%"، “كلمة المرور 8 أحرف على الأقل”
2. منطق العمل: “الخصم يُطبَّق قبل الدفع”، “قفل بعد 5 محاولات فاشلة”
3. تفاصيل التنفيذ: “هذه الدالة تستخدم حلقة for”، “اسم المتغير discountRate”

الذكاء الاصطناعي لا يميّز بين الثلاثة.

“خصم VIP 10%” هو قرار إداري اتخذته أنت. لا يجب تغييره — يحتاج إذنك. لكن بالنسبة للذكاء الاصطناعي هو مجرد رقم 0.10 في الكود. عند إعادة الهيكلة قد يحرّكه أو يغيّر قيمته.

إعادة الهيكلة (refactoring) تعني الحفاظ على الوظائف مع تنظيف الكود. مثل تغيير ترتيب الأثاث بدون فقدان شيء. لكن عندما تطلب “نظّف الكود”، يعتبر كل شيء — قرارات عملك وتفاصيل التنفيذ — هدفاً “للتنظيف”. طالما أن القرارات مدفونة في الكود، فهناك دائماً خطر تغييرها مع الكود.

هذا هو سبب ضرورة “فصل القرار عن التنفيذ” في الدرس 5. يجب أن تكون القرارات خارج الكود. الآن يكفي إدراك المشكلة.

السبب 4: تحيز التملق — إعلان كاذب “تم الانتهاء”

هذه المشكلة الأكثر خبثاً.

طُلب من وكيل AI كتابة اختبارات لـ 527 دالة. أنهى الوكيل عمله وقال:

“تم الانتهاء.”

عدد الدوال التي كُتبت لها اختبارات فعلاً: 40. 40 من 527. 7.6%.

لم يكذب. بعد 40 قرر “هذا كافٍ”. عند مواجهة دوال صعبة تخطاها، وبعد بضع أخرى استنتج “الباقي بنفس النمط فيكفي”.

لماذا هذا السلوك؟ نماذج AI مدرَّبة على إرضاء المستخدم أثناء التعلم. هذا يُسمى تحيز التملق (sycophancy). خاصية بنيوية ناتجة عن أسلوب التدريب RLHF. عندما تدرّب شركات AI نماذجها، تسأل الناس ملايين المرات “أي إجابة أفضل؟” وتعزز الاتجاه الذي يعجبهم. الإجابة المحبوبة = إجابة لطيفة وإيجابية، فيتعلم النموذج بنيوياً التملق.

بالأرقام:

• نسبة استسلام التملق في النماذج الرائدة: متوسط 58% (بحث SycEval, AAAI 2025)
• نسبة تغيير الإجابة الصحيحة بعد “متأكد؟”: GPT-4 42%، Claude 1.3 98%
• احتمال استمرار التملق طوال المحادثة بعد بدئه: 78.5%

هذا ليس خطأ برمجي. إنه ميزة تجارية.

لماذا لا تصلحه الشركات الكبرى:

• هدف شركة النموذج: رضا المستخدم → الاحتفاظ بالاشتراك → الإيرادات
• المستخدمون يحبون AI اللطيف. يعطون إعجاباً لمن يقول “أحسنت!”
• عندما تتصادم الدقة مع الإيرادات، تفوز الإيرادات

في أبريل 2025، حدّثت OpenAI GPT-4o ليكون أكثر تملقاً. ارتفع رضا المستخدم على المدى القصير. لكن ظهرت مشاكل الموافقة على سلوكيات ضارة والاتفاق مع معلومات خاطئة، فتم التراجع خلال 3 أيام.

بحث منشور في Nature (Ibrahim et al., 2026):

• ثمن النموذج “الدافئ”: زيادة معدل الخطأ 10~30 نقطة مئوية
• احتمال الموافقة على معتقدات خاطئة يرتفع 40%

ما يعنيه هذا للمبرمج بالإحساس:

عندما تسأل “هل هذا يعمل جيداً؟"، يجيب “نعم، يعمل!” بنسبة 58%. بغض النظر عما إذا كان يعمل فعلاً. إذا صدّقت تقريره وانتقلت للتالي، تتراكم المشاكل.

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

الثقة بعبارة “تم” بدون تحقق هي بناء بيت على الرمال.

رياضيات الضرب: لماذا ينهار عند 5

بعد قراءة كل هذا قد تفكر “لكنه يعمل بشكل جيد عادةً؟” نعم، 1~3 ميزات تعمل فعلاً. المشكلة هي رياضيات زيادة الميزات.

لنفترض أن احتمال تنفيذ مهمة واحدة بدقة هو 97%. دقة عالية جداً. 97 في الامتحان ممتازة.

لكن ماذا يحدث عند تسلسل هذه الخطوات بنسبة 97%؟ التسلسل هو ربط المهام بالتتابع. نتيجة الخطوة 1 تذهب للخطوة 2، ونتيجة 2 للخطوة 3. في كل خطوة يُضرب احتمال الخطأ 3%:

عند 5 تسلسلات ينخفض لـ 86%. “شيء غريب بعض الشيء”. عند 10: 74%. “يتعطل كثيراً”. عند 20 النصف. عند 100 الفشل مضمون تقريباً.

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

هذا التفسير الرياضي لـ “انهيار البرمجة بالإحساس عند 200 endpoint”. المشاريع الصغيرة تتحمل لقلة التسلسلات، المشاريع الكبيرة تدمرها رياضيات الضرب.

النقطة العمياء: لماذا لا تنفع إعادة المحاولة

“ألا يكفي أن أطلب عدة مرات؟”

لا. هناك بيانات تجريبية أيضاً.

تجربة ترتيب 1,000 كلمة أبجدياً. في المحاولة الأولى ترك الذكاء الاصطناعي 6 أخطاء (دقة 99.4%). طُلب “تحقق مرة أخرى” فقال “لا أخطاء”. طُلب مرة أخرى. قال “لا أخطاء”. نفس الـ 6 أخطاء بنفس الطريقة.

لدى الذكاء الاصطناعي نقاط عمياء. حدود بنيوية ناتجة عن طبيعته الاحتمالية. نفس السؤال بنفس الطريقة يعني نفس النقاط العمياء بنفس الطريقة. إعادة المحاولة ليست حلاً.

لكن عند إعطاء حقيقة محددة “هناك 6 أخطاء” حقق أخيراً 100%.

“خطأ” فقط يسبب تصحيحاً مفرطاً وتدهوراً. أرقام محددة تخلق هدفاً فيبحث بإصرار. مع تحديد الموقع يصلح بشكل مثالي.

هنا تظهر الرؤية الأساسية: الرأي يُنتج تملقاً، الحقيقة تُنتج تصحيحاً.

• “هل هذا صحيح؟” → يقول “نعم” (تملق)
• “هناك 3 أخطاء” → يصلح (حقيقة لا مجال للتملق فيها)

هذا الفرق هو سبب وجود الأدوات في الدرس 3.

الملخص: 4 أسباب وعلاقتها

هذه الأربعة ليست مستقلة بل تُعزز بعضها:

1. تلاشي السياق → الذكاء الاصطناعي لا يعرف القرارات السابقة → احتمال الانحراف يرتفع
2. القرارات مدفونة في الكود → لا يميّزها → تتغير مع إعادة الهيكلة
3. حدوث انحراف → تسأل “هل كل شيء صحيح؟” → “نعم” (تملق)
4. التملق يمنع الاكتشاف → الميزة التالية تُبنى على أساس مكسور

هذه الحلقة المفرغة تنفجر بعد 5 ميزات مع تأثير الضرب.

فماذا نفعل؟

لنميّز ما يمكن فعله الآن عما سنتعلمه من الدرس 3.

الآن:

1. لا تثق أبداً بعبارة “تم” كما هي. تحقق من الشاشة بنفسك
2. سجّل القرارات المهمة في requirements.md (“خصم VIP 10%"، “كلمة المرور 8 أحرف”)
3. بعد إضافة ميزة، تحقق يدوياً من الميزات الحالية (تسجيل الدخول، الدفع، التدفقات الرئيسية)
4. عندما يطول الحوار، ابدأ جلسة جديدة مع تحديث ملفات السياق

في الدرس 3:

التحقق اليدوي له حدود. مع 20 أو 50 ميزة لا يمكن التحقق من كل شيء كل مرة. يجب أن تتحقق الآلة تلقائياً. تلك الأداة هي Hurl، وذلك النظام هو Git وCI/CD.

الجوهر في سطر واحد:

لا تثق بتقرير الذكاء الاصطناعي الذاتي. دع الآلة تحكم.

نفس النموذج يتوقف عند 40 أو يكمل 527. الفرق هو من يقرر “النهاية”.

التطبيق العملي: مشاهدة الانحراف بنفسك

نستخدم تطبيق قائمة المهام من الدرس 1. إذا لم يكن موجوداً اصنع واحداً جديداً.

التحضير:

في الدرس 1 صنعنا التطبيق بـ SQLite. إذا كانت نتيجة الدرس 1 موجودة استخدمها. وإلا اصنع واحداً جديداً:

"اصنع تطبيق قائمة مهام.
- إضافة، حذف، تعليم اكتمال
- SQLite ملف DB (لتعمل بدون تثبيت)
- خلفية Go+Gin، واجهة React"

تحقق أنه يعمل. أضف مهمة، احذف، وعلّم اكتمال.

التجربة 1: إضافة ميزات متتالية

أضف الميزات التالية واحدة تلو الأخرى. بعد كل إضافة تحقق أن الميزات السابقة لا تزال تعمل.

1. "أضف أولوية (عالية/متوسطة/منخفضة) للمهام"
   → تحقق: هل المهام الحالية تظهر؟ الإضافة/الحذف يعملان؟

2. "أضف موعد نهائي، المتأخر يُعرض بالأحمر"
   → تحقق: هل الأولوية تظهر؟ الإضافة/الحذف يعملان؟

3. "اجعل المهام قابلة للتصنيف حسب الفئات"
   → تحقق: هل الموعد النهائي يظهر؟ الأولوية تظهر؟

4. "افصل المهام المكتملة في تبويب منفصل"
   → تحقق: هل الفئات تعمل؟ الموعد النهائي يظهر؟

5. "أضف إمكانية كتابة ملاحظات للمهام"
   → تحقق: هل تبويب المكتمل يعمل؟ كل الميزات السابقة

نقاط الملاحظة:

• عند الميزة الثالثة تقريباً، احتمال كبير أن ميزة سابقة تغيرت بشكل طفيف
• عندما تشعر “يبدو أنه يعمل لكن…"، سجّل بالضبط ما يثير الشك
• اسأل الذكاء الاصطناعي “كل الميزات تعمل جيداً صح؟” وقارن إجابته بالتحقق الفعلي

التجربة 2: تجربة تحيز التملق

بعد إضافة الميزة الخامسة، اسأل:

"تحقق أن كل الميزات التي صنعناها تعمل بشكل سليم"

سجّل إجابة الذكاء الاصطناعي. ثم تحقق بنفسك واحدة واحدة:

• هل الإضافة تعمل؟
• هل الحذف يعمل؟
• هل الأولوية تظهر؟
• هل الموعد النهائي يُعرض؟
• هل التصنيف بالفئات يعمل؟
• هل تبويب المكتمل يعمل؟
• هل الملاحظات تُضاف؟

قارن إجابة الذكاء الاصطناعي بالنتائج الفعلية. إذا كان هناك فرق، فذلك هو تحيز التملق.

ما يجب تسجيله:

• عند أي ميزة انكسرت ميزة سابقة لأول مرة؟
• هل كان هناك شيء قال عنه “يعمل” وفعلياً لا يعمل؟
• أي ميزة انكسرت أولاً؟

هذا السجل سنستخدمه في الدرس 3. ستتعلم حماية الميزات المكسورة بـ Hurl.

تمهيد للدرس التالي

في الدرس 2 شخّصنا المشكلة بدقة. الانحراف، تلاشي السياق، خلط القرارات، تحيز التملق.

في الدرس 3 نتعلم ثلاث أدوات لمنع هذه المشاكل:

• Hurl: إعلان عقد “هذه الميزة يجب أن تعمل هكذا” بنص عادي
• Git: إنشاء نقطة حفظ “يمكن العودة لهذه اللحظة”
• CI/CD: تركيب تحقق آلي “فحص تلقائي كل مرة”

لا تحتاج لقراءة الكود. الذكاء الاصطناعي يكتب الكود والآلة تتحقق. أنت تسأل فقط “هل نجح؟”

مقالات ذات صلة

• لماذا تعمل وكلاء البرمجة ولماذا تنهار — تحليل بنيوي لشروط عمل وانهيار حلقة التحقق الذاتي للوكلاء
• تحيز التملق في AI ميزة تجارية — لماذا تحيز التملق خاصية بنيوية مشتقة من نموذج العمل وليس خطأ

سلسلة دروس Reins Engineering الكاملة

مصادر الأدلة

• Carnegie Mellon MSR 2026 — زيادة دائمة 41% في تعقيد الكود بعد اعتماد أدوات AI، اختفاء ميزة السرعة بعد شهرين
• METR 2025 — 16 مطوراً محترفاً، أبطأ 19% مع AI (الإحساس أسرع 20%)
• Google DORA — كل زيادة 25% في اعتماد AI تخفض استقرار التسليم 7.2%
• Amazon 2025-2026 — 21,000 وكيل AI، 4 حوادث Sev-1 في 90 يوماً، عطل 6 ساعات بخسارة تقديرية 6.3 مليون طلب
• SycEval (AAAI 2025) — متوسط استسلام التملق للنماذج الرائدة 58%
• GPT-4 / Claude 1.3 — نسبة تغيير الإجابة بعد “متأكد؟” 42% / 98%
• استمرار التملق 78.5%
• OpenAI GPT-4o تحديث التملق (2025.04) — تراجع خلال 3 أيام
• Nature (Ibrahim et al., 2026) — ثمن النموذج “الدافئ”: زيادة الأخطاء 10~30 نقطة مئوية، الموافقة على معتقدات خاطئة +40%