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

كاتب المقال: CyrilXBT

تأليف المقال ومصدره: ME News

في يونيو 2026، خلال أسبوع واحد، توصل ثلاثة أشخاص بشكل مستقل إلى نفس الاستنتاج.

أعلن مطور OpenClaw، بيتر شتاينبرغر، أن الناس يجب أن يتوقفوا عن كتابة تعليمات مباشرة للوكلاء البرمجيين، وبدلاً من ذلك يصممون أنظمة حلقات تلقائية تصدر تعليمات للوكلاء.

في نفس الوقت تقريبًا، أشار بوريس تشيرني، المسؤول عن Anthropic Claude Code، إلى أنه لم يعد يُدخل أوامر مباشرة إلى Claude. الآن، يعمل على مجموعة من الدورات التي تقوم تلقائيًا بدعوة Claude وتحديد الخطوة التالية، بينما يتركز عمله الحقيقي على كتابة وتصميم هذه الدورات.

بعد عدة أيام، قام مهندس Google، Addy Osmani، بتلخيص هذا الممارسة بشكل منهجي واعطائه اسماً:

Loop Engineering، الهندسة الدائرية.

لم يخلقوا هذا الأسلوب في العمل من العدم، بل أطلقوا اسمًا على تغيير كان يحدث بصمت.

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

هذا بالضبط السبب في وجود هذه الخريطة الطريق.

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

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

الهندسة الدائرية ليست مهارة واحدة "مُتقنة" أو "غير مُتقنة"، بل هي مجموعة من طبقات القدرات المتراكبة. كل طبقة تعتمد على متانة الأساس الذي يقع أسفلها.

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

وبالمثل، إذا قمت ببناء طبقة الذاكرة الدائمة في الخطوة 11 قبل إكمال آليات التحقق الموثوقة في الخطوتين 6 و7، فقد تقوم بحفظ بدقة التجارب التي خلص إليها "مُراجع" متساهل جدًا يسمح باستمرار بنتائج خاطئة.

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

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

الخطوة الأولى الحقيقية لا تتضمن أي تقنية.

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

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

يمكن للنموذج تنفيذ التحقق وإعادة المحاولة، وهذه العمليات أسرع بكثير من مراقبة الإنسان التدريجية له أثناء إكمال المهمة.

هذه الخطوة لا تحتوي على كلمة إرشادية محددة، بل هي قرار إدراكي.

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

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

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

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

الهندسة الدائرية غيرت تمامًا هذا التفكير.

عند ظهور مشكلة، لم تعد تضيف طلبًا جديدًا إلى المُحفّز، بل تضيف مكونًا جديدًا للنظام، مثل:

• أضف خطوة تحقق مستقلة؛
• أضف ملف ذاكرة؛
• أضف مُحفّزًا مُجدولًا؛
• أضف جلسة مراجعة منظمة.

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

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

التعرف، التسليم، التحقق، التخزين الدائم، الجدولة.

الاكتشاف

حدد المهمة الحقيقية التي يجب إكمالها.

التسليم

Assign the task to the model, agent, or tool responsible for execution.

التحقق

تحقق من صحة النتائج وفقًا للمعايير الحقيقية.

الاستمرارية

سجل ما حدث خلال هذه العملية وما تعلمته، لتجنب فقدان الخبرة في العملية القادمة.

الجدولة

حدد متى يجب إعادة تشغيل هذه العملية.

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

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

جوهر الهندسة الدائرية هو جعل هذه الحركات الخمسة جميعها صريحة وتحقيق تشغيلها التلقائي قدر الإمكان.

قبل البدء في بناء النظام، اختر مهمة تقوم بتنفيذها بشكل متكرر ويمكنك وصف معايير جودتها بوضوح.

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

يجب أن يستوفي المهمة المرشحة الأولى ثلاثة شروط:

1. يجب أن تقوم بتنفيذها مرارًا وتكرارًا؛
2. لديه معايير واضحة يمكن كتابتها؛
3. It has an easily recognizable "completed status".

بعبارة أخرى، يجب أن يتمكن زميل من تقييم ما إذا كانت المهمة أُنجزت بشكل صحيح بمجرد رؤية النتائج.

هذا الحد أكثر أهمية مما يبدو عليه سطحيًا.

إذا لم تكن هناك معايير واضحة لإكمال المهمة، فلا يمكن بناء دورة تحقق حقيقية. ودورة بدون آلية تحقق موثوقة ليست دورة حقيقية، بل هي مجرد تخمين دون رقابة.

