حذّر Addy Osmani من دين الفهم في توليد الكود بواسطة AI على نطاق واسع

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

من أين تنشأ ديون الفهم

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

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

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

السرعة مقابل الفهم

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

في فريق حقيقي، يظهر هذا في عدة أماكن في نفس الوقت:

• مطور مبتدئ يمكنه أن يُنتج أكوداً أكثر مما يستطيع محترف أن يراجعه بشكل نقدي
• طلبات السحب تنمو أسرع مما تستطيع الفريق استعادة السياق المعماري
• الموافقة على التغييرات تتحول من تحليل إلى إجراء رسمي
• مقاييس السرعة تتحسن، حتى عندما يسقط الفهم الحقيقي للنظام

لماذا الاختبارات غير كافية

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

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

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

سيتعين على الفهم أن يُدفع ثمناً له، والفوائد على هذا الدين تنمو بسرعة.

ما يعنيه هذا

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