البرمجة بنظام أطلق وانسَ: صعود العملاء في الخلفية عام 2026
الأسبوع الماضي أعطيت عميلًا تذكرة مهمة، أغلقت الحاسوب المحمول، وذهبت لتناول الغداء. حين عدت، كان طلب سحب ينتظر — الاختبارات ناجحة، ملخص قصير، فروق تلامس أحد عشر ملفًا. نجح الأمر. دمجته.
الثلاثة الأخرى التي أرسلتها في تلك الصباح لم تسِر على ما يرام. واحد حذف علامة ميزة بهدوء لأنها "لم تكن مرجوعًا إليها" (كانت كذلك، من ملف إعداد لم يقرأه العميل قط). آخر أحرق بعض الدولارات يعيد اكتشاف أن مجموعة الاختبارات لدينا تحتاج إلى حاوية قاعدة بيانات لم يستطع تشغيلها. وواحد أنتج فروقًا بدت معقولة جدًا وخاطئة جدًا حتى كدت أوافق عليها من شاشة الهاتف.
هذا هو الشكل الصادق للعملاء في الخلفية عام 2026. التشغيل الجيد يبدو كالغش. التشغيل السيئ يبدو كإدارة مبتدئ يعمل في الساعة الثالثة صباحًا، لا يطرح أسئلة، وواثق جدًا من نفسه.
الخلاصة القصيرة: حلّ العملاء في الخلفية بشكل أساسي مسألة "اكتب الكود بينما لا أشاهد". ما لم يحلوه — وما جعلوه أسوأ بحجج وجيهة — هو المراجعة. الاختناق تحرّك. كان من قبل في مدى سرعة كتابة النموذج. الآن في مدى سرعة أنت في القراءة والثقة ودمج عمل لم تشاهد كتابته. إن لم تبنِ عملية لذلك، لن تحصل على مضاعف قوة؛ ستحصل على تراكم من طلبات السحب نصف المطبوخة.
ما يعنيه "عميل الخلفية" الآن فعلًا
عميل الخلفية هو عميل برمجة غير متزامن يعمل في مكان خارج انتباهك الأمامي — عادةً جهاز VM سحابي — ينجز المهمة ويسلّمك النتيجة لاحقًا. تعيّن العمل وتبتعد. هذا هو العرض كله، وبحلول منتصف 2026 كل إطار عمل رئيسي يشحن نسخة منه.
أعادت Cursor بناء واجهتها بالكامل حول هذا في الإصدار 3.0. ملاحظة الإصدار صريحة بشأن مركز الجاذبية الجديد: يمكنك "تشغيل عملاء متعددين بالتوازي عبر مستودعات وبيئات: محليًا، في أشجار العمل، في السحابة، وعلى SSH بعيد" (cursor.com/changelog/3-0). عملاؤهم السحابيون يعملون في بيئات معزولة، "يكررون حتى يتحققوا من مخرجاتهم"، ويحوّلون تذاكر Linear أو Jira مباشرةً إلى طلبات سحب (cursor.com/cloud). قراءة Futurum للإصدار 3.2 التالي وصفت بيئة التطوير المتكاملة بأنها "أُعيدت صياغتها كبيئة تشغيل للعملاء" (futurumgroup.com) — مجاور للتسويق، لكن صحيح من حيث الاتجاه.
سار Claude Code بالاتجاه ذاته لكنه أبقى المصطلحات دقيقة. تميّز وثائقه بين أربع طرق للتوازي: عملاء فرعيون (عمال مفوّضون داخل جلسة واحدة)، عرض العملاء (claude agents — "إرسال الجلسات ومراقبتها وهي تعمل في الخلفية"، معاينة بحثية)، فرق العملاء (قائد ينسّق العمال، "تجريبي ومعطّل افتراضيًا")، وسير العمل الديناميكي (نص برمجي ينشر عملاء فرعيين متعددين ويتحقق منهم بشكل متقاطع) (code.claude.com/docs/en/agents). الأربعة ليست قابلة للتبادل، والأسماء تؤدي عملًا حقيقيًا.
Devin، الذي بدأ هذه الفئة إلى حد بعيد، أمضى 2026 يحوّل عميلًا واحدًا مستقلًا إلى كثيرين. إصداره في 19 مارس أضاف "Devin Manages Devins" — جلسة منسّقة تحدد نطاق العمل وتفوّضه إلى "فريق من Devins المُدارة التي تعمل بالتوازي"، كل واحدة على جهاز VM معزول خاص بها (docs.devin.ai/release-notes/2026).
الخيط المشترك: بيئة معزولة، تسليم غير متزامن، طلب سحب في النهاية. الاختلافات في مقدار الحرية الممنوحة لك وكيفية عودة المراجعة إليك.
ما هم بارعون فيه فعلًا
كن محددًا بشأن أين يؤتي هذا ثماره، لأن الضجيج يُسطّحه.
العملاء في الخلفية بارعون في العمل المحدود، المحدّد جيدًا، القابل للتحقق. نقطة الحلاوة هي مهمة يمكنك فيها (أ) وصف "الإنجاز" في جملة، (ب) يمكن لاختبار أو مدقق نوع إثباته، و(ج) لا تتطلب ذوقًا. رفع الاعتماديات مع مجموعة اجتياز. إضافة حقل عبر مكدس معروف. كتابة اختبارات الوحدة الواضحة. إعادة الهيكلة الآلية عبر ملفات عديدة — النوع الذي صُمّمت له مهارة /batch في Claude Code، تقسيم "تغيير واحد كبير إلى 5 إلى 30 عميلًا فرعيًا معزولًا في أشجار العمل، كل منها يفتح طلب سحب" (code.claude.com/docs/en/agents).
هم بارعون في الاتساع المتوازي. مهارة /best-of-n في Cursor تشغّل المهمة ذاتها عبر نماذج متعددة، "كل منها في شجرة عمل معزولة خاصة به، ثم تقارن المخرجات" (cursor.com/changelog/3-0). لخطأ معقد حيث لا تعرف النهج الصحيح فعلًا، إطلاق ثلاث محاولات والإبقاء على الأفضل استخدام حقيقي لإمكانية تشغيل أشياء لا تشاهدها.
وهم بارعون في السماح لشخص واحد بفعل أكثر من شيء واحد. كمطور منفرد، لم يكن القيد أبدًا في الأفكار — بل في أنني لا أستطيع التواجد في أكثر من ملف واحد في آنٍ واحد. إرسال النصف الممل بينما أعمل على النصف المثير هو الربح الحقيقي. ليس "الذكاء الاصطناعي يبني تطبيقي" — هذا لا يزال خيالًا. "الذكاء الاصطناعي يصفّي تراكم المهام الصغيرة الواضحة بينما أفكر" هو قابل للشحن اليوم.
ما هم سيئون فيه، بصدق
أنماط الفشل ليست غريبة. إنها مملة وتتكرر.
جفاف السياق. لا يعرف عميل الخلفية إلا ما جمعه قبل بدء تشغيله. لا يمكنه طرح سؤال توضيحي في منتصف التشغيل — أو إن استطاع، أنت في الغداء. فيخمّن. حادثة حذف علامة الميزة لديّ كانت جفافًا صريحًا للسياق: استدل العميل بصواب على الملفات التي لديه وتوصّل إلى نتيجة خاطئة لأن الحقيقة ذات الصلة كانت في مكان لم ينظر إليه. الحل استباقي: صياغة مهام أفضل، ملف AGENTS.md يخبره بمكان الأشياء، روابط للمشكلة. مدخلات رديئة، مخرجات رديئة واثقة.
الانجراف الصامت. الفشل المخيف ليس طلب السحب المكسور بوضوح — ستلاحظه. إنه الواحد الذي يكون صوابًا بنسبة 90% وخاطئًا بخفاء، مع ملخص نظيف يصف السلوك الصحيح بينما يفعل الكود شيئًا آخر. الملخص مُولَّد من النية، وليس من فعل الكود. ثق بالفروق، لا بالوصف.
تعارض الدمج والتدخل المتبادل. شغّل ستة عملاء ضد مستودع واحد وسيتصادمون. جواب الصناعة كله هو عزل أشجار العمل — كل عميل يحصل على فحص git خاص به حتى الجلسات المتوازية "لا تحرر الملفات ذاتها أبدًا" (code.claude.com/docs/en/agents). هذا يحل تصادم العملاء أثناء التشغيل. لا يفعل شيئًا حيال ستة فروع تصل إلى main مساء الثلاثاء، كل منها قديم قليلًا. التعارض ينتقل فقط إلى وقت الدمج، أي ينتقل إليك. شحنت Devin كشف تعارض الدمج في المراجعة في فبراير تحديدًا لأن هذا هو المكان الذي يلتقي فيه الحلم المتوازي مع الواقع (docs.devin.ai/release-notes/2026).
التكلفة الجامحة. غير المتزامن يعني أن لا أحد يراقب العداد. يستند العملاء في الخلفية إلى أغلى النماذج، وقارنة صادقة واحدة رصدت "طلب سحب سهل" على عميل Cursor في الخلفية بحوالي 4.63 دولار خلال المعاينة (aitechfy.com). هذا جيد لتذكرة حقيقية وسخيف لخطأ مطبعي. تكاليف "تصبح غير متوقعة في العمل الجديد"، والإنفاق لكل مهمة "غير واضح ما لم تتحقق من لوحة الاستخدام" (techsy.io). وثائق Anthropic تقول بصراحة: تشغيل عدة عملاء في آنٍ واحد "يضاعف استخدام الرمز المميز" (code.claude.com/docs/en/agents). ضع حدود الإنفاق قبل الإطلاق والنسيان، لا بعد الفاتورة.
الاختناق الحقيقي هو المراجعة، وهي الآن ملكك
هذا هو الجزء الذي تتخطاه العروض التوضيحية. حين كان التوليد الخطوة البطيئة، كانت المراجعة مجانية — كنت تشاهد الكود يظهر سطرًا بسطر وتوافق عليه مع ظهوره. العملاء في الخلفية يكسرون ذلك. الكود يظهر بينما أنت غائب. الآن أنت مراجع لعمل لم تشاهده، بحجم كل العملاء الذين أرسلتهم.
الموردون يعرفون هذا بوضوح، لأن أبرز شحنات 2026 لم تكن في التوليد — بل في المراجعة. أطلقت Devin منتج مراجعة كامل في يناير يجمع التغييرات ذات الصلة، "يكشف الكود المنسوخ والأخطاء والمشكلات الأمنية"، وأضافت دمجًا تلقائيًا وزر "إصلاح تلقائي مع Devin" بحلول أبريل (docs.devin.ai/release-notes/2026). هذا يخبرك بأين تكمن المشكلة.
لكن احذر مما تتمناه. المقارنة ذاتها التي سعّرت هذه الأدوات تلاحظ أيضًا أن "كل فريق نعرفه يشترط مراجعة بشرية قبل الدمج" وتصف الدمج التلقائي بأنه "طلقة في القدم" (techsy.io). أوافق. هدف عميل يراجع عميلًا هو فرز طابورك — للإشارة إلى ثلاثة طلبات سحب تحتاج نظرك والمصادقة الروتينية على الاثنين المملين — لا إزالتك. اليوم الذي تدع فيه عميلًا يوافق على عمل عميل آخر في main دون إشراف هو اليوم الذي أتمتت فيه إنتاج الأخطاء الدقيقة.
لذا المهارة التي تهم فعلًا في 2026 ليست الطرح السريع. إنها تشغيل طابور مراجعة دون الغرق. بشكل ملموس:
- فرز قبل القراءة. الإشارة الرخيصة الآلية أولًا: هل نجحت الاختبارات، هل نجح مدقق النوع، هل الفروق صغيرة. طلب سحب يفشل بوابته الخاصة لا يستحق انتباهك بعد.
- اقرأ الفروق، وليس الملخص أبدًا. الملخص هو نية العميل. الفروق هي ما يحدث. كلاهما ينفصل بصمت.
- اجعل "الإنجاز" قابلًا للإثبات. إن لم تستطع كتابة فحص يؤكد المهمة، ليس لديك مهمة لعميل خلفية — لديك شيء ستراقبه على أي حال. ادفع التحقق إلى تشغيل العميل حتى يختبر نفسه؛ عملاء Cursor السحابيون "يكررون حتى يتحققوا من مخرجاتهم" (cursor.com/cloud)، وتلك البوابة تستحق أكثر من أي تعديل في الطرح.
- ضع سقفًا لعمق الطابور. المزيد من العملاء لا يعني مزيدًا من المخرجات بعد النقطة التي تستطيع فيها المراجعة. إن وصلت طلبات السحب أسرع مما تصفّيها، فقد بنيت مولّد تراكم، لا مضاعف قوة.
يوم في الحياة يعمل فعلًا
هذه هي الحلقة التي أشغّلها كمطور منفرد. إنها مملة عن قصد.
الصباح: أفرز قائمة مشكلاتي الخاصة إلى دلوين — مناسبة للعميل (محدودة، قابلة للاختبار، مملة) ومناسبة لي (حكم، هندسة معمارية، أي شيء يمس المال أو المصادقة). أرسل ثلاث أو أربع تذاكر مناسبة للعميل، كل منها إلى شجرة عمل أو بيئة معزولة سحابية خاصة بها، مع وصف حقيقي ورابط للمشكلة. ثم أغلق تلك النافذة وأعمل على مشكلة مناسبة لي بنفسي، في المقدمة، بالطريقة القديمة.
لا أجلس وأشاهدهم. النقطة كلها هي الأسلوب غير المتزامن. مشاهدة عميل خلفية هي مجرد عميل متزامن مع خطوات إضافية ومنظر أسوأ.
في منتصف الصباح، تبدأ طلبات السحب بالوصول. أشغّل جولة الفرز: حالة البوابة أولًا، ثم الفروق الصغيرة قبل الكبيرة. الاثنان اللذان اجتازا بنظافة ويلمسان عشرة أسطر، أقرأ وأدمج في خمس دقائق لكل منهما. الواحد الذي "نجح" لكنه أعاد كتابة أكثر مما توقعت، أقرأه بعناية — هناك يختبئ الانجراف. الواحد الذي فشل اختباراته الخاصة، إما أعيد صياغته وأرسله مجددًا بالسياق الجديد، أو أسحبه محليًا وأنهيه يدويًا. عميل يحرق أربعين دقيقة على بيئة اختبار مكسورة يخبرني فحسب أن إعدادي هو المشكلة؛ أصلحه مرة واحدة ويكون التشغيل التالي نظيفًا.
أدمج فروع العملاء واحدة في كل مرة، أعيد التأسيس مع المضي قدمًا، لا في دفعة في نهاية اليوم — هكذا تتجنب تراكم تعارض مساء الثلاثاء. وأحتفظ بقاعدة صارمة: لا شيء يتعلق بالمصادقة أو الفوترة أو الترحيل يُشحن من تشغيل خلفي دون أن أقرأ كل سطر. ليس لأنه يناسبني بسبب الصعوبة. بل لأن نطاق الضرر كبير والعميل لا يشعر بالعواقب.
صافي اليوم: ربما ست تذاكر مغلقة حيث كنت سأنجز اثنتين. ليس لأن العملاء أذكياء — بعض طلبات السحب تلك كانت إعادة عمل — بل لأن النصف الممل تصفّى بالتوازي بينما أمضيت انتباهي الفعلي على النصف الذي يحتاج إنسانًا.
الرأي المتوازن
العملاء في الخلفية حقيقيون، يُشحنون، وحلقة VM-السحابي-المتوازي-إلى-طلب-السحب تعمل بشكل جيد بما يكفي لتغيير كيفية قضاء مطور منفرد يومه. هذا ليس ضجيجًا. ما هو ضجيج هو الإيحاء الضمني "وحينها لن تضطر لفعل أي شيء". ستضطر. العمل فقط تغيّر شكله — من كتابة الكود إلى تحديده وتأمين بواباته ومراجعته.
تعامل معهم كفريق صغير سريع يعمل بينما تنام وينتج كومة من طلبات السحب في الصباح: بعضها ممتاز، بعضها خاطئ بهدوء، والكل واثق من نفسه. العائد حقيقي إن بنيت عضلة المراجعة لتناسب التوليد. إن تجاوزت ذلك، لم تشترِ لنفسك فريقًا. لقد اشتريت طابورًا.
ابدأ بعميل واحد، تذكرة واحدة محدودة، تعريف واحد قابل للإثبات للإنجاز. اجعل حلقة الفرز تعمل بعمق واحد قبل أن تتوسع إلى أربعة. التوليد لم يكن الجزء الصعب أبدًا.