وكلاء كتابة الكود بالذكاء الاصطناعي مفيدون، لذلك تحتاج الفرق إلى سياسة خبرة

الجدل حول أن البرمجة بمساعدة الذكاء الاصطناعي قد تمنع تكوّن الخبرة ليس مريحاً لأي طرف. هو لا يقول إن وكلاء كتابة الكود بلا فائدة، ولا يطالب بالعودة إلى كتابة كل القوالب يدوياً. السؤال عملي: ماذا يحدث للحكم الهندسي عندما تستخدم الشركات Claude Code وCursor وCodex وأدوات شبيهة بـ Copilot وGemini CLI وOpenCode، وتفوّض جزءاً من العمل الذي كان يدرّب هذا الحكم؟

الشرارة الأخيرة جاءت من نقاش Hacker News حول مقال Lars Faye بعنوان “AI Coding will Prevent Expertise”. الفكرة الأساسية هي فقدان الاحتكاك المعرفي: التصحيح، قراءة الوثائق، ارتكاب الأخطاء، وفهم الحدود والمفاضلات. لاقى النقاش صدى لأن فرقاً كثيرة تشعر بهذا التحول الآن. يستطيع AI إنتاج كود وتذاكر وملاحظات تصميم وتعليقات مراجعة أكثر مما يستطيع الفريق فهمه بهدوء.

جوهر الحجة

يتحدث Faye عن مفارقة المنسق الماهر. أكثر من يستفيد من الوكلاء هم المهندسون أصحاب الخبرة. فهم يلاحظون التجريد السيئ، وAPI المتخيلة، وكلفة الترحيل المخفية، والتغيير الذي يصعب صيانته. يطرحون أسئلة أفضل لأن لديهم نموذجاً مسبقاً للإجابة الجيدة.

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

هذا ليس حنيناً إلى المعاناة. بعض الاحتكاك كان هدراً، وبعضه كان تدريباً. إذا أزال AI الطبقتين معاً، قد تكسب الشركة سرعة ظاهرة وتفقد فهماً طويل الأمد.

لماذا أثار النقاش ردوداً

قارن فريق AI بالمترجمات وIDE والإكمال التلقائي وStack Overflow. كل طبقة أدوات أزالت عملاً يدوياً. ورد فريق آخر بأن AI قد يزيل التفكير نفسه، لا الكتابة فقط. المترجم لا يقدم بنية كاملة، وStack Overflow كان يعطي أجزاء تحتاج إلى فهم. أما الوكيل فيمكنه إنتاج diff وتفسير واختبارات في مرور واحد.

كلا الرأيين فيه حق. إزالة العمل منخفض القيمة مفيدة. إزالة حلقات التغذية الراجعة خطرة. السؤال ليس هل نستخدم AI في التطوير، بل أي حلقات يجب الحفاظ عليها: قراءة diff، التصميم الصريح، الاختبارات ذات المعنى، والمسؤولية البشرية.

فخ القياس في الشركات

من السهل قياس adoption عبر الحجم: مزيد من pull requests، إغلاق أسرع للتذاكر، واختبارات أكثر. هذه الأرقام لا تفيد إلا مع مؤشرات جودة. يستطيع الفريق توليد كود أكثر مما يستطيع مراجعته وصيانته. عندها تصبح الإنتاجية الظاهرة دين فهم.

رسالة “من يكتب يدوياً بطيء” خطرة. فهي تدفع المهندسين إلى ترك أعمال تحمي المنتج: فحص المتطلبات، قراءة diff، تتبع الحالات الحدية، رفض تغيير واسع، أو سؤال هل الميزة مطلوبة أصلاً.

يزيد AI أيضاً ضجيج العمل. تصبح التذاكر أطول، وملاحظات التصميم أكثر، وأدوات المراجعة أكثر كلاماً. يفلتر الفريق وثائق تبدو دقيقة لكنها لا تمثل دائماً قراراً حقيقياً.

المبتدئون يحتاجون إلى ممارسة

