تجميع العملية، لا الكود
وكلاء البرمجة هم مولدات عالية السرعة. إنهم مبدعون ولكنهم غير موثوقين. وغالبًا ما ينسون القواعد عندما يصبح السياق ثقيلًا.
لإصلاح ذلك، لا ينبغي عليك إلقاء المحاضرات على الوكيل. بدلاً من ذلك، قم ببناء مُحقق (verifier).
المُحقق هو فحص منخفض التكلفة وحتمي (deterministic) يوضع أمام المولد. إذا خرق الوكيل قاعدة ما، فإن الفحص يوقف العمل. هذا هو الفصل بين المولد والمُحقق (generator/verifier split).
يستخدم معظم الناس هذه الفحوصات للكود. فهي تبحث عن الأخطاء المطبعية أو أخطاء بناء الجملة (syntax errors). لكن القوة الحقيقية تكمن في مكان آخر. يمكنك استخدام هذه الفحوصات لتجميع سير عملك بالكامل.
أنا أستخدم الفحوصات لفرض الانضباط المهني:
• فحص واحد يضمن وجود مواصفات مكتوبة للمهمة قبل بدء التنفيذ. • وفحص آخر يحدد التبعيات (dependencies) التي أصبحت قديمة. • وفحص ثالث يفرض دورة حياة صارمة: مقترح، مراجع، ثم مقبول.
في الفرق البشرية، تعيش هذه القواعد في رؤوس الأشخاص. وغالبًا ما يكون ميكنة هذه القواعد مكلفًا للغاية. أما مع الوكيل، فإن الحسابات تتغير.
يتسبب الوكيل في حدوث الانحراف (drift) بشكل أسرع من البشر. ولكن يمكن للوكيل أيضًا كتابة نص التنفيذ (enforcement script) في ثوانٍ. أصبحت تكلفة ميكنة عمليتك الآن تقترب من الصفر.
عندما تنخفض تكلفة التنفيذ، يمكنك إضفاء الطابع الرسمي على منهجيتك. ستنتقل من مجرد "قائمة تحقق" (checklist) إلى "قواعد لغوية" (grammar). ستصبح تعليماتك أقصر وأكثر صدقًا لأن "البوابات" (gates) هي من يتولى مهمة التذكر.
ومع ذلك، كن حذرًا من ثلاثة أمور:
- هذه مجرد أدوات فحص (linters)، وليست نظام أنواع (type system) مثاليًا. فهي تكتشف الأخطاء المعروفة ولكنها لا تضمن الصحة المطلقة.
- لا يوجد مخطط رئيسي. قواعدك تنمو بشكل تفاعلي بناءً على الإخفاقات السابقة.
- غالبًا ما يكتب الوكيل بواباته الخاصة. وهذا يعني أن البوابة قد تكتشف فقط الأخطاء التي يعرف الوكيل بالفعل كيفية تجنبها.
توقف عن التعامل مع ملفات التعليمات الخاصة بك ككتيبات إرشادية. تعامل معها كـ "نية" (intent). انقل مفهوم الصحة من النثر إلى الفحوصات.
قم بتجميع عمليتك، وليس الكود الخاص بك فحسب.
مجتمع تعليمي اختياري: https://t.me/GyaanSetuAi