TL;DR
· في يونيو 2026، طرح عدد من ممارسي البرمجة بالذكاء الاصطناعي مفهوم "هندسة الحلقات" (Loop Engineering) في وقت واحد تقريبًا، وقد قامت شركة Stripe بدمج أكثر من 1300 طلب سحب (PR) تم إنشاؤها بواسطة الذكاء الاصطناعي أسبوعيًا باستخدام Minions.
· لم تعد هذه الطريقة تعتمد على التوجيه البشري المتسلسل، بل تسمح للنظام باكتشاف المهام تلقائيًا، وتسليمها، والتحقق منها، وحفظ الحالة، والانتقال إلى الجولة التالية.
· لا تزال الموثوقية تعتمد على المُقيّم المستقل، والبوابات الصارمة، والمراجعة البشرية، وقد يؤدي دين التحقق وتدهور الفهم إلى تضخيم المخاطر في الاتجاه المعاكس.

في الآونة الأخيرة، نشر أحد مهندسي Anthropic وثيقة من 11 صفحة حول "هندسة الحلقات للأنظمة الذكية"، واضعًا هندسة الحلقات بعد هندسة المطالبات (Prompt Engineering)، وهندسة السياق (Context Engineering)، وهندسة التسخير (Harness Engineering)، معتبرًا إياها الطريقة الرئيسية لدخول البرمجة بالذكاء الاصطناعي إلى المرحلة التالية.

أثارت هذه الوثيقة الاهتمام لأنها تزامنت مع نقطة تحول في نقاشات البرمجة بالذكاء الاصطناعي في يونيو 2026. أطلق كل من Addy Osmani وBoris Cherny وPeter Steinberger على المرحلة الجديدة من البرمجة بالذكاء الاصطناعي اسم "هندسة الحلقات" في نفس الأسبوع تقريبًا، بينما كان خط أنابيب Minions في Stripe يدمج بالفعل أكثر من 1300 طلب سحب تم إنشاؤها بواسطة الذكاء الاصطناعي أسبوعيًا باستخدام فكرة مماثلة.

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

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

في الآونة الأخيرة، نشر أحد مهندسي Anthropic وثيقة من 11 صفحة حول "هندسة الحلقات للأنظمة الذكية"، واضعًا هندسة الحلقات بعد هندسة المطالبات، وهندسة السياق، وهندسة التسخير، معتبرًا إياها الطريقة الرئيسية لدخول البرمجة بالذكاء الاصطناعي إلى المرحلة التالية. تستخدم هذه المقالة هذه الوثيقة كنقطة دخول، وتجمع بين النقاشات العامة لكل من Boris Cherny وAddy Osmani وغيرهما، بالإضافة إلى حالة Stripe Minions التي تدمج أكثر من 1300 طلب سحب تم إنشاؤها بواسطة الذكاء الاصطناعي أسبوعيًا، لشرح ما هي هندسة الحلقات بالضبط، ولماذا أصبحت فجأة موضع نقاش على نطاق واسع، وكيف أن ما تغيره حقًا ليس كتابة التعليمات البرمجية، بل التحقق والجدولة والحكم في تطوير البرمجيات.

البرمجة بالذكاء الاصطناعي: من "المطالبة الواحدة" إلى "الحلقة المستمرة"

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

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

تتكون الحلقة الكاملة عادةً من خمسة إجراءات.

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

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

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

1300 طلب سحب من Stripe: الموثوقية تأتي من القيود، وليس من النموذج

يعد خط أنابيب Minions من Stripe أكثر حالات المؤسسات تأثيرًا في هذه المناقشات: دمج أكثر من 1300 طلب سحب تم إنشاؤها بواسطة الذكاء الاصطناعي أسبوعيًا، مع أن التعليمات البرمجية نفسها لم تُكتب سطرًا سطرًا بواسطة البشر.

لكن هذا لا يعني أن Stripe تركت النظام الإنتاجي يعمل بحرية بفضل نموذج كبير واحد. على العكس، يكمن مفتاح Minions في عملية شديدة التحكم: يقوم المنسق الحتمي أولاً بتجميع السياق، واستخراج معلومات المهمة من Jira والبحث في التعليمات البرمجية والأدوات الداخلية؛ ثم يقوم LLM بتوليد التعليمات البرمجية؛ وبعد ذلك يتم تحديد ما إذا كان يمكن الدمج عبر أدوات الفحص الصارمة (linter) المبرمجة، وبوابات الإرسال، والمراجعة البشرية النهائية.

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

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

بدون هذه القيود، فإن 1300 طلب سحب أسبوعيًا ليس قفزة في الكفاءة، بل قد يكون آلة لتوليد الديون التقنية.

يجب فصل المولد والمُقيّم

أحد التصميمات الأساسية لهندسة الحلقات هو فصل المولد عن المُقيّم.

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

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

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

التكاليف الخفية تتفاقم تبادليًا

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

النوع الأول من التكاليف هو دين التحقق. تتراكم الأخطاء التي لم تغطيها الاختبارات في الحلقة باستمرار حتى تنفجر دفعة واحدة عند الدمج أو النشر. النوع الثاني هو تدهور الفهم. تتوسع قاعدة التعليمات البرمجية باستمرار، لكن المهندس لم يمر شخصيًا بخيارات التصميم الرئيسية، وتبقى خريطته الذهنية على الإصدار القديم. النوع الثالث هو الاستسلام المعرفي. يبدأ البشر في قبول مخرجات الآلة افتراضيًا، ويقومون فقط بالموافقة الشكلية. النوع الرابع هو انفجار استهلاك الرموز (tokens). تؤدي إعادة المحاولة، والوكلاء الفرعيون، والسياق الطويل، والتحقق متعدد الحلقات إلى ارتفاع الفاتورة بسرعة.

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

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

بعد أن أصبحت التعليمات البرمجية أرخص، أصبح الحكم هو الغالي

تضع هندسة الحلقات اتجاهًا طويل الأمد في موضع أوضح: أصبحت التعليمات البرمجية والخطط وطلبات السحب وتقسيم المهام تكاد تكون مجانية، لكن "ما هو صحيح حقًا" لم يصبح أرخص.

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

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

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

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

انقر لمعرفة الوظائف الشاغرة في BlockBeats

مرحبًا بكم في انضمام مجتمع BlockBeats الرسمي:

قناة Telegram للاشتراك: https://t.me/theblockbeats

قناة Telegram للنقاش: https://t.me/BlockBeats_App

حساب Twitter الرسمي: https://twitter.com/BlockBeatsAsia