تأهيل مهندس جديد على كود كتبه وكلاء الذكاء الاصطناعي

يسألك المهندس الجديد عن كاتب وحدة التسوية. تشغّل git blame فيهبط كل سطر على squash merge من مارس، منسوبًا إلى من ضغط الزر، فوق رسالة نصّها "implement reconciliation per spec" وسطر Co-authored-by يحمل اسم نموذج. أما صاحب الطلب الذي أنتج هذا الكود فقد غادر في مايو.

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

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

رسالة الـ commit لا تقول شيئًا، وسطر Co-authored-by ليس دليلًا

الثقة بهذا السطر أكبر مما يستحق. بدأ VS Code 1.110 بإضافة Co-authored-by: Copilot تلقائيًا في أوائل مارس 2026، وكان يظهر حتى على commits لم يُستخدم فيها Copilot، وبعد أن يكون المطوّر قد راجع الرسالة بنفسه. ثم أعادت Microsoft الإعداد إلى الاختيار اليدوي في الإصدار 1.119 يوم 3 مايو 2026. أي أن السطر قد يحمل اسم نموذج لم يلمس الملف، وقد يغيب عن كود كتبه نموذج من أوله إلى آخره. وحتى السطر الصحيح يسمّي إصدار أداة، لا شخصًا تستطيع سؤاله.

git log --format='%h %an %(trailers:key=Co-authored-by,valueonly)' \
  -- src/billing/reconcile.ts

لو كانت المشكلة حقلًا واحدًا مشوّشًا لهانت. في ورقته The Substrate Collapse، المقدَّمة في 18 يونيو 2026، يطرح Brett Wheeler ما هو أكبر: كل مقياس معرفة مبني على من كتب الكود، بما فيه truck factor، يقوم على استنتاج واحد، وهو أن كتابة الكود تثبت فهمه. التوليد يكسر هذا الاستنتاج. "البصمة نفسها صارت متوافقة مع فهم كامل أو جزئي أو معدوم."

أنت لم تفقد اسمًا. نظام إدارة الإصدارات لم يعد قادرًا على الإجابة عن السؤال أصلًا.

لا، تكليف وكيل بشرح الكود لا يحلّ المشكلة

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

لكنها لا تقترب من السؤال الذي يحمله مهندسك الجديد فعلًا، وهو دائمًا صيغة من صيغ "لماذا". لماذا طابور دائم بدل cron؟ ولماذا عدد محاولات الإعادة أربع؟ هذا لم يكن في الكود من الأساس.

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

التشخيص ليس لنا وليس جديدًا. نشر Addy Osmani مصطلح دين الفهم (comprehension debt) في أبريل 2026، ويعرّفه بأنه "الفجوة المتنامية بين كمية الكود الموجودة في نظامك وكمية ما يفهمه أي إنسان منها فهمًا حقيقيًا." ووضعت Thoughtworks فكرة قريبة منه باسم الدين الإدراكي لقاعدة الكود في حلقة التحذير من Technology Radar Vol. 34 في الشهر نفسه. أما ما لا يكتبه أحد تقريبًا فهو النصف التشغيلي: أي أثر تنتجه، ومتى.

ثلاثة أشياء كان يمنحها الكاتب البشري ولا يحملها أي diff

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

ما كان التأهيل يعتمد عليه	أين كان يعيش	ما الذي يبقى حين يكتبه وكيل
البدائل التي جُرِّبت ورُفضت	ذاكرة الكاتب، وأحيانًا مستند تصميم	لا شيء. نافذة السياق ذهبت.
القيد الذي فرض هذا الشكل	ذاكرة الكاتب، أو سلسلة محادثة	لا شيء، إلا إذا ذكرته التذكرة
إلى من تصعّد حين ينكسر	ذاكرة الفريق، تسندها سجلات blame	‏merge commit واسم نموذج

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

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

المشكلة تُحلّ لحظة التفويض، لا لحظة التنقيب

إما أنك حللتها يوم كتبت التذكرة، أو أنك لم تحلّها. لا توجد نافذة ثانية.

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

## Why this shape
Durable queue, not cron: reconcile has to survive a deploy mid run.
Rejected: cron plus an advisory lock. The lock outlived the pod twice in staging.
Constraint: the settlement file lands between 02:10 and 02:40 UTC, unordered.
Ask: @dana

flowchart LR
  A["Constraint is known"] --> B["Ticket records why"] --> C["New engineer reads it"]
  D["Constraint stays in your head"] --> E["Window discarded"] --> F["New engineer guesses"]

اكتب هذه الكتلة وأنت لا تزال تعرف الجواب، فهذه اللحظة الوحيدة التي تكون فيها رخيصة، وضعها في قالب المهام لا في انضباطك الشخصي، لأن الانضباط يخسر أمام أسبوع مزدحم. أما أعراف المستودع فمكانها AGENTS.md، وقد تناولناها في توزيع العمل بين وكلاء البرمجة. أما التذكرة فتحمل ما يخصّ هذا التغيير وحده.

الأثر الذي يتركه إعداد جيد

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

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

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

