فحص فهم الكود مقابل الاختبارات: متى تتفوق كل طريقة

هذا سيناريو بات شائعًا: يكتب وكيل البرمجة 600 سطر موزعة على أربعة ملفات، وتنجح الاختبارات، ويرضى الـ linter، فتدمج التغيير. بعد أسبوعين ينكسر في الإنتاج، فتحدّق في الـ diff كأن شخصًا غريبًا كتبه، وهذا صحيح من الناحية العملية. لم يكن العيب في الكود نفسه، بل في الفجوة بين الكود وتصورك الذهني له. هذه الفجوة هي ما تحاول فحوصات فهم الكود بالذكاء الاصطناعي — وهي بوابات تختبرك حول الـ diff قبل أن يُشحن — أن تغلقها. أداة Git hook مفتوحة المصدر اسمها Sphinx انتشرت هذا الأسبوع وتفعل ذلك بالضبط: قبل أن ينجح الـ push، تقرأ الـ diff وتسألك سؤالًا عمّا يفعله الكود عندما تسوء الأمور.

كان غريزي كمهندس تعلم آلة سابق هو الشك. بوابة أخرى؟ طقس آخر؟ لكن كلما فكرت في أنماط الفشل التي أراها فعلًا مع الكود المولّد بالوكلاء، ازددت اقتناعًا بأن هذه الفكرة تستهدف شيئًا لا تستطيع الاختبارات الوصول إليه بنيويًا. لذلك لنقارن بصدق: فحوصات الفهم مقابل شبكة الأمان الآلية التي لديك بالفعل — الاختبارات، والـ linters، ومدققات الأنواع، وCI — ومتى تنتصر كل واحدة فعلًا.

ما الذي تتحقق منه الاختبارات والـ Linters فعلًا؟

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

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

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

ما الذي تلتقطه فحوصات الفهم ولا تلتقطه الاختبارات؟

فحص الفهم يقلب اتجاه التحقق. بدلًا من السؤال «هل يعمل الكود؟»، يسأل «هل الشخص الذي يشحنه يعرف ما الذي يفعله عندما تسوء الأمور؟». مثال Sphinx التوضيحي جيد: معالج الـ webhook الخاص بك صار يحفظ معرّف حدث Stripe قبل استدعاء charge(). ماذا يحدث عند إعادة المحاولة بعد انتهاء المهلة؟ إذا قلت «سيُحاسَب العميل مرتين»، فأنت مخطئ، لأن المعرّف المحفوظ يقطع إعادة المحاولة. لكن ماذا لو فشل charge() نفسه؟ عندها ستتخطى إعادة المحاولة التالية الشحن. لن يُحاسَب العميل أبدًا، ولن يفشل أي اختبار، لأن هذا نمط idempotency يبدو صحيحًا لكنه مطبّق بترتيب خاطئ.

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

هناك فائدة ثانية أقل تعلقًا بالتقاط الأخطاء وأكثر تعلقًا بعكس تسرّب المهارة البطيء. كثير من المطورين يصفون التجربة نفسها: دفع الوكيل نحو نتيجة تعمل يستهلك طاقة حقيقية لكنه لا يترك شيئًا مكتسبًا. تشحن أكثر وتفهم أقل، والفجوة تتراكم. اختبار قصير وقت الـ push يجبرك على إعادة بناء ولو سطحي لمنطق الـ diff، وهذا غالبًا كافٍ لتحويل «كود وافقتُ عليه» إلى «كود أملكه». سبق أن قلت إن أدوات الذكاء الاصطناعي تغيّر طريقة تفكير المطورين بهدوء، وبوابات كهذه من أوائل الأدوات التي تدفع في الاتجاه المعاكس.

متى تنتصر الاختبارات الآلية؟

لا نبالغ في تمجيد البوابة البشرية. الاختبارات تنتصر بوضوح في مجالات عدة، والتظاهر بغير ذلك هو ما يجعلك تعتمد على اختبار كشبكة أمان وحيدة.

