السياق هو الـ prompt الحقيقي

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

اتضح أن الحل لا علاقة له تقريبًا بصياغة الطلب؛ بل بما يستطيع النموذج رؤيته لحظة الإجابة.

النموذج يكتب للمشروع الذي يراه فقط

النموذج اللغوي أمام نافذة سياق فارغة لا يكتب كودًا سيئًا؛ بل يكتب المتوسط الإحصائي لكل المشاريع التي تدرّب عليها. اطلب منه «endpoint يعيد مؤشرات المشغّلين» من دون سياق وستحصل على وسيط عشرة آلاف تدوينة: controller عام، وDTO مخترع في اللحظة، واستثناءات تُبتلع داخل try/catch، وترقيم صفحات مضاف كيفما اتفق.

مشروعك ليس ذلك الوسيط، ومشاريعي بالتأكيد ليست كذلك. منصة المؤشرات التي بنيتها لمشغّلي الاتصالات في عُمان كانت تفرض عقدًا صارمًا لشكل أخطاء التحقق؛ لأن أنظمة المشغّلين نفسها كانت تحلل تلك الاستجابات برمجيًا. غيّر الشكل وستكسر تكاملًا عند طرف آخر. عبارة «تصرّف كمهندس خبير» لن توصل هذه المعلومة مهما كرّرتها؛ أما لصق معالج الأخطاء والعقد نفسه فيوصلها فورًا.

النموذج بلا سياقك لا يكتب كودًا سيئًا؛ بل يكتب كودًا جيدًا يخص شخصًا آخر.

حين استوعبتُ ذلك، توقفت تقريبًا عن تلميع الصياغات وبدأت أتعامل مع كل طلب باعتباره مسألة سياق: ماذا يحتاج النموذج أن يرى لينتج كودًا يجتاز المراجعة هنا، في هذا المستودع، هذا الأسبوع؟

ما الذي يدخل نافذة السياق فعلًا؟

هذا ما أحمّله قبل أي طلب غير بديهي، مرتبًا تقريبًا حسب الأثر:

• مثالان أو ثلاثة من كود مشابه موجود. هذه أقوى أداة على الإطلاق. فقرة تقول «اتبع اصطلاحاتنا في معالجة الأخطاء» لا تفعل شيئًا تقريبًا؛ بينما معالج واحد مكتوب بالطريقة الصحيحة يفعل كل شيء تقريبًا.
• الواجهات الفعلية التي سيلمسها. الـ entity الحقيقي، وتوقيع الـ repository الحقيقي، وخدمة Angular الحقيقية؛ ملصوقة أو مفتوحة أمامه، لا موصوفة من الذاكرة. الواجهات الموصوفة تنحرف عن الواقع، أما الحقيقية فلا.
• قيود تُذكر كحقائق لا كرغبات. «نستخدم PostgreSQL 14». «Angular بمكونات standalone دون NgModules». «هذا يعمل داخل Docker بذاكرة 512MB، فلا تُحمّل ملف التصدير كله في الذاكرة». الحقائق تُحترم؛ أما الأمنيات الغامضة فيبتلعها المتوسط.
• ملف اصطلاحات يعيش داخل المستودع. التسمية، والطبقات، وكيف ننفذ الـ migrations، وما نسجّله في الـ logs وما لا نسجّله أبدًا. يُكتب مرة ويُحمّل في كل جلسة.
• الأنماط الممنوعة مع أسبابها. «لا تضف طبقة cache هنا؛ هذا الجدول يتغير كل خمس دقائق وقد اكتوينا بهذا من قبل». النماذج تأخذ السبب المذكور على محمل الجد بطريقة لا تأخذ بها القاعدة المجردة.

لاحظ الغائب في هذه القائمة: الصفات. لا شيء عن كونه خبيرًا، ولا شيء عن التفكير بعناية. كفاءة النموذج لم تكن يومًا عنق الزجاجة؛ بل ما يستطيع رؤيته.

عامله كموظف جديد، لا كعرّاف

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

هذه النظرة تغيّر سير العمل اليومي:

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

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

هندسة الـ prompt تحسّن السؤال؛ أما هندسة السياق فتحسّن ما يُسمح للإجابة أن تُبنى منه. واحدة فقط منهما تصلح لما هو أبعد من العرض التجريبي.