هل وفّر وكلاء الذكاء الاصطناعي وقتًا حقًا، أم أن الإحساس وحده كان سريعًا؟

عمود «منجزة» عندك ممتلئ بتذاكر الوكلاء، ومساؤك ممتلئ بالفروقات البرمجية. اللوحة تبدو أسرع. أما أسبوعك فلا.

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

وقبل أي شيء آخر، القيد: ‏Taskfolk لا يسجّل لحظة دمج طلب السحب، فتكامل GitHub عندنا يستقبل أحداث push وrelease ولا شيء غيرها، ولا يوجد تقرير يحسب الرقم الذي تهتم به هذه المقالة أكثر من غيره. كل ما هنا يعمل على حقل التقدير، وحقل مخصص واحد، وصفوف جلسات الوكلاء، وتصدير تسحبه بنفسك.

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

ساعة الوكيل تتوقف في مكان آخر

جلسة الوكيل تنتهي حين يضع التذكرة في «منجزة». وعملك أنت يبدأ من هناك. الوفر يُحتسب عند حدّ، والكلفة تقع عند حدّ آخر، والاثنان يظهران في جدولَي شخصين مختلفين. مقياس مبني هكذا يجامل الأول ويخفي الثاني.

flowchart LR
  A["Ticket assigned, session runs"] --> C["Agent marks it done"]
  C --> D["Waits in the review queue"]
  D --> E["A human reads the diff"]
  E --> F["Merged"]
  C --> G["The saving is reported here"]
  F --> H["The cost lands here"]

استطلاعان من 2026 ينتهيان إلى التناقض نفسه. سألت Harness 700 مهندس ومدير في خمس دول، وأعلنت في مايو أن 89% من قادة الهندسة يقولون إن الإنتاجية تحسّنت منذ تشغيل الذكاء الاصطناعي، بينما يقول 81% من القادة أنفسهم إن زمن مراجعة الكود ارتفع. واستطلعت Sonar آراء 1,149 مطورًا فوجدت 75% يوافقون على أن الذكاء الاصطناعي خفّض عملهم المرهق، بينما بقيت حصة أسبوع العمل التي قالوا إنها تذهب إلى ذلك العمل بين 23 و25% سواء استخدموه يوميًا أو من حين لآخر. وعنوان الفصل عند Sonar نفسها هو «وهم توفير الجهد المرهق». استطلاع يناقض نفسه داخل صفحة واحدة هو أنظف صورة رأيتها لهذه المشكلة.

لماذا تبتلع المراجعة المكسب؟ تلك حجة منفصلة، طرحناها في مقالة تحوّل مراجعة الكود إلى عنق الزجاجة. هذه المقالة عن القياس، لا عن التشخيص.

لا يمكنك تنفيذ التذكرة مرتين، فاكتب الرقم قبل البدء

لتعرف إن كان الوكيل قد وفّر وقتًا، عليك أن تعرف كم كانت التذكرة ستستغرق من دونه، وتلك التذكرة نُفِّذت مرة واحدة فقط.

الحيلة المعتادة هي السؤال بعد الانتهاء. وهذا ما يفعله بنك الاحتياطي الفيدرالي في سانت لويس بالضبط: استطلاعه Real Time Population Survey يسأل الناس كم ساعة إضافية سيحتاجون للعمل لإنجاز الشيء نفسه من دون الذكاء الاصطناعي التوليدي، وتجميع موجاته الثلاث لعام 2025 ينتهي إلى وفر قدره 1.6% من ساعات العمل كلها. وهذا مقبول في استطلاع وطني، لأن البنك لا يرى العمل قبل وقوعه. أما أنت فتراه.

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

flowchart TD
  A["Ticket refined and ready"] --> B["Human writes would have taken X"]
  B --> C{"Who runs it"}
  C -->|"agent"| D["Assign to the agent"]
  C -->|"human"| E["Assign to a person"]
  D --> F["Done, record actual"]
  E --> F
  F --> G["After fourteen days, record reopens"]

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

أربعة أرقام، والحقل الذي يسكنه كل رقم

الكلفة غائبة عن هذه القائمة عن قصد، فما ينفقه الوكيل على كل مهمة سؤال قائم بذاته تناولناه على حدة.

