بناء أنظمة قابلة لتشغيل الوكلاء

Image generated by Google Gemini

إذا طلبت من وكيل الذكاء الاصطناعي إعادة الهيكلة فتحطم التطبيق، إذا كنت تريد تحويل نظام legacy إلى بيئة يمكن للذكاء الاصطناعي العمل فيها، إذا كنت تريد تحويل ميزانية صيانة legacy في Fortune 500 إلى ميزانية تحول — هذا المقال هو خارطة الطريق.

ذاكرة مقفلة

في عصر فقاعة الإنترنت، بدأت الشركات بتراكم الأصول الرقمية. كود، قواعد بيانات، مواصفات، وثائق، APIs — عقود من ذاكرة الشركات.

تلك الذاكرة كانت مقفلة. لا يمكن البحث فيها، لا يمكن التحقق منها، غير قابلة للوصول (unreachable). الطريقة الوحيدة كانت أن يقرأها شخص بنفسه، يفهمها بنفسه، ويعدّلها بيده. لذلك يُنفق 60-80% من ميزانيات تقنية المعلومات في Fortune 500 على صيانة هذه الذاكرة المقفلة. لا يستطيعون فتحها، فيكتفون بحراستها.

نحن الآن في منتصف ما يُسمى فقاعة الذكاء الاصطناعي. المعنى الحقيقي لهذا العصر ليس أن النماذج تصبح أذكى. بل أن ذاكرة legacy المقفلة منذ سنوات بدأت تصبح قابلة للوصول (reachable).

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

لماذا يتكرر هذا؟

ليس لأن الوكيل غبي. بل لأن البيئة غير مبنية لعمل الوكلاء. لا تضع روبوتاً في مكتب بشري. ابنِ مصنعاً يستطيع فيه الروبوت العمل.

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

ما معنى Agent-Operable

لكي يعمل الوكيل بشكل مستقل، يحتاج ثلاثة شروط:

1. يجب أن يكون قابلاً للقراءة — بدون ضوضاء

للعثور على دالة واحدة في ملف من 2,000 سطر، هناك 1,950 سطراً من الضوضاء. للعثور على بيانات العملاء في قاعدة بيانات غير مُطبَّعة، تحتاج join لثلاثة جداول. قواعد العمل المخبأة في أوراق Excel غير مرئية للوكلاء.

القابلية للقراءة لا تعني أن الإنسان يستطيع قراءتها. تعني أن الآلة تستطيع تحليلها هيكلياً.

2. يجب أن يكون قابلاً للتحقق — حتمياً

إذا لم يستطع الوكيل معرفة ما انكسر بعد تعديل، يقع في doom loop. الكود يحتاج اختبارات. قواعد البيانات تحتاج قيوداً. APIs تحتاج تحققاً من schema. المواصفات تحتاج تحققاً تبادلياً.

أن يتحقق LLM من LLM آخر مثل أن تسأل صديقك السكران “هل أنا سكران؟”. go test لا يهلوس. CHECK constraint لا يكذب. JSON Schema لا ينحرف.

3. الحالة يجب أن تبقى — حتى لو مات الوكيل

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

عندما يعالج الوكيل A حتى الدالة رقم 200 ويموت، يجب أن يبدأ الوكيل B من رقم 201. الوكلاء قابلون للاستبدال. لكن التقدم يجب أن يتراكم.

الخطوة صفر: جمّد الأخطاء

الشروط الثلاثة هي الوجهة. نقطة البداية مختلفة. لا توثيق، لا اختبارات، 300 ملف بـ 2,000 سطر لكل منها. هذه هي نقطة البداية.

أخبر وكيلاً بـ"أعد الهيكلة" في هذه الحالة. ماذا يحدث؟ يُ"صلح" خطأ عمره عشر سنوات. المشكلة أن ذلك الخطأ ليس خطأ.

قانون Hyrum: كل سلوك قابل للملاحظة في API قديمة بما يكفي، هناك من يعتمد عليه. خطأ تقريب عشري مُهمَل لعقد كامل، منطق دفع عميل VIP مربوط به. خطأ تحليل تواريخ أنتج ماكرو Excel يحمل قسم المحاسبة بأكمله. الأخطاء القديمة هي مواصفات عمل ضمنية.

المهمة الأولى للوكيل ليست إصلاح الكود. بل تجميد السلوك الحالي.

اطعن API. سجّل الاستجابة. ثبّت تلك الاستجابة كاختبار Hurl. خطأ غريب أم سلوك مقصود — لا تمييز. جمّده كما هو. هذا أول سن في ratchet — يقفل الوكيل من أن “يحسّن” الأمور من تلقاء نفسه.

التغييرات يقررها فقط من يملك المواصفات. الوكيل منفذ. ليس حَكَماً.

بعد انتهاء التجميد، يبدأ التحول نحو الشروط الثلاثة: القراءة، التحقق، الاستمرارية.

ليس الكود فقط

“Agent-operable codebase” هي نقطة البداية. الأصول الرقمية للشركة ليست كوداً فقط.

كل صف على حدة يبدو “يجب أن نرتب”. مجتمعة، تشكل نظاماً.