هذه هي الخطوة التي يتجاوزها معظم الناس بسهولة، لكنها الخطوة الحاسمة لضمان عمل النظام بشكل صحيح في ما بعد.

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

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

يمكن استخدام القالب التالي:

اسم المهمة: [اسم المهمة]

إكمال تعريف الإنجاز (Definition of Done، DoD):

• [مقياس محدد وقابل للتحقق 1]
• [معيار محدد وقابل للتحقق 2]
• [مقياس محدد وقابل للتحقق 3]

حتى إذا بدا الإخراج النهائي كاملاً ومُحسَّنًا بعناية، فإن المهمة لا يمكن اعتبارها مكتملة ما لم تُستوفَ جميع البنود المذكورة أعلاه.

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

هذا هو أهم قرار هندسي في جميع الأنظمة الدورية.

The role responsible for generating results must be separated from the role responsible for reviewing results.

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

في دورة منطقية، يجب أن يكون هناك على الأقل دوران مستقلان:

المُنشئ

يملك المُنشئون مساحة إبداعية معينة مسؤولة عن توليد النسخة الأولى من النتائج.

المُقيِّم

يقوم المُراجع باستلام مخرجات المُنشئ وتعريف الإنجاز المُحدد في الخطوة 5، ثم يُقيّم ما إذا كانت النتائج تلبي هذه المعايير.

في المثالية، ينبغي أيضًا أن يكون لدى المراجع القدرة على الوصول إلى أدلة مستقلة لا يمكن للمُنشئ الوصول إليها، مثل:

• مجموعة الاختبار؛
• المصدر الأصلي؛
• البيانات في الوقت الحقيقي؛
• قاعدة بيانات موثوقة؛
• Original task brief.

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

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

It cannot determine whether the result is truly correct.

لذلك، يجب أن يمتلك المراجعون أساسًا موضوعيًا يمكن التحقق منه، وهو Ground Truth. ووفقًا للسياق، يمكن فهمه على أنه "الحقيقة المرجعية" أو "البيانات الحقيقية" أو "الأساس الموثوق".

للمهام المختلفة، تكون المعايير الموضوعية مختلفة أيضًا.

مهمة برمجة

الأساس الموضوعي هو مجموعة الاختبارات ونتائج التشغيل الفعلية للرمز.

مهمة إنتاج المحتوى

الأساس الموضوعي هو المواد الأصلية وملخصات المحتوى. يجب على المراجعين مقارنة المواد الأصلية مع النص المُنشأ جنبًا إلى جنب.

مهمة بحث

The objective basis is the original files, papers, datasets, or authoritative sources explicitly required for the task.

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

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

بدون ذلك، لا يمتلك المُدير الخطوة التالية معلومات مستقرة وموثوقة لاتخاذ القرار وإعادة التوجيه.

يمكن للمطورين استخدام التنسيق التالي للإخراج:

مخرجات المُنشئ:

• المحتوى النهائي المُسلَّم؛
• درجة الثقة في النتائج؛
• اللايقينية المعروفة.

يمكن للمراجعين استخدام تنسيق الإخراج التالي:

نتيجة المراجعة:

• PASS: ناجح؛
• FAIL: فشل؛
• يحتاج إلى مراجعة؛
• ال проблемы المحددة التي تم اكتشافها؛
• المعايير الموضوعية أو الأدلة الأصلية التي استند إليها هذا التحقق.

قبل الربط مع الجدولة التلقائية وإعادة المحاولة التلقائية، قم بتشغيل يدويًا مرة واحدة عملية "المُنشئ—المُراجع" بالكامل.

اقرأ بعناية الحكم المقدم من المراجع، واسأل نفسك:

• هل توافق على استنتاجه؟
• هل تخلّت يومًا عن نتيجة كنت تعلم أنها خاطئة؟
• Did it incorrectly negate a originally qualified result?

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

أتمتة خطوة تحقق خاطئة ستؤدي فقط إلى إنتاج نتائج خاطئة بسرعة أكبر.

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

الخطوة 5: تحديد الإنجاز

يمكن أن تكون معايير إنجاز هذه المهمة:

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

الخطوة 6: ينشئ المُطور المسودة

يتلقى المُنشئ المواد الأصلية وموجز المحتوى، ثم يُنتج مسودة أولية.

في الوقت نفسه، يجب أن تسرد بوضوح عدم اليقين الموجود أثناء عملية الكتابة، مثل:

