مع قدرة وكلاء الذكاء الاصطناعي على كتابة آلاف الأسطر من الكود البرمجي في وقت قصير، أصبح عنق الزجاجة في عملية التطوير ليس توليد الكود بل مراجعته. فالطرق التقليدية لمراجعة الكود لا تتناسب مع هذه المتغيرات، مما يترك المطورين في حيرة حول كيفية التأكد من جودة وموثوقية الكود المولّد.
لماذا تفشل أساليب المراجعة التقليدية مع أكواد الذكاء الاصطناعي؟
عند مراجعة كود كتبه زميل بشري، يعتمد المراجع على معرفته بمستوى خبرة الزميل، نقاط قوته وضعفه، وقدرته على التواصل معه مباشرة للاستفسار. هذه الروابط الاجتماعية والسياقية تُعد «سقالات خفية» تساعد في توجيه عملية المراجعة. لكن مع نماذج اللغة الكبيرة (LLMs)، تختفي هذه السقالات تمامًا.
المشكلة الأكبر هي أن نموذج اللغة يقدم كل سطر من الكود الذي يولده بنفس الثقة الظاهرة، بغض النظر عن مدى «عدم اليقين» الذي كان عليه عند إنتاج هذا السطر. لا توجد إشارة واضحة تميز بين الكود البسيط والمنطق المعقد أو عمليات ترحيل قواعد البيانات التي قد تكون حساسة. يبدو كل شيء متماثلًا، مما يدفع المطورين إلى مراجعة كل سطر على حدة، وهي عملية غير فعالة ولا يمكن توسيعها مع تزايد قدرات وكلاء الذكاء الاصطناعي.
نرى أن جوهر المشكلة يكمن في «معايرة الثقة» (trust calibration)، وهي القدرة على تخصيص جهد المراجعة بما يتناسب مع مستوى المخاطرة لكل جزء من الكود، خاصة عندما لا يمكن استجواب المؤلف (وهو الذكاء الاصطناعي) حول ثقته أو منطقه. هذا هو ما تفتقر إليه الأدوات الحالية.
إطار عمل جديد لمراجعة أكواد الذكاء الاصطناعي
يقدم فريق Human-AI eXperience، بالتعاون مع باحثين من جامعة Lund، إطار عمل مفاهيمي جديد لبناء أدوات مراجعة الكود الجاهزة للذكاء الاصطناعي. ستعرض الدراسة في الأسبوع الدولي لهندسة البرمجيات التجريبية 2026 (ESEIW) في أكتوبر. هذا الإطار مبني على دراسة تصميم تشاركية شارك فيها 17 مطورًا، بالإضافة إلى استطلاع لاحق شمل 43 متخصصًا في البرمجيات.
يقترح الإطار هيكل عمل ثلاثي المستويات يتوافق مع مبدأ Shneiderman المعروف في تصور المعلومات: نظرة عامة أولًا، ثم تكبير وتصفية، ثم التفاصيل حسب الطلب. يهدف هذا النهج إلى تمكين المراجعين من تكوين فرضيات عالية المستوى، ثم التعمق بشكل انتقائي للتحقق منها، بدلًا من المراجعة السطرية المكلفة معرفيًا.
يجب على مصممي الأدوات في عصر التطوير الأصيل للذكاء الاصطناعي ألا يسألوا «كيف نعرض التغييرات (diff)؟»، بل «ما هي درجة التفصيل التي يحتاجها المراجع لتخصيص انتباهه، وما هي الإشارات التي نحتاج إلى إظهارها؟». يقدم الإطار مبادئ لبناء هذه الأدوات:
- أدوات مستوى النظرة العامة: يجب أن تحل محل التوجيه البيني الذي توفره مراجعة الكود البشري، مثل القدرة على سؤال المؤلف عن تفكيره.
- أدوات مستوى الملف: يجب أن تقوم بتقييم المخاطر قبل أن يقرأ المراجع سطرًا واحدًا من الكود، مما يساعده على تركيز جهده حيث يهم.
- أدوات مستوى مقطع الكود: يجب أن تستعيد العمل التحليلي الدقيق الذي تتطلبه مراجعة الكود الجيدة، مع دعم تفكيك الكتل وربط «سلسلة التفكير» التي لا يمكن لمراجعة الكود البشري توفيرها.
بينما توجد بعض الأدوات الحالية التي تقدم ميزات جزئية (مثل CodeRabbit وClaude Code وGraphite)، فإن أيًا منها لا يدمج هذه الأفكار بالكامل، خاصة في معالجة «معايرة الثقة». حتى GitHub بدأت تنشر إرشادات محددة لمراجعة الكود المولّد بالذكاء الاصطناعي، وتفيد بأن المراجعات بمساعدة Copilot تمثل الآن أكثر من خُمس مراجعات المنصة.
ماذا يعني هذا للمطورين ومصممي الأدوات؟
بالنسبة للمطورين، هذا يعني أن استراتيجيات مراجعة الكود تحتاج إلى التطور. لم تعد مراجعة التغييرات السطرية كافية. يجب أن نركز على فهم المخاطر الكامنة في الكود المولّد بالذكاء الاصطناعي وتخصيص جهد المراجعة بذكاء. أما مصممو الأدوات، فعليهم إعادة التفكير في كيفية عرض الكود ليتجاوز مجرد إظهار التغييرات إلى توفير إشارات الثقة والمخاطر في مستويات دقيقة، مما يمكّن المطورين من اتخاذ قرارات مستنيرة حول أين يضعون انتباههم. هذا الإطار يوفر أساسًا متينًا لبناء الجيل القادم من أدوات التطوير المدعومة بالذكاء الاصطناعي.
المصدر: blog.jetbrains.com