كاتب على Habr يحدد خمسة قرارات يتخذها المهندس قبل أن يكتب الذكاء الاصطناعي الكود

من أكثر الأخطاء إزعاجًا في منطق الدفع أنه يبدو بريئًا: التحقق من أن العملية في حالة PENDING، ثم تحويلها إلى SUCCESS وإضافة المبلغ إلى الرصيد. إذا وصل طلبا webhook في وقت واحد، يرى كلاهما الحالة PENDING، ويجتاز كلاهما الفحص، فيحصل المستخدم على المبلغ مرتين. وقد عثر كاتب مادة حديثة على Habr على هذا الخطأ في سوق إلكتروني (marketplace) يخصه. وكان قد كتب الكود بنفسه، دون AI.

يستعين المؤلف بهذا المثال لطرح سؤاله الرئيسي: إذا كان الوكيل ينفّذ معالجًا كهذا خلال دقائق اليوم، فمن الذي يضع القيود غير الواردة في الوصف الوظيفي؟ بعد ذلك يحلل خمس حالات من سوق إلكتروني (marketplace) ومنصة متعددة العلامات التجارية، ويختم بقائمة تحقق من 12 سؤالًا ينبغي المرور عليها قبل توليد الكود.

أين تصمت المواصفات

يؤدي الوكيل بكفاءة ما هو موصوف له. فعبارة «عند نجاح webhook أضف المبلغ إلى الرصيد» تتحقق شكليًا في التنفيذ السليم وفي التنفيذ المعرَّض للثغرات على حد سواء. ولا يظهر الفرق إلا تحت حمل متوازٍ، بينما لا يمكن رؤيته في الاختبارات التي تعمل في مسار تنفيذ واحد (thread).

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

يحدد المؤلف خمس مناطق تُتخذ فيها مثل هذه القرارات مسبقًا:

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

يورد المؤلف القائمة الكاملة المؤلفة من 12 سؤالًا في المقال الأصلي. وهنا تنبغي الإشارة إلى أن الإعلان عن المقال لا يتضمن تفاصيل القرارات، ولذلك يتناول ما يلي الطريقة التي تُعالَج بها هذه المشكلات عادةً في القطاع، لا استنتاجات المؤلف.

كيف تُحَل هذه المشكلات عادةً

بالنسبة إلى حالة webhook، فإن مجموعة الإجراءات المعتادة معروفة. مفتاح فريد للحدث أو مفتاح عدم التكرار (idempotency key) للطلب. وتحديث شرطي ذري من نوع «حوّل إلى SUCCESS فقط إذا كانت الحالة لا تزال PENDING» مع التحقق من عدد الصفوف المتأثرة. وقفل السجل طوال مدة المعاملة. وأي من هذه الإجراءات يحوّل «تحققتُ ثم كتبتُ» إلى عملية واحدة غير قابلة للتجزئة.

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

كيف نستخدم ذلك عمليًا

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

ومن المفيد كذلك أن تطلبوا من الوكيل ألا يكتفي بكتابة الكود، بل أن يسرد الافتراضات التي وضعها بشأن التزامن وترتيب الأحداث. فالتباين بين افتراضاته وافتراضاتكم هو أسرع ما يكشف الثغرة في صياغة المهمة.

وأخيرًا، الاختبارات. تحتاج مسارات الدفع إلى اختبار واحد على الأقل بطلبات متزامنة، وإلا بقي التحقق من الصحة عند مستوى «يبدو صحيحًا». وهكذا كان يبدو المعالج في قصة المؤلف: بدا منطقه سليمًا، ولم يتعطل إلا عند حدوث تعارض زمني (race condition).

وتنطبق خلاصات المادة على الكود الذي يكتبه الإنسان أيضًا. فالذكاء الاصطناعي يسرّع التنفيذ، لكن القرارات المتعلقة بثوابت النظام (invariants) لا يزال لا بد من اتخاذها قبله، والمهندس هو من يتخذها.