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

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

الاختناق هو الإنسان

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

«ليست المشكلة في النموذج ونواقصه، بل في نفسي». هذه ملاحظة مهمة لكل

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

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

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

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

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

خبير وليس راكب

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

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

ماذا يعني هذا

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