الرقم	من أين يأتي	سهل التصدير
التقدير المسبق مقابل الفعلي، مقسّمًا بين الوكيل والإنسان	حقل مخصص من نوع number، وestimate_minutes، وspent_minutes	نعم، عبر API
الفجوة بين «منجزة» والدمج	‏resolved_at من هنا، ووقت الدمج من GitHub	لا، تُجمَّع يدويًا
إعادة الفتح أو إعادة العمل خلال 14 يومًا	تكرار الدخول إلى الحالة نفسها في سجل النشاط	نعم، لكل مهمة
التذاكر التي طالتها التعديلات أكثر من مرتين	عدد صفوف النشاط بحسب الفاعل	نعم، لكل مهمة

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

مهمة تظهر فيها بطاقة الوقت بالتقدير مقابل الوقت المستهلك، وتحتها جلسة وكيل حيّة تحمل حالتها ووقت بدئها ورابط طلب السحب.

الإعداد كله في 20 دقيقة تقريبًا

أضف حقلًا مخصصًا واحدًا إلى المشروع. نوعه number، واسمه صريح مثل "Would have taken (min)"، ومطبّق على القصة والمهمة والخطأ. استخدم نوع الرقم المجرّد، لأنك ستحسب متوسطه لاحقًا.

بطاقة الحقول المخصصة في إعدادات المشروع وفيها حقل رقمي معرَّف، يظهر نوعه وعلامة كونه مطلوبًا وأنواع العمل التي ينطبق عليها.

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

ثم يأتي التصدير، وهنا المنتج أسوأ مما يوحي به وصفه. ملف CSV من عرض القائمة يحمل estimate_minutes ولا يحمل spent_minutes ولا story_points ولا completion_pct ولا أي قيمة لحقل مخصص، ويتوقف عند 5,000 صف. اسحب الباقي من REST API:

curl -s "https://taskfolk.ai/api/v1/workspaces/acme/projects/WEB/issues?status=done&limit=100" \
  -H "Authorization: Bearer tfk_live_a1b2..."

import os, requests
r = requests.get(
    "https://taskfolk.ai/api/v1/workspaces/acme/projects/WEB/issues",
    params={"status": "done", "limit": 100},
    headers={"Authorization": f"Bearer {os.environ['TASKFOLK_API_KEY']}"},
)

{
  "data": [
    {
      "key": "WEB-412",
      "status": "done",
      "assignee_id": "0199b1c4-7f3a-7c21-9d55-2b8e4a1f0c6d",
      "estimate_minutes": 90,
      "spent_minutes": 140,
      "resolved_at": "2026-07-14T09:21:44.000Z"
    }
  ],
  "pagination": { "next_cursor": "eyJjIjoiMjAyNi0wNy0xMVQxNjowMjoxMFoifQ" }
}

قيم الحقول المخصصة تأتي من نقطة نهاية الحقول المخصصة لكل مهمة، فالسحب سحبان. ولا يوجد مرشّح لنطاق زمني في قائمة المهام أيضًا، فنافذة الأسابيع الأربعة تعني تقليب الصفحات بالمؤشر (cursor) والترشيح في جانب العميل، أو حصر الفحص في سبرنت واحد. أنا أختار السبرنت. المزيد في كيف تستخدم REST API.

أربعة أسابيع، ولماذا نافذة إعادة العمل 14 يومًا

شغّلها أربعة أسابيع ثم توقّف. الأطول ليس أفضل هنا، لأن الأثر يتلاشى. قارن الباحث He وزملاؤه في Carnegie Mellon 806 مستودعات تبنّت Cursor بمشاريع لم تتبنَّها قط، فوجدوا قفزة تتراوح بين ثلاثة وخمسة أضعاف في الأسطر المضافة خلال شهر التبنّي الأول، تتبدّد بعد شهرين، يرافقها ارتفاع مستمر في تحذيرات التحليل الساكن وفي تعقيد الكود. قِس عند الشهر السادس فستقيس شيئًا آخر.

ولم يُختَر الرقم 14 اعتباطًا. يستخدم تحليل GitClear الصادر في يناير 2026 لـ623 مليون تغيير برمجي تبدّل الأسبوعين، أي الكود الذي يُعاد تعديله خلال أسبوعين من كتابته، مقياسًا لإعادة العمل، ويسجّله مرتفعًا بنسبة 15%. واستعارة النافذة نفسها تُبقي رقمك قابلًا للمقارنة برقم غيرك.

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

قراءة النتيجة حين تكون العيّنة 40 تذكرة وثلاثة أشخاص

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

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

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

الأزواج غير المتعادلة	الأزواج المطلوبة في اتجاه واحد لتنزل p تحت 0.05	قيمة p عندها
6	6	0.031
10	9	0.021
15	12	0.035
20	15	0.041
40	27	0.038

