البرمجة بالتحسس مشروعة في سياق واحد بالضبط: حين تبني نموذجاً أولياً تنوي التخلص منه.
المشكلة أن معظم الأنظمة المبرمجة بالتحسس لا يُتخلص منها. تعمل. تتراكم فيها المستخدمون. تصبح النظام الذي يجب صيانته وتوسيعه وتصحيحه من قِبَل أشخاص لم يكتبوه ولا يستطيعون مطالبة الذكاء الاصطناعي بشرح قراراته في السياق. قاعدة الكود لا تعلم أنها كانت من المفترض أن تكون مؤقتة.
هذه ليست انتقاداً لاستخدام الذكاء الاصطناعي لتوليد الكود بسرعة. إنها وصف لما يحدث حين تُطبّق استراتيجية نموذج أولي على بيئة إنتاج.
ما هي البرمجة بالتحسس فعلاً
البرمجة بالتحسس هي توليد الكود بوصف النية، وقبول ما يبدو صحيحاً، والتكرار حتى ينجح شيء ما، دون قراءة كل سطر أو فهم كل قرار. حلقة التغذية الراجعة هي: هل يعمل، هل يبدو صحيحاً، هل تعمل الميزة في المسار السعيد. حين تكون الإجابة نعم، الكود يُشحن.
هذا النهج مفيد فعلاً لأغراض محددة. إثبات المفهوم لتحقيق التوافق مع أصحاب المصلحة. اختبار مسبار التصميم لمعرفة ما إذا كانت واجهة برمجة التطبيقات قابلة للاستخدام قبل الالتزام بالتكامل. استكشاف مهمَل لإطار عمل لم تلمسه من قبل. توليد الكود النمطي الذي سيُراجع سطراً بسطر قبل أن يصل أي منه إلى الإنتاج.
في جميع هذه الحالات، القطعة هي أداة تواصل أو جهاز تعلم، لا نظام إنتاج. شرط الخروج هو “هذا جيد بما يكفي لإجراء المحادثة”، لا “هذا جاهز للمستخدمين.”
حين تدخل الأنظمة المبرمجة بالتحسس الإنتاجَ دون إيضاح هذا التمييز صراحةً، تحمل ديوناً تتضاعف. القرارات التي لم تُتخذ بوعي تصبح قيوداً يرثها المهندس التالي. حالات الحافة التي لم تُفكَّر فيها قط تصبح الأخطاء التي تظهر في الساعة الثانية صباحاً.
مشكلة الحافة المتذبذبة على نطاق واسع
وكلاء البرمجة بالذكاء الاصطناعي ليسوا متساوي القدرة. يتفوقون في الأنماط المطروقة: نقاط نهاية CRUD، مكونات واجهة المستخدم، تحويل البيانات، الإعدادات النمطية. يفشلون بشكل غير متوقع في قرارات البنية الجديدة، إدارة الحالة عبر الأنظمة، حالات حافة الأمان، خصائص الأداء على نطاق واسع، والصواب الخاص بالمجال.
هذا التفاوت هو الحافة المتذبذبة. ثقة الوكيل موحدة حتى حين موثوقيته ليست كذلك. يكتب الكود المجاور للأمان بنفس النبرة التي يكتب بها دالة مساعدة. يتعامل مع نمط تزامن جديد بنفس اليقين الظاهر الذي يجلبه لكتابة حلقة for.
البرمجة بالتحسس تُضخّم الحافة المتذبذبة على نطاق واسع. نظام ينمو في الاتجاهات التي يتعامل معها الوكيل جيداً، وهي أيضاً الاتجاهات التي تبدو سلسة وسريعة، حتى يصطدم بحد لا يستطيع الوكيل التنقل فيه. بحلول ذلك الوقت، الحد مُدمَج في الإنتاج، محاط بكود بُني على افتراضات الوكيل الواثقة لكن الخاطئة.
الحافة المتذبذبة ليست سبباً لتجنب أدوات البرمجة بالذكاء الاصطناعي. إنها سبب للحفاظ على إشراف بشري عند النقاط المحددة حيث تنخفض موثوقية الوكيل: قرارات الأمان، المسارات الحرجة للأداء، منطق المجال الجديد، الحالة عبر الأنظمة.
النموذج الوكيلي وانضباطه
وُصفت البرمجيات من حيث نماذج برمجة متعاقبة. الأول: تعليمات صريحة كتبها البشر للتنفيذ الحتمي. الثاني، الذي وصفه Karpathy بـ Software 2.0: سلوك مُترجَم إلى أوزان شبكة عصبية من البيانات والأهداف، حيث البرنامج في الأوزان لا في الكود المكتوب بشرياً.
الثالث، ما يُسمى النموذج الوكيلي، يمتد هذا أكثر: أنظمة يقع البرنامج فيها بشكل متزايد في الموجّه والسياق والأدوات، مع نموذج لغوي كبير كبيئة تشغيل. قاعدة الكود لا تزال كوداً، لكن سلوك النظام يتشكل بالسياق بقدر ما يتشكل بالتعليمات.
البرمجة بالتحسس هي هذا النموذج بدون انضباط. الموجّه يحل محل المواصفة. النموذج اللغوي الكبير يحل محل المهندس المعماري. شعور “إنه يعمل” يحل محل مجموعة الاختبارات.
الهندسة الوكيلية تُطبّق انضباطاً على نفس النموذج: مواصفة صريحة قبل التوليد، معايير قبول قابلة للتحقق، تغطية اختبارات يمتلكها البشر لا تُفوَّض لحكم الوكيل، قابلية الرصد قبل الإطلاق، بوابات مراجعة بشرية عند نقاط القرار المعماري.
الانضباط لا يُبطئ النموذج. إنه ما يجعل النموذج جديراً بالثقة على نطاق الإنتاج.
ما تُضيفه الهندسة الوكيلية
الهندسة الوكيلية ليست برمجة بالتحسس بشكل أسرع. إنها نفس توليد الكود المدعوم بالذكاء الاصطناعي مع العناصر التي تتخطاها البرمجة بالتحسس مُطبَّقة بتعمد.
تعريف النطاق: ما سيبنيه الوكيل، وما لن يبنيه، والملفات التي سيلمسها وتلك التي لن يلمسها. هذا الحد يمنع التشعب الذي يجعل الأنظمة المبرمجة بالتحسس غير قابلة للصيانة.
كشف الافتراضات: الوكيل يذكر تفسيره قبل تطبيقه. توضيح لثلاثين ثانية قبل أول كتلة كود يمنع إعادة عمل لساعتين بعدها.
عزل الـ worktree: الوكيل يعمل في فرع، لا على main. الفرق مرئي وقابل للمراجعة قبل أن يقبله أي إنسان.
انضباط الاختبار أولاً: اختبار القبول يُعرَّف قبل بدء التنفيذ. الاختبار هو العقد بين ما طُلب وما سُلِّم.
مراجعة تنافسية قبل الدمج: تمرير ثانٍ، قبل وصول التغيير إلى الإنتاج، حول ما يمكن أن يسوء. ليست بوابة بيروقراطية. بحث منظم عن نمط الإخفاق الذي لم يفكر فيه أحد في مرحلة التخطيط.
قابلية الرصد من اليوم الأول: السجلات والتنبيهات مُضبَّطة قبل طرح الميزة للمستخدمين، لا بعد وصول أول تقرير خطأ.
خطة التراجع: قبل النشر، هناك إجابة صريحة على “ماذا نفعل إذا فشل هذا في الإنتاج؟”
الفرق التي تمارس الهندسة الوكيلية تشحن أسرع من المبرمجين بالتحسس في الشهر الثاني والثالث وما بعده. ليس لأن الهندسة الوكيلية تُنتج كوداً أكثر في الساعة. لأنها تُنتج إعادة عمل أقل في الشهر.
حين تكون البرمجة بالتحسس الأداة الصحيحة
الاستخدامات المشروعة حقيقية وتستحق التسمية.
مسبار التصميم: تحتاج إلى معرفة ما إذا كان نهج تقني ممكناً قبل الاستثمار فيه. ابرمج بالتحسس نموذجاً أولياً، راقب النتيجة، تخلص منه أو استخرج الدروس.
عرض توضيحي للتخلص منه: تحتاج إلى إظهار صاحب مصلحة كيف يمكن أن تبدو ميزة ما. العرض التوضيحي ليس المنتج.
استكشاف تعلمي: تتعرف على واجهة برمجة تطبيقات أو إطار عمل أو مجال لم تعمل فيه. المخرجات معرفة، لا برمجيات إنتاج.
السقالات النمطية: الكود المُولَّد سيُراجع سطراً بسطر قبل أن يصل أي منه إلى الإنتاج.
شرط الخروج للكود المبرمج بالتحسس الداخل إلى الإنتاج صريح: مراجعة معمارية للتأكد من توافقه مع تقاليد النظام، فحص أمني لنقاط الحقن أو بيانات الاعتماد المكشوفة أو فجوات المصادقة، تغطية اختبارات من مجموعة مكتوبة بشرياً تتحقق من السلوك، قابلية الرصد للتأكد من أن ما يفعله الكود في الإنتاج مرئي.
مقياس عملي: إذا لم تستطع وصف لزميل ما تفعله دالة مبرمجة بالتحسس ولماذا تعمل بالطريقة التي تعمل بها، فليست جاهزة للإنتاج. العجز عن الشرح ليس علامة على أن الكود معقد جداً. إنه علامة على أن قرارات اتُّخذت دون فهمها.
المكسب الحقيقي في الإنتاجية هو في جودة المواصفة
الفرق التي تفوز بالبرمجة المدعومة بالذكاء الاصطناعي ليست تلك التي تكتب أقل كود. إنها تلك التي تكتب أفضل المواصفات.
أدوات البرمجة بالذكاء الاصطناعي تضغط الفجوة بين المواصفة والكود الشغّال. لا تُلغي متطلب المواصفة الجيدة. مهمة محددة بدقة، مُسلَّمة لوكيل يعمل ضمن ضوابط، تُنتج كوداً جاهزاً للإنتاج بسرعة. مهمة محددة بشكل سيئ، مُسلَّمة لنفس الوكيل، تُنتج كوداً واثقاً يحتاج إلى إعادة كتابة.
المواصفة تشمل ما يفعله المكون، وما لا يفعله، والمدخلات التي يتعامل معها، وأنماط الإخفاق الموجودة، وكيف يُقاس النجاح. هذا ليس عبئاً في التوثيق. إنها المعلومات التي يحتاجها الوكيل لإنتاج مخرجات صحيحة في المرة الأولى بدلاً من الثالثة.
الفرق التي تستثمر في جودة المواصفة تحصل على عوائد مركبة من البرمجة بالذكاء الاصطناعي. الفرق التي تبرمج بالتحسس تحصل على ديون مركبة. كلاهما يبدو إنتاجية في الشهر الأول. بحلول الشهر السادس، الفارق مرئي في وقت الدورة بين المتطلب والإنتاج، وفي حجم المتراكم الذي هو فعلاً إعادة عمل، وفي ثقة المهندسين الذين يعملون في قاعدة الكود.
التحول في دور المهندس حقيقي: من كاتب إلى محدد ومراجع وخبير مجال يعرف متى يتجاوز الوكيل. المهندسون الذين يُجرون هذا التحول أسرع. الذين يتعاملون مع البرمجة بالذكاء الاصطناعي على أنها كتابة أسرع يعملون بجهد أكبر للبقاء في مكانهم.
السؤال ليس ما إذا كنت ستستخدم الذكاء الاصطناعي لتوليد الكود. بل ما إذا كانت المواصفة موجودة، والاختبارات يمتلكها البشر، وقائمة تحقق الإنتاج تعمل قبل النشر.
ذات صلة: Claude Code ليس مساعد برمجي. إنه نظام تسليم. والضوابط الأربعة التي تفصل البرمجة بالذكاء الاصطناعي عن الشحن بالذكاء الاصطناعي