33% فقط من المطورين يثقون بإجابات الذكاء الاصطناعي: كيف نُعلّم الوكيل العمل وفق المواصفات

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

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

كانت تلك القراءة تحمي قاعدة عمل، ولم يخبر أحد الوكيل بها. لهذا لا يثق بإجابات الذكاء الاصطناعي في استطلاع Stack Overflow لعام 2025 سوى 33% من المطورين. يقترح الكاتب حلاً هو العمل وفق المواصفات (SDD، أي spec-driven development): يُوصَف أولاً ما يجب أن تفعله الشيفرة، ثم تُكتب الشيفرة وتُتحقَّق مقابل هذا الوصف.

ويستخدم لذلك إطار العمل OpenSpec.

لماذا تخدعنا العروض التجريبية

في العروض التجريبية يبني الوكيل تطبيق CRUD أو يسرّع استعلام SQL خلال خمس دقائق. هذه المهمة بلا تاريخ، والنتيجة الصحيحة فيها واضحة. أما في النظام الحي فهناك عمليات تكامل وقواعد غير مدوَّنة في أي مكان: فالوكيل لا يعرف أي عميل يقرأ هذا الحقل. يستكمل الناقص بنفسه، فتأتي الشيفرة معقولة المظهر، لكنها ليست صحيحة بالضرورة.

تؤكد أرقام Stack Overflow 2025 ذلك. يستخدم 84% من المطورين الذكاء الاصطناعي أو ينوون استخدامه، لكن 33% فقط يثقون بدقة إجاباته، بينما لا يثق بها 46%. وأكثر الشكاوى، في 66% من الحالات، تتعلق بحلول شبه صحيحة لكنها ليست كذلك تماماً، ويقول 45% إن تصحيح الشيفرة المولَّدة يستغرق وقتاً أطول. ويصف مؤلفو تقرير DORA 2025 الذكاء الاصطناعي بأنه مضخِّم: فهو يعزّز نقاط القوة لدى الفرق القوية، ويفاقم المشكلات لدى الفرق الضعيفة.

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

مواصفات بدل تذاكر من سطر واحد

التذكرة المكوّنة من سطر واحد يملأ الوكيل فراغاتها بتخمينه، أما المواصفة الكاملة بقيودها وحالاتها الحدّية فيعمل بموجبها ضمن حدود مرسومة. ولدى GitHub Spec Kit نهج مشابه، وقد أُتيح للجمهور كمشروع مفتوح في سبتمبر 2025. شبّه مانفريد ريم، المشرف الرئيسي عليه، الوكيل بمتدرّب شديد الكفاءة وسريع، يحتاج إلى مواصفات فنية واضحة ومرشد.

OpenSpec إطار عمل خفيف: توجد المواصفات في المستودع بجوار الشيفرة بصيغة Markdown العادية. ويدعم أكثر من 30 أداة، منها Claude Code وCursor وGitHub Copilot. يتألف المجلد openspec/ من ثلاثة أجزاء: يصف specs/ كيف يعمل النظام حالياً، ويحفظ changes/ التغييرات المقترحة (proposal وdesign وtasks وفروق المتطلبات)، ويحمل config.yaml سياق المشروع الذي يُمرَّر إلى الوكيل عند إنشاء المخرجات.

تُكتب المتطلبات بالكلمات المفتاحية SHALL/MUST وبسيناريوهات GIVEN/WHEN/THEN. فمثلاً في حالة الاسترداد الجزئي: يجب ألا يتجاوز مجموع المبالغ المستردة للطلب المبلغ المدفوع (MUST NOT)، ولا ينشئ الطلب المتكرر بمفتاح التكرار الآمن (idempotency key) نفسه عملية استرداد ثانية. وتتألف الدورة من ثلاثة أوامر: ينشئ /opsx:propose الخطة وتُراجَع قبل كتابة الشيفرة؛ وينفّذ /opsx:apply المهام؛ ويدمج /opsx:archive الفروق في المواصفات الرئيسية. وتبدأ المهمة التالية عندئذ بصورة محدَّثة عن النظام.

السياق والثوابت والمهارات

يصل الوكيل إلى المشروع في كل مرة كأنه موظف جديد في يومه الأول، لذا ينبغي الاحتفاظ بوصف للنظام بجوار الشيفرة: حدود المنتج، وعمليات العمل، ومسارات CI/CD، والمسرد، والثوابت، أي القواعد التي لا يجوز خرقها في أي عملية إعادة هيكلة. وهذه الأخيرة أكثر ما يُستهان به، ومنه جاءت قصة المرتجعات. ويعالج المسرد مشكلة مشابهة: يكتب المحلل «إلغاء»، بينما توجد في الشيفرة Refund وReversal وCancellation، وبلا قاموس سيختار الوكيل عشوائياً. ويقترح الكاتب إدراج تحديث السياق في Definition of Done على قدم المساواة مع الاختبارات.

المهارات (skills) تعليمات قابلة لإعادة الاستخدام، مثل «كيف نكتب الترحيل (migration) لدينا» أو «كيف تُراجَع طلبات الدمج PR». تقابل مهارة review-against-spec كل سيناريو في الفروق بالشيفرة والاختبارات، وتتحقق من أن الثوابت لم تُضعَف، وتُصدر قائمة بالتباينات دون إجراء تعديلات من تلقاء نفسها. وعندما نطلب من الوكيل «انظر هل كل شيء على ما يرام»، يجيب عادةً بأن كل شيء على ما يرام، أما قائمة التحقق فتُلزمه بالبحث. وتبقى الكلمة الأخيرة في المراجعة للإنسان.

الناس وحلقة الأخطاء

المواصفات لا تحل محل الكفاءة: يرى المطوّر المبتدئ شيفرة تُترجَم وتجتاز الاختبارات، بينما يرى فيها المطوّر الخبير حالة تسابق أو ثابتاً منتهكاً. ومن العلامات المقلقة وجود موظف «وسيط» يحيل التذكرة إلى الوكيل ثم يرسل النتيجة إلى المراجعة دون أن يقرأها. عندها يقع عبء التحقق كله على قائد الفريق ويصبح عنق زجاجة. ويلزم أثناء فترة الاعتماد مرشد يملك خبرة في SDD: يضبط القواعد والمهارات، ويعلّم الفريق كتابة المواصفات ومراجعة الشيفرة التي يولّدها الذكاء الاصطناعي. ويشبّهه الكاتب بـScrum Master: دوره مؤقت، لكن المنهجية من دونه تذوب في عبارة «لدينا Cursor أصلاً».

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

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