0%
ما الذي يغيّره وكيل البرمجة

ما الذي يغيّره الوكيل

لم تعد المهارة النادرة كتابة الشيفرة، بل تأطيرها ومراجعتها.

10-15 دقيقة

ما الذي يغيّره وكيل البرمجة

إعادة تسمية حقل في واجهة API، ونشر التغيير في أربعين ملفًا، وتعديل الاختبارات والتوثيق: كانت هذه قبل وقت قصير ساعتين من العمل الآلي، وصارت اليوم عشر دقائق. المكسب حقيقي ولا جدال فيه. أما ما يستدعي النقاش فهو ما يلي ذلك: بعد عشر دقائق من التوليد تأتي أربعون دقيقة من المراجعة، وتكتشف أن الوكيل «صحّح أيضًا» مقارنةً في ملف لم تذكره، وأضاف تبعية (dependency) لتنسيق تاريخ، وحذف اختبارًا كان يفشل لأنه رآه قديمًا. الوقت لم يختفِ، بل انتقل.

لقد تغيّرت طبيعة نمط الإخفاق، وهذه هي النقطة المهمة. في السابق كان حدّك أن تعرف كيف تكتب الشيء: كنت تتعثر، وتبحث، وتتعلم، وكانت الشيفرة التي تنتجها مفهومة لديك بحكم طريقة بنائها. أما الآن فتصلك الشيفرة كاملة، سليمة نحويًا تمامًا، بأسماء متغيرات مناسبة وتعليقات في مواضعها الصحيحة، وبالتالي مقنعة تمامًا. غير أن كونها مقنعة وكونها صحيحة خاصيتان مستقلتان. فالوكيل يحسّن ما يستطيع ملاحظته: بناءً (build) ينجح، ومجموعة اختبارات خضراء، وجوابًا يبدو كجواب. أما نيّتك فلا يلاحظها، ولا القيد غير المكتوب الذي يجعل هذا السطر، وهو يبدو بلا فائدة، ضروريًا تمامًا. وعملك الآن أن تقدّم له ما لا يلاحظه، ثم أن تتحقق مما أنتجه.

التعليقات

التعليقات مدعومة عبر GitHub Discussions

سجّل الدخول باستخدام GitHub للمشاركة في النقاش

تم نسخ الرابط!