لا يرتبط المطورون بأدوات مثل Vim وEmacs أو بيئات التطوير المتكاملة لمجرد الاعتياد عليها، بل لأن هذه الأدوات تصبح جزءاً من الطريقة التي يفكرون ويكتبون ويراجعون بها الشيفرة. ومع اكتساب المستخدم خبرة طويلة، تتحول الأوامر والإجراءات إلى معرفة ضمنية وذاكرة عضلية، فتبدو الأداة امتداداً طبيعياً ليده. هذه العلاقة تفسر جانباً من التردد تجاه أدوات البرمجة الوكيلة، التي تستطيع إنتاج تطبيقات كاملة بسرعة، لكنها أقل دقة ووضوحاً وقابلية للتنبؤ.
يربط المقال بين الأدوات والثقة والعملية المحيطة بها. فالأداة الموثوقة ليست فقط ما ينفذ المهمة، بل ما يتيح للمطور معرفة حدودها وسلوكها وتوقع نتائجها. أما أدوات الذكاء الاصطناعي الوكيلة، فتتغير قدراتها باستمرار، وتعتمد على أوامر بلغة طبيعية يمكن أن تكون غامضة. ووفقاً لبيانات مسح المطورين الأخير الذي يشير إليه المقال، ارتفعت نسبة استخدام الذكاء الاصطناعي من 76% إلى 84%، بينما تراجعت الثقة به من 40% إلى 29%.
الأداة جزء من عملية التطوير
تعلم المطور العمل في الطرفية أو داخل محرر نصي أو بيئة تطوير متكاملة لا يعني تعلم برنامج منفصل فقط؛ بل يعني بناء عملية كاملة لكتابة الشيفرة وفهمها وتحسينها. لذلك فإن الانتقال من الطرفية إلى بيئة تطوير متكاملة قد يتطلب إعادة صياغة طريقة العمل، والانتقال من أي منهما إلى أداة برمجة وكيلة يمثل تحولاً أكبر.
توضح Tricia Gee، وهي مناصرة لإنتاجية المطورين، أن المطور قد يكون أسرع باستخدام بيئة التطوير التي يعرفها، لأن أصابعه اعتادت ما ينبغي فعله. وينطبق الأمر نفسه على مستخدمي Vim وEmacs ذوي الخبرة. ومع الوقت، تتكون كفاءة غير واعية تساعد المطور على الوثوق بالأداة وعلى استخدامها لإنتاج الشيفرة وتحسينها.
وتمنح الأدوات التقليدية، مثل بيئات التطوير المتكاملة وأدوات الحاويات والمحللات الساكنة، المستخدم تصوراً واضحاً لحدودها وأدوارها. أما الذكاء الاصطناعي فيتغلغل في أجزاء متعددة من سلسلة أدوات دورة حياة تطوير البرمجيات، ما يجعل انخفاض الثقة به مؤثراً في العملية بأكملها. فقد تصبح كتابة الشيفرة أسرع، لكن التحقق منها والتأكد من أنها لن تتسبب في أعطال مكلفة عند الإنتاج قد يستغرق وقتاً أطول.
الأدوات لا تصلح العمليات المعطلة
غيّرت أدوات البرمجة الوكيلة طبيعة عملية التطوير، وهو ما قد يجعل أدوات نشأت حول العملية السابقة، مثل أدوات الفحص الثابت والاختبارات الوحدوية والتكامل والنشر المستمرين، أقل ملاءمة بصورتها الحالية. لكن المقال يميز بين الأداة والعملية التي تجسدها: أداة تكامل ونشر مستمر جيدة لا تضمن شحناً أسرع، وبيئة تطوير متكاملة قوية لا تضمن كتابة شيفرة أفضل، ونظاماً لتتبع القضايا لا يضمن دقة تقدير الجهد.
جزء من العملية يتشكل داخل ثقافة المؤسسة وسلوك أفرادها ومعاييرهم. ولهذا قد تفشل الأدوات الجديدة، مهما بدت وعودها كبيرة، إذا لم تنسجم مع الثقافة والعمليات القائمة أو إذا لم يفهم المطورون سبب استخدامها. ويشير المقال إلى أن أدوات البرمجة الوكيلة اكتسبت انتشاراً سريعاً لأنها تساعد المطورين على حل المشكلات بسرعة، لكنها كشفت في الوقت نفسه عيوباً قديمة في تحديد المتطلبات وتعريف المشكلة ومعنى حلها.
أصبح إنتاج الشيفرة شبه مجاني مقارنة بما كان عليه، لكن مراجعتها لم تصبح كذلك. فالمطورون قد يواجهون تغييرات ضخمة في طلبات الدمج تنتجها الوكلاء في لحظات، ما يزيد العبء على المراجعين أو يدفع إلى اعتماد مراجعات شكلية. ويجري تطوير استخدام نموذج لغوي بوصفه حكماً لتوسيع نطاق المراجعة، إلا أن بناء الثقة في قدرة الذكاء الاصطناعي على مراجعة شيفرة كتبها ذكاء اصطناعي يتطلب عملاً إضافياً.
كما أن تشغيل الشيفرة له تكاليفه. وتشمل هذه تكاليف البنية التحتية، والموارد السحابية من حوسبة وذاكرة وحركة مرور، والخدمات التابعة وواجهات البرمجة المستضافة، فضلاً عن كلفة الأعطال مثل التوقفات والاختراقات الأمنية وتكاليف الفرص. ولا تكون الأدوات التي تنتج شيفرة من دون مراعاة هذه العوامل مفيدة بالضرورة، وقد تضعف العملية التي كانت تنتج برمجيات موثوقة.
بناء الثقة عبر المسؤولية والعمليات
في دورة التطوير التقليدية، كانت الثقة تتوزع عبر أدوار مترابطة: يحدد مديرو المنتجات المتطلبات، ويصمم المعماريون الحلول، ويبني المهندسون البرمجيات ويراجعون التغييرات، ويختبر فريق ضمان الجودة نقاط الانهيار، ثم يراقب متخصصو DevOps وSRE الأداء والموارد بعد الإطلاق. ساعد هذا التوزيع على تقليل احتمال أن يتصرف فرد أو أداة خارج الحدود بما يضر النظام.
ويرى المقال أن دورة التطوير المدعومة بالذكاء الاصطناعي تحتاج إلى مبادئ مماثلة: العمل مع الأشخاص، وتحديد المسؤولية والمساءلة، ومشاركة العمليات وتحسينها تدريجياً، وتقليل فرص الخطأ. وينبغي أن يظل البشر الأطراف المسؤولة، مع توضيح المواضع التي أسهم فيها الذكاء الاصطناعي.
المسؤولية لا تنتقل إلى الوكيل لمجرد أنه أنشأ التغيير. فالشخص الذي يدفع التغيير إلى المستودع مسؤول عن الشيفرة، ومن يوافق على طلب الدمج مسؤول عن الموافقة. وبحسب المنطق الذي يقدمه المقال، إذا تسبب التغيير في كسر بيئة الإنتاج، فلا يمكن إلقاء اللوم على بيئة التطوير أو الأداة؛ بل تقع المسؤولية على الأشخاص والعملية التي سمحت بمرور التغيير.
يحمل هذا التحول تحدياً آخر يتعلق بالتعاون. فقد يتيح الوكيل لمطور واحد تنفيذ مهام تمتد من متطلبات المنتج إلى عمليات DevOps، ما يزيد احتمال تحوله إلى جزيرة منفردة لا تتواصل مع المصمم أو المهندس المتخصص في قاعدة شيفرة معينة. ويحذر المقال من أن هذا المسار قد يقود إلى طلبات دمج ضخمة، حتى لو بدت الأداة قادرة على تنفيذ العمل بسرعة.
الخلاصة الأساسية ليست أن الأدوات الجديدة غير مفيدة، بل أن تحسين الأدوات وحده لا يكفي لإصلاح دورة تطوير معطلة. تحتاج المؤسسات إلى عمليات يفهمها المطورون ويقبلونها، وحدود واضحة لدور الوكلاء، ومراجعة بشرية ذات مسؤولية فعلية، وتعاون يمنع تحول التطوير إلى نشاط فردي مغلق. عندها يمكن للأدوات والثقافة أن تعملا معاً لبناء ثقة جديدة في بيئة تطوير تعتمد على الذكاء الاصطناعي.