استعلام التنقيب كله طلب واحد:

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

const res = await fetch(
  "https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions?issue_key=WEB-39",
  { headers: { Authorization: "Bearer tfk_live_a1b2..." } },
);
const { data } = await res.json();

import requests

res = requests.get(
    "https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions",
    params={"issue_key": "WEB-39"},
    headers={"Authorization": "Bearer tfk_live_a1b2..."},
)
data = res.json()["data"]

{
  "data": [
    {
      "agent_name": "Dana's Claude Code",
      "state": "done",
      "note": "opened PR 412, ledger diff is zero",
      "external_url": "https://github.com/acme/api/pull/412"
    }
  ]
}

وهنا حدّ يغيّر ما تقوله لوكلائك. الحقل note عمود واحد، وكل تحديث يكتب فوق سابقه. لا تاريخ له. ما تقرأه على جلسة منتهية هو آخر ما قاله الوكيل، لا سجل ما فعله.

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

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

أين تتفوق Linear علينا في هذا

أطلقت Linear جلسات البرمجة في 11 يونيو 2026. وكيلها يكتب الكود عبر Claude Code وCodex، ثم يعيد الـ diff على المهمة للمراجعة. يحتاج إلى ربط GitHub بصلاحية الوصول إلى الكود، ويستهلك رصيد الذكاء الاصطناعي، ومتاح على خطط Basic وBusiness وEnterprise. وتقول Linear إن هذا المسار يحلّ نحو 30% من تقارير الأخطاء الواردة إليها، معظمها من المحاولة الأولى.

هذا السجل يتفوق على سجلنا في النقطة التي تهم هنا، لأن الـ diff نفسه يجلس على التذكرة. نحن نخزّن مؤشرًا إليه فقط. فإن حُذف الـ pull request، أو انتقل المستودع، أو لم يكن لمهندسك الجديد وصول إلى منظمة GitHub تلك، صار external_url عندنا رابطًا ميتًا ولم يبقَ سوى الملاحظة. لذلك اجعل وكلاءك يضعون التبرير في تعليق على المهمة، لا في وصف الـ pull request وحده.

وما نكسبه من تصميمنا هو التجانس. لا يشغّل Taskfolk وكيلك أبدًا، بل يرسل إليه المحفزات ويخزّن الجلسة بينما تعمل البيئة على حاسوب محمول أو داخل CI. في جدول مقارنة المزايا يبدو هذا نقصًا. وفي عملية تنقيب يعني أن الأثر يبدو واحدًا سواء جرى التشغيل في Claude Code أو في Codex أو في شيء كتبته بنفسك.

مقعد المنفّذ في Taskfolk بـ $3 شهريًا على Pro و$6 على Business، بينما تعلن Linear خطة Basic بـ $10 وBusiness بـ $16 لكل مستخدم شهريًا بفوترة سنوية (تحققنا من الأرقام في 27 يوليو 2026). والوكلاء المتصلون عندنا لا يُحتسبون مقاعد منفّذين. لكننا لم نجد قاعدة منشورة لدى Linear بخصوص فوترة الوكلاء، فعامل هذه النقطة على أنها مجهولة، لا مكسبًا لنا.

ماذا عن الكود المكتوب سلفًا بلا شيء من هذا

أنت تقرأ هذا لأن الكود موجود ولم يُسجَّل شيء من سياقه. والكلمة الصادقة لما يأتي بعد ذلك هي الإنقاذ.

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

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

تتبّع Liu وزملاؤه 302,600 commit من تأليف الذكاء الاصطناعي عبر 6,299 مستودع GitHub، فوجدوا أن 22.7% من العيوب التي أدخلها الذكاء الاصطناعي لا تزال حية في أحدث نسخة من المستودع. وكانت روائح الكود 89.3% منها، وهي الفئة التي يرجّح أن يقرأها القادم الجديد على أنها مقصودة فيتركها كما هي.

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

أسبوع أول مبني على ما تبقّى

لا تبدأ بالمهندس الجديد من المستودع. ابدأ به من اللوحة.

sequenceDiagram
    participant E as New engineer
    participant I as Issue
    participant S as Agent session
    participant O as Agent owner
    E->>I: Which ticket produced this file
    I->>E: Scope, constraint, acceptance
    I->>S: Session anchored to the issue
    S->>E: State, output URL, agent name
    E->>O: Ask the named human owner
    O->>E: Why the cron was rejected

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

في اليوم الثالث يكتب تذكرة لتغيير صغير، ويفوّضها بنفسه، ويراجع ما يعود إليه. هذا هو نمط السؤال المفاهيمي الذي صمد في دراسة Anthropic.

يبقى على أحدهم أن يجيب عن "لماذا"، وحين يكون المالك قد غادر يُعاد بناء الجواب بدل استرجاعه. ويبقى على أحدهم أن يجلس مع المهندس الجديد وهو يقول "هذا يبدو جنونيًا" عن وحدة صحيحة تمامًا. لا شيء مما سبق يغني عن أي من هاتين المهمتين.

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