• هل ظهر الرقم الحقيقي في المصدر الأصلي؛
• هل الاستنتاج مذكور صراحة في النص الأصلي، أم تم استنتاجه من قبل النموذج؟
• هل يفتقر هذا الحقائق إلى مصادر كافية؟

الخطوة 7: يراجع المراجع النص الأصلي

يُرسل المُراجع كلاً من المسودة والمصدر الأصلي، وليس المسودة فقط.

يجب التحقق من كل معيار من المعايير الثلاثة المحددة بشكل منفصل، وتقديم نتيجة نجاح أو فشل لكل معيار على حدة، بدلاً من دمج جميع الأبعاد في درجة شاملة غامضة.

دمج ثلاثة معايير مختلفة في حكم عام واحد يخفي أي بعد من الأبعاد هو الذي يواجه مشكلة. هذا هو السبب الأكثر شيوعًا لفقدان الدورات التي كانت تعمل سابقًا قيمتها التغذوية الراجعة.

الخطوة 8: التسليم المُنظَّم

يجب أن يكون استنتاج المُقيِّم كائنًا منظمًا، وليس فقرة من اللغة الطبيعية مليئة بعبارات تحفظية.

يجب أن يُنتج ثلاثة نتائج واضحة ناجحة أو فاشلة، مع تقديم سبب محدد لكل فشل.

الخطوة 9: التحقق اليدوي من آلية المراجعة

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

مراجعون متساهلون جدًا قد يتجاوزون البيانات المزيفة بسبب سلاسة كتابة المقال.

قد يرفض مُقيّم مفرط الصرامة مقالًا مؤهلًا بسبب تفضيل شخصي غير مذكور أبدًا في التقرير.

هذه المشكلتان شائعتان جدًا عند الإعداد الأولي.

وإيجادها بعد تشغيل النظام بدون رقابة 50 مرة يكون أغلب بكثير من حل المشكلات عند الاختبار اليدوي الأول.

يقوم المدير بقراءة أحكام المراجعين واتخاذ الإجراء التالي.

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

على سبيل المثال:

شرط الإيقاف:

• أقصى عدد من التعديلات: 3 مرات؛
• عند فشل المراجعة الثالثة، قم بإرسال السجل الكامل للمعالجة البشرية، ولا تبدأ المراجعة الرابعة؛
• معايير الجودة: يجب أن تظهر كل بند من البنود المحددة كـ PASS؛
• الحد الأقصى للميزانية: إذا تجاوزت تكلفة المهمة X أو استمرت لأكثر من Y، فيجب إيقافها فورًا بغض النظر عن الحالة الحالية.

الحلقة التي لا تحتوي على شرط توقف حقيقي ليست نظامًا، بل هي مسؤولية تنتظر الكشف عن المخاطر.

لماذا لا تعتبر التعليمات المرنة مثل "توقف عندما تكون النتائج جيدة بما يكفي" موثوقة؟

لأنه مجرد اقتراح.

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

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

إذا بدأت كل دورة من الصفر، فلن تتذكر ما تعلمته في التشغيل السابق.

لذلك، من الضروري إضافة طبقة استمرارية بسيطة.

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

• What did you learn?
• What was fixed;
• Why is this experience important?

المبدأ الأساسي هو: تسجيل المعرفة الجديدة فقط التي لم تُحفظ من قبل في مكان آخر.

التكرار ليس معرفة، بل ضجيج.

لضمان فعالية آلية التخزين الدائم على المدى الطويل، يجب التحلي بالاعتدال أثناء الكتابة.

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

التجارب التي تستحق التسجيل حقًا هي تلك التي إذا نسيتها، ستحتاج إلى وقت طويل لإعادة اكتشافها، وليس مجرد سجل عادي لعملية تمت بنجاح كما كان متوقعًا.

إن زيادة آلية التخزين الدائم ببساطة ستؤدي في النهاية إلى مشاكل مشابهة لتلك الناتجة عن عبارات التوجيه الطويلة جدًا.

مع مرور الوقت، يتراكم النظام عشرات الملفات، العديد منها تحتوي فقط على صيغ مختلفة قليلاً لنفس المشكلة.

لذلك، يجب تنظيم ملفات الذاكرة وفقًا لدورة ثابتة. عادةً ما يكون تنفيذ ذلك أسبوعيًا ترددًا مناسبًا.

تشمل عملية التنظيم:

• مراجعة الذاكرة الحالية؛
• دمج المحتوى المكرر؛
• دمج عدة تجارب متشابهة في مبدأ واحد أكثر وضوحًا؛
• احذف المحتوى الذي تم إثبات خطأه أو قدمه.