• كشف الانحدار على نطاق واسع. لا يصمد تصور ذهني لأي أحد أمام إعادة هيكلة من 30,000 سطر. الاختبارات تعيد التحقق من آلاف السلوكيات في كل commit بتكلفة زهيدة، بينما قد يغطي فحص الفهم ثلاثة أسئلة تقريبًا لـ diff واحد.
• الصحة الميكانيكية. أخطاء off-by-one، وصيغ السلاسل الخاطئة، وسوء معالجة المناطق الزمنية. الآلات أفضل بكثير في الفحص الشامل لهذه من إنسان يجيب على أسئلة تحت ضغط الوقت.
• القابلية للتكرار. الاختبار يعمل بالطريقة نفسها إلى الأبد. جودة سؤال الاختبار تعتمد على النموذج الذي ولّده وعلى مدى يقظتك في الخامسة مساءً يوم جمعة.
• الثقة في إعادة الهيكلة. عندما يجب ألا يتغير السلوك إطلاقًا، الاختبارات هي الفحص الوحيد ذو المعنى. فهمك للكود لا يساعدك على التحقق من أنك لم تغيّره.

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

متى تنتصر فحوصات الفهم؟

تنتصر فحوصات الفهم تحديدًا حيث يكون الإنسان الحلقة الأضعف، وهذا في التطوير المدعوم بالوكلاء أكثر مما نحب أن نعترف.

• الاستدلال على مسارات الفشل. إعادة المحاولة، والمهلات الزمنية، والكتابات الجزئية، والمعاملات الموزعة: هذه مسارات الكود التي لا تُنفَّذ إلا عندما يكون شيء آخر معطّلًا أصلًا. الوكلاء جيدون في المسار السعيد ومتهاونون مع المسار الحزين.
• الـ diffs عالية نطاق الضرر. المدفوعات، والمصادقة، وعمليات ترحيل البيانات، وأي شيء يمس أنظمة يجب أن تقاوم الكوارث. كلفة الإجابة الخاطئة هنا تفوق بكثير دقيقتين من احتكاك الاختبار.
• كود لم تكتبه ولم تراجعه بالكاد. طلب سحب من 1,500 سطر من زميل غير مطور، أو فرع الوكيل المستقل الذي عمل طوال الليل. ذكر أحد الممارسين أنه استخدم موجهًا بعنوان «اختبرني على هذا الـ PR» فقط ليبقى مركّزًا أثناء مراجعة منظمة لهذا النوع تحديدًا.
• التأهيل وصيانة المهارة. إذا كان فريقك يشحن كود الوكلاء أسرع مما يتعلم أحد المجال، فبوابة الفهم هي أرخص آلية إجبار متاحة.

القاسم المشترك: فحوصات الفهم تستحق وجودها عندما يكون الـ diff ذا عواقب وعندما يكون التصور الذهني للإنسان موضع شك. هذا مجال محدد، وليس مجالًا عامًا.

إخفاقات البوابة نفسها

سأكون مقصرًا في حقك إن لم أذكر قائمة صادقة بطرق فشل هذا النهج، فالمشككون لديهم نقاط حقيقية.

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

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

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

بوابة الفهم لا تتحقق من الكود. إنها تتحقق من أن إنسانًا لديه السياق والمسؤولية قد تفاعل معه فعلًا، وهذا بالضبط ما أزالته سير عمل الوكلاء بهدوء.

بناء البوابة داخل سير عمل حقيقي

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

المسار المفروض هو Git hook. يُثبَّت Sphinx في دقيقة: npm install -g sphinx-understand ثم sphinx install، وهو يربط Git ووكلاء البرمجة لديك ويسألك أي نموذج يجب أن يراجع. يعمل مع Claude Code وCodex وCursor وغيرها، أو مع Git العادي، ويمكنه العمل عبر أي نقطة نهاية متوافقة مع OpenAI. إذا أردت بناءه بنفسك، فالهيكل الأساسي هو hook باسم pre-push:

#!/usr/bin/env bash
# .git/hooks/pre-push — quiz gate for protected branches
protected_branch="main"
current_branch=$(git rev-parse --abbrev-ref HEAD)
if [ "$current_branch" != "$protected_branch" ]; then
exit 0  # only gate the branches that matter
fi
diff=$(git diff origin/main...HEAD)
if [ -z "$diff" ]; then
exit 0
fi
# Send the diff to your model of choice, get a scenario question,
# check the answer. Pseudocode for the core loop:
question=$(quiz_generate "$diff")
echo "$question"
read -r answer
if ! quiz_verify "$diff" "$question" "$answer"; then
echo "Not quite — here's why. Push blocked; try again."
exit 1
fi

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

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

التوصية

الاختبارات وفحوصات الفهم ليستا متنافستين، فهما تتحققان من موضوعين مختلفين. الاختبارات تتحقق من الكود، وفحوصات الفهم تتحقق من الشخص المسؤول عنه. التطوير المدعوم بالوكلاء كسر الافتراض الضمني بأن الاثنين شيء واحد، وهذه البوابات ترقيع عملي، وليست خدعة.

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