يستخدم المهندس الكبير الوكيل كشريك صبور لأنه يستطيع مجادلته. أما المبتدئ فقد يستخدمه كآلة إجابات. الفرق ليس أخلاقياً بل معرفي.

التعلم الصحي بمساعدة AI يجب أن يبدأ بالشرح: وصف النظام، القيود، البدائل، الأسئلة، والاختبارات المهمة. بعد ذلك يأتي الكود. الهدف أن يكون الوكيل معلماً ومراجعاً، لا آلة تصدر التصحيحات.

ينبغي للفرق الحفاظ على تدريب مباشر: تصحيح بلا AI، قراءة كود غريب، كتابة ميزة صغيرة من الصفر، وشرح التصميم في review. هذه ليست طقوساً ضد التقدم، بل تدريب على الحكم الذي يقيّم إجابات الوكيل.

يمكن أن يكون AI معلماً جيداً

عند استخدامه جيداً، يسرّع AI التعلم. يمكنه شرح وحدة قديمة، مقارنة خيارات قاعدة بيانات، اقتراح اختبارات، أو نقد خطة refactoring. هذا أفضل من التعثر الصامت.

الفارق في الطلب. “اكتب الميزة” يعطي نتيجة. “اشرح النظام، اسأل عما هو غامض، قدم بدائل ومخاطر” يعطي فهماً. النمط نفسه يظهر في التحليل والقانون والتسويق والدعم: ينتج AI أسرع مما يتحقق البشر. من دون خبرة مجال، تصبح الإجابة المصقولة خطراً.

هل يجب قراءة كل الكود؟

يوازن طرح Adam Tornhill عن التحكم في آلة عدم اليقين النقاش. ربما لا يجب قراءة كل سطر بنفس العمق. الهندسة تثق أصلاً بالمكتبات والمترجمات وقواعد البيانات.

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

يجب أن تعتمد المراجعة على الخطر. تغيير واجهة صغير ليس مثل المصادقة أو المدفوعات أو ترحيل البيانات أو التزامن أو الكود الأمني. الكود المولّد بالذكاء الاصطناعي لا يحتاج خوفاً أسطورياً، بل مالكاً بشرياً.

Auto mode يرفع المتطلبات

نقاش Claude Code auto mode يوضح السبب. تقليل طلبات التأكيد مريح، لكن كلما قلّت مقاطعة الوكيل للمستخدم زادت أهمية تحديد sandbox مسبقاً: المجلدات المسموح تعديلها، الأوامر، الاعتمادات، migrations، CI، والملفات المولّدة، ومتى يلزم قبول بشري.

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

قواعد عملية

كل تغيير بمساعدة AI يحتاج إلى human owner يستطيع شرح الهدف والمخاطر وخطة rollback. العمل غير البسيط يحتاج مذكرة تصميم قصيرة: النطاق، الاختبارات، الترحيل، والمخاطر التشغيلية. يجب أن تكون refactors الكبيرة وغير المرئية نادرة ومبررة.

الاختبارات إلزامية لكنها لا تغني عن review. يجب البحث عن API متخيلة، وتجريدات غير ضرورية، واعتمادات جديدة، وتغييرات حالة مخفية، وكود لا يستطيع الكاتب شرحه. كما تفيد no-AI drills للحفاظ على التصحيح والقراءة والتصميم.

ينبغي أن تقيس المؤسسات defects التي وصلت للإنتاج، وrollbacks، وحمل review، والقابلية للصيانة، ووقت فهم التغيير، لا PR throughput فقط. إذا زاد الكود وزادت الديون والحوادث، فالتبني لم ينجح.

الموقف الناضج

الجواب ليس حظر coding agents. يجب التعامل معها كمسألة إدارة هندسية. هي قوية عندما تخفض العمل الميكانيكي وتوسع الاستكشاف، وخطرة عندما تستبدل حكم الفريق في العمارة والمخاطر والصيانة. قد يكتب مطور المستقبل كوداً خاماً أقل، لكنه لا يستطيع التوقف عن فهم الأنظمة والفشل والمسؤولية.