قيّم قبل أن تبني: دليل المطوّر للبرمجة المنضبطة بالذكاء الاصطناعي

مساعد البرمجة بالذكاء الاصطناعي (Vibe Coding) كتب لك خدمة خلفية تعمل خلال ساعتين. العرض التوضيحي بدا ممتازاً. العميل وقّع على التسليم. بعد ثلاثة أشهر، فريقك يطارد عطلاً سبّبه كودٌ لم يفهمه أحد بالكامل — لأن أحداً لم يسأل ماذا تعني عبارة "جاهز للإنتاج" قبل الموجِّه (prompt) الأول.

هذه فجوة الإنتاج. ليست مشكلة أداة. مشكلة تفكير.

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

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

الإطار: قيّم، حلّل، ابنِ

أغلب المطوّرين يبدؤون جلسة البرمجة بالذكاء الاصطناعي بموجِّه شبيه بهذا:

"ابنِ لي واجهة برمجية (API) تتصل بمزوّد المدفوعات وتعالج عمليات الاسترداد."

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

الحل ثلاث مراحل، مرتّبة:

التقييم — أنت تقود. الذكاء الاصطناعي ينتظر. تجيب عن ستة أسئلة تحدّد حدود ما سيُبنى.

التحليل — أنت والذكاء الاصطناعي تتعاونان. تبحثان في الأنماط، تقارنان الخيارات، تكشفان المفاضلات.

البناء — الذكاء الاصطناعي يقود. أنت تراجع. الكود الذي يُنتَج الآن يعكس قراراتك، لا تخمينات الذكاء الاصطناعي.

مرحلة التقييم كاملة تستغرق عشر دقائق. تحلّ محلّ شهور من الديون التقنية المتراكمة.

الأسئلة الستة

قبل أن تكتب موجِّهاً واحداً يولّد كوداً، أجب عن هذه الأسئلة:

1. ما الغرض؟ ليس ما الذي يفعله — لماذا يوجد. "معالجة الاسترداد" ميزة. "تقليل تذاكر الدعم بتمكين العملاء من استرداد المبالغ تحت 50 دولاراً ذاتياً" غرض. الذكاء الاصطناعي لا يستطيع معرفة هذا. أنت تعرفه.

2. ما الموجود مسبقاً؟ ما الأنماط والأدوات والاتفاقيات الموجودة في الكود الحالي؟ ما الذي يجب إعادة استخدامه؟ ما الذي يجب تجنّبه؟ إذا تجاوزت هذا السؤال، الذكاء الاصطناعي سيعيد اختراع ما هو موجود — أو الأسوأ، سيُدخِل نمطاً متعارضاً.

3. ما المخاطر؟ ما الذي يتعطّل إن فشل هذا الكود؟ ما البيانات الحسّاسة؟ ما الحالات الحدّية المهمّة؟ واجهة استرداد لا تتعامل مع التكرار الآمن (idempotency) سترُدّ المبلغ مرّتين للعميل نفسه. الذكاء الاصطناعي لن يفكّر في ذلك ما لم تفكّر أنت أولاً.

4. ما البدائل؟ هل الواجهة البرمجية هي المقاربة الصحيحة، أم يجب أن تكون مهمّة في الخلفية؟ هل تستدعي المزوّد مباشرة، أم تمرّ عبر طبقة خدمات قائمة؟ البدائل تُجبرك على تبرير المقاربة قبل الالتزام بها.

5. كيف يبدو النجاح؟ ليس "أنّه يعمل" — معايير محدّدة. زمن استجابة أقل من 200 مللي ثانية. منطق إعادة محاولة عند انتهاء مهلة المزوّد. سجلّ تدقيق لكل عملية. هذه المعايير تصبح قائمة المراجعة بعد أن يولّد الذكاء الاصطناعي الكود.

6. ماذا يجب أن نحفظ؟ أيّ قرارات أو مفاضلات أو دروس من هذه الجلسة يجب توثيقها للمطوّر التالي (أو الجلسة التالية مع الذكاء الاصطناعي) الذي يلمس هذا الكود؟

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

الشرح التفصيلي: بناء تكامل مدفوعات

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

المرحلة الأولى: التقييم (أنت تقود — 10 دقائق)

تفتح مشروعك. قبل كتابة أي تعليمة بناء، تبدأ بنقطة التدقيق.

تخبر المساعد: "أحتاج إلى بناء مسار لمعالجة عمليات الاسترداد. قبل أن نكتب أي كود، أريد أن نمرّ بنقطة التدقيق ما قبل البناء."

المساعد المُهيَّأ جيّداً يطرح عليك الأسئلة الستة. أنت تجيب:

الغرض: استرداد ذاتي للطلبات تحت 50 دولاراً، بهدف تقليل حجم الدعم بنسبة 30% تقريباً.

الموجود مسبقاً: المشروع فيه غلاف لخدمة المدفوعات في مجلد الخدمات. هناك نمط وسيط برمجي للمصادقة. الفريق يستخدم تنسيق أخطاء موحّداً عبر كل مسارات الواجهة البرمجية.

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

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

