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

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

المشكلة غالباً ليست في الذكاء الاصطناعي. أنت لم تعطه ما يكفي ليعمل عليه.

الأمر الذي يدفع النموذج للتخمين

خذ أمراً بسيطاً:

Create a user authentication system for my app.

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

ما الذي على الذكاء الاصطناعي أن يخمّنه

• أي قاعدة بيانات. PostgreSQL أو MySQL أو Mongo — يتغيّر مع الجواب شكل الجداول والاستعلامات ونصف معالجة الأخطاء.
• أي واجهة خلفية. مشروع على Node وExpress ومشروع على Django يريدان شكلين مختلفين للخاصية نفسها.
• كيف بُني مشروعك أصلاً. أين تعيش الملفات، وما أسماء وحداتك، وأي أعراف تتبعها بقية الشيفرة.
• أي نوع من المصادقة تريد. جلسات أم رموز أم مزوّد خارجي — ثلاثة أنظمة مختلفة تحت كلمة واحدة.
• ما متطلّبات الأمان لديك. تعمية كلمات المرور، وأعمار الرموز، وكم يجب أن يكون مسار الدخول صارماً.
• ماذا يحدث عند الأطراف. تدوير رموز التحديث، والأدوار، وتحديد معدّل المحاولات — وهي التي تقرّر هل يصمد النظام أمام مستخدمين حقيقيين.

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

الطلب نفسه، لكن مصمَّماً

قارن ذلك بأمر مكتوب بعد تفكير حقيقي في النظام:

Build a JWT-based authentication system for my Node/Express + PostgreSQL app. The users table has email, hashed password, and role (admin/user). Implement signup, login, refresh-token rotation, and rate limiting for login attempts. Follow the existing project structure and keep authentication inside the "/auth" module. Don't use third-party authentication providers.

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

أمر ضعيف مقابل أمر مصمَّم

ما الذي يحسمه	«Create a user authentication system»	الصيغة المصمَّمة
التقنيات	متروكة للنموذج	Node/Express وPostgreSQL، منصوص عليهما
بنية البيانات	مُخترعة	بريد، وكلمة مرور معمّاة، ودور
النطاق	مفتوح	تسجيل، ودخول، وتدوير الرموز، وتحديد المعدّل
الانسجام مع شيفرتك	مُهمَل	البنية القائمة، وداخل وحدة «‎/auth‎»
ما يُستبعَد	لا شيء	لا مزوّدين خارجيين

العمود الثاني ليس أطول لمجرّد أن يكون أطول. كل سطر فيه قرار كان سيُتَّخذ من دونك.

كيف أتعامل مع الأمر الآن

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

ما الذي لن تبنيه

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

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

الذكاء الاصطناعي يمنحك سرعة هائلة. لكنه لا يعرف القرارات التي لم تتّخذها أنت.

فكّر في النظام أولاً، ثم دع الذكاء الاصطناعي ينفّذ.

فأيّهما تفعل — تصمّم قبل أن تكتب الأمر، أم تكتب وتأمل؟