وكيل ذكاء اصطناعي ظلّ يعمل في حلقة متواصلة 40 ساعة: كيف ندمج الذكاء الاصطناعي في التطوير دون تراجعات

غالباً ما تنحصر النقاشات حول الحاجة إلى المطورين في عصر «البرمجة بالإحساس» (vibe coding) في العواطف. أما كاتب هذا التحليل على Habr فيعرض بدلاً من ذلك ما يحدث عملياً حين يُسلَّم الوكيلُ مهمةً من دون أي إطار.

أين تتعثر البرمجة بالإحساس

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

لكن سوء جودة الكود ليس حتمياً. ففي العرض التجريبي للتطبيق المصرفي DemoBank حدّد المؤلف متطلبات للأداء وإعادة استخدام الميزات ونظام التصميم، وتعمّد ألا يملي البنية المعمارية. فكانت النتيجة بنية معيارية (modular) قائمة على مبدأ feature-first مع عناصر من Clean Architecture، واستخدام BLoC/Cubit لإدارة الحالة، مع الـ idempotency وآليات retry في طبقة الشبكة. وتعمل ميزة دفع الغرامات داخل التطبيق وكذلك بشكل مستقل، من دون جرّ تبعيات زائدة.

واختُبر الأداء على جهاز realme RMX3760 حقيقي منخفض التكلفة: ففي تمرير لمدة دقيقة شمل 12 000 عملية، بلغت نسبة الإطارات التي تجاوزت ميزانية 16.7 ملّي ثانية 0.25% مقابل معيار أقل من 1%. ويشير المؤلف بأمانة إلى أن الأمر يخص جهازاً واحداً وسيناريو واحداً.

السرعة لا تعني الجاهزية

استغرق DemoBank نحو 27 ساعة من العمل التراكمي لـ Codex ونحو 19 ساعة من الوقت الفعلي مع احتساب التوازي، إضافة إلى 2–3 ساعات من عمل المؤلف نفسه. وكانت أكثر الأمور كلفةً عمليات تشغيل اختبارات الأداء على الهاتف. وينبغي أن يكون المقياس لدى الفريق ليس «ما مدى سرعة توليد الكود»، بل «كم يستغرق الأمر من تحديد المهمة حتى قبول التغيير»، بما في ذلك المراجعة والتعديلات.

الـ Harness وبوابة الجودة والمسؤولية

يقصد المؤلف بـ AI Harness بيئة عمل الوكيل: سياق المشروع، والأدوات، وقيود الإجراءات، والفحوص الآلية، وآلية تسليم النتيجة إلى الإنسان. وأبرز الأفكار:

• يجب أن تعمل الفحوص التي يتوقف عليها القبول تلقائياً وأن تمنع الدمج. أما عبارة «شغّل الاختبارات» في الـ prompt فلا تضمن ذلك.
• ينبغي تقييد حلقة «استمر حتى تنجح الفحوص». فقد ظل أحد مشاريع المؤلف يعمل 40 ساعة حتى أوقفه يدوياً. المطلوب حدود للوقت والمال، وعند تكرار الخطأ دون تقدّم يجب أن يتوقف الوكيل ويبلّغ بما جرّبه.
• بعد الإيقاف القسري ينبغي إصلاح العملية لا تعديل الكود فحسب: فربما فهم الوكيل المهمة خطأً، أو أن خريطة المشروع قديمة، أو أن النموذج ضعيف جداً.
• يجب أن يكون لكل قرار مسؤول واضح: فالسلوك يتفق عليه مدير المنتج والمحلل، وعقود الوحدة (module) يراجعها مالكها، أما تفسير الوكيل للمهمة فيطّلع عليه المطور قبل كتابة الكود.

السياق والعقود والمجالات

لا تضمن نافذة السياق الكبيرة الاستخدام الصحيح للمعلومات: فقد أظهرت دراسة Lost in the Middle أن الجودة تتأثر بموضع البيانات في السياق. لذلك لا بد من خريطة للوحدات وعقود محدّثة وسجلات ADR. ويقترح المؤلف حفظ عقد الـ API في مصدر واحد، مثل TypeSpec، وتوليد OpenAPI والتوثيق وكود العميل منه، مع التحقق من الاتساق في CI. وتُوسَم سجلات ADR القديمة بوسم superseded.

لكن العقد لا يغني عن الاختبارات السلوكية: فمفتاح الـ idempotency يمكن وصفه في المخطط (schema)، أما عدم حدوث استرداد مزدوج للأموال فلا يُتحقق منه إلا بسيناريو مستقل. مثال من التجارة الإلكترونية: مع خريطة مشروع سيئة قد يستدعي الوكيل واجهة API الخاصة بمزوّد الدفع مباشرة من وحدة الطلبات، فلا تدخل عمليات الاسترداد في سجل المدفوعات. وهنا يفيد DDD وقواعد معمارية تُفحص آلياً، إضافة إلى مراجعة من نموذج آخر.

ما العمل

القيود: هذه تجربة مؤلف واحد على مشاريع صغيرة ومن دون تدقيق مستقل للكود. لكن الاستنتاجات قابلة للنقل. ثبّتوا المتطلبات في مواصفات (OpenSpec وSpec Kit وBMAD وKiro)، واجعلوا بوابة الجودة إلزامية، وضعوا ميزانيات لحلقات الوكيل، وعيّنوا مسؤولين عن السياق. ينتقل دور المطور من كتابة الكود إلى وضع الأطر وقبول النتيجة.