الأنظمة تجعل العبقرية أكثر تألقًا

الأنظمة تجعل العبقرية أكثر تألقًا الصورة: من إنتاج الذكاء الاصطناعي

موظف McDonald’s ليس طاهيًا حائزًا على نجمة ميشلان. ومع ذلك، فإن Big Mac في سيول هو نفسه Big Mac في نيويورك. الأنظمة تصنع الاتساق.

عند هذه النقطة يخلص الناس عادةً إلى: “لا حاجة للموهبة. النظام يكفي.” أنا أيضًا ظننت ذلك ذات يوم. كنت مخطئًا.

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

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

تاريخ التحرير عبر الهيكل

في عام 1935، تحطمت طائرة Boeing B-17 أثناء رحلة تجريبية. لم يكن السبب عدم كفاءة الطيار. بل لأن الطائرة أصبحت معقدة لدرجة لا يمكن لذاكرة شخص واحد استيعاب جميع الإجراءات. لم يكن الحل البحث عن طيار أمهر، بل إنشاء قائمة مراجعة. بعد ذلك حلّقت B-17 مليونًا وثمانمائة ألف ميل دون حوادث.

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

نظام إنتاج Toyota (TPS) يتبع البنية ذاتها. حين يُسحب حبل الandon يتوقف الخط. لا تخرج سيارة واحدة حتى تُحلّ المشكلة. تعليمات العمل القياسية (SOP) تصنع جودة قابلة للتكرار. لكن القوة الحقيقية لنظام TPS ليست في SOP بحدّ ذاته. لأن SOP يمتص تقلبات العمليات اليومية، يستطيع المهندسون تكريس وقتهم لـkaizen، التحسين الجوهري. حين يتولّى الهيكل التكرار، يتفرّغ الإنسان للتحسين.

بحث أتول غاواندي نقل هذا المبدأ إلى غرفة العمليات. المستشفيات التي اعتمدت قائمة مراجعة سلامة الجراحة الخاصة بـWHO شهدت انخفاضًا في مضاعفات الجراحة بنسبة 36% وفي الوفيات بنسبة 47%. القائمة ورقة واحدة من 19 بندًا. لم ترفع مهارة الجرّاح. بل نقلت العبء المعرفي مثل “عدم نسيان الشاش” إلى النظام، لتمكّن الجرّاح من التركيز على الأحكام الصعبة حقًا: الاستجابة الفورية لنزيف غير متوقع، وإعادة تصميم مسار الجراحة في الوقت الحقيقي.

النمط واحد. حين يتولّى الهيكل التكرار، تتركز قدرات الإنسان في الحكم والإبداع. قيمة النظام ليست في استبدال الموهبة. بل في التأكد من أن الموهبة لا تُهدر فيما لا يحتاجها.

المبدأ ذاته ينطبق على الذكاء الاصطناعي

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

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

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

أسمّي هذا الانحراف (drift). الظاهرة التي يبتعد فيها الوكيل تدريجيًا عن المواصفات الأصلية خلال حلقات التكرار. بلا هيكل، الانحراف حتمي. ترقية النموذج تؤخّر لحظة حدوثه فحسب. لكنها لا تقضي عليه أبدًا.

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

ثلاث وأربعون دقيقة، اثنان وثلاثون نقطة طرفية، صفر أخطاء

الدليل موجود. معيار ZenFlow.

Claude Sonnet 4.6، نموذج من الفئة المتوسطة وليس الأعلى (Opus)، بنى تطبيقًا من الصفر إلى النهاية داخل هيكل SSOT الخاص بـyongol.

النتائج:

32 نقطة طرفية، 9 جداول قاعدة بيانات، 9 ملفات استعلام، 37 اختبار Hurl، جميعها نجحت
نحو 43 دقيقة
أخطاء توليد الشيفرة: صفر

لم يتجنب النموذج جميع الأخطاء. كانت هناك 4 أخطاء (BUG-077~080). المهم أنها جميعًا صُنّفت بوصفها “أخطاء كتابة SSOT”. لم تكن أخطاء في مولّد الشيفرة: أخطأ الوكيل في كتابة المواصفات. والنظام التقطها. أبلغ validate عن الفشل، فصحّح الوكيل المواصفات، وأعاد التشغيل، ونجح.

من أصل ثلاث وأربعين دقيقة، استُهلكت نحو ست عشرة دقيقة في حلقات validate هذه. ذلك هو الوقت الذي علّم فيه النظام الوكيل.