Symbolic Feedback Loop

بنية مشتركة تجعل هذا التحول ممكناً.

LLM يولّد → أداة حتمية تحكم → النتيجة تُعاد إلى LLM → تكرار

في الكود، في الاختبارات، في المواصفات، في البيانات — نفس الحلقة تعمل:

بنية الكود:      filefunc validate → تغذية راجعة بالمخالفات → LLM يصلح → تكرار
الاختبارات:      go test + coverage → تغذية راجعة بالأسطر غير المغطاة → LLM يعزز → تكرار
اتساق المواصفات: yongol check → تغذية راجعة بالانحراف → LLM يصلح → تكرار
قواعد المستخدم:  rulecat evaluate → تغذية راجعة بالمخالفات → LLM يصلح → تكرار

الشيء الوحيد الذي يفعله LLM هو التوليد. ماذا يُصلح، هل نجح، ما التالي، هل انتهى — كلها تقررها الآلة. LLM لا يحصل على صلاحية اتخاذ القرار.

هذا ليس اختراعاً. C. elegans يخصص 60 من أصل 302 خلية عصبية (20%) للإدخال الحسي. للتحقق، لا للتوليد. 500 مليون سنة من التطور وصلت إلى هذه النتيجة: تحسين جودة التغذية الراجعة يتفوق على إضافة المزيد من الخلايا العصبية للبقاء.

الصناعة تجعل القطار (النموذج) أسرع. نماذج أكبر، وكلاء أذكى، prompts أفضل. لكن كلما أسرع القطار، زادت أهمية السكة.

80/20

في الحالة النهائية، ينقسم النظام إلى طبقتين.

SSOT (80-90%)
├── OpenAPI, DDL, SSaC, FuncSpec, Rego, Hurl, React TSX, Mermaid, manifest
└── يُولَّد من المواصفات. الانحراف يُمنع من المصدر. الوكلاء يعدّلون بحرية.

Custom (10-20%)
├── قواعد العمل، منطق النطاق، الحسابات القانونية/السياسية
└── مُهيكل بـ filefunc، مُختبر بـ tsma. البشر يراجعون.

الكود الذي يحتاج البشر فعلاً للاهتمام به ينضغط إلى 10-20%. الباقي يولّده وكلاء يقرؤون المواصفات، وتتحقق منه الآلات.

60% من Fortune 500

60-80% من ميزانيات تقنية المعلومات في Fortune 500 تُستهلك في صيانة legacy. 42% من وقت المطورين يذهب للديون التقنية. 70% من عمليات ترحيل legacy اليدوية تفشل.

هذه الميزانية تُنفق بالفعل. لا حاجة لميزانية جديدة. فقط أعد توجيهها. حوّل ميزانيات الصيانة إلى ميزانيات تحول.

أدخل legacy بالكامل، ويخرج نظام agent-operable. هذا وعد Building Agent-Operable Systems.

لماذا لا تفعل الشركات الكبرى هذا

Anthropic وOpenAI يبنيان نماذج عامة الغرض. حسّن النموذج 10% وينطبق على كل العملاء. لكن ابنِ حلقة تغذية راجعة لـ Go test وتنطبق فقط على مطوري Go. ابنِ أداة coverage لـ Python وتنطبق فقط على مشاريع Python.

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

لذلك هذا المكان فارغ. من يبني القطار ومن يمد السكة ليسوا منافسين. هم مكمّلون.

أسئلة

وكيلك يكتب الكود. لكن من يتحقق أن ذلك الكود صحيح؟

وكيل آخر؟ أم go test؟

هل يقرأ LLM الخاص بك فعلاً كل الـ 100,000 سطر؟

أم يتظاهر بالقراءة؟

ما يحتاجه عصر الوكلاء ليس وكلاء أذكى. بل أنظمة يستطيع فيها الوكلاء العمل.

Sources

• Gartner, “IT Budget and Cost Optimization” — 60–80% of enterprise IT budgets consumed by legacy maintenance
• Stripe & Harris Poll, The Developer Coefficient (2018) — 42% of developer time spent on technical debt
• McKinsey & Company, Why do most transformations fail? (2019) — ~70% of digital transformation projects fall short of goals
• Hyrum Wright, Hyrum’s Law — “With a sufficient number of users of an API, all observable behaviors of your system will be depended on by somebody”
• Winters, Manshreck, Wright, Software Engineering at Google (O’Reilly, 2020) — Formal book source for Hyrum’s Law
• White et al., “The structure of the nervous system of C. elegans”, Phil. Trans. R. Soc. Lond. B 314 (1986) — 302-neuron connectome
• Inglis et al., The sensory cilia of C. elegans, WormBook (2007) — 60 sensory neurons (~20% of total)
• METR, Early-2025 AI Developer Productivity Study (2025) — AI tools made experienced developers 19% slower, yet developers perceived 24% speedup
• GitClear, AI Copilot Code Quality 2025 (2025) — 211M lines analyzed, refactoring down 60%, copy-paste code up 48%
• Mehtiyev & Assuncao, Beyond Resolution Rates (2026) — 19 agents, 9,374 trajectories; 12.4% of total compute spent on zero-yield tasks