ماذا يفعل مهندسك المبتدئ بعد أن أخذ وكلاء الذكاء الاصطناعي التذاكر؟

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

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

التوزيع أولًا، والمبرّر بعده

لا أحد ينشر مزيج تذاكر لهذه الحالة، فالتوزيع أدناه توصية تضبطها على فريقك، لا نتيجة بحثية. المدخل الخارجي الوحيد فيه هو بيانات الدمج. درست ورقة قُدّمت في MSR 2026 نحو 33,000 pull request كتبها وكلاء، ووجدت أن تغييرات التوثيق وCI والبناء هي الأعلى دمجًا، وأن عمل الأداء وإصلاح الأخطاء هو الأدنى (‏Ehsani وآخرون، 21 يناير 2026، خمسة وكلاء). ضع الإنسان في الموضع الذي يكون فيه معدل دمج الوكيل أضعف.

المسار	حصة البداية من الأسبوع	ما ينتجه
كتابة المواصفات	30%	تذاكر ينهيها الوكيل دون أن يسأل
المراجعة الأولى لـ PRs الوكلاء	30%	تعليق مراجعة قبل أن ينظر الخبير
ملكية التسليم في الأصناف الممنوعة على الوكلاء	25%	عمل منجز يحمل اسمه
عمل الحُكم: إعادة إنتاج الخلل، والغموض، والعبور بين الخدمات	15%	قرار يستطيع غيره البناء عليه

اكتبها، بنسبها، رغم أنها تخمينات. وجد تقرير LeadDev عن أثر الذكاء الاصطناعي لعام 2025 أن 38% من المشاركين يوافقون على أن أدوات الذكاء الاصطناعي قلّصت الإرشاد المباشر الذي يتلقاه المهندسون المبتدئون من الخبراء، وأن 18% يتوقعون توظيفًا أقل للمبتدئين خلال عام، مقابل 10% يتوقعون توظيفًا أقل للخبراء (‏Chantal Kapani، 4 سبتمبر 2025). الإرشاد الذي كان يحدث فوق خلل مشترك لم يعد يحدث مصادفة.

المسار الأول: هو من يكتب التذكرة التي ينفّذها الوكيل

كتابة المواصفة وقاية من العيوب، وصار لهذا الكلام سند رقمي الآن. شملت دراسة صدرت في مايو 2026 20,574 جلسة حقيقية لوكلاء برمجة عبر 1,639 مستودعًا، وصنّفت الإخفاقات الظاهرة فيها إلى سبعة أشكال متكررة. أكبرها، بنسبة 38.33%، هو مخالفة الوكيل قيدًا ذكره المطوّر أصلًا. وجاء سوء فهم المقصد ثانيًا بنسبة 26.95%، وفي 44.10% من تلك الحالات كانت الفجوة في الـ prompt نفسه. وعلى مستوى المجموعة كلها، احتاجت 91.49% من الحلول التي استطاع الباحثون رصدها تدخّل إنسان يصحّح للوكيل مساره.

هذه الأرقام الثلاثة هي المسار: اكتب القيود، اكتبها بدقة، وأبقِ إنسانًا قريبًا للحالات التي لا ينفع فيها الأمران.

لذلك تحمل التذكرة معايير قبول تستطيع آلة التحقق منها، وخطوات إعادة إنتاج الخلل، وحدود الوحدة البرمجية، وقائمة صريحة بما لا يُمَسّ، والاختبار الذي يثبت النتيجة. وشكل التذكرة موضوع قائم بذاته، يغطيه اكتب تذاكر يستطيع وكلاء الذكاء الاصطناعي إنهاءها.

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

curl -s "https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions?state=needs_input" \
  -H "Authorization: Bearer tfk_live_a1b2..."

const res = await fetch(
  "https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions?state=needs_input",
  { headers: { Authorization: `Bearer ${process.env.TASKFOLK_API_KEY}` } },
);

{
  "data": [
    {
      "issue_key": "WEB-241",
      "state": "needs_input",
      "note": "Spec does not say if retries are per delivery or per endpoint."
    }
  ]
}

اقرأ عشرًا من هذه الملاحظات وستعرف ما الذي لم يكتبه المبتدئ عندك بعد. ‏WEB-241 عيب في المواصفة، وله ختم زمني.

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

المسار الثاني: عمود المراجعة هو مكتبه

أضف عمودًا حقيقيًا بين قيد التنفيذ ومنجزة، وسمّه مراجعة الوكيل. الوسم يترك البطاقة قابعة في قيد التنفيذ حيث لا يعدّها أحد، أما العمود فيجعل الـ PR غير المُراجَع عالقًا أمام العين. واربطه بفئة الحالة قيد المراجعة، فهي ما تُرشّح عليه العروض العابرة للمشاريع.

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

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

flowchart TD
  A["Ticket is ready"] --> B{"On the register?"}
  B -->|"Senior class"| C["Senior owns it"]
  B -->|"Judgment class"| D["Junior owns it"]
  B -->|"Neither"| E["Agent picks it up"]
  E --> F["Agent review column"]
  F --> G["Junior first review"]
  G -->|"Signs off"| H["Senior merges"]
  G -->|"Escalates"| C

والجزء الذي يبقى عادةً بلا كتابة هو خط الفصل: ما الذي يعتمده المراجع الأول وحده، وما الذي يرفعه إلى غيره كما هو.

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

