جزء من “السيطرة على الإنتروبيا”

معظم المشكلات التي أواجهها مع الكود المولد بالذكاء الاصطناعي تتعلق بالثقة. هل أثق بالشخص الذي كتب هذه التذكرة؟ هل أثق بأن المهندس الذي فتح طلب السحب هذا فهم التذكرة ووجه وكيل الترميز لتنفيذها بشكل صحيح؟ هل أثق في تنفيذ وكيل الترميز؟ هل أثق في مجموعة اختباراتنا لالتقاط التراجعات قبل وصولها للإنتاج؟ هل أثق في خط CI/CD الخاص بنا لبناء واختبار ونشر تغييراتنا بشكل صحيح؟ هل أثق في إعداد المراقبة لدينا لتنبيهنا عندما يكسر الكود المولد بالذكاء الاصطناعي الإنتاج؟ هل أثق في مهندس موثوقية الموقع (SRE) بالذكاء الاصطناعي لتشخيص المشكلة بشكل صحيح ومساعدتنا في التخفيف منها؟ هل أثق في Git Hub بعدم وقوع حادث عندما نكون في أمس الحاجة إليه؟ الثقة يصعب كسبها ويسهل فقدانها. لذلك أعتقد أنه من الضروري تعزيز ثقافة الثقة داخل فريق الهندسة. يجب أن تثق في المهندسين للقيام بالشيء الصحيح.

تشجيع المساءلة

أجد أنه من المفيد توصيل شيء مثل هذا بوضوح: “أنت مسؤول عما تشحنه. إذا كسر هذا الإنتاج وكنت من كتب طلب السحب، فيجب أن تكون موجوداً لإصلاحه.”

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

إليك بعض الممارسات التي وجدتها مفيدة لتسهيل مساءلة الهندسة في عصر الترميز الجديد هذا:

إرشادات الترميز

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

أدوات حتمية

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

فرض طلبات سحب صغيرة

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

امتلاك الاختبارات

اكتب حالات الاختبار يدوياً. هذا مشابه لعمل محلل الأعمال. فكر بعمق في الميزة وحدد سيناريوهات الاختبار المناسبة. ناقش هذا داخل الفريق. يمكن لوكلاء الترميز تنفيذ الاختبارات، ولكن يجب تحديدها من قبل البشر.

الذوق في المنتج

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

النموذج الأولي

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

التركيز على النتيجة

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