أصبحت نماذج اللغة الكبيرة (LLMs) شبه مثالية في توليد الكود، لكن هذه ليست نهاية القصة. مجرد أن الكود صحيح شكليًا لا يعني أنه لا يقدم تجريدات غير ضرورية، أو ينشئ تكرارات، أو يتخذ قرارات سيئة بشكل عام. هذه ليست ملاحظة رائدة، معظم الأشخاص الذين قاموا ببرمجة مشروع بطريقة "vibe-coded" أدركوا أن كل ميزة إضافية يمكن أن تؤدي أحيانًا إلى انفجار في أسطر الكود (LOC). يؤدي هذا إلى فقدان الوكالة البشرية، لأنه في المشاريع التي تضيف ملايين الأسطر شهريًا، يصعب على البشر مواكبة ذلك. قد يقول بعض الناس أن هذه ليست مشكلة على الإطلاق، لأنهم يثقون في وكلائهم للتعامل معها. لدي أخبار سيئة لك، الوكلاء لا يمكنهم حقًا التعامل مع الإهمال أيضًا.

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

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

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

الكيانات الرئيسية: الشركات: Earendil