يمكن لكل وكيل برمجة يعمل بالذكاء الاصطناعي أن يُخرج "diff" (فرق التغييرات). المشكلة الحقيقية تكمن في معرفة ما إذا كان هذا الـ diff ناتجاً عن عملية مركزة ومدروسة، أم أنه مجرد مسح عشوائي وسريع عبر مستودع الكود الخاص بك انتهى بالصدفة إلى النتيجة الصحيحة. في الوقت الحالي، لا تستطيع معظم الفرق التمييز بينهما.
هذه ليست مشكلة تقنية، بل هي مشكلة في الرؤية والوضوح.
عندما يكتب الوكيل ثلاثة أسطر من كود الإنتاج، فقد يكون قد قرأ ثلاثة ملفات وشغل الاختبارات. أو قد يكون قد عبث بأربعين ملفاً غير ذي صلة، ونفذ عشرات الأوامر الفاشلة، وتخطى مجموعة الاختبارات الخاصة بك لأن تثبيت التبعيات قد تعطل، ثم حاسبك على هذه الامتيازات. يبدو الـ diff متطابقاً في كلتا الحالتين. وبدون سجل يوضح مسار العمل، ستظل تخمن جودة النتيجة النهائية.
لماذا لا تُعد سجلات الدردشة بمثابة إيصالات
تقدم العديد من الأدوات نص المحادثة كدليل على العمل. لكن نص المحادثة ليس إيصالاً؛ بل هو صندوق من القطع المبعثرة على مكتبك. فهو يحتوي على كل حلقة تفكير، وكل محاولة فاشلة، وكل أمر نظام (system prompt)، وكل استدعاء غير ذي صلة للأدوات. إذا كنت بحاجة لقراءة ألف سطر من المحادثة للتحقق من رقعة برمجية (patch) مكونة من ثلاثة أسطر، فإن سير عمل المراجعة لديك معطل بالفعل.
الانتباه البشري محدود. الهدف من وجود الوكيل هو توفير الجهد الإدراكي، وليس توليد واجبات منزلية. يطلب نص المحادثة من المراجع أن يتحول إلى محقق، بينما يمنحه الإيصال الإجابة بنظرة واحدة.
الإيصال المفيد هو ملخص عملي. يخبرك بما طُلب من الوكيل فعله، وما فعله حقاً، وكيف توصل إلى استنتاجه. هو لا يخفي الفشل، بل يسلط الضوء عليه.
كيف يبدو الإيصال الجيد
يجب أن يجيب الإيصال القابل للمراجعة على أسئلة محددة دون الحاجة للبحث العميق:
- ما هي المهمة؟ وصف واضح للتغيير المقصود، وليس مجرد تكرار غامض للأمر (prompt).
- ما هي الملفات التي تمت قراءتها؟ حتى تتمكن من الحكم ما إذا كان الوكيل قد بنى سياقه من المصادر الصحيحة.
- ما هي الملفات التي تم تعديلها؟ الأثر النهائي للتغيير.
- ما هي الأوامر التي تم تشغيلها؟ خطوات البناء، أو أدوات التدقيق (linters)، أو أدوات التنسيق (formatters)، أو السكربتات المخصصة التي استدعاها الوكيل.
- ما هي الأوامر التي فشلت؟ ليس النجاح فقط؛ فالفشل يكشف الأماكن التي اضطر فيها الوكيل للارتجال أو الأماكن التي استسلم فيها.
- ما هي الاختبارات التي نجحت أو تم تخطيها؟ الاختبارات المتخطاة هي علامة خطر. يجب أن يوضح الإيصال سبب تخطيها.
- ما هي التكلفة الإجمالية؟ الـ tokens، واستدعاءات الـ API، ووقت الحوسبة. يشمل ذلك تكلفة بنيتك التحتية، وليس فقط تكلفة النموذج.
يحول هذا التنسيق عملية المراجعة من عملية تنقيب أثرية إلى فحص سريع للسلامة. يجب أن يكون المهندس الخبير قادراً على مسح الإيصال وقول "هذا منطقي" أو "هذا يبدو مريباً" في أقل من دقيقة.
اقرأ الأثر، وليس التاريخ فقط
يوضح أثر تشغيل الوكيل شكل العمل المنجز. هل التزم الوكيل بحدود التذكرة (ticket)؟ أم أنه تاه في وحدات (modules) غير ذات صلة وغير أشياء لم يطلبها أحد؟ الإيصال الذي يسرد "الملفات المعدلة" جنباً إلى جنب مع "الملفات المقروءة" يجعل هذا الأمر واضحاً.
يكشف الأثر أيضاً عن التكرار. الوكيل الذي يستمر في الاصطدام بنفس الطريق المسدود — مثل قراءة نفس ملف الإعدادات ثلاث مرات، أو تشغيل الاختبار الفاشل مراراً وتكراراً — يهدر موارد الحوسبة ونافذة السياق (context window). يجب أن يكون هذا النمط مرئياً. إذا استغرق الوكيل تسع محاولات لتشغيل سكربت ترحيل (migration script)، فيجب أن يذكر الإيصال ذلك. هذه المعلومات تغير طريقة تقييمك للمخرجات. فالـ diff "الصحيح" الناتج عن فوضى القوة الغاشمة ليس هو نفسه الـ diff الصحيح الناتج عن عملية نظيفة.
التكلفة الخفية للتصميم السيئ
التكلفة ليست مجرد السعر لكل توكن. سير العمل المصمم بشكل سيئ يجعل الوكيل مكلفاً حتى قبل أن يولد حرفاً واحداً. مخططات الأدوات المتضخمة، وفهرسة الملفات غير الضرورية، والأوامر النظامية (system prompts) الواسعة للغاية، كلها تزيد من استهلاك نافذة السياق. يجب أن يكشف الإيصال عن هذا العبء الإضافي.
إذا أصبح التوليد أرخص ولكن المراجعة أصبحت أصعب، فلن تكون قد كسبت شيئاً؛ بل قمت فقط بنقل عنق الزجاجة. وقت المهندسين هو عادةً أندر مورد في الفريق. توفير خمسة دولارات في تكاليف الـ API مقابل إضافة ثلاثين دقيقة من وقت المراجعة لكل طلب سحب (pull request) هو مقايضة سيئة للغاية. يساعدك الإيصال على تدقيق هذه المقايضة مباشرة.
الصدق ميزة
يجب أن يكون الإيصال المفيد مزعجاً عند الضرورة. يجب أن يبلغ عن الحقائق التي تجعل الوكيل يبدو غير فعال، لأن تلك الصراحة تجعل القرار البشري التالي أسرع وأفضل.
الأمثلة تهم:
- "قرأ 37 ملفاً من أجل تغيير في سطر واحد فقط."
- "تخطى الاختبارات لأن
npm installفشل بسبب تعارض في التبعيات المتزامنة (peer dependency conflict)." - "عدّل
utils.pyخارج النطاق المطلوب لإصلاح عملية استيراد (import) أدخلها الوكيل." - "شغّل أداة التدقيق (linter) 4 مرات؛ فشلت المرات الثلاث الأولى بسبب خطأ في تكوين المسار."
هذه ليست أخطاءً في الإيصال (receipt). بل هي إشارات. فهي تخبر المراجع أين يجب أن يركز شكوكه. كما تخبر فريق المنصة بالمواضع التي تحتاج فيها سير العمل (workflow) إلى ضبط وإحكام.
عمليات تشغيل أصغر، وإشراف أوضح
هناك إغراء طبيعي لترك الوكلاء (agents) يعملون بحرية مطلقة عبر مساحات واسعة. قد يبدو استخدام أمر (prompt) واحد ضخم لإعادة هيكلة (refactor) خدمة كاملة أمراً سريعاً، لكنه ليس كذلك؛ فهو يخلق كتلة من العمل غير قابلة للمراجعة. ستضيع فترة ما بعد الظهر في تتبع أي من الملفات الثمانين التي تغيرت كانت مقصودة.
عمليات التشغيل الصغيرة والقابلة للفحص هي الأفضل. حدد حدوداً واضحة للمهمة. افصل بين قائمة الملفات التي يمكن للوكيل قراءتها وقائمة الملفات التي يمكنه الكتابة فيها. سجل تاريخاً للأوامر الفاشلة لتكون المسارات المسدودة مرئية. ضع علامة صريحة على عمليات التحقق التي تم تخطيها. ودون كل استخدام للأدوات الخارجية، بدءاً من واجهات برمجة تطبيقات البحث (search APIs) وصولاً إلى مشغلات الاختبار (test runners).
الهدف ليس الاستقلالية الكاملة. فالاستقلالية الكاملة التي لا يمكن لأي بشر التحقق منها ليست سوى أتمتة محفوفة بالمسؤولية. الهدف الحقيقي هو قابلية المراجعة. يجب أن يكون من السهل الموافقة على كل مخرج للوكيل أو رفضه. يجب ألا تكون هناك منطقة رمادية غامضة تقبل فيها الكود لمجرد أنك متعب جداً من البحث والتحري.
الاختبار لأي وكيل برمجي
قبل اعتماد أي وكيل أو منصة، اطرح سؤالاً واحداً: هل يمكنه ترك أدلة كافية تتيح للإنسان الموافقة على الخطوة التالية بثقة؟
إذا كانت الإجابة نعم، فإن الأداة تتناسب مع سير العمل الاحترافي. أما إذا كانت الإجابة لا، فأنت لا تشتري الإنتاجية، بل تشتري لغزاً يعمل (compiles) أحياناً. قد يكون هذا مقبولاً في مشروع جانبي خلال عطلة نهاية الأسبوع، لكنه غير مقبول في هندسة الإنتاج (production engineering).
الفرق التي تتعامل مع مخرجات الوكلاء كأنها هدايا غير مفحوصة ستنتهي في المطاف بإطلاق خطأ برمجياً خفياً ناتجاً عن توسع غير مكتشف في نطاق العمل (scope creep). سيبدو الفرق (diff) بريئاً، بينما كان الإيصال (receipt) ليقول الحقيقة.
اطلب الإيصالات. صمم من أجل المراجعة. الثقة ليست استراتيجية، بل الأدلة هي الاستراتيجية.
للمزيد من المناقشات العملية حول أدوات الذكاء الاصطناعي وسير عمل المطورين، يمكنك الانضمام إلى المجتمع عبر GyaanSetu on Telegram.