هل لا تزال جودة الكود مهمة في عصر الذكاء الاصطناعي؟ يعتمد الأمر على شيء واحد
اسأل أي مهندس برمجيات كبير سؤالًا، ومن شبه المؤكد أن تحصل على إجابته المفضلة المكونة من كلمتين: «يعتمد الأمر.»
في عصر أدوات الترميز بالذكاء الاصطناعي و«vibe coding»، وصل النقاش حول ما إذا كانت جودة الكود لا تزال مهمة إلى ذروة على وسائل التواصل الاجتماعي. في عرض تقديمي لقناة AI Engineer، يتجاوز ماكس كانات-ألكسندر (Capital One) الحجج الثنائية «نعم أو لا» ليقدم إطارًا ملموسًا لمعرفة متى تكون الصرامة الهندسية حرجة — ومتى يمكنك رميها من النافذة.
الأساس: لماذا يوجد الكود أصلاً
قبل أن تقرر ما إذا كانت جودة الكود مهمة، علينا أن نثبت ما تحاول ممارسات هندسة البرمجيات تحقيقه فعليًا. وفقًا لكانات-ألكسندر، كل ما تريد إنجازه بقطعة من البرمجيات — سواء محاذاة نموذج، أو توسيع نظام، أو دفع التبني — ينحصر في عاملين:
- فهم النظام.
- التنفيذ بناءً على هذا الفهم.
لا توجد أدوات التصحيح والمراقبة والتقييمات والاختبارات في فراغ؛ إنها موجودة حصريًا لتحسين فهمنا للنظام وقدرتنا على التصرف بناءً عليه. بالنسبة لمهندس البرمجيات، ينحصر هذا في سؤالين حرجين:
- ما هو السلوك الفعلي والملموس للنظام؟ (ليس فقط ما تدعيه الوثائق أنه يفعله.)
- كيف أعدل هذا السلوك بشكل صحيح وآمن؟
بينما برنامج «Hello World» البسيط سهل الاستيعاب بالكامل، فإن أنظمة العالم الحقيقي — مثل قاعدة كود Chromium مفتوحة المصدر الضخمة — لها تفاعلات محتملة لا نهائية تقريبًا. لا يمكن لأي إنسان أن يحتفظ بسلوك Chromium بالكامل في رأسه. بدلاً من ذلك، نعتمد على فهم مكونات محددة، مثل محلل URL.
لهذا يوجد الكود: من أجل الهيكل. في الماضي، تحدث المهندسون عن مفاهيم مثل «قابلية القراءة» و«قابلية الاختبار»، التي تبدو كمخاوف بشرية بحتة. ما كان دائمًا الأهم تحت السطح هو الهيكل القابل للتعرف والفهم.
الدورة الشريرة لمخاطر التعديل
الهيكل يكون أهم عندما تحتاج إلى تعديل نظام. كل تعديل يحمل خطرين:
- إدخال مشكلة فورية: هذا ليس مجرد خطأ — قد يكون تفويت موعد نهائي، أو تجاوز ميزانية، أو سلوك مستخدم غير متوافق ناجم عن صعوبة فهم النظام.
- جعل التغييرات المستقبلية أصعب: بتقليل جودة الهيكل، تجعل النظام أصعب للفهم في المرة القادمة.
الخطر #2 يغذي مباشرة الخطر #1 في دورة مركبة وغير خطية. مع الوقت، يمكن لقواعد الكود العملاقة أن تصل إلى حالة حيث كل تغيير واحد يطلق احتكاكًا تنظيميًا أو تأخيرات في الجدول الزمني أو حوادث إنتاج.
الانقسام الكبير: البرمجيات الدائمة مقابل القابلة للتصرف
بينما يناقش الناس ما إذا كانت نماذج الذكاء الاصطناعي المستقبلية ستمتلك في النهاية قدرة لا نهائية على فك التعقيد الهائل، فإن الذكاء الاصطناعي يفعل شيئًا آخر الآن بالفعل: يجعل البرمجيات القابلة للتصرف أكثر شيوعًا بـ100,000 مرة.
تاريخيًا، قضى المهندسون معظم وقتهم في بناء وصيانة البرمجيات الدائمة — أنظمة تعيش لسنوات، تخدم آلاف أو ملايين المستخدمين، وتحمل عواقب تجارية كارثية إذا فشلت. البرمجيات الدائمة لن تختفي؛ في الواقع، من المرجح أن تؤدي أدوات الذكاء الاصطناعي إلى بناء المزيد من البرمجيات الدائمة.
ومع ذلك، تسمح وكلاء الذكاء الاصطناعي لنا أيضًا بتشغيل برمجيات حيث:
- عواقب الفشل ضئيلة أو غير موجودة.
- قليل من الأشخاص (ولا أنظمة إنتاج أخرى) يعتمدون عليها.
- تكلفة الاستبدال شبه صفرية (يمكن إعادة بنائها في ساعات).
- تكلفة الصيانة هي في الأساس لا شيء.
لا تحب حاسبة نظام التشغيل لديك؟ اطلب من وكيل بناء واحدة مخصصة. تخطط لحفل عيد ميلاد طفل؟ شغّل تطبيق مخطط حفل لمرة واحدة وارمه يوم الاثنين. في عالم البرمجيات القابلة للتصرف، لا تهم جودة الكود على الإطلاق لأن المخاطر المركبة للتعديلات المستقبلية ببساطة غير موجودة.
| عامل التقييم | البرمجيات القابلة للتصرف | البرمجيات الدائمة |
|---|---|---|
| عواقب الفشل | ضئيلة إلى معدومة | عالية / حرجة للأعمال |
| الاعتماديات | معزولة؛ يستخدمها شخص أو قليل | يعتمد عليها آلاف/ملايين أو أنظمة أخرى |
| تكلفة الاستبدال | شبه صفرية (قابلة للاستبدال في ساعات/أيام) | مرتفعة للغاية |
| تكلفة الصيانة | غير مهمة أو شبه مجانية | استثمار مستمر ضخم |
| الصرامة الهندسية المطلوبة | لا شيء | الحد الأقصى |
تخصصان جديدان للهندسة الحديثة
لأن القابلية للتصرف والديمومة موجودتان على طيف، فإن فرق البرمجيات الحديثة لديها رافعتان استراتيجيتان يمكنهما سحبهما.
1. الهندسة من أجل القابلية للتصرف
بدلاً من تطبيق عمليات ثقيلة على كل شيء، يمكن للمنظمات هندسة بيئات تجعل البرمجيات آمنة للتخلص منها عمدًا:
- بيئات معزولة: أنشئ صناديق رمل تصل فقط إلى بيانات مستخدم فردي، مع صفر وصول إلى بيانات العملاء أو المعلومات الشخصية.
- استقلالية مفروضة: امنع استدعاءات API الواردة من أنظمة إنتاج أخرى حتى لا يعتمد شيء عن طريق الخطأ على أداة قابلة للتصرف.
- تكرار دائم: احتفظ بنظام قديم موثوق و«ثقيل» كنسخة احتياطية، بينما تدع الموظفين «vibe code» واجهات أمامية مخصصة سريعة لسير عملهم الخاص. إذا تعطلت واجهتهم المخصصة، يعودون ببساطة إلى النظام الدائم.
- حدود نطاق صارمة: أبقِ الأدوات مركزة للغاية على مستخدم واحد أو حدث واحد.
2. خفض تكلفة الصرامة
يعرف المهندسون ذوو الخبرة أن النماذج الأولية «المؤقتة» لها عادة أن تصبح أنظمة إنتاج دائمة. إذا أخطأت في تقدير موقع مشروع على الطيف — أو غيرت رأيك لاحقًا — تريد أن يكون الانتقال من القابل للتصرف إلى الدائم سلسًا قدر الإمكان. تحقق ذلك بجعل الصرامة الهندسية رخيصة ودون جهد:
- توحيد صارم: توحيد اللغات والأطر وبروتوكولات RPC ليس بيروقراطية؛ إنه إزالة للإمكانيات. أطر أقل تعني أدوات تحليل أقل وتصحيحات أمان وأدوات وكلاء مخصصة يجب صيانتها.
- أدوات داخل سير العمل: ابني فحوصات جودة تعمل تلقائيًا في الخلفية. عندما تكون الأدوات سريعة وموثوقة وقليلة الإيجابيات الكاذبة وتتطلب صفر جهد واعٍ من المطور، فإنها تبدو مجانية — مما يعني أنه يمكنك تطبيقها حتى على المشاريع القابلة للتصرف.
- بنية تحتية للاختبار بلا احتكاك: لا تطلب من كل مطور أن يكون خبير اختبارات. استثمر في بنية تحتية تجعل الاختبارات سريعة وحتمية من البداية — على سبيل المثال، استخدام وكلاء الترميز لتوليد وصيانة إصدارات وهمية في الذاكرة من الخدمات تلقائيًا.
- الحد الأقصى من الصرامة من اليوم الأول: فعّل جميع قواعد التحليل وإعدادات الصرامة إلى الحد الأقصى من اليوم الأول. هذا يلغي النقاشات اللانهائية للفريق ويمنع كابوس محاولة تفعيل محلل بأثر رجعي على قاعدة كود بمليون سطر.
الحكم
إذن، هل لا تزال جودة الكود مهمة؟ يتركنا كانات-ألكسندر بثلاث إجابات واضحة:
- للبرمجيات القابلة للتصرف؟ لا.
- للبرمجيات الدائمة؟ نعم.
- هل يجب أن تكون الصرامة باهظة؟ لا.
بناءً على محاضرة ماكس كانات-ألكسندر لـ AI Engineer.