Флант: كيف حوّل مطوّر Go محرر Zed ونموذج Gemini إلى وكيل ذكاء اصطناعي مفيد

وصف مطوّر Go في شركة «Флант» مسارًا عمليًا تعرفه فرق كثيرة: يبدأ بالفضول تجاه إضافات الذكاء الاصطناعي، ثم خيبة الأمل منها، وصولًا إلى منظومة عمل يخفّف فيها الوكيل فعلًا جزءًا من الأعمال الروتينية عن المطوّر. والفكرة الرئيسية للمقال بسيطة: نموذج اللغة الكبير (LLM) بحد ذاته بالكاد يرفع الإنتاجية إذا كان وصوله إلى سياق المشروع ضعيفًا، وواجهته بطيئة، وأدواته غير مناسبة للغة البرمجة المعنية.

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

جاءت المرحلة التالية مع وصول مؤسسي إلى عدة نماذج. قيّم المؤلف جودة إجابات GPT-4o بأنها أعلى بوضوح من GigaChat، لكن ذلك لم يحلّ المشكلة الأساسية. وعندما أتاحت الشركة الوصول عبر مفتاح API، جُرّبت في بيئة التطوير إضافات شائعة مثل Cline وContinue. وكانت النتيجة ضعيفة مجددًا: فالمزيج المكوّن من بيئة التطوير ومنطق الواجهة الويب والنموذج الخارجي كان بطيئًا، وظل العمل مرهقًا.

وكانت نقطة التحول مع وكلاء الطرفية. كان OpenCode شائعًا بين الزملاء، لكن المؤلف اختار Crush لأن تثبيته أسهل ولأن الأداة مكتوبة بلغة Go. وهناك حصل لأول مرة على فائدة حقيقية: كان الوكيل قادرًا على تحليل المشروع وقراءة الملفات وكتابة الشيفرة واستخدام LSP وMCP. غير أن وكيل الطرفية لم يكن المحطة الأخيرة أيضًا؛ فللعمل اليومي مع مستودع Git وقاعدة الشيفرة كان لا يزال ينقص ما يوفّره المحرر من راحة.

لذلك انتقل المؤلف إلى Zed، وهو محرر سريع مكتوب بلغة Rust، يضم لوحة ذكاء اصطناعي مدمجة ووكيلًا خاصًا به، ويدعم الوكلاء الخارجيين عبر ACP. ويشرح في المقال بالتفصيل كيفية ربط Zed بخدمة LLM المؤسسية عبر Open-WebUI وواجهة API متوافقة مع OpenAI، واختيار نموذج Gemini 3 Flash، وإعداد ملف تعريف write بالأدوات اللازمة: diagnostics وread_file وgrep وlist_directory وterminal وthinking وweb_search. ويشدد المقال على تفصيل عملي: مفتاح API لا يُخزَّن في ملف الإعدادات، بل يُدخَل يدويًا عبر واجهة المحرر.

أما الجزء التقني الأهم فيتعلق بلغة Go وجودة السياق. يبيّن المؤلف بمثال بسيط أن أداة grep المدمجة تعثر على التطابقات النصية فقط، وتقود النموذج بسهولة إلى افتراضات خاطئة إذا صيغ الطلب بشكل فضفاض. ولكي يعمل الوكيل بما يقرب من دلالات الشيفرة، يربط gopls في وضعه التجريبي MCP. ولأن LSP العادي في Zed لا يزال موجّهًا للإنسان لا للوكيل، يضطر إلى تشغيل gopls-mcp منفصل بمتغيرات بيئة خاصة به ومهلة زمنية (timeout) أطول. لكن الوكيل يحصل بعد ذلك على أدوات من فئة مختلفة: نظرة عامة على مساحة العمل (workspace)، وواجهات الحزم (API)، والبحث عن الرموز، والإحالات إلى الرموز، وإعادة التسمية الآمنة، والتشخيص، وحتى فحص التبعيات بحثًا عن الثغرات المعروفة.

ويخرج القارئ من المقال بمذكّرة مفيدة لاختيار منظومة البرمجة بالذكاء الاصطناعي. فينبغي أولًا اختيار LLM قادر على العمل في وضع الوكيل ويحلّ مهام البرمجة بشكل جيد؛ وللتقدير التقريبي ينصح المؤلف بالنظر إلى التوازن بين الجودة والسعر والسرعة وحجم نافذة السياق. ثم اختيار الوكيل نفسه: إذ تهمّ توافقيته مع النموذج المطلوب، ومجموعة معقولة من الأدوات (tools) المدمجة، ودعم MCP، وعند الحاجة دعم تعدد الوكلاء. وبعد ذلك فقط يصبح من المجدي الاشتغال على المطالبات (prompts). ومن التقنيات التي يعدّها المؤلف عملية فعلًا: role prompting، وإرفاق السياق صراحةً، والتخطيط خطوة بخطوة، وstep-back prompting، واستخدام أمثلة من الشيفرة القائمة أو الاختبارات.

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