كاتب على Habr ينفّذ ثلاث أدوات بلغة Rust بأسلوب الفايب كودينغ: DirMerge وProcessTree وNotepad

نشر كاتب السلسلة على Habr دفعة جديدة من الأدوات التي كُتبت بمساعدة LLM بلغة Rust، وهي DirMerge وProcessTree وNotepad. ثلاثة برامج وسؤال واحد: هل يمكن بناء أدوات بمساعدة شبكة عصبية بحيث يستخدمها الإنسان فعلًا كل يوم، ولا يعود بعد أسبوع إلى برامجه القديمة؟ ويصف الكاتب نفسه ما يجري بأنه «شيزوفازيا مع الفايب كودينغ»، فنبرة السخرية من الذات حاضرة منذ البداية.

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

ما الذي يجري اختباره تحديدًا

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

يمكن افتراض، من الأسماء، أن DirMerge يتولى دمج المجلدات، وأن ProcessTree يعرض العمليات على شكل شجرة، وأن Notepad يحل محل محرر النصوص. هذه مهام كلاسيكية توجد لها منذ زمن حلول ناضجة. لذلك ستُقارَن الأدوات الجديدة بمنافسين أقوياء جدًا.

لماذا Rust ولماذا أدوات بسيطة

لم يُختَر Rust لهذه التجربة عبثًا. فالمترجم يتحقق بصرامة من ملكية الذاكرة ومن الأنواع، ولذلك يُكتشف أثناء البناء جزء من الأخطاء التي ترتكبها LLM عادةً في اللغات الديناميكية. والنتيجة ملف تنفيذي واحد بلا بيئة تشغيل ثقيلة. أما الوجه الآخر فهو أن النماذج تتعامل بشكل أضعف مع borrow checker وlifetimes، وقد تستغرق دورة «ولّد الكود، فلم يُبنَ، فصحّح» الكثير من التكرارات.

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

ما هو معروف عن التجربة:

• اللغة: Rust؛
• الأسلوب: الفايب كودينغ بمشاركة LLM؛
• عدد الأدوات في هذا الجزء: ثلاث (DirMerge وProcessTree وNotepad)؛
• المعيار: استبدال الأدوات التي يستخدمها الكاتب عمليًا؛
• الخطر الرئيسي الذي حدده الكاتب: مشكلات لا حل لها يضطر بعدها إلى العودة إلى البرامج القديمة؛
• لم يكشف الإعلان عن النموذج ولا عن حجم الكود ولا عن مقاييس الأداء.

كيف تستفيد من هذه التجربة

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

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