الهدف ليس تجميع المزيد والمزيد من الملفات، بل اكتساب معرفة أقل عدداً وأعلى كثافة معلوماتية.

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

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

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

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

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

لا تُجبر تجاربك السابقة على تطبيقها على مشكلة جديدة تمامًا فقط لأن نظامًا مشابهًا موجود بالفعل.

بعد ذلك، يجب تحديد متى يجب أن تعمل هذه الدورة تلقائيًا دون تشغيل يدوي.

طرق التفعيل قد تشمل:

• مهمة جدولة Cron؛
• مراقب تغييرات الملفات؛
• مُحفِّز دوري مبني على التقويم؛
• يُفعّل عند تغيّر حدث خارجي أو حالة ما.

هذه الخطوة ستُحوّل نظامًا لا يمكن تشغيله إلا يدويًا إلى نظام يمكنه الاستمرار في العمل أثناء نومك.

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

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

اختبار واحد: المهمة المستحيلة

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

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

اختبار ثاني: نتيجة تبدو منطقية لكنها خاطئة في الواقع

قدم للمراجع إخراجًا تعرف بوضوح أنه يحتوي على أخطاء طفيفة.

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

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

الاختبار الثالث: مشاركة المُبنِي والمُقيِّم لمناطق العُمق في النموذج

إذا استخدم المُنشئ والمُراجع نفس النموذج الأساسي، يمكن إدخال خطأ نموذجي يرتكبه هذا النموذج غالبًا لمراقبة ما إذا كان المُراجع سيتجاهله.

إذا كان المراجع والمبني يمتلكان نفس نقاط blind spot، فإن فصل الأدوار المُصمم في الخطوة 6 يفقد معناه.

الاختبار الرابع: حساب تكلفة التشغيل في أسوأ الحالات

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

ثم اسأل نفسك بصدق:

Would you feel uneasy if this number appeared on a real bill?

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

خلاف ذلك، من المرجح أن تظهر هذه المشكلات لأول مرة أمام العملاء أو المديرين، أو تتجلى مباشرة في فاتورتك، بدلاً من أن تظهر في اختبار تتحكم به أنت بشكل نشط.

بعد أن يبدأ الدوران بشكل مستقر، لا تجعل جميع الأدوار تستخدم نفس النموذج المفضل لديك.

الأدوار المختلفة في الدورة تتطلب متطلبات مختلفة لقدرات النموذج.

المُنشئ

يجب على المطورين عادةً استخدام النموذج الأقوى قدرة.

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

في النهاية، قد تتجاوز التكلفة المستهلكة لتصحيح المسودات الأولية ذات الجودة المنخفضة التكلفة التي تُدفع من البداية لاستخدام نموذج أقوى.

مُراجع

يقوم المراجعون بمراجعة المحتوى وفقًا لمعايير محددة، ولا يتطلب الأمر عادةً قدرة إبداعية كبيرة.

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

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

مدير

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

مهمته تنفيذ المنطق المحدد مسبقًا، وليس إجراء استدلال مفتوح.

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

عادةً ما تكون التكوينات الطبقية المعقولة:

• النموذج القوي مسؤول عن البناء؛
• النماذج الرخيصة والمستقرة مسؤولة عن المراجعات الروتينية؛
• يقوم نموذج أو برنامج قواعد منخفض التكلفة بالترحيل والإدارة.

تُنشأ تحسينات التكلفة الحقيقية البارزة في النظام الدائري من مطابقة أدوار هذا النموذج.

يعتقد الكثيرون أن التحكم في التكلفة يعني تقليل عدد الدورات أو التعديلات. في الواقع، الطريقة الأكثر فعالية هي مواءمة تكلفة النموذج مع صعوبة كل دور في الدورة.

بعد نجاح الدورة الأولى، من السهل على الناس محاولة بناء عدة دورات في وقت واحد، ومعالجة خمس مهام مختلفة بالتوازي.

حتى لو كان الهيكل الحالي قادرًا على دعم هذا التوسع، يجب التحكم في هذا الدافع.

يجب أن تدع الدورة الأولى تعمل بثبات لفترة كافية حتى لا تحتاج إلى مراقبة كل مخرجاتها عن كثب.

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

يجب فقط البدء في بناء الدورة الثانية عندما تصل إلى هذه الحالة.

يجب أن يُعالج الدورة الثانية مهمة مختلفة بوضوح عن الدورة الأولى.

