أهم نقاش حول AI هذا الأسبوع لا يتعلق بإطلاق نموذج جديد. السؤال الحقيقي هو لماذا يعطي LLM نفسه مسودة مفيدة لشخص، وأخطاء واثقة لشخص آخر، وطريقاً أسرع إلى منتج لا يستطيع الفريق إطلاقه بعد.

خبير يوجه لوحات AI كأدوات مع قوائم تحقق واختبارات وسياق عمل

النقاشات التي صعدت على Hacker News حول “LLMs reward expertise” وcognitive debt وAI Productivity Gap تشير إلى درس عملي واحد: AI يزيد قدرة الناس على الإنتاج، لكن الجودة لا تزال تعتمد على خبرة المجال، والتحقق، وفهم النظام.

Prompting ليس مجموعة عبارات سحرية. الخبير يعرف أي تفصيل يغير المشكلة، وأي مصطلح يفتح الطريق الصحيح، وأين يهلوس النموذج، وأي جواب يبدو معقولاً لكنه خاطئ. AI لا يلغي الخبرة؛ بل يجعلها نقطة الرفع.

المبتدئون يستفيدون، لكن بحدود

يساعد AI المبتدئين في النماذج الأولية، والمسودات، والشرح، والاستكشاف. تظهر الحدود عندما تخرج المهمة من مسار الدروس. عندها نحتاج إلى مفردات المجال، ومعايير الجودة، ومعرفة النشر، والأمن، والصيانة، ومعنى “done”.

لذلك لا ينبغي للشركات منع juniors من AI. الأفضل هو scaffolding: أمثلة، checklists للمراجعة، بيئات آمنة، قواميس مجال، evals وتوجيه من mentors. مع feedback يسرع AI التعلم؛ وبدونه قد يخفي الفجوات.

Cognitive debt تكلفة حقيقية

عندما يكتب agent تغييراً كبيراً ويقبله الإنسان بعد review سطحي، يظهر الكود قبل أن يفهمه أحد. يقترح Ankur Sethi أن يعرض LLM التعديلات ثم يكتبها الإنسان أو يعيد صياغتها يدوياً للحفاظ على mental model. ليس على كل فريق فعل ذلك حرفياً، لكن المبدأ مهم: الفهم جزء من الناتج.

الوضع السريع مناسب للمهام الميكانيكية والقابلة للاختبار. أما core logic، والأمن، وbilling، وmigrations، والعمارة، والتعلم فتحتاج إلى وضع يحافظ على الفهم. يجب أن يستطيع المسؤول شرح التغيير والاختبارات وحالات الفشل وسبب ملاءمته للنظام.

فجوة الإنتاجية هي الاختناقات

تسريع كتابة الكود لا يعني تسريع تسليم المنتج بالقدر نفسه. المتطلبات، التصميم، المراجعة، الاختبار، CI، النشر، التنسيق وحكم المنتج تبقى اختناقات. وقد يزيد AI حجم المواد التي تحتاج إلى review.

لذلك عدد الأسطر، وعدد PR، وحجم tokens مقاييس ضعيفة. الأفضل قياس النتائج المتحققة: مشاكل عملاء محلولة، دورة أقصر إلى الإنتاج، عيوب أقل، تحليل صحيح أسرع، وتوثيق أفضل.

الممارسات القديمة تعود كممارسات AI

حالة refactoring التي وصفها Martin Fowler توضح أن البنية مهمة. في تطبيق من 150,000 سطر كتبته agents، وصل ملف Rust واحد لطبقة البيانات إلى 17,155 سطراً. بعد refactoring انخفضت input tokens لتغيير تمثيلي من 159,564 إلى 27,360، أي 83%. لكن الاستراتيجية احتاجت إلى توجيه بشري.

للفرق غير التقنية، النظير هو نظافة workflow. من دون معايير واضحة ينتج AI المزيد من الفوضى: رسائل sales غير متسقة، بنود قانونية مرتجلة، سياسات دعم مختلطة، وتحليلات جميلة لكنها خاطئة.

قائمة عملية

قِس throughput النتائج لا حجم المخرجات. اجعل القرار النهائي مملوكاً لإنسان. أبقِ التغييرات صغيرة. استخدم agents للمهام المحدودة والقابلة للاختبار. ضع افتراضات المجال في وثائق واختبارات وأمثلة دائمة. أنشئ evals قبل التوسع. راقب review burden وcognitive debt. احمِ مسار تعلم juniors.

دخل AI مرحلة ما بعد العرض التجريبي. لم يعد السؤال هل يستطيع النموذج الإنتاج؛ يستطيع. السؤال هو من يستطيع جعله ينتج الشيء الصحيح في السياق الصحيح من دون خلق دين معرفي لبقية الفريق.