عصر التشفير بالذكاء الاصطناعي، لا تزال عادات البرمجة الجيدة مهمة

مؤخرًا قمت بعمل اختبار أداء لوكيل، واكتشفت أنه لا يمكن تقييم مدى تعقيد مهمة برمجية للذكاء الاصطناعي ببساطة من خلال منظور المطور.
على سبيل المثال، مهمة إعادة هيكلة: تقسيم ملف كبير يتكون من آلاف الأسطر إلى أكثر من عشرة وحدات صغيرة حسب الوظيفة.
هذه المهمة ليست صعبة حقًا على المطور، العمل الرئيسي هو نقل الكود، تنظيم الاستيرادات، التحقق من الترجمة، ويمكن للمبتدئين إنجازها.
لذا فكرت في استخدام مهمة بسيطة لإجراء اختبار أداء، لكن النتيجة كانت غير متوقعة.
يعتقد Claude Code أن المهمة كبيرة، حاول تقسيم جزء منها، وقدم طلب سحب (PR) وكتب عمل مستقبلي يخطط لتقسيمها خطوة بخطوة.
أنا وكيل الخاص بي هو "العمل بقوة"، ودفعت نحو تقسيم كامل أكثر، لكن الثمن كان واضحًا: استهلاك الرموز (Token) هو عشرات أضعاف ما يستهلكه Claude، والكثير من الوقت يُقضى في قراءة الملفات مرارًا وتكرارًا، وتصحيح أخطاء الترجمة، ثم قراءة الملفات مرة أخرى، وتصحيح الأخطاء مجددًا.
هذا جعلني أدرك أن المهمة التي يراها الإنسان بسيطة، قد لا تكون كذلك بالنسبة للوكيل.
بالنسبة للبشر، غالبًا ما تكون إعادة الهيكلة من نوع "نقل هذا الجزء". لكن بالنسبة للوكيل، عليه أولاً قراءة ملفات كبيرة على دفعات، وتذكر أي الدوال مرتبطة بأي الاختبارات، ثم توليد مجموعة من التعديلات عبر الملفات، وأخيرًا سد الثغرات تدريجيًا من خلال أخطاء الترجمة.
يبدو الأمر كأنه عمل ميكانيكي، لكنه في الواقع يتحول إلى مهمة ذات تكلفة عالية من حيث الرموز (Token) وإدارة الحالة.
قبل فترة، رأيت شخصًا يقول إنه في عصر التشفير بالذكاء الاصطناعي، لم تعد مبادئ تقسيم الوحدات مهمة جدًا، لأنه على أي حال لا يقرأ الناس الكود.
لكن الآن، أعتقد أنني لا أتفق تمامًا. فحدود الوحدات الواضحة، وحجم الملفات المناسب، وبساطة الاعتمادات، ليست فقط لتسهيل القراءة على البشر، بل تساعد أيضًا في تقليل تعقيد المهمة على الوكيل.
من زاوية أخرى، أدوات قراءة وتعديل الملفات للوكيل الآن ليست مريحة جدًا لهذا النوع من إعادة الهيكلة.
وكيل التشفير، عند تعديل الملفات، يعتمد بشكل رئيسي على استبدال النصوص. على سبيل المثال، Claude Code غالبًا يستخدم نمط old_string / new_string: يعرض نصًا قديمًا ثم يستبدله بالنص الجديد.
أما Codex، فهو يستخدم apply_patch: يولد تصحيحًا يشبه فرق git diff، ويعبر عن استبدال المحتوى القديم بالجديد.
كلها مناسبة للتعديلات الصغيرة، لكن إذا أردت حذف جزء كبير من الكود القديم، أو نقل مجموعة من الدوال إلى ملفات أخرى، غالبًا ما يحتاج النموذج إلى قراءة المحتوى الأصلي أولاً في السياق، ثم توليد استبدال كبير أو فرق (diff).
لذا، أعطيت الوكيل تلميحًا، وهو أن يستخدم أدوات مثل السكربتات، sed، perl، لتفكيك الملف الكبير بشكل تقريبي، وحذف المحتوى القديم مباشرة، وكتابة المحتوى الجديد في ملف جديد، ثم يقوم بالتعديلات تدريجيًا.
وقد زاد ذلك من كفاءته بشكل كبير.
الوكيل بشكل افتراضي لا يفعل ذلك، ويرجع ذلك أساسًا إلى أن نظام التلميحات (System Prompt) يصر على أن يستخدم الوكيل الأدوات المدمجة لتعديل الملفات، وليس أدوات سطر الأوامر.
لو فكرنا خطوة أبعد، ربما يحتاج وكيل التشفير إلى أدوات تحرير أكثر تقدمًا.
ليس فقط واجهة "استبدال النص"، بل أن يُبنى هيكل الكود باستخدام parser، أو LSP، أو المترجم (compiler)، بحيث يمكن للوكيل أن يقوم بإعادة الهيكلة كما يفعل IDE: نقل الدوال، حذف كتل التنفيذ (impl block)، تنظيم الاستيرادات.
لا أدري إذا كان هناك أصدقاء قاموا بمحاولات في هذا المجال.
بشكل عام، حتى في عصر التشفير بالذكاء الاصطناعي، لا تزال العادات البرمجية الجيدة ذات قيمة.
من الأفضل أن نحول العادات الجيدة إلى نمط عمل افتراضي للوكيل من خلال هندسة الأدوات في المراحل المبكرة، بدلاً من الانتظار لإعادة الهيكلة لاحقًا، حيث أن التكاليف ستكون أقل بكثير.