معايير النجاح: آمن للتكرار (الطلب نفسه مرّتين = استرداد واحد). معالجة المهلة باحتياطي غير متزامن. سجلّ تدقيق لكل محاولة. زمن استجابة أقل من 500 مللي ثانية للمسار المتزامن. يستخدم تنسيق الأخطاء القائم والوسيط البرمجي للمصادقة.

نحفظ: نوثّق نمط الاحتياطي عند انتهاء المهلة — هذا النمط سينطبق على كل تكامل مزوّد سنبنيه.

عشر دقائق. لا كود بعد. لكن كل قرار معماري قد اتُّخِذ.

المرحلة الثانية: التحليل (تعاون — 5 دقائق)

الآن تُدخِل الذكاء الاصطناعي شريكاً للبحث:

"انظر إلى غلاف خدمة المدفوعات الحالي ووسيط معالجة الأخطاء. أرني كيف تعمل الأنماط الحالية لنطابقها."

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

المرحلة الثالثة: البناء (الذكاء الاصطناعي يقود، أنت تراجع)

الآن — وفقط الآن — تُعطي تعليمة البناء. لكنّها ليست موجِّهاً غامضاً بعد الآن. هي محدّدة:

"ابنِ مسار إرسال (POST) لمعالجة الاسترداد. استخدم غلاف خدمة المدفوعات الحالي. طبّق وسيط المصادقة. اجعله آمناً للتكرار باستخدام معرّف الطلب مفتاحاً. إذا انتهت مهلة المزوّد بعد 5 ثوانٍ، أدخِل الاسترداد كمهمّة خلفية وأرجِع الرمز 202 مع معرّف تتبّع. سجّل كل محاولة في جدول التدقيق. اتّبع تنسيق الاستجابة للأخطاء القائم."

كل قرار من المرحلة الأولى مُرمَّز في الموجِّه. الذكاء الاصطناعي لا يخمّن. هو ينفّذ معماريّتك.

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

النمط المضاد: المهمّة نفسها، بلا نقطة تدقيق

للمقارنة، إليك المهمّة نفسها مكتوبة بأسلوب البرمجة بالذكاء الاصطناعي بلا نقطة تدقيق:

"ابنِ لي مسار واجهة برمجية للاسترداد."

الذكاء الاصطناعي يولّد مساراً يعمل. يعالج الاسترداد. العرض التوضيحي ينجح. لكن:

• يُنشئ عميل دفع جديداً بدلاً من استخدام الغلاف القائم — الآن هناك طريقتان للتحدّث مع المزوّد، وكل منهما يعالج الأخطاء بطريقة مختلفة.
• لا أمان للتكرار. إعادة محاولة من الواجهة الأمامية تردّ المبلغ مرّتين. تكتشف ذلك من فريق المالية، لا من سجلاّتك.
• مهلة المزوّد لا تُعالَج. المسار يعلّق 30 ثانية، موزّع الأحمال يقتله، العميل يرى خطأً عاماً، والاسترداد قد يكون نُفِّذ وقد لا يكون.
• لا أثر تدقيق. حين تسأل المالية "ماذا حدث للطلب رقم 4471"، لا أحد يستطيع الإجابة بدون التنقيب في سجلاّت المزوّد.

كل ثغرة من هذه الثغرات وُجِدت لأن أحداً لم يطرح الأسئلة الستة. الذكاء الاصطناعي فعل بالضبط ما طُلِب منه. المشكلة في ما لم يُطلَب.

اجعلها تلقائية: نقطة تدقيق ما قبل البناء

الأسئلة الستة تنفع على الورق. تنفع أكثر حين تُدمَج في سير عملك.

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

## نقطة تدقيق ما قبل البناء

قبل تنفيذ أي ميزة جديدة أو تغيير جوهري، اطرح عليّ
هذه الأسئلة وانتظر إجاباتي قبل توليد الكود:

1. ما غرض هذا التغيير؟
2. أيّ كود أو أنماط قائمة يجب إعادة استخدامها؟
3. ما الذي قد يتعطّل؟ ما المخاطر؟
4. ما البدائل التي درسناها؟
5. كيف سنعرف أن هذا يعمل؟ (معايير النجاح)
6. ماذا يجب أن نوثّق للمرّة القادمة؟

لا تولّد كود التنفيذ حتى أُجيب عن الأسئلة الستة كاملة.

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

للنسخة التفاعلية الكاملة — مع مسح الكود، وخيارات قابلة للاختيار، وأسئلة مكيّفة لكل نوع قرار — المهارات الكاملة مفتوحة المصدر على github.com/jneaimi/evaluate-before-you-build.

الهرم الأوسع

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

لكن اتّساع المدخل لا يعني صمود الكود. المطوّرون الذين يبقون — الذين يُسلّمون منتجات تنجو من أوّل مئة مستخدم، وأوّل تدقيق أمني، وأوّل دورة استدعاء طارئ — هم من يقيّمون قبل أن يبنوا.

التفكير هو الانضباط. الذكاء الاصطناعي هو الأداة. لا تخلط أيّهما يحمل الحِمل.