Sonnet “أقل ذكاءً” من Opus، نتائجه المرجعية أدنى في جميع المجالات. ومع ذلك، داخل الهيكل أنتج شيفرة بجودة إنتاجية. لا لأن العبقرية غير ضرورية، بل لأن الهيكل تولّى التنفيذ فلم تحتج العبقرية إلى فعل ذلك.

لأن الهيكل يتيح لـSonnet معالجة التنفيذ بجودة كافية، يمكن توظيف النموذج العبقري حصرًا في التصميم والحكم، المجال عالي الصعوبة حقًا. التشغيل ذاته كموظفي McDonald’s الذين يصنعون الهمبرغر بإتقان ثابت، ليتفرّغ طاهي المقر الرئيسي لابتكار أصناف جديدة.

ثلاثة تروس

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

1. SSOT: ماذا نبني؟

Single Source of Truth. في yongol، تؤدي تسعة ملفات مواصفات تصريحية هذا الدور. OpenAPI يعرّف نقاط النهاية، وDDL يعرّف الجداول، وRego يعرّف الصلاحيات. الجوهر أن هذه التسعة مُسلسَلة بمعرّف واحد: operationId. لنقطة نهاية واحدة، مواصفات الواجهة البرمجية واستعلامات قاعدة البيانات والاختبارات وقواعد الصلاحيات مربوطة جميعًا بالمفتاح ذاته.

ما يتحمّله SSOT: الذاكرة. أسماء الحقول، العلاقات، القيود. لا تحتاج العبقرية إلى تذكّر هذه الأشياء. المواصفات تتذكّر.

2. Codegen: كيف نبني؟

يُولَّد الكود من SSOT. الوكيل لا يكتب كودًا بحرية، بل يكتب كودًا مشتقًا من المواصفات. الانحراف يُكبح هيكليًا. ما ليس في المواصفات لا يمكن إنشاؤه، وما فيها لا يمكن إغفاله.

ما يتحمّله Codegen: التكرار. كتابة الشيفرة النمطية لاثنين وثلاثين نقطة طرفية واحدةً واحدة ليس عمل العبقري. الهيكل يقوم بذلك.

3. Gate: هل بُني بشكل صحيح؟

تحقق حتمي. يفحص validate التناسق بين ملفات المواصفات التسعة. إن وُجد operationId في OpenAPI ولم يوجد في اختبارات Hurl، يفشل. إن وُجد عمود في DDL ولم يُرجَع إليه في استعلام sqlc، يُصدر تحذيرًا. لا تجاوز للمرحلة التالية دون نجاح.

ما يتحمّله Gate: الفحص. التحقق البصري من تناسق اثنين وثلاثين نقطة طرفية يشبه محاولة طيار B-17 تذكّر الإجراءات من ذاكرته. القياسات هي التي تقرّر النجاح.

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

اللحظة التي تتألق فيها العبقرية

إذن أين تدخل العبقرية؟ في كل مكان خارج الهيكل. وذلك بالتحديد هو المكان الذي تُصنع فيه القيمة الحقيقية.

من كتب دليل McDonald’s ليس عامل الفرع. من صمّم الوصفة وفكّك العملية وقرّر أين تُوضع نقاط الفحص هو الخبير. حبل الandon في Toyota كذلك. من حدّد شروط إيقاف الخط كانت بصيرة تاييتشي أونو. النظام يتولّى التنفيذ لا التصميم. التصميم مملكة العبقرية. ولأن الهيكل أزال عبء التنفيذ، يستطيع العبقري الانغماس في التصميم وحده.

الأمر ذاته في الذكاء الاصطناعي. كتابة SSOT في yongol (تحديد نقاط النهاية المطلوبة، تصميم علاقات الجداول، اتخاذ قرار نموذج الصلاحيات) يتطلب استدلالًا عميقًا. الاستكشاف قبل ثبات الهيكل، أحكام معمارية غير مسبوقة، السؤال “كيف أفكّك هذه المشكلة؟” لا شيء من هذا يندرج داخل الهيكل. وهنا يستحق النموذج القوي تكلفته.

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

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

ليس توفيرًا للنموذج الغالي: استخدامه بالشكل الصحيح

لننظر إلى الأسعار.

