قادة الفكر

الكتابة البرمجية بواسطة الذكاء الاصطناعي، ولكن هل يمكن لبيئتك保持 المسار؟

mm
أضف Unite.AI إلى مصادرك المفضلة على Google

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

لقد قمت بتقديم سنوات من العمل على أدوات DevOps، وشاركت في تأليف الأبحاث، ومساعدة فرق الهندسة على الوصول إلى أعلى أداء لها. ما أراه الآن مع التطوير الموجه بواسطة الذكاء الاصطناعي هو أكثر من مجرد تطور. إنه يكشف كل شق في سير عملنا الحالي.

المشكلة موجودة بالفعل

دراسة 2025 GitClear وجدت أن ما يقرب من 7٪ من التعديلات تحتوي على رمز تم إنشاؤه بواسطة الذكاء الاصطناعي. وتحليلهم السابق ل 153 مليون سطر من رمز تم تغييره كشف عن التكلفة: “تقلب الرمز” – الرمز المكتوب أو المحذوف في غضون أسبوعين – تضاعف بحلول عام 2024 مقارنة بالأسس السابقة للذكاء الاصطناعي.

الآثار الأمنية لا تقل حدة. التحليل الأخير ل 80 مهمة برمجة محددة عبر أكثر من 100 نموذج لغة كبير وجد أن الرمز المولود بواسطة الذكاء الاصطناعي يُroduce ثغرات أمنية في 45٪ من الحالات. ما هو التأثير في العالم الواقعي؟ واحد من كل خمسة مسؤولين أمنيين يُبلغون الآن عن حوادث رئيسية تسبب فيها رمز تم إنشاؤه بواسطة الذكاء الاصطناعي.

الربح في السرعة حقيقي، ولكن التكاليف الثابتة حقيقية أيضًا.

تأثير التضخيم

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

وكلاء الذكاء الاصطناعي يتبعون نفس النمط. إذا أعطيت لهم بيئة متسقة حيث يعني Python نفس الإصدار عبر كل मशينة مطور، حيث يتم تتبع الاعتماديات وقفلها، فهم يتفوقون. إذا أجبرتهم على التنقل في 17 تكوينًا مختلفًا، كل منها يختلف بشكل دقيق، فإنك تحرق رموزًا في تحديد تفاصيل البيئة بدلاً من حل المشكلات الفعلية.

مفارقة التحديد

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

إجابتي؟ احتفظ بكمية كبيرة من المكدس بالتحديد قدر الإمكان. إذا كنت يمكن أن تحتفظ ب 80٪ من بنيتك التحتية على مستوى تحديد، فإن وكلاء الذكاء الاصطناعي لديهم متغيرات أقل لإدارةها. هم لا يبذرون نوافذ السياق في “لماذا لم تثبت هذه الاعتماديات؟” أو “دعني أجرّب هذا الأمر مرة أخرى.” هم يركزون على العمل الفعلي الذي تطلب منهم القيام به.

فكر في الأمر: عندما يحاول وكيل تجميع شيء ما ويفشل الارتباط الأصلي بسبب عدم تثبيت ImageMagick، هذا هو تحويل مكلف. إذا كانت بيئتك بالفعل تحتوي على كل ما هو مطلوب (المجمعات، المكتبات، شجرة الاعتماد الكاملة حتى libc)، فإن الوكيل يعمل ببساطة. لا يوجد تصحيح، لا تجربة وخطأ، فقط تقدم.

التحديد والتحقق هما المفتاح

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

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

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

الثقة ولكن التحقق (والسيطرة)

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

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

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

ما يأتي بعد ذلك

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

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

إليك نصيحتي الأكبر لأي فرق تحاول النجاح في عصر الذكاء الاصطناعي:

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

  • ابني التحقق في سير العمل، لا في النهاية. مع توليد الذكاء الاصطناعي للرمز بسرعة أكبر من التي يمكن للمطورين مراجعتها، لا يمكنك الاعتماد على مراجعة الرمز اليدوية فقط. قم بتنفيذ اختبارات آلية تُحقق ليس فقط تشغيل الرمز، ولكن حل الحاجة الفعلية. اجعل трубة CI/CD شباك أمانك، مع بوابات قوية في وقت التشغيل لتنصيب الإنتاج.

  • استثمر في التكرار كبنية تحتية. اعامل συνέISTENCE من البيئة على أنها مشكلة أولية في البنية التحتية. عندما يمكنك إثبات رياضيًا أن بيئتك المحلية، وبيئتك في CI، وبيئتك في الإنتاج متساوية، تُزيل فئة كاملة من مشاكل “يعمل على جهازي”. هذا الأساس التحديدي هو ما يسمح لك بتركيب حمولات الذكاء الاصطناعي الاحتمالي بأمان.

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

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

مايكل هو حاليًا نائب رئيس الهندسة في فلوز. كان مسؤولًا سابقًا في القيادة الهندسية في سيركل سي آي و بوبيت، حيث قام بزيادة فرق الهندسة بأكثر من 5 مرات. قام ببناء فرق عالية الأداء، ومنظمات، وبحث في الفعالية الهندسية بالإضافة إلى العمل على أنظمة التعبئة والإصدار. كان يتحدث في أحداث ديف أوبس وأوتوميشن منذ عام 2007. أسس مستودع الحزم إكسترا باكاجز فور إنتربرايز لينكس (إي بي إي إل) وكتب كتابًا عن أوبن إس إس إتش في عام 2005.