Claude AI في أربع بيئات تطوير: لماذا أصبح المطوّر عنق الزجاجة الرئيسي أمام الوكلاء

نشر موقع Habr AI نصًا عن كيف تُسرّع مساعدات الذكاء الاصطناعي التطوير، وتخلق في الوقت نفسه نوعًا جديدًا من الإرهاق. فعندما يعمل المطوّر على عدة مشاريع معًا، لا يعود القيد الرئيسي هو Claude AI ولا جودة توليد الشيفرة، بل انتباه المطوّر نفسه.

عنق الزجاجة هو الإنسان

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

«ليس النموذج بأخطائه، بل أنا».

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

الاختبارات بدل المراجعة

يتضح من المقال أن الكاتب يستبدل بصورة متزايدة المراجعة التقليدية للشيفرة (code review) بالاختبار القائم على السيناريوهات. والمنطق بسيط: إذا كانت المهمة لا تنطوي على خطر مباشر لخسائر مالية، فمن الأسرع ألا يتعمق المطوّر في كل وحدة، بل أن يفحص النظام بوصفه black box. وفي مثال عقد ذكي على EVM، زُوّد الوكيل بمجموعة قيود هندسية — offline nonce، والامتناع عن طلبات RPC الزائدة، وقيمة gasLimit ثابتة، وround robin على العناوين — ثم بدأ الكاتب، بدلًا من قراءة الشيفرة، بمهاجمة الحل بالأسئلة والتشغيلات التجريبية.

• مراجعة متوازية من السياق الحالي ومن سياق نظيف
• التحقق مما سيحدث عند انقطاع مصادر الأسعار
• مراقبة منطق gasPrice وخطر استنزاف الوديعة في الرسوم
• قياس زمن معالجة التيكات (ticks) والإرسال غير المتزامن
• Dry run باستخدام mocks بدل المعاملات الحقيقية

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

خبير لا راكب

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

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

ماذا يعني ذلك

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