ماذا تعرض عندما يكتب الوكيل الكود في خمس دقائق

عندما يكتب الوكيل في خمس دقائق البنية المعمارية، والإطار البرمجي، والوظائف الأساسية، ونصف الكود التشغيلي، ماذا يعرض المطوّر في ملف أعماله؟ لم تعد قاعدة الكود إشارة على المهارة — فأي شخص لديه إمكانية الوصول إلى الوكيل نفسه يستطيع كتابتها.

هذا السؤال يستند إلى مبدأ من كتاب أوستن كليون «Show Your Work!» — ألا تنتظر انتهاء المشروع، بل تعرض العملية على خطوات صغيرة، وتُعلّم الآخرين ما تعرفه. لكن في عام 2026، يتطلّب هذا إعادة نظر: يجب عرض الأحكام، لا المنتجات النهائية.

ستة أمور بدلاً من الكود

ما يكشف عملك عندما يكون الكود قد كتبه الوكيل بالفعل:

• القرارات والخيارات المرفوضة. تُظهر حكماً لا يملكه الوكيل بشأن مشروعك. عندما خفّض دليل خوادم MCP درجتين بسبب أسماء وظائف خالية من النقاط (مثل `stories.search`)، كان ذلك قراراً متعمّداً: فمزوّدو النماذج الكبار لا يتجاوزون النقاط في الأسماء، وأسماء مطابقة للدليل كانت ستُعطّل العملاء الذين وُجد الخادم من أجلهم.

• الإخفاقات وطريقة التشخيص. بدأت غوغل تصنّف الصفحات كـ«soft 404»، مع أنها كانت تُفتح بشكل طبيعي في المتصفح. السبب: سطر واحد في ملف robots.txt كان يحجب واجهة برمجة التطبيقات الخاصة بجلب المحتوى. تُجري غوغل العرض كما يفعل المتصفح، فلم تستطع الحصول على البيانات ورأت شاشة خطأ.

• كيف تحقّقت من عمل الوكيل. المهارة الأهم اليوم، وغير الظاهرة في الكود. ثلاثة أمثلة في أسبوع واحد: اختبار الخادم كان يفحص رمز خطأ غير صحيح ونجح لعدة أيام، إلى أن تعطّل عميل حقيقي عبر أداة طرف ثالث مع استثناء؛ وقسم إحصائيات كان فارغاً في بيئة الإنتاج بسبب سياسة أمان خاصة بشبكة CDN لم يطبّقها متصفح الاختبار؛ وعثرت غوغل على صفحات غير موجودة تنتهي بـ`.mdread-only` — فالرابط إلى النص المصدري كان ملتصقاً بالملاحظة، وكان المتصفح يُظهر مسافة لم تكن موجودة في الكود المصدري، فدمجتهما غوغل في عنوان واحد.

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

• الأرقام قبل وبعد. يمكن عرض النتيجة بسهولة حتى عندما لا يمكن عرض النظام نفسه. عبارة «بعد يومين من الإصلاح، لم تعد غوغل تصنّف الصفحات كـsoft 404» أو «الفحص الآن يكتشف هذا قبل الإصدار» تقول أكثر من أي مقارنة تفصيلية للكود (diff).

• ما كنت ستفعله بشكل مختلف. التحليل الصادق يولّد ثقة أكبر من قصة النجاح، وهو أكثر فائدة لمن يقوم بعمل مشابه.

كيف يعمل هذا: عبقرية جماعية (سِينيوس) لا عمل فردي

عندما تعرض القرارات والأخطاء بدلاً من الكود، يتفاعل أشخاص بخبرات مختلفة. تحوّلت مناقشتان في التعليقات على موقع dev.to حول خادم MCP إلى ميزات في المنتج: فحص الإصدار، ومجموعة اختبارات عبر عميل حقيقي. وصلت واحدة من هذه المناقشات إلى سيدني بيسولي، مؤلّف سبعة خوادم MCP للبيانات المفتوحة البرازيلية. فابتكر منها أداة مستقلة، وشغّلها على كل إصداراته الـ142 من الخوادم، ووجد إصدارين لم يكونا يعملان على الإطلاق، وكتب مقالاً استنتج فيه أن «سلسلة تعليقات واحدة غيّرت طريقة إصدار ثمانية خوادم». يسمّي أوستن كليون هذه الظاهرة «السِّينيوس» — فالعمل الجيد ينشأ في مجموعة تعرض بعضها لبعض ما تفعله، لا عند شخص منفرد.

داخل الشركة: الآلية دون الأسماء

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

حتى في المشاريع المغلقة، يمكن عرض معظم المحتوى إذا احتفظت بالآلية وأزلت الأسماء. «خدمة داخلية»، «خطوة الدفع»، «شبكة CDN الخاصة بنا» — فالدرس لا يعتمد على العلامة التجارية تقريباً أبداً. اعرض المنطق، لا المنتج: لماذا اختير هذا الحل، وكيف جرى التحقّق منه، وما الذي سيتغيّر. اطلب الإذن مرة واحدة — فمعظم المديرين لا يعترضون على درس مجهول الهوية. والصيغة الصغيرة مقبولة أيضاً: مشكلة واحدة، وإصلاح واحد، و300 كلمة. والمخطط العملي هو: السياق ← أين كان الوكيل واثقاً وأخطأ ← التشخيص ← ما الذي تغيّر لمنع التكرار.