وكلاء البرمجة: أين تنفع الاستقلالية فعلًا؟

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

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

أين يستحق الوكلاء ثقتك فعلًا

أربعة أنواع من العمل أسلّمها اليوم دون تردد:

• الترحيلات. ترقية أطر العمل، ورفع إصدارات الاعتماديات، ونقل وحدةٍ بعيدًا عن مكتبة مهجورة. كلّفتُ وكيلًا مؤخرًا بنقل قاعدة كود Angular متقادمة عبر إصدارين رئيسيين، فلمس نحو مئتي ملف. العمل ميكانيكي لكنه واسع: مئات التعديلات الصغيرة المتشابهة، كلٌّ منها ممل، وكلٌّ منها فرصة لزلّة من إنسان متعب. الوكيل يطحنها واحدةً تلو الأخرى، وتلتقط مجموعة الاختبارات مع مراجعة متأنية ما تبقّى.
• هياكل الاختبارات. لا أقصد تصميم الاختبارات، بل الهيكلة: الـ fixtures والـ mocks ودوال الـ factory، وكل الكود التمهيدي المحيط بالـ assertion الوحيد الذي يهم فعلًا. أصف السلوكيات التي تعنيني؛ فيبني الوكيل الإطار حولها.
• الكود النمطي. نقاط نهاية CRUD، وكائنات DTO، وملفات Dockerfile، وإعدادات CI. كل ما له شكل صحيح واحد واضح، ولا يحمل في داخله أي قرار مثير للاهتمام.
• التنقيب في قواعد الكود. هذا ما فاجأني أكثر. وجِّه وكيلًا إلى مستودع لا تعرفه واسأله: لماذا يوجد غلاف إعادة المحاولة هذا؟ وما الذي سينكسر إن حُذف؟ سيقرأ في عشر دقائق كودًا أكثر مما أقرؤه في يوم كامل، ويتتبّع مواضع الاستدعاء، ويفحص git blame، ثم يعود بجواب مفيد حقًا. وقد ورثتُ خلال ست سنوات ما يكفي من قواعد الكود غير الموثّقة لأعرف بالضبط كم أمسيةً يوفّر هذا.

الخيط المشترك بينها أن المهمة قابلة للتحقق؛ ففي نهايتها مُصرِّف، أو مجموعة اختبارات، أو سؤال محدد له جواب يمكن فحصه.

ما لا أتركه من يدي

البنية المعمارية، والمفاضلات، والذوق.

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

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

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

انتقل عنق الزجاجة من سرعة الكتابة إلى جودة المواصفة وصرامة المراجعة.

من كتابة كل سطر إلى التوجيه والمراجعة

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

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

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