قيادة إعادة هيكلة واسعة النطاق

ترحيل ستين استدعاءً من واجهة برمجية داخلية قديمة إلى الجديدة هو بالضبط نوع المهام التي لا يُضاهى فيها الوكيل (agent): آلية ومتكررة ولا تتطلب اتخاذ أي قرار. وهي أيضًا نوع المهام الذي ينتج أسوأ نتيجة ممكنة عندما تُطلق دفعة واحدة. تحصل على diff من 1400 سطر يمس اثنين وستين ملفًا، وتعرض مجموعة الاختبارات أحد عشر إخفاقًا، ولا تملك أي وسيلة لمعرفة هل تعود هذه الإخفاقات الأحد عشر إلى خطأ منهجي تكرر ستين مرة أم إلى ثلاث حالات خاصة مشروعة. الـ diff أكبر من أن يُراجَع، وأكثر تشابكًا من أن يُلغى جزئيًا، وأطول من أن يُعاد توليده فيُرمى دون ألم.

المشكلة ليست في قدرة الوكيل، بل في دقة التحقق. في أي إعادة هيكلة، السؤال الذي يجب أن تكون قادرًا على الإجابة عنه في كل لحظة هو: «هل ما زال المستودع متسقًا؟». أما الـ diff الأحادي الكتلة فلا يتيح الإجابة إلا مرة واحدة، في النهاية، حين تختلط كل الأخطاء معًا. لذلك تقوم المنهجية على فرض تسلسل من الخطوات، كل منها قابل للـ commit وحده، وللتحقق وحده، وللإلغاء وحده، وعلى جعل هذا التسلسل قيدًا في الـ prompt لا أملًا معلّقًا.

اجعل التغيير إضافيًا قبل أن تجعله هادمًا

القاعدة التي تبني أي ترحيل جاد: لا تحذف المسار القديم أبدًا في الـ commit نفسه الذي يُدخل المسار الجديد. نطبّق التسلسل المعروف باسم التوسيع ثم الانقباض (expansion-contraction).