كيف أُطلق شيفرة الإنتاج بفريق من وكلاء الذكاء الاصطناعي

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

على منصة تداول في بيئة الإنتاج، لا تكفي عبارة «يبدو صحيحًا». لذلك لا أستخدم مساعدًا واحدًا للذكاء الاصطناعي، بل أشغّل منهجية صغيرة من الوكلاء المتخصصين، لكلٍّ منهم مهمة واحدة وقواعد مكتوبة، ولا يحقّ لأي منهم تقييم عمله بنفسه. إليك كيف يعمل ذلك.

المنهجية في لمحة

1. تُحدَّد التذكرة انطلاقًا من عقد الواجهة البرمجية.
2. يبنيها وكلاء التنفيذ بالتوازي، كلٌّ في مساحة عمل git خاصة به.
3. تعمل بوابات صارمة قبل أي دفع للشيفرة.
4. يحاول وكيل مراجعة هجومي كسر التغيير.
5. تستمر حلقة مراجعة بالذكاء الاصطناعي حتى لا تبقى أي ملاحظة.
6. أراجع وأعتمد.

كل خطوة موجودة لأن شيئًا ما فشل في غيابها.

1. العقد هو المرجع

يكتب البشر التذاكر، والبشر غامضون. أما عقد OpenAPI فليس كذلك. يقرأ كل وكيل العقد من الفرع نفسه الذي يعمل عليه، لا من النسخة التي صادف وجودها على الجهاز. وعندما يختلف نص التذكرة عن العقد، يفوز العقد.

هذه القاعدة وحدها تزيل فئة كاملة من الأخطاء: أدوات تحقق تنحرف عن الواجهة الحقيقية، وقيم تعداد شبه صحيحة، وحقول اختيارية في مكان وإلزامية في مكان آخر.

2. وكلاء التنفيذ في مساحات عمل معزولة

أشغّل وكيلي تنفيذ في الوقت نفسه، ولكلٍّ منهما مساحة عمل git خاصة به. لا يتشاركان أبدًا مجلد العمل نفسه، فلا يتداخلان في الملفات، وأستطيع مراجعة تذكرتين بالتوازي دون فوضى في الدمج.

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

3. لا شيء يُطلق وهو أحمر

قبل أي دفع، يجب أن تنجح كل البوابات:

• فحص الشيفرة على المستودع كاملًا
• الاختبارات الوحدوية في كل مساحات العمل، لا في تلك التي عدّلتها فقط
• بناء نسخة الإنتاج
• اختبارات شاملة في متصفح حقيقي

«نجح فحص الشيفرة» خطوة واحدة، وليست البوابة كلها. يميل الوكلاء كثيرًا إلى إعلان النجاح مبكرًا، لذا فالبوابات مبرمجة وغير قابلة للتفاوض.

4. مراجِع مهمته كسر الشيفرة

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

• مدخلات غير موثوقة تُقرأ قبل التحقق منها
• بيانات مرتبطة بالمالك الخطأ، كنتيجة تصل بعد أن غيّر المستخدم حسابه
• أدوات تحقق تنحرف عن العقد
• الحدود والدقة: اختبار جانبي كل حدّ، والتوقّف عليه تمامًا
• واجهة تعرض حالة خاطئة أو تسرّبها

5. كل ملاحظة تحتاج إلى اختبار فاشل يعيد إنتاجها

هذه هي القاعدة التي تُبقي النظام كله متماسكًا. لا يستطيع المراجِع أن يقول فقط «يبدو هذا خاطئًا». يجب أن تأتي كل ملاحظة مع اختبار فاشل يعيد إنتاجها، إضافة إلى حالة ضابطة تثبت أن بيانات الاختبار نفسها صحيحة.

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

6. الاعتماد لكل تعديل على حدة

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

7. معرفة متى تتوقّف

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

ما الذي يمنحك إياه ذلك

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

إذا أردت إعداد منهجية كهذه لفريقك، لنتحدّث.