درّبه على الصف الثالث أكثر من غيره. تقرير GitClear لعام 2026 عن قابلية الصيانة، المستخلص من 623 مليون تغيير برمجي منذ 2023، يضع الكتل المكرّرة عند 73.0 لكل مليون سطر متغيّر هذا العام مقابل 40.3 في 2023، بينما هبطت الأسطر المنقولة أو المعاد تشكيلها من 21% من التغييرات في 2022 إلى 3.8%. الوكلاء يعيدون البناء بدل إعادة الاستخدام. وسؤال "هل هذا موجود أصلًا؟" فحص يستطيع مبتدئ إجراءه بـ grep وستة أسابيع من الألفة بقاعدة الكود، ولا أحد يجريه اليوم. أما إيصال مهندس جديد إلى تلك الأسابيع الستة حين يكون معظم الكود مولَّدًا فمهمة قائمة بذاتها، يغطيها مقال تأهيل مهندس جديد على كود كتبه وكلاؤك.

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

الاعتراض، ولماذا أظنه يسقط

الاعتراض المعتاد أن الخبير وحده يستطيع مراجعة الكود المولَّد بأمان، فوضع مبتدئ على PRs الوكلاء تهوّر. وهو معقول بمقاييسه هو. لكنه يقيس على خط أساس لا يملكه أحد.

صنّفت دراسة نُشرت في 4 مايو 2026 نشاط المراجعة على 33,596 pull request كتبها وكلاء في مستودعات لها 100 نجمة أو أكثر. ووجدت أن 61.38% منها لم تحظَ بأي مراجعة مسجّلة إطلاقًا. وباحتساب البوتات مراجِعين، تبقى 84.0% منها بلا مراجعة أو بمراجعة وكيل وحدها، فلم يبقَ إلا 15.9% فيها أي مشاركة بشرية موثّقة.

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

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

جلسة وكيل حيّة على المهمة، وفيها شارة الحالة والملاحظة ورابط الـ pull request.

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

المسار الثالث: سجل ما لا يُفوَّض

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

# do-not-delegate.yml, reviewed monthly
senior_only:      # agent barred, junior does not own the merge either
  - authentication
  - authorization
  - cryptography and keys
  - payment and refund paths
  - personal data paths
  - database migrations
  - public API contracts
  - infrastructure and deploy config
junior_owned:     # agent barred: the spec must be discovered, not executed
  - customer bugs with no reproduction yet
  - requirements with an open question in them
  - changes crossing more than one service
  - performance work

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

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

ما تفرضه الأداة، وما يبقى عرفًا

أن تظن سجلًا مفروضًا وهو ليس كذلك أسوأ من أن تعرف أنه مجرد عرف.

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

وضابطان آخران يفرضان، على محور مختلف. الانتقالات المسموح بها بوابة صلبة: أي نقل حالة ليس على قائمة العمود المسموحة يُرفض في كل مسار كتابة، بما فيها REST وMCP. وسياسة الحقول لكل وكيل قائمة سماح على 14 حقلًا في المهمة، تُفحص عند نقطة اختناق واحدة تغطي REST ونقطة نهاية الانتقال وMCP ونقطة نهاية الوقت. والوكيل الذي تُسقط سياسته assignee لا يستطيع إعادة الإسناد، من أي باب دخل.

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

وثلاثة أشياء تبدو ضوابط وهي ليست كذلك. حدود الـ WIP عدّاد ولون، ولا شيء يرفض بطاقة. وقواعد الانتقال على مستوى المشروع ولا ترى من ينفّذها، فلا يمكنك السماح لإنسان بنقل بطاقة إلى منجزة ومنع وكيل من النقل نفسه. وسياسة الحقول لكل حقل لا لكل قيمة، فجملة "يجوز له ضبط الحالة، لكن إلى مراجعة الوكيل فقط" لا يمكن التعبير عنها.

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

المسار الرابع: سُلّم الحُكم

اختفت آلاف الإصلاحات الصغيرة التي كانت تبني الحدس. وإن لم تعوّضها عمدًا، فلن يعوّضها شيء.

الأسابيع	ما يملكه	الإشارة التي تبحث عنها
1 إلى 2	يقرأ جلسات الوكلاء من أولها إلى آخرها، ولا يراجع شيئًا وحده	يسمّي ما الذي تخطّاه الوكيل
3 إلى 6	مراجعة أولى على PRs الوكلاء قليلة المخاطر، ويعيد الخبير مراجعة كل واحدة	تعليقاته تصل قبل تعليقات الخبير
7 إلى 12	مراجعة أولى على كل PR خارج السجل، ومواصفات تذاكره	تراجُع needs_input على تذاكره
الربع الثاني	يملك صنفًا من قائمة المبتدئ كاملًا، بمساعدة وكيل، من أوله إلى آخره	يرفض diff يبدو سليمًا ويقول لماذا

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

طابور المراجعة كعرض مشترك على مستوى مساحة العمل، فيصير رابطًا واحدًا بدل مرشّح يُعاد بناؤه.

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

أين تضعف هذه الخطة

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

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

المسارات عرف. مشروع مقيّد واحد يجعل جزءًا من السجل حقيقيًا، وضابطان يضيّقان ما يجوز للوكيل كتابته، والباقي أنت، تتحقق.

ابدأ بعمود واحد

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