تشهد هندسة الحلقات (Loop engineering) طفرة حالياً. تصفح أي منتدى تقني وستجد أصواتاً تجادل بضرورة التوقف عن معاملة وكلاء الذكاء الاصطناعي (AI agents) كدردشة آلية (chatbots) يتم توجيهها عبر مطالبات ذكية (clever prompts). بدلاً من ذلك، يقولون إنه يجب علينا تصميم حلقات: دورات ذاتية القيادة تسمح للوكيل بالتخطيط، والتنفيذ، والتحقق من عمله الخاص، والتكرار بينما نحن نائمون. هذا الطرح مغرٍ؛ فإذا كانت الحلقة مبنية بشكل جيد، فسيظل الوكيل على المسار الصحيح دون إشراف بشري مستمر، محولاً النوايا الخام إلى مخرجات نهائية خلال الليل.
هذا الوعد يعمل بشكل رائع من الناحية النظرية. أما في الممارسة العملية، فإن معظم الوكلاء يعملون بالفعل ضمن حلقات؛ فهم يقومون بتوليد الكود، وفحص أخطاء المترجم (compiler errors) أو فشل الاختبارات، وإصلاح الكود، ثم تشغيل المجموعة مرة أخرى. دورة التغذية الراجعة الأساسية هذه ليست جديدة، ولكن ما ينادي به المؤيدون الآن هو شيء أكثر طموحاً: حلقة خارجية تحكم المهمة بأكملها، وليس فقط أخطاء بناء الجملة (syntax errors). بناء تلك الحلقة الخارجية هو المكان الذي تصبح فيه الأمور صعبة، لأن هندسة البرمجيات نادراً ما تكون نظاماً مغلقاً بقواعد ثابتة.
مشكلة تصميم الحلقة
أهداف المنتج فوضوية؛ فنادراً ما تبدأ بتعريف مثالي لـ "الانتهاء من العمل" (definition of done). في أغلب الأحيان، تكتشف الهدف الحقيقي بينما أنت منغمس في عملية البناء. فالمتطلبات التي بدت واضحة على السبورة البيضاء قد تتبين لاحقاً أن لها حالات استثنائية (edge cases) تغير شكل الحل تماماً. عندما تضع وكيلاً داخل حلقة جامدة، يصبح هذا الجمود عبئاً، حيث تستمر الحلقة في الضرب على هدف قد يكون خاطئاً. والأسوأ من ذلك، أن الحلقة المرنة قد تحل المأزق أحياناً عن طريق تغيير الهدف بهدوء ليتناسب مع أي مخرجات تمكنت من إنتاجها. لا أي من النتيجتين مفيدة؛ إحداهما تهدر موارد الحوسبة (compute)، والأخرى تُنتج مخرجات رديئة بكل ثقة.
القضية الأعمق هي تكلفة المواصفات (specification cost). إذا كنت تريد حلقة تعمل دون إشراف، فيجب عليك كتابة مواصفات تتوقع كل شيء تقريباً. ما الذي يجب على الوكيل تغييره بالضبط؟ ما هو السلوك الحالي الذي يعتبر مقدساً ويجب الحفاظ عليه؟ تحت أي شروط دقيقة يجب أن يتوقف الوكيل عن التكرار؟ ما هي المخاطر المقبولة، وما هي الآثار الجانبية التي يجب أن تستدعي التوقف الفوري؟ كتابة تلك الوثيقة قد تستغرق وقتاً أطول من مجرد الجلوس مع الوكيل وتوجيهه عبر المهمة في الوقت الفعلي. أنت تدفع ضريبة باهظة مقدماً مقابل أتمتة لا تؤتي ثمارها إلا إذا كانت عملية التحقق أرخص بكثير من عملية التنفيذ.
أين تحقق الحلقات جدواها حقاً
هذا لا يعني أن هندسة الحلقات عديمة الفائدة، بل يعني أنها أداة متخصصة وليست استراتيجية شاملة. تبرز أهمية الحلقات عندما تتراكم تكاليف التحقق وتكون معايير النجاح غير غامضة. هناك ثلاثة مواضع ينطبق فيها هذا الأمر عادةً:
الأعمال الميكانيكية الروتينية. فكر في المهام التي تجعل كبار المهندسين يرغبون في التقاعد: بدء التطبيقات بتسلسل معين، أو النقر عبر واجهة مستخدم النشر (deployment UI) لتأكيد كل مرحلة، أو البحث في السجلات (grepping logs) عن سلاسل أخطاء معروفة بعد الإصدار، أو التحقق من كتابة ملف التكوين في جميع العقد الصحيحة. هذه الخطوات مملة للبشر ولكن التحقق منها بسيط للغاية. يمكن للحلقة أن تراقب العملية، وتتحقق من نقاط النهاية الصحية (health endpoints) بعد كل إعادة تشغيل، وتقوم بالتراجع (rollback) عند أول بادرة خطر. لا يزال الإنسان هو من يحدد خطة النشر، بينما تقوم الحلقة ببساطة بتنفيذها بصبر الآلة في الثانية صباحاً.
أهداف التحسين القابلة للقياس. عندما يكون النجاح رقماً، تكون الحلقات فعالة بشكل مذهل. خفض زمن الاستجابة (p99 latency) إلى أقل من 150 مللي ثانية. تقليل بصمة الذاكرة (memory footprint) بنسبة عشرين بالمائة. نقل مسار سريع (hot path) من Python إلى Rust والتأكد من أن جميع اختبارات الوحدة الحالية لا تزال تجتاز الاختبار. يمكن للحلقة توليد تغيير، وقياس أدائه (benchmark)، والاحتفاظ بالنسخة التي أحدثت فرقاً، والتخلص من الباقي. ولأن التحقق مؤتمت ومساحة البحث كبيرة، فإن التكلفة التراكمية للمراجعة اليدوية ستجعل هذا العمل غير عملي بدون حلقة. الهدف ثابت، والمسار غير معروف؛ وهذا هو المكان الأمثل.
كتيبات التشغيل (Operational playbooks). غالباً ما تتبع الاستجابة للحوادث وتذاكر الدعم أنماطاً اكتشفها البشر بالفعل. فئة معينة من أخطاء الإنتاج تتطلب دائماً تدوير بيانات الاعتماد (rotating a credential) ومسح ذاكرة التخزين المؤقت (clearing a cache). فئة من طلبات الدعم يمكن حلها برد الأموال عند استيفاء ثلاثة شروط محددة. يمكن للحلقة مراقبة تلك المحفزات وتنفيذ كتيب التشغيل، مع التصعيد فقط عندما ينكسر النمط. هي لا تقرر ما إذا كان كتيب التشغيل صحيحاً أم لا؛ بل تفرض الاتساق فقط بنطاق وسرعة لا يمكن للمهندسين المناوبين (on-call engineers) مضاهاتهما.
المنظمون، وليس واضعو المراجع
هناك تمييز جوهري مفقود في الكثير من النقاشات الحالية. الحلقات (Loops) هي منظمات؛ فهي تحافظ على توافق النظام مع هدف محدد مسبقاً، تماماً كما يحافظ منظم الحرارة (thermostat) على درجة حرارة الغرفة عند اثنتين وسبعين درجة. لكن منظم الحرارة لا يختار الرقم اثنتين وسبعين، بل كان على شخص ما أن يقرر أولاً أن تلك هي درجة الحرارة المناسبة.
وعند تطبيق ذلك على البرمجيات، فإن هذا يعني أن الوكيل (agent) داخل حلقة يمكنه إصلاح الأخطاء (bugs)، أو إعادة هيكلة الدوال (refactor functions)، أو ضبط المعلمات (tune parameters) طوال اليوم. ومع ذلك، لا يمكنه تقرير أي ميزة تساعد العميل فعلياً، أو ما إذا كان الخطأ يستحق الإصلاح قبل الإصدار القادم. تتطلب هذه الاختيارات حكماً مبنياً على سياق العمل، ومعاناة المستخدم، والأولويات الاستراتيجية. الوكلاء ينفذون، أما البشر فيقررون. والخلط بينهما هو ما يؤدي بالفرق إلى الحصول على أنظمة محسنة بشكل رائع ولكنها تحل المشكلة الخاطئة.
هندسة الحلقات (Loop engineering) مفيدة، لكنها محدودة النطاق. فهي تساعدك على تشغيل الآلة بانضباط وسرعة، لكنها لا تقرر أي آلة يجب بناؤها، أو لمن هي، أو كيف يبدو النجاح بالمعايير البشرية. إن الحكم على الميزة المهمة، والمخاطرة المقبولة، ومتى يجب تغيير الهدف نفسه، هو أمر يقع على عاتقك. ابنِ حلقات للأعمال التي تفهمها جيداً بما يكفي للتحقق منها تلقائياً، واترك لنفسك زمام السيطرة على كل شيء آخر.
يستند هذا المقال إلى أفكار ناقشها في الأصل Isaac Hagoel في “Loop Engineering Minus The Hype.” لمزيد من النقاشات الهندسية، انضم إلى مجتمعنا التعليمي على Telegram.