الذكاء الاصطناعي نقل عنق الزجاجة من كتابة الكود إلى مراجعته

لوحتك تقول إن الفريق يتحرك. وGitHub يقول إن هناك 41 pull request مفتوحًا، أقدمها عمره أحد عشر يومًا، والميزة التي وعدت بها يوم الخميس لم تصدر بعد. الجميع يشعرون بأنهم أسرع، وهم على الأرجح محقّون بشأن ساعاتهم هم.

تقرير GitLab عن المساءلة في الذكاء الاصطناعي، الذي نفّذته The Harris Poll على 1,528 مطوّرًا ومشتريًا للتقنية في ست دول ونُشر في 23 يونيو 2026، وجد أن 85% يوافقون على أن الذكاء الاصطناعي نقل عنق الزجاجة من كتابة الكود إلى مراجعته والتحقق منه. هذا استطلاع، فهو يقيس شعورًا. وثلاث مجموعات بيانات تشغيلية من هذا العام تتفق معه، ثم تناقض تقريبًا كل علاج يُباع من أجله.

تحيّزي، مرة واحدة: أعمل على أداة تتبّع مشاريع. تظهر في قسم واحد قرب النهاية، ومعها قائمة بما لا تستطيع فعله.

ثلاث مجموعات بيانات، ثلاثة تواريخ، وما تقوله فعلًا

معظم ما يُكتب في هذا الموضوع يستشهد بالرقمين نفسيهما، زيادة 98% في الـ pull requests المدموجة وارتفاع 91% في زمن المراجعة، بلا تاريخ عليهما. كلاهما من تقرير Faros AI الصادر في يوليو 2025. ونسخة 2026 أسوأ بمرتبة كاملة.

مجموعة البيانات	تاريخ النشر	العيّنة	الرقم المهم
‏CircleCI، تقرير حالة تسليم البرمجيات	18 فبراير 2026	28.7 مليون workflow	إنتاجية فروع الميزات ارتفعت 15%، والفرع الرئيسي انخفض 7%
‏LinearB، معايير الهندسة القياسية	2026	أكثر من 8.1 مليون PR	الـ PRs المولّدة بالذكاء الاصطناعي تنتظر 4.6 أضعاف قبل الالتقاط، وتُراجَع أسرع بمرتين
‏Faros AI، تقرير الهندسة 2026	12 أبريل 2026	22,000 مطوّر	الوقت في المراجعة ارتفع 441.5%، والدمج بلا مراجعة ارتفع 31.3%

انقسام CircleCI هو شكل المشكلة. عبر 28.7 مليون workflow منذ سبتمبر 2025، شغّل الفريق الوسيط عملًا على فروع الميزات أكثر بـ 15%، وعملًا على الفرع الرئيسي أقل بـ 7%. يُبنى أكثر. ويصل أقل.

قارنت Faros كل مؤسسة بنفسها: فترة أدنى تبنٍّ للذكاء الاصطناعي مقابل فترة أعلى تبنٍّ. الملاحم المنجزة لكل مطوّر ارتفعت 66%، ووسيط الوقت في مراجعة الكود ارتفع 441.5%، والأخطاء لكل مطوّر ارتفعت 54% مقابل 9% في نسخة 2025. الشركات نفسها قبل وبعد، فلا يفسّر الأمر ضعفُ فريق بعينه.

أكثر رقم يُستشهد به في هذا النقاش هو الرقم الخطأ

نصف الصفحات في هذا الموضوع تخبرك أن المطوّرين يشعرون بأنهم أسرع 20% بينما هم أبطأ فعليًا 19%. النتيجة حقيقية، لكنها لا تقول ما يريد أكثر من يستشهدون بها أن تقوله.

مصدرها METR في 10 يوليو 2025: 16 مطوّرًا خبيرًا في مشاريع مفتوحة المصدر، و246 مهمة، داخل مستودعات يعرفونها منذ سنوات. ستة عشر شخصًا، والرقم يُستشهد به اليوم إلى جوار 8.1 مليون pull request من LinearB كأن الاثنين دليل من النوع نفسه.

وهي أيضًا قديمة. تحديث METR في 24 فبراير 2026 شمل 57 مطوّرًا بأجر 50 دولارًا في الساعة بدلًا من 150. المجموعة العائدة تُظهر الآن تسارعًا بنسبة 18%، بفاصل ثقة يمتد من أسرع بـ 38% إلى أبطأ بـ 9%، وتصف METR الإشارة نفسها بأنها غير موثوقة: المطوّرون غير الراغبين في العمل بلا ذكاء اصطناعي رفضوا المشاركة، وبين 30% و50% من المشاركين تخطّوا مهامًا لم يرغبوا في إنجازها بلا مساعدة.