هذا هو السبيل الوحيد للتحقق من أن البنية التحتية تتمتع بقابلية عامة حقيقية، وليس فقط بتحسينات متزايدة الدقة لمهام مماثلة.

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

منفردة، قد يكون ميزانية المهمة الدورية منطقية تمامًا.

لكن إذا عملت جميع الدورات العشر ضمن ميزانيتها، فقد لا يزال إجمالي تكلفتها يصل إلى مستوى مفاجئ.

بما أن بيانات كل دورة مستقلة تبدو طبيعية، فإن هذا الخطر غالبًا ما يُكتشف فقط عند ظهور الفاتورة المجمعة.

بالإضافة إلى المهام المكتملة بنجاح، يجب تسجيل كل تفعيل لشرط التوقف بشكل منفصل.

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

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

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

أوضح معيار لتحديد ما إذا كان التحول الذهني قد اكتمل حقًا هو تغيّر المؤشرات التي تركز عليها يوميًا.

يهم مشغّل التعليمات البرمجية:

• كم عدد التعليمات الفعالة التي كتبتها اليوم؟
• أي تعليمات أفضل أداءً؟
• كيفية صياغة التعليمات بشكل أكثر دقة.

يُهتم مصممو النظام بـ:

• كم عدد الدورات الجارية حاليًا؟
• How reliable is each cycle?
• كم من الوقت أطلقه النظام لنفسه؛
• ما الأعمال التي لم تعد بحاجة إلى إشراف بشري.

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

الخطوة الأخيرة لم تعد تتعلق تمامًا بنظامك الخاص.

It is used to verify whether you truly understand this method.

يجب أن تحاول شرح خمسة إجراءات أساسية لشخص آخر دون الاعتماد على مصطلحات معقدة:

التعرف، التسليم، التحقق، التخزين الدائم، الجدولة.

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

أنت لست الشخص الذي يبقى داخل الدورة، ويُدخل الأمر التالي باستمرار.

أصبحت الشخص الذي يقف خارج الدورة، ويبني النظام ويراقبه وهو يعمل ذاتيًا.

بعد تخطي الخطوات، ستتراكم أربعة تكاليف بصمت

في نهاية المقال، من الضروري تقديم تحذير.

تجاوز خطوات خارطة الطريق هذه لا يؤدي عادةً إلى تعطل النظام على الفور.

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

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

لا يزال الدوران يبدو أنه يعمل بشكل طبيعي، لأن النتائج المُولَّدة "تبدو جيدة".

حتى يُكتشف خطأ ما بعد تراكمه على مدار عشرات العمليات، ستدرك أن النظام لم يُحدّد أبداً ما إذا كانت النتائج صحيحة من البداية.

عند تخطي الخطوة 20، قد يحدث تدهور في الفهم.

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

السبب هو أنك لم تُدمج قط المنطق وراء هذا الهيكل.

يحدث الاستسلام المعرفي إذا لم تُكمل الخطوة الأولى أبدًا.

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

هذا السلوك يبدو حذرًا، لكنه في الواقع يلغي المعنى الكامل لبناء النظام.

إذا تم تخطي الخطوة 10 ولم يتم تحديد شرط توقف حقيقي للدورة، فقد يحدث فقدان غير متحكم فيه للرموز وتكاليف الاستدعاء.

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

يمكن تجنب جميع التكاليف المذكورة أعلاه.

الطريقة لتجنبها هي دائمًا نفس الانضباط:

ابنِ بالترتيب، لا تتجاوز الخطوات التي تبدو غير مثيرة بما فيه الكفاية.

الأشياء التي تعمل فعليًا هي غالبًا تلك الأجزاء الأكثر مللًا:

• تعريف واضح للإكمال؛
• شروط إيقاف موثوقة؛
• أساس موضوعي قابل للتحقق؛
• Independent review mechanism.

على العكس، فإن الأجزاء التي تبدو أكثر جاذبية—مثل عبارات التوجيه الذكية ورسومات البنية النظامية المعقدة—أقل أهمية بكثير مما يتخيله الناس.

ما يحدد جودة النظام حقًا هو ما إذا كان النظام الذي بنيته يعرف:

• متى تكون محقًا بنفسك؛
• متى تكون أنت مخطئًا؛
• متى يجب التوقف.

هذا هو الفرق الكامل بين مشغّل التعليمات البرمجية وصانع النظام.

الفرق ليس في من هو أكثر ذكاءً، ولا في من يستطيع كتابة أوامر أكثر تفصيلاً.

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