Faros: في الفرق التي تستخدم وكلاء الذكاء الاصطناعي ارتفع الوسيط الزمني لمراجعة الكود بنسبة 441%

تُظهر بيانات Faros عن 22 000 مطوّر أن الوسيط الزمني لمراجعة الكود ارتفع بنسبة 441% في الفرق ذات المستوى المرتفع من اعتماد الذكاء الاصطناعي، وأن دمج طلبات السحب (pull request) دون أي مراجعة صار أكثر تكرارًا بنسبة 31%. أما الوقت الذي توفّره الوكلاء، فينفقه الناس بأنفسهم على مهام جديدة وعلى مراجعة كود كتبه غيرهم. وفي سبتمبر راسل أحد كتّاب Habr معارفه الذين بدؤوا العمل مع وكلاء الذكاء الاصطناعي قبل شهرين تقريبًا، وسألهم عن أحوالهم.

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

المطوّرون ينفقون الوقت الموفَّر بأنفسهم

راقب باحثو Berkeley Haas على مدى ثمانية أشهر شركة تقنية أمريكية يعمل فيها نحو 200 شخص (ونشرت HBR النتائج). مع الذكاء الاصطناعي التوليدي يعمل الموظفون بسرعة أكبر، ويتولّون مهام أوسع، وينتهون من العمل في وقت متأخر، مع أن أحدًا لا يطلب منهم ذلك. تُرسَل الـprompts وقت الغداء وأثناء المكالمات وخلال تحميل ملف ما. ومع الوقت يتحوّل النمو المبكر في الإنتاجية إلى تراجع في الجودة وارتفاع في معدل ترك العمل.

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

الأمر يسوء أولًا: منحنى التعلّم والانطباعات المضلِّلة

أكثر الدراسات استشهادًا بها حول التباطؤ هي دراسة METR الصادرة في يوليو (وهو مختبر يقيس الأثر الفعلي للذكاء الاصطناعي على العمل). حلّ 16 مطوّرًا من ذوي الخبرة في المشاريع مفتوحة المصدر (open-source) مهامَّ في مستودعاتهم الخاصة، واستغرق ذلك معهم وقتًا أطول بنسبة 19% عند استخدام الذكاء الاصطناعي. وقبل التجربة كانوا يتوقعون تسريعًا بنسبة 24%، وبعدها ظلّوا يعتقدون أنهم أنجزوا أسرع بنسبة 20%. استخدم المشاركون Cursor لبضع عشرات من الساعات فقط، ويكتب المؤلفون صراحةً أنه لا يمكن استبعاد تأثير التعلّم بعد 50+ ساعة.

وأظهر قياس ثانٍ بعد ستة أشهر تسريعًا بنحو 18% لدى عشرة مشاركين عادوا إلى التجربة. غير أن فاصل الثقة يشمل الصفر، ويصف المؤلفون أنفسهم هذه الإشارة بأنها غير موثوقة: فكثيرون رفضوا العمل بدون الذكاء الاصطناعي، فانحازت العيّنة. وفي استطلاع METR يقدّر الناس الفائدة بنحو الضعف، وبحسب القياسات السابقة يبالغون في تقدير الأثر بمتوسط 40 نقطة مئوية.

خلاصة الكاتب: بلا مهارة ومشروع مهيّأ قد يبطّئ الذكاء الاصطناعي العمل فعلًا، والانطباعات تخدع. من توقف في قاع الحفرة يخلص إلى أن «الذكاء الاصطناعي لا يعمل». ومن اجتازها يقول: «لم أعد أستطيع العمل بدونه». أما الخطر ففي المنتصف: يرى المطوّر في خلاصته عشرة وكلاء أنهَوا قائمة المهام المتراكمة (backlog) في ليلة واحدة، فيثبّت إطار عمل (framework) آخر وخمسة MCP، ويشغّل الوكلاء بالتوازي، ويدخل في حالة قلق دائم.

الثقة تساوي قابلية التحقق: ترتيب الاعتماد

يرسم استطلاع Stack Overflow 2026 الحدّ الفاصل: في القرارات المهمة يثق بالذكاء الاصطناعي 6% من المطوّرين، لكن قرابة نصفهم يثق به إذا استطاع التحقق من النتيجة. وبدون تحقق آلي سريع يبقى خياران مرهقان: قراءة كل سطر، أو قبول عبارة «تم» على محمل الثقة ومعالجة العواقب بعد أسبوع. والموقف المعقول هو موقف قائد الفريق (team lead): مراقبة «الجذع والأغصان» (المعمارية، والفوترة، ونموذج البيانات، والاختبارات الحرجة) وعدم لمس كل ورقة.

وفي استطلاع أجراه الكاتب في قناته على Telegram، اعتبر 2 فقط من 32 مشاركًا أن اختيار الأداة هو المشكلة الرئيسية، فيما اعتبر 19 أن المشكلة هي تنظيم المعرفة. وهذا هو الترتيب الذي توصّل إليه:

• الأساس الهندسي، وبدونه لا يمكن التمييز بين تغيير يعمل وتغيير يبدو معقولًا؛
• صياغة المهمة مع معايير القبول قبل كتابة الكود؛
• حلقة التغذية الراجعة (feedback loop): الأنواع (types)، وأداة فحص الكود (linter)، والاختبارات، والمتصفح، والسجلات، كي يتحقق الوكيل من نفسه؛
• الإضافات (skills وMCP والإضافات البرمجية) بعد ذلك فقط؛
• المعرفة بالمشروع، وخطة للمهام الكبيرة، والمراجعة وفق المتطلبات؛
• الوكلاء المتوازون في آخر المطاف.

المرحلة التي يجري تخطّيها تكلّف أكثر لاحقًا. والخطأ المعتاد هو القفز مباشرة إلى Spec-Driven Development وأدوات التنسيق (orchestrators) وخمسة وكلاء. يحصل المبتدئون على مواصفات (specs) يفوق حجمها حجم الكود بـ3–5 أضعاف ولا يقرؤها أحد، وعلى حدود استخدام مستنفدة وإحساس بالتعامل مع صندوق أسود. كما أن تثبيت الإضافات دون تدقيق ينطوي على خطر على سلسلة التوريد: ففي فبراير 2026 عثرت Koi Security على 341 skill خبيثة من أصل 2 857 في سوق ClawHub.

لأسلوب التعلّم أهميته أيضًا. ففي تجربة Anthropic، حصل المطوّرون المبتدئون الذين تعلّموا مكتبة جديدة بمساعدة الذكاء الاصطناعي على 50% في الاختبار مقابل 67% لمن تعلّموها بدونه. لكن من طرحوا على الوكيل أسئلة مفاهيمية وعالجوا الأخطاء بأنفسهم حصلوا على 65% فأكثر.

خلاصة الكاتب: الحفرة ستُعبَر، أما حجم عمل التحقق فلن يزول، وهذا هو الوضع الطبيعي الجديد. ويمكن تخفيف الحمل بإسناد الفحوص الروتينية إلى الأدوات ووكيل ثانٍ بسياق نظيف، والاحتفاظ بالجوانب الحرجة فقط، وعدم إبقاء عدد من الوكلاء مفتوحًا يفوق ما تستطيع مراجعته. وسيقدّم الكاتب عرضه حول هذا الموضوع في المؤتمر الإلكتروني AI Dev Live في 12 نوفمبر.