من يستشهد بالـ 19% اليوم دون هذا التحديث يفعل بالضبط ما كُتب هذا المقال للتذمّر منه. هل يجعل الذكاء الاصطناعي مطوّرًا واحدًا أسرع؟ السؤال ما زال مفتوحًا. أما هل طال الطابور أمام المراجعة، فلا خلاف عليه.

هذا طابور، والطوابير ليست لغزًا

flowchart LR
  A["Arrivals from humans and agents"] --> B["Queue of open PRs"]
  B --> C["Review, the service stage"]
  C --> D["Merge to main"]
  D --> E["Deploy and enable"]

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

ومعايير LinearB القياسية، المستخلصة من 8.1 مليون pull request عبر 4,800 مؤسسة، تقول لك أي طرف تحرّك. الـ pull requests المكتوبة بمساعدة الذكاء الاصطناعي تنتظر نحو 4.6 أضعاف قبل أن يلتقطها أحد، والصادرة عن وكلاء تنتظر 5.3 أضعاف، وحين يبدأ إنسان بقراءتها تُراجَع أسرع بنحو الضعف.

زمن الخدمة نزل. زمن الانتظار صعد خمسة أضعاف. التأخير ليس داخل المراجعة، بل أمامها.

والطرف الآخر الذي يتخطّاه الناس هو حجم الدفعة. قاست Faros ارتفاع متوسط حجم الـ PR بنسبة 154% في 2025، وبنسبة 51.3% في بيانات 2026. الوحدة الأكبر أبطأ في الخدمة وأصعب في البدء، ولهذا لا يفتحها أحد في الرابعة عصر الثلاثاء. وتضع LinearB نسبة قبول الـ PRs المولّدة بالذكاء الاصطناعي عند 32.7% مقابل 84.4% للمكتوبة يدويًا، فجزء من ذلك الطابور ينتظر أن يُرفض. أما ماذا تفعل بـpull request صحيح بنسبة 80 بالمئة من وكيل فقرار منفصل، يأتي بعد الانتظار لا أثناءه.

ما كلّفه الطابور مشروعين لم يستطيعا استيعابه

في 14 مارس 2026، أعلن Jazzband إغلاقه: 3,135 عضوًا، و84 مشروعًا، وأكثر من 150 مليون تنزيل شهريًا. إعلان Jannis Leidel يسمّي "slopocalypse" على GitHub، أي طوفان الـ PRs والمهام الرديئة المولّدة بالذكاء الاصطناعي، ويستشهد برقم مفاده أن واحدًا من كل عشرة pull requests مولّدة بالذكاء الاصطناعي يستوفي معايير المشروع.

ويسمّي سببًا ثانيًا بلا مواربة: كل شيء كان يمرّ عبر شخص واحد، والعضوية المفتوحة مع صلاحية push مشتركة لا تستوعب معدل ورود كهذا بمراجِع واحد.

‏curl هاجم الطرف الآخر. في 26 يناير 2026 أنهى Daniel Stenberg مكافآت الثغرات في curl، اعتبارًا من 31 يناير، مغلقًا برنامجًا يعمل منذ أبريل 2019 ودفع أكثر من 100,000 دولار مقابل 87 ثغرة مؤكدة. نسبة البلاغات المؤكدة كانت تتجاوز 15% في السنوات الأولى، ثم هبطت دون 5% منذ 2025. الدفع مقابل البلاغات تحوّل إلى دفع مقابل الفرز.

هل تشتري بوت مراجعة؟

بقية الإنترنت تجيب بنعم، مباشرة بعد تشخيص صحيح لمشكلة طابور. الأسعار من صفحة تسعير كل مزوّد، مراجَعة في يوليو 2026.

الأداة	الخطة	السعر	ما تشمله
‏CodeRabbit	Pro	24 دولارًا للمستخدم شهريًا بالاشتراك السنوي، و30 بالشهري	مراجعات وفحوص ما قبل الدمج
‏Greptile	Pro	30 دولارًا لكل مقعد شهريًا	50 رصيدًا لكل مقعد، ثم دولار لكل رصيد إضافي
‏Graphite	Team	40 دولارًا للمستخدم شهريًا بالاشتراك السنوي	مراجعات ذكاء اصطناعي بلا حد

بوت المراجعة يستحق ثمنه في الفحوص الآلية التي لا ينبغي لأحد أن يجريها بيده، وفي الفرز الذي يقول أيّ الـ 41 تُفتح أولًا. إن كان كبار مهندسيك يكتبون تعليقات في مستوى الـ lint، فاشترِ واحدًا.

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

ملاحظة بنيوية واحدة: Greptile وحده فاتورته فيها مكوّن لكل مراجعة، فهي تكبر مع معدل الورود الذي تحاول خفضه.

قِس قبل أن تضع سقفًا، فقد يكون Fenton محقًّا بشأنك

نشر Steve Fenton عكس عنواني في The New Stack يوم 16 يوليو 2026: البرمجة لم تكن يومًا عنق الزجاجة، والمراجعة ليست عنق الزجاجة اليوم، والقيد يقع لاحقًا في تجميع النشر بدفعات. اختباره جيد. في الخدمة التي تعمل عليها، كم تغييرًا اجتاز المراجعة ولم يُنشر ويُفعَّل للمستخدمين بعد؟

DEPLOYED=$(curl -s https://your-app.example.com/version | jq -r .sha)
git fetch origin main
git rev-list --count "$DEPLOYED"..origin/main

إن كان العدد كبيرًا، أغلق هذه الصفحة واذهب لإصلاح النشر.

وثلاثة أرقام تستحق أن تمتلكها أولًا. زمن المراجعة كتوزيع لا كمتوسط: وسيط أربع ساعات مع مئين 95 يبلغ تسعة أيام مرضٌ مختلف تمامًا عن توزيع مستوٍ عند يومين. ومعدل الورود مقسّمًا بحسب نوع الكاتب، أسبوعيًا. ونسبة المُراجَع إلى المدموج، لأن صعود الدمج بلا مراجعة يعني أن الطابور يُخفَّف بأسوأ طريقة متاحة.

gh pr list --state open --json author --jq 'group_by(.author.login)|map({(.[0].author.login): length})|add'

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

العلاجات، الأرخص أولًا

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

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

ثانيًا، اجعل التسلسل قابلًا للفرض. كل حالة تحمل قائمة بالحالات التي يجوز الانتقال إليها، وكل مسار كتابة يتحقق منها: سحب البطاقة على اللوحة، والتعديل الجماعي، وواجهة REST، ونقطة نهاية الانتقال، وقواعد الأتمتة. والحالة التي بلا قواعد تبقى بلا قيد، فالبوابة لا توجد إلا بعد أن يكتب أحدهم القواعد.

stateDiagram-v2
    state "In progress" as Prog
    state "In review" as Rev
    [*] --> Backlog
    Backlog --> Prog
    Prog --> Rev
    Rev --> Done
    Rev --> Prog

لا شيء يصل إلى "منجزة" دون المرور بالمراجعة: لا شخص يسحب بطاقة، ولا تعديل جماعي على 40 تذكرة، ولا وكيل يطرق الـ API في الثالثة فجرًا.

curl -X POST https://taskfolk.ai/api/v1/workspaces/acme/projects/WEB/issues/WEB-142/transition \
  -H "Authorization: Bearer tfk_live_..." -d '{"status": "backlog"}'

requests.post("https://taskfolk.ai/api/v1/workspaces/acme/projects/WEB/issues/WEB-142/transition",
    headers={"Authorization": "Bearer tfk_live_..."}, json={"status": "backlog"})

{ "error": { "code": "validation",
  "message": "Workflow blocks this transition: \"In Review\" cannot move to \"Backlog\".",
  "details": { "code": "workflow_transition_blocked", "from": "In Review", "to": "Backlog" } } }

‏HTTP 400، من أي باب جاءت الكتابة. حالات سير العمل المخصصة يغطي تحرير المخطط، وكيف تستخدم لوحة كانبان يغطي عرض الـ WIP.

ثالثًا، وهذا هو العلاج الذي خلفه دليل، اخفض معدل الورود. لم يوظّف curl مراجعين. أزال المكافأة، وفي 25 فبراير كتب Stenberg أن "تسونامي الوارد جفّ إلى حد بعيد"، وعاد الاستقبال إلى HackerOne في 1 مارس، فرزًا فقط وبلا مال.

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

لن تمحو طابور الـ PR لديك بهذه الطريقة، لكن الرافعة من الشكل نفسه: صغّر كل وحدة. قسّم الملحمة قبل أن يبدأ الوكيل، بدل قراءة 900 سطر بعدها. اكتب التذكرة بحيث تكون النتيجة الجيدة 150 سطرًا، وتكون قد فعلت لطابورك أكثر مما يفعله أي بوت. والموافقة بمشاركة إنسان هي النصف الآخر: بوابة أمام الكتابة خير من طابور خلفها.

ما لا يصلحه أي من هذا

نحن لا نراجع الكود: لا عرض diff، ولا تعليقات مضمّنة داخل التغييرات، ولا اقتراح إصلاح. إن أردت آلة تقرأ الـ diff، فاشترِ واحدة من الثلاث أعلاه.

تكاملنا مع GitHub يستهلك webhooks من نوع push وrelease فقط. يربط الـ commit بالمهام عبر #KEY-NUM، ويطلق إصدارًا حين يصل tag مطابق. ولا يرى أحداث pull_request أبدًا، فهو لا يعرف حالة مراجعة الـ PR: عمود اسمه "قيد المراجعة" هو كلمة فريقك، لا كلمة GitHub. وGitHub هو المزوّد الوحيد، فلا شيء هنا لفرق GitLab وBitbucket.

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

شيء واحد تفعله هذا الأسبوع

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

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

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