الترجمة: لماذا لا تستطيع نماذج اللغات الكبيرة إنشاء برامج بقلم كونراد إيروين شيء واحد أقضي الكثير من الوقت في القيام به هو إجراء مقابلات مع مهندسي البرمجيات. من الواضح أن هذه مهمة صعبة ، ولا أجرؤ على القول إن لدي أي حيل. لكنها منحتني الوقت للتفكير في ما يفعله مهندس البرمجيات الفعال. الدورة الأساسية لهندسة البرمجيات عندما تنظر إلى متذوق حقيقي ، سترى أنه يقوم دائما بالخطوات التالية في دورة: * بناء نموذج عقلي للاحتياجات. * اكتب (نأمل؟!) ) التعليمات البرمجية التي تنفذ المتطلبات. * قم ببناء نموذج عقلي لكيفية تصرف التعليمات البرمجية الخاصة بك بالفعل. * ابحث عن الفرق بين الاثنين ، ثم قم بتحديث الكود (أو المتطلبات). هناك العديد من الطرق لإنجاز هذه الخطوات ، ولكن الشيء العظيم في المهندسين الفعالين هو قدرتهم على بناء نماذج عقلية واضحة والحفاظ عليها. كيف تعمل نماذج اللغات الكبيرة؟ لكي نكون منصفين ، فإن نماذج اللغات الكبيرة جيدة جدا في كتابة التعليمات البرمجية. كما أنهم يقومون بعمل جيد في تحديث الكود عندما تشير إلى المشكلة. يمكنهم أيضا القيام بكل الأشياء التي قد يفعلها مهندس حقيقي: قراءة التعليمات البرمجية ، وكتابة الاختبارات وتشغيلها ، وإضافة السجلات ، و (من المفترض) استخدام مصحح الأخطاء. لكن ما لا يمكنهم فعله هو الحفاظ على نموذج ذهني واضح. سوف تقع نماذج اللغة الكبيرة في ارتباك لا نهاية له: سيفترضون أن الكود الذي يكتبون قابل للاستخدام بالفعل. عندما يفشل الاختبار ، يمكنهم فقط تخمين ما إذا كان رمز إصلاح أو اختبارا ثابتا. عندما يشعرون بالإحباط ، فإنهم ببساطة يقطعون كل شيء ويبدأون من جديد. هذا هو عكس ما أتوقعه من مهندس. يختبر مهندسو البرمجيات أثناء عملهم. عندما يفشل الاختبار ، يمكنهم استخدام نموذجهم العقلي لتحديد ما إذا كان سيتم إصلاح الكود أو الاختبار ، أو جمع المزيد من المعلومات قبل اتخاذ القرار. عندما يشعرون بالإحباط ، يمكنهم طلب المساعدة من خلال التواصل مع الناس. على الرغم من أنهم يحذفون كل شيء في بعض الأحيان ويبدأون من جديد ، إلا أنه خيار يتم اتخاذه بعد فهم أوضح للمشكلة. لكنها ستكون قريبا ، أليس كذلك؟ هل سيتغير هذا عندما تصبح النماذج أكثر قدرة؟ ربما؟؟ لكنني أعتقد أن هذا يتطلب تغييرا جوهريا في طريقة بناء النماذج وتحسينها. تتطلب هندسة البرمجيات نماذج أكثر من مجرد إنشاء تعليمات برمجية. عندما يواجه الشخص مشكلة ، يكون قادرا على تنحية السياق بأكمله جانبا مؤقتا والتركيز على حل المشكلة المطروحة ، ثم العودة إلى المشكلة الكبيرة المطروحة. يمكنهم أيضا التبديل بين الصورة الكبيرة والتفاصيل الدقيقة ، وتجاهل التفاصيل مؤقتا للتركيز على الكل ، والبحث في الأجزاء عند الضرورة. لا نصبح أكثر إنتاجية بمجرد حشر المزيد من الكلمات في "نافذة السياق" الخاصة بنا ، فهذا لن يؤدي إلا إلى الجنون. على الرغم من أننا نستطيع التعامل مع قدر كبير من السياق ، إلا أننا نعلم أن هذه النماذج التوليدية لديها حاليا العديد من المشكلات الخطيرة التي تؤثر بشكل مباشر على قدرتها على الحفاظ على نماذج عقلية واضحة: * الإغفال السياقي: النماذج ليست جيدة في اكتشاف المعلومات السياقية التي تم التغاضي عنها. * تحيز الحداثة: يخضعون لتحيز حداثة شديد عند العمل مع نوافذ السياق. * الهلوسة: غالبا ما "يتخيلون" التفاصيل التي لا ينبغي أن تكون موجودة. قد لا تكون هذه المشاكل مستعصية على التغلب عليها ، ويعمل الباحثون على إضافة الذاكرة إلى النماذج حتى يتمكنوا من ممارسة مهارات تفكير مماثلة لأننا نفعل. لكن لسوء الحظ ، في الوقت الحالي ، لا يمكنهم (بعد تجاوز مستوى معين من التعقيد) فهم ما حدث بالفعل. لا يمكنهم إنشاء برامج لأنهم لا يستطيعون الحفاظ على "نموذجين عقليين" متشابهين في نفس الوقت ، ومعرفة الاختلافات ، وتحديد ما إذا كانوا يريدون تحديث التعليمات البرمجية أو تحديث المتطلبات. إذن ماذا الآن؟ من الواضح أن نماذج اللغات الكبيرة مفيدة لمهندسي البرمجيات. يقومون بإنشاء التعليمات البرمجية بسرعة ويتفوقون في دمج المتطلبات والوثائق. بالنسبة لبعض المهام ، هذا يكفي: المتطلبات واضحة بما فيه الكفاية ، والمشاكل بسيطة بما يكفي بحيث يمكن القيام بها بين عشية وضحاها. ومع ذلك ، بالنسبة لأي مهمة ذات بعض التعقيد ، لا يمكنهم الحفاظ على سياق كاف بدقة كافية للتكرار لإنتاج حل قابل للتطبيق في النهاية. بصفتك مهندس برمجيات ، فأنت لا تزال مسؤولا عن التأكد من أن المتطلبات واضحة وأن الكود يقدم بالفعل ما يدعي القيام به. في Zed ، نؤمن بمستقبل حيث يمكن للبشر ووكلاء الذكاء الاصطناعي بناء البرامج معا. ومع ذلك ، فإننا نعتقد اعتقادا راسخا (على الأقل في الوقت الحالي) أنك السائق خلف عجلة القيادة ، وأن نماذج اللغات الكبيرة هي مجرد أداة أخرى في متناول يدك.