سعر رمز الإخراج لـClaude Sonnet هو 15 دولارًا لكل مليون رمز. Opus يكلّف 75 دولارًا لكل مليون رمز. فرق خمسة أضعاف. بلا هيكل، لو أوكلت العملية كاملة إلى Opus، يُستهلك معظم استدلاله في توليد الشيفرة النمطية والحفاظ على اتساق أسماء الحقول. كأنك تجعل معماريًا أجره 75 دولارًا في الساعة ينقل الطوب.

مع الهيكل تختلف القصة. التنفيذ (توليد الشيفرة، الحفاظ على التناسق، اجتياز الاختبارات) يعالجه Sonnet داخل الهيكل. كما أثبت ZenFlow، بجودة تجتاز البوابات بنسبة 100%. Opus لا يُوظَّف إلا في التصميم والحكم. بالميزانية ذاتها يتركّز استدلال Opus بكثافة خمسة أضعاف.

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

أسئلة لم تُجَب بعد

بإنصاف، ثمة أمور لم تُثبت بعد.

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

وأمر آخر. كتابة SSOT ذاتها تتطلب خبرة. بالعودة إلى تشبيه McDonald’s: لا بدّ أولًا من وجود من يستطيع كتابة الدليل. لكي يُلمّع الهيكل العبقرية، يلزم أولًا عبقري يصمّم الهيكل. هذا ليس دورانًا. إنه ترتيب. تصميم واحد يحمل تنفيذات لا نهائية.

لكن النمط الجوهري لا يتزعزع.

التضاعف

“ما مدى ذكاء الذكاء الاصطناعي؟” سؤال بنصف إجابة.

النصف الآخر هو: “أين يركّز هيكلك ذلك الذكاء؟”

حين لم يكن لـB-17 قائمة مراجعة، تحطّم حتى أفضل الطيارين. بعد ظهور القائمة، حلّق طيارون عاديون مليونًا وثمانمائة ألف ميل دون حوادث، ونال الطيارون المتميزون فسحة للتعامل مع تحديات غير مسبوقة. لو قالت Toyota “لنوظّف مهندسين أمهر” بدلًا من تطبيق حبل الandon، لما وُجد الإنتاج الرشيق. لأن حبل الandon كان موجودًا، استطاع المهندسون التركيز على kaizen.

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

العبقرية وحدها تتيه. الهيكل وحده عادي. حين تتضاعف العبقرية بالهيكل، عندها فقط تبلغان ما لا يبلغه أيٌّ منهما وحده.

النظام لا يهزم العبقرية. النظام يجعل العبقرية أكثر تألقًا. هذا ليس اكتشافًا جديدًا. مُثبت منذ عام 1935. كل ما في الأمر أننا لم نطبّقه على الذكاء الاصطناعي بعد.

للمزيد من القراءة (مصادر خارجية)

Atul Gawande, The Checklist Manifesto — المصدر الأصلي لحالات B-17 وقوائم مراجعة WHO. كيف تكمّل الأنظمة الخبراء عندما يتجاوز التعقيد القدرة الفردية.
Haynes et al., “A Surgical Safety Checklist to Reduce Morbidity and Mortality in a Global Population” (NEJM, 2009) — الورقة الأصلية لقائمة مراجعة السلامة الجراحية. انخفاض المضاعفات 36% والوفيات 47% في 8 دول.
Mike Mason, “AI Coding Agents in 2026: Coherence Through Orchestration, Not Autonomy” — لماذا التنسيق وليس الاستقلالية هو ما يحافظ على اتساق الوكيل.
“Spec-Driven Development with AI Coding Agents” (ZeroShot, 2026) — كيف تمنع المواصفات المُدارة بالإصدارات (SSOT) انحراف وكلاء البرمجة.
“Guardrails for AI Coding Agents” (Earthly) — تضمين السياسات في سير العمل لالتقاط الانحراف قبل طلب السحب.

المراجع

Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press.
Gawande, A. (2009). The Checklist Manifesto: How to Get Things Right. Metropolitan Books.
Haynes, A. B., et al. (2009). “A Surgical Safety Checklist to Reduce Morbidity and Mortality in a Global Population.” New England Journal of Medicine, 360(5), 491-499.
World Health Organization. (2009). WHO Surgical Safety Checklist. WHO Patient Safety.
حالة قائمة مراجعة B-17: Schamel, J. (2012). “How the Pilot’s Checklist Came About.” Flight Safety Australia Magazine.