الـ AI بيكتب كود أكتر… والشغل اللي بيخلص ما زادش

كود أكتر مش معناه شغل خلصان أكتر

الـ AI coding agents بقت جزء من أغلب فرق البرمجيات. الوعد كان بسيط: نكتب كود أسرع ونسلّم أكتر. بس أرقام 2026 بتحكي حكاية تانية.

الأرقام بتقول إيه؟

دراسة من Harvard عملها Fiona Chen و James Stratton، واتحدثت يوم 7 نوفمبر 2026، غطت أكتر من 720 ألف مهندس في 655 شركة. الفرق اللي استخدمت AI coding agents فتحت Pull requests أكتر بنسبة 35.7%. لكن الـ Issues اللي اتحلت فعلًا زادت 13.7% بس، والنتيجة دي على الحد من ناحية الدلالة الإحصائية.

ونسخة أقدم من نفس الدراسة لقت إن عدد الناس اللي اتسحبوا للـ Code review زاد 14%، وده حمل تقيل على الـ Senior engineers.

وAtlassian شافت نفس الفجوة في أبحاثها: استخدام المهندسين للـ AI زاد 65%، بينما مكاسب الـ Velocity واقفة عند حوالي 10%. وAtlassian بتقول إن السبب اختناقات برّه كتابة الكود، زي الـ Planning والـ Review والـ Maintenance.

عنق الزجاجة اتنقل

لما كتابة الكود بتبقى أسهل، الجزء البطيء في السيستم بيتنقل لمكان تاني. في أغلب الفرق اتنقل لـ:

• الـ Code review. كل Pull request طالع من الـ AI لسه محتاج بني آدم يقراه ويفهمه ويوافق عليه.
• الـ Testing والـ QA. تغييرات أكتر يعني حاجات أكتر لازم تتراجع.
• الـ Rework. كود ماشي على الـ Prompt بس مش على اللي المستخدم محتاجه فعلًا، بيرجع Bugs أو إعادة تصميم.

لو سرّعت خطوة واحدة من غير ما تحل اللي بعدها، التسليم مش هيزيد. انت بس بتنقل كومة الشغل من مكان لمكان.

ليه الـ Velocity لوحده بقى مضلل

لو قارنت الـ Velocity قبل الـ AI وبعده، ممكن تلاقيه زاد وتعتبرها نجاح. لكن الـ Velocity بيحسب اللي الفريق بيقول عليه Done، ومش بيوضح:

• كام ساعة راحت في مراجعة كود الـ AI،
• قد إيه من الشغل رجع Bugs أو Rework،
• هل فيه واحد أو اتنين Seniors شايلين الـ Review كله.

الـ Sprint ممكن يبان أسرع على الـ Chart، والفريق نفسه حاسس إنه أبطأ وتعبان أكتر.

٤ حاجات تغيّرها في الـ Sprint Planning الجاي

1. احجز Capacity للـ Review. اتعامل مع الـ Code review كشغل حقيقي في الخطة، مش حاجة بتتعمل في الوقت الفاضي. لو الـ AI ضاعف عدد الـ Pull requests، وقت الـ Review هيزيد هو كمان.

2. قيس الشغل اللي خلص، مش النشاط. تابع التذاكر اللي وصلت Done وفضلت Done. عدد سطور الكود والـ Commits والـ Pull requests بيقيس نشاط، مش قيمة اتسلمت.

3. وزّع حمل الـ Review. شوف مين بيراجع إيه. لو نفس الاتنين بيوافقوا على أغلب الـ Pull requests، يبقى هما الحد الحقيقي للـ Sprint.

4. تابع الـ Rework والـ Bug fixing. قيس قد إيه من كل Sprint بيروح على الـ Bugs وإعادة الشغل مقارنة بالشغل الجديد. لو النسبة دي زادت بعد الـ AI، يبقى المكسب أقل بكتير من اللي باين.

دورك

وقت الـ Review عندكم زاد من ساعة ما بدأتوا تستخدموا أدوات الـ AI؟ ومين شايل أغلبه؟ قولولنا انتوا شايفين إيه.

LazyScrum فين من ده؟

LazyScrum بيساعدك تعمل الـ Planning على عنق الزجاجة الحقيقي. مع LazyScrum هتقدر تشوف وتتابع كل الـ Activity من مكان واحد. اعمل Planning بـ Capacity حقيقية فيها مساحة للـ Review، وشوف حمل كل شخص على Timeline بدقة ٣٠ دقيقة، واستخدم تقرير نهاية الـ Sprint والـ Measure report عشان تعرف قد إيه وقت راح على الـ Bug fixing والـ Rework مقارنة بالشغل الجديد. LazyScrum بيعمل Sprint Planning لايف فوق Jira، فيه Estimation، وأعضاء الفريق بيدخلوا الـ Planning مجانًا.

LazyScrum فيه Free trial لمدة ٧ أيام. جرّبه من هنا.

المصادر: تغطية دراسة Harvard على Beri.net · Forkast · إعلان Atlassian