from math import comb

def sign_test(favor_agent, favor_human):
    n = favor_agent + favor_human       # ties dropped, never counted
    k = max(favor_agent, favor_human)
    tail = sum(comb(n, i) for i in range(k, n + 1))
    return min(1.0, 2 * tail / 2 ** n)

print(round(sign_test(17, 7), 3))   # 0.064
print(round(sign_test(19, 9), 3))   # 0.087

الحالتان المطبوعتان أعلاه ستصادفهما فعلًا: 17 من 24 لصالح الوكيل، و19 من 28، ولا واحدة منهما تنزل تحت 0.05. وستة أزواج تشير كلها إلى الاتجاه نفسه هي أصغر مجموعة تعبر العتبة، فأقل من ستة أزواج قابلة للمقارنة لكل شخص لا يقول لك شيئًا.

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

ما لا تستطيع البيانات قوله

استنتاجات لا يدعمها هذا التصميم مهما جاءت الأرقام:

• أن الوكلاء أسرع عمومًا. أنت قِست وكلاءك، وقاعدة كودك، وتذاكرك، في هذا الشهر.
• أن الأثر سيدوم. عمل Carnegie Mellon يضع المكسب في الشهرين الأولين.
• أن النتيجة الصفرية تعني أن الوكلاء بلا فائدة. الوقت نفسه بملل أقل نتيجة حقيقية، لكنها ليست وفرًا في الوقت.
• أن الوكيل هو السبب. أنت لم توزّع التذاكر عشوائيًا، والتذاكر التي ذهبت إلى الوكلاء هي التي بدت مناسبة لوكيل.
• أي شيء عن جودة الكود. لا شيء هنا ينظر في الفروقات.

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

ما لا يلتقطه Taskfolk

لا طابع زمني للدمج، كما قلت في المقدمة. يستقبل webhook التكامل مع GitHub أحداث push وrelease فقط، ولا يوجد عمود merged في أي موضع من المخطط، فتحصل على ذلك الطرف من GitHub بنفسك. ‏Jira يُظهره فعلًا: لوحة التطوير فيه تضع على عنصر العمل علامة الدمج بمجرد وصول طلب سحب مرتبط، ويمكن لقاعدة أن تنقل العنصر بين الحالات عند الحدث نفسه. فإن كان الفارق بين «منجزة» والدمج هو رقمك الرئيسي، فهو موجود في Jira وغير موجود عندنا.

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

تقرير زمن الدورة للمشروع، مفيد لقياس التدفق لكنه يوقف ساعته عند «منجزة»، ولهذا تحتاج الطريقة إلى مصدر ثانٍ.

ولا يوجد سجل ساعات بمدخلات منفصلة أيضًا، فقيمة spent_minutes هي ما كتبه الشخص بيده. وإن أردت تعريفًا دقيقًا لزمن الدورة وزمن الاستجابة الكلي (lead time)، كتبنا ذلك على حدة.

الأداة التي تدفع ثمنها أصلًا

منصات القياس منتجات جيدة، لكنها مبنية لمشترٍ مختلف.

الأداة	السعر المعلن، 27 يوليو 2026	ما الذي تغطيه
‏Axify Starter	‏$100 شهريًا ثابتة، بلا حدّ لعدد المساهمين	تبنّي أدوات الذكاء الاصطناعي وكلفتها فقط
‏Axify Pro	‏$29 لكل مساهم نشط، بفوترة سنوية	يضيف مقاييس طلبات السحب والسبرنت وDORA
‏DX	لا سعر معلن، تواصل مع المبيعات	عرض سعر بعد محادثة
‏Faros AI	لا سعر معلن، اطلب عرضًا توضيحيًا	عرض سعر بعد محادثة
‏Taskfolk	‏$3 أو $6 لكل منفّذ بشري، والوكلاء مجانًا	الحقول الأربعة التي تقرأها هذه الطريقة

سعر Axify Starter حقيقي ولن أثني أحدًا عنه، لكن تلك الفئة الثابتة تقف عند تبنّي الأدوات وكلفتها، والفئة التي تقرأ طلبات السحب تبدأ من $29 للفرد بالتزام سنوي. أما DX وFaros فتنشران إطار عمل بلا رقم. ولا واحدة من الثلاث تلتقط السيناريو البديل أصلًا، لأن أيًّا منها لا يرى التذكرة قبل أن يبدأ العمل. أداة التتبع عندك تراها، وهذه ميزتها الحقيقية الوحيدة هنا.

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