راقب نفسك وأنت تعمل مع coding agent لمدّة ساعة. تكتب طلبًا. تنتظر. تقرأ ما يعود إليك. تقرّر إن كان صحيحًا. تكتب الشيء التالي. وبين كل خطوة من هذه الخطوات، يجلس الـ agent عاطلًا — في انتظار أبطأ مكوّنات النظام كلّه وأغلاها ثمنًا: أنت، تقرأ وتقرّر وتضغط زرّ الانطلاق.
على مدى عامين كانت هذه هي الصفقة، وكانت صفقة جيّدة. كان الـ model يحتاج إنسانًا يُسدّده في كل turn على حدة. لكن الادّعاء الجذري الذي ينتشر بهدوء الآن هو أنه لم يعد يحتاج ذلك — ليس في كل خطوة، ولم يعد كذلك.
قالها Boris Cherny، المسؤول عن Claude Code في Anthropic، بأوضح ما يمكن: لم يعد يكتب prompts لـ Claude. لديه loops تعمل تكتب الـ prompts لـ Claude وتُقرّر ما الخطوة التالية، ومهمّته هو أن يكتب الـ loops. وقال Peter Steinberger، الذي يبني في العالم نفسه، الكلام ذاته من الاتجاه المقابل — توقّف عن كتابة الـ prompts لـ coding agents، وابدأ بتصميم الـ loops التي تكتبها نيابةً عنك.
إنها جملة غريبة حين تقرأها أوّل مرّة. فلنُفكّكها إذًا. تنبيه منصف بدايةً: هذا الأمر في بداياته، وأفضل الممارسات لا تزال قيد الابتكار، وهناك أسباب حقيقية للتشكيك — التكلفة أعلاها صوتًا. سأصل إلى كل ذلك. لكن الشكل الكامن تحت السطح يستحقّ أن تفهمه الآن، لأنه على الأرجح حيث يتّجه العمل.
كنتَ أنت الـ loop
إليك إعادة التأطير التي تجعل الاقتباسين مفهومين. في الإيقاع القديم — prompt، ثم قراءة، ثم تصحيح، ثم prompt من جديد — كنتَ أنت الـ loop. كان الـ agent أداةً تمسكها طوال الوقت، وكل دورة كانت تمرّ بين يديك. ابحث عن الشيء التالي الذي يجب فعله، سلّمه إلى الـ agent، تحقّق ممّا عاد إليك، قرّر ما التالي. كنت تؤدّي أربع وظائف وتسمّي واحدة منها «استخدام الذكاء الاصطناعي».
هندسة الـ loop هي ممارسة بناء نظام صغير يؤدّي تلك الوظائف بدلًا منك. يجد العمل، ويوزّعه، ويتحقّق من النتيجة، ويدوّن ما أُنجِز، ويقرّر الخطوة التالية — ثم ينبّه الـ agents، كي لا تضطرّ أنت إلى ذلك. الـ prompt تعليمة لـ turn واحد. أمّا الـ loop فمهمّة قائمة بذاتها: تُعرّف أنت ما الذي يعنيه «الانتهاء» فعلًا، فيكدح النظام نحوه وحده، تشغيلًا بعد تشغيل، حتى يتحقّق الشرط الذي كتبته.
إن كنت قد قرأت مقالنا عن الـ software factory، فهذا يسكن طابقًا تحته. الـ factory هي الدائرة كلّها — إشارة من العالم الخارجي تتحوّل إلى برمجيات مشحونة ومُراقَبة بينما تتولّى الآلة العمل اليدوي. والـ loop هو المحرّك الذي يُدير تلك الدائرة. تخيّله مساحة عمل الـ agent وقد ثُبّتت على جدارها ساعة، وقائمة مهامّ يكتبها لنفسه، وباب يمكنه أن يرسل عبره مساعدين. الغرفة نفسها كما كانت. لكنها الآن تعمل على وقتها الخاصّ.
ممّ يتكوّن الـ loop
الشيء الجديد فعلًا ليس الفكرة — فالناس يصنعون loops يدويًّا من shell scripts منذ سنوات. الجديد أن الأجزاء صارت تأتي جاهزةً داخل المنتجات. كنت في الماضي تصون كومةً من الـ bash إلى الأبد؛ أمّا الآن فالقدرات نفسها أصبحت features تُفعّلها بضغطة. وهي ستّة، والـ loop يتماسك أو يتسرّب بهدوء بحسب ما إذا كانت لديك الستّة كلّها.
الـ automations هي نبض القلب. هذا ما يجعل الـ loop loop لا شيئًا شغّلته مرّة واحدة. في Claude Code لديك بضع طرق لضبط الإيقاع: /loop يُعيد تشغيل prompt على مؤقّت داخل جلستك؛ و/goal يواصل العمل عبر الـ turns حتى يتحقّق شرط كتبته تحقّقًا فعليًّا؛ وتُطلق الـ hooks أوامر shell عند نقاط في دورة حياة الـ agent؛ ويُبقي /schedule (أو مهمّة cron، أو CI) كل شيء يعمل بعد أن تُغلق حاسوبك المحمول. وأقربها إلى جوهر الموضوع هو /goal — تُسلّمه شيئًا مثل «كل test في test/auth ينجح والـ linter نظيف»، ثم تنصرف، فيعمل حتى يتحقّق ذلك. والاختيار بين مؤقّت داخل الجلسة ومهمّة على التقويم قرار صغير قائم بذاته، نُفصّله في scheduled agent مقابل /loop.
الـ worktrees تمنع التوازي من أن يتحوّل فوضى. ما إن تُشغّل أكثر من agent واحد حتى تبدأ الملفات بالتصادم — وأن يكتب اثنان من الـ agents في الملف نفسه هو تمامًا الصداع الذي يحدث حين يُجري مهندسان commit على الأسطر ذاتها دون أن يتحدّثا أوّلًا. يحلّ git worktree ذلك بنظافة: كل agent يحصل على working directory خاصّ به على branch خاصّ به، يتشارك تاريخ الـ repo لكنه لا يمسّ checkout الآخرين أبدًا. ويتيح لك Claude Code هذا عبر الـ flag المسمّى --worktree لفتح جلسة في checkout خاصّ بها، وإعداد isolation: worktree تُعلّقه على subagent بحيث يعمل كل مساعد في نسخة جديدة تُنظّف نفسها بعد الانتهاء.
الـ skills هي معرفة المشروع مكتوبةً مرّة واحدة. الـ skill مجلد بداخله SKILL.md — أعرافك، وخطوات البناء لديك، و*«لا نفعلها بهذه الطريقة بسبب الحادثة التي وقعت الربيع الماضي».* بدونه، يُعيد الـ loop استنتاج مشروعك كلّه من الصفر في كل دورة، ويملأ كل ثغرة في فهمه بتخمين واثق. ومعه، تتراكم المعرفة: مكتوبة مرّة، مقروءة في كل تشغيل. الـ loop بلا skills موظّف جديد ينسى كل شيء بين ليلة وضحاها، كل ليلة.
الـ plugins والـ connectors تمنح الـ loop يدين. الـ loop الذي لا يرى سوى نظام ملفاتك loop صغير. الـ connectors — المبنيّة على MCP، المعيار المفتوح الذي نتناوله في كيفية استخدام MCP مع Claude Code — تتيح للـ agent أن يقرأ issue tracker، أو يستعلم من database، أو يطرق staging API، أو يترك رسالة في Slack. هذا هو الفرق بين agent يقول «ها هو الإصلاح» وloop يفتح الـ pull request، ويربط التذكرة، وينبّه القناة حالما تتحوّل الـ tests إلى الأخضر، وحده.
الـ subagents تُبقي الصانع بعيدًا عن المُدقّق. هذه أكثر حركة بنيوية تحمل الوزن في التصميم كلّه، ومن السهل تخطّيها. الـ model الذي كتب الكود للتوّ مُصحّحٌ متساهلٌ لعمله هو — سيُقنع نفسه بأنه أنجزه. agent ثانٍ، بتعليمات مختلفة وأحيانًا model مختلف تمامًا، يلتقط ما تجاوزه الأوّل بالتبرير. والتقسيم الموثوق هو: agent يستكشف، وagent يُنفّذ، وagent يتحقّق في مقابل المواصفة. تُعرّفها ملفّاتٍ في .claude/agents/، وهو تمامًا ما يفعله /goal خلف الكواليس: model جديد، لا الذي أدّى العمل، يقرّر إن كان الـ loop قد انتهى. (وحين تحتاج مهمّة إلى أسطول كامل من هؤلاء يُنشَأ على الفور، فذلك dynamic workflow — وبإمكان الـ loop أن يستدعي واحدًا كخطوة واحدة.)
الـ memory هي العمود الفقري. يستيقظ الـ model مصابًا بفقدان الذاكرة في كل تشغيل — لا يتذكّر شيئًا بين المحادثات. لذا يجب أن تعيش الذاكرة على القرص، لا في الـ context: ملف markdown، أو لوحة تتبّع، أيّ شيء خارج الجلسة الواحدة يحفظ ما جُرّب، وما نجح، وما لا يزال مفتوحًا. يبدو هذا أبهت من أن يكون الشيء الذي يقوم عليه التصميم كلّه. وهو بالضبط الشيء الذي يقوم عليه التصميم كلّه. الـ model ينسى؛ والملف يتذكّر؛ وتشغيل الغد يلتقط الخيط من حيث توقّف تشغيل اليوم تمامًا.
كيف يبدو loop واحد فعلًا
اربط الستّة معًا فيتحوّل خيط واحد إلى لوحة تحكّم صغيرة. إليك شكلًا يستحقّ أن تسرقه.
automation يعمل كل صباح على الـ repo لديك. الـ prompt الخاصّ به يستدعي skill للفرز يقرأ الـ tests التي فشلت الليلة الماضية، والـ issues المفتوحة، والـ commits الأخيرة، ثم يكتب ما توصّل إليه في ملف markdown. ولكل نتيجة تستحقّ التحرّك، يفتح الـ loop worktree معزولًا ويُرسل subagent يكتب مسوّدة الإصلاح — وsubagent ثانيًا يُراجع تلك المسوّدة في مقابل skills المشروع والـ tests الموجودة. ويفتح connector الـ pull request ويُحدّث التذكرة. وأيّ شيء لا يستطيع الـ loop التعامل معه بأمان يصل إلى صندوق وارد لك. وملف الحالة هو العمود الفقري: يتذكّر ما جُرّب، وما نجح، وما لا يزال مفتوحًا، فيستأنف تشغيلُ صباح الغد بدلًا من أن يبدأ من جديد.
الآن انتبه إلى ما فعلته هناك. صمّمت ذلك مرّة واحدة. لم تكتب prompt لأيّ من تلك الخطوات — لا للفرز، ولا للمسوّدة، ولا للمراجعة، ولا للـ pull request. هذا هو الادّعاء كلّه مجسّدًا. وقد وُصِف عمدًا بمصطلحات محايدة تجاه الأداة، لأن الأجزاء هي الأجزاء نفسها أينما بنيته؛ الـ loop هو التصميم، لا العلامة التجارية.
افتح الـ loop ببطء
ليست كل الـ loops سواء، والتمييز بينها هو القلب العملي لإنجاز هذا دون ندم.
الـ loop المغلق هو الذي رسمتَ مساره أوّلًا. هدف واضح، وخطوات محدّدة، وتحقّق عند كل خطوة، ونقطة يتوقّف عندها أو يُعيد الأمر إليك. تبقى الـ agents تدور، لكن داخل إطار بنيته أنت — فيتحسّن في كل تشغيل لأن كل مرور يُغذّي التالي، ويبقى في المتناول لأن المسار ضيّق. والـ loop المفتوح هو الطرف المثير: تُسلّم الـ agent هدفًا وتتركه يتجوّل، يكتشف طريقه الخاصّ، ويبني أشياء لم تُحدّدها بالكامل قطّ. هذا قويّ، وهو تقريبًا ما يفعله أهل الطليعة. وهو أيضًا حيث تصبح الفاتورة مخيفة، وحيث يتحوّل — إن وُجّه إلى عمل بمعايير رخوة — إلى آلة سريعة ومكلفة لإنتاج الرداءة.
وهذا يقودنا إلى المأخذ الذي لا يضعه أحد في الكتيّب الدعائي: الـ loops تستهلك الـ tokens، وتستهلكها على نحو يعتمد كليًّا على ما إذا كنت غنيًّا بالـ tokens أم فقيرًا بها. كل إعادة محاولة تكلّف. كل subagent يكلّف. كل تمريرة تحقّق تكلّف. مهمّة متوسّطة قد تلتهم عشرات الآلاف من الـ tokens؛ وأسطول من الـ specialists، أضعاف ذلك بكثير؛ وجدول يومي، مثل ذلك كل أسبوع. إن كانت ميزانيتك بلا حدود فعليًّا، فلن يُلاحَظ شيء من هذا ويمكنك ترك الـ loops تتجوّل. وإن لم تكن كذلك، فإن loop مفتوحًا سيُفرغ شهرك في أيّام. والانضباط هو ذاته الذي نعتمد عليه في الـ dynamic workflows: حُدّ النطاق، وضَع سقفًا للـ tokens داخل الـ prompt نفسه، واستحقّ الـ loop المفتوح بإتقان المغلق أوّلًا. ابدأ مغلقًا. ولا تفتحه إلا حين تصبح بوّابات الجودة حقيقية.
ابنِ الـ loop، وابقَ المهندس
إليك الثقل الموازن، وهو السبب الكامل في أن هذا أصعب من كتابة الـ prompt لا أسهل. الـ loop يُغيّر العمل؛ لكنه لا يحذفك منه. ثلاث مشكلات تزداد حدّةً فعلًا كلّما صار الـ loop أكثر سلاسة.
التحقّق ما زال مسؤوليّتك. الـ loop الذي يعمل دون إشراف هو أيضًا loop يرتكب الأخطاء دون إشراف — و«الانتهاء»، حين يُعلنه model، ادّعاء لا برهان. السبب في فصلك الـ verifier عن الصانع هو أن تجعل لذلك الادّعاء معنى، وحتى عندئذ تبقى مهمّتك أن تشحن كودًا تأكّدت من أنه يعمل. هذه هي نقطة الرافعة التي نرى أنها صارت أثمن مهارة في البرمجيات، في الكتابة صارت رخيصة، أمّا الفهم فلا: حين تُنتج الآلة أسرع ممّا تقرأ، يصبح الانتباه هو المورد النادر، وتُنفقه حيث يؤلم الخطأ فعلًا.
فهمك يتعفّن إن سمحت له. كلّما أسرع الـ loop في شحن كود لم تكتبه، اتّسعت الهوّة بين ما هو موجود وما تستوعبه أنت فعلًا — والـ loop السلس لا يزيد تلك الهوّة إلا سرعةً، ما لم تقرأ ما صنعه.
والوضعية المريحة هي الخطرة. حين يُشغّل الـ loop نفسه، يغدو من المغري أن تكفّ عن أن يكون لك رأي وتأخذ أيّ شيء يعود إليك. والحقيقة المُقلقة أن شخصين قد يبنيان الـ loop ذاته ويحصلان على نتيجتين متعاكستين: أحدهما يستخدمه ليتحرّك أسرع في عمل يفهمه فهمًا عميقًا، والآخر يستخدمه ليتجنّب فهم العمل بتاتًا. الـ loop لا يميّز الفرق. أمّا أنت فتميّزه.
فامضِ وابنِ loops — لكن ابنِها كمن ينوي أن يبقى المهندس، لا مجرّد من يضغط زرّ الانطلاق. لم تكن نقطة Cherny يومًا أن العمل صار أسهل، بل أن الرافعة انتقلت: من كتابة التعليمة المثالية إلى تصميم النظام الذي يُنتج نتيجة مُتحقَّقًا منها وحده. وإن أردت أن تلمس ذلك هذا الأسبوع، فخذ prompt تجد نفسك تكتبه مرّة بعد مرّة، وامنحه شرط توقّف واضحًا، وأضِف إليه subagent واحدًا للتحقّق وملف memory، ثم اتركه يعمل مغلقًا. هذا loop. إنه شيء أصغر ممّا توحي به الاقتباسات — وتحوّلٌ في عملك أكبر ممّا يبدو لأوّل وهلة.