توليد الكود بالذكاء الاصطناعي يُحدث اختناقات في مراجعة الكود مع صعوبات المهندسين

المؤلف: The Pragmatic Engineer

مُترجم: Deep潮 TechFlow

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

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

سمعت أن أحد أكثر الأمور التي تقلق قادة الهندسة هو كيفية التعامل مع عبء مراجعة الكود المتزايد باستمرار. هذا الموضوع موجود منذ فترة، ويبدو أن هذه المحادثات تزداد الآن.

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

منذ فبراير، شهدت أدوات مراجعة الكود بالذكاء الاصطناعي نموًا هائلاً للتعامل مع زيادة الحمل، حيث ازدادت تجارب واعتماد الأدوات المتخصصة لمراجعة الكود بالذكاء الاصطناعي مثل CodeRabbit و Greptile و Qodo و SonarQube (الآن مع إضافة Gitar). كما ظهرت أدوات مدمجة ضمن أدوات البرمجة نفسها، مثل مراجعة Claude Code و Cursor Review و GitHub Copilot Review. بالإضافة إلى ذلك، بدأت أدوات لم تكن تشارك سابقًا في مراجعة الكود ولكنها تمتلك سياقًا لقاعدة الكود في الانضمام إلى هذا المجال، مثل مراجعات Seer AI الخاصة بـ Sentry ومراجعات Linear للكود.

تقوم شركات كبيرة ببناء أدوات داخلية لتحسين تجربة مراجعة الكود. أحد الأمثلة هو Code Inbox من Uber:

التوزيع الذكي هو ميزة داخل Code Inbox تُستخدم لدفع عملية المراجعة:

الرسم البياني: إعدادات التخصيص الذكي (Smart assignment) لـ Code Inbox لدفع عملية المراجعة. المصدر: The Pragmatic Engineer

كما توجد وظيفة ملف المخاطر لتقييم تأثير التغييرات وتشجيع المطورين على الانتباه بشكل خاص إلى التغييرات عالية المخاطر:

الرسم البياني: ميزة ملفات المخاطر (Risk Profiles) لـ Code Inbox، والتي تُقدّر مخاطر التغييرات في الكود وتشير إلى النقاط التي تحتاج إلى تركيز خاص. المصدر: The Pragmatic Engineer

قدمنا تقارير عن كيفية استخدام أوبر للذكاء الاصطناعي في تطوير البرمجيات، وليس فقط أوبر: فقد طورت Cloudflare (AI Code Reviewer) وFaire (Fairey) وHubSpot (Sidekick) والعديد من الشركات الأخرى أدوات لجعل عمليات مراجعة الكود الخاصة بها أكثر سلاسة، لأنهم اكتشفوا أن الحلول الداخلية تحقق نتائج أفضل من دمج حلول الموردين.

طريقة أخرى هي التفكير في كيفية التحقق من الكود بدلاً من مراجعته. يبدو الأمر سهلاً على الورق، لكنه صعب التطبيق عمليًا؛ نظريًا، يجب أن تكون الاختبارات الشاملة قادرة على التحقق من أن الكود يعمل كما هو متوقع. لكن ما الذي يُعد "شاملاً" من الاختبارات؟ ما نوع الاختبارات المقصود؟ هل تشمل اختبارات التكامل واختبارات النهاية إلى النهاية؟ ماذا عن اختبارات التخمين؟ وماذا عن الأساليب الرسمية؟ كيف نتحقق من أن الاختبارات الجديدة تغطي الوظائف كما هو متوقع؟ كيف نربط كل هذا بالقابلية للرصد؟

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

هناك مشكلة، لكن الحل يبدو أكثر كتجربة.