JetBrains Air: هل تتحوّل بيئة التطوير إلى مضيف لكل وكلاء البرمجة؟
أعلنت JetBrains برنامج وصول مبكر لـAir، نظام مفتوح يستضيف Codex وCopilot وCursor عبر ACP. ما الذي أُعلن فعلاً وما حدوده، وما المخاطر، وكيف تجرّبه عملياً؟
في أول أكتوبر 2026 أعلنت JetBrains برنامج وصول مبكر لمنتج اسمه Air، ووصفته بأنه «نظام مفتوح من المنتجات للتطوير الوكيلي». الخبر يمرّ بسهولة وسط زحام إعلانات الأسبوع، لكنه يحمل سؤالاً مهماً للمطوّرين: ماذا لو لم تكن بيئة التطوير هي التي تملك الوكيل، بل صارت هي المنصّة التي تستضيف أي وكيل تختاره؟ في هذا المقال نفصل ما أُعلن فعلاً عمّا لم يُعلن، ونقرأ ما يعنيه ذلك لطريقة عملك اليومية.
ما الذي أُعلن فعلاً؟
بحسب ما نشرته SD Times في ملخّصها الإخباري ليوم 1 أكتوبر 2026، يصل Air عبر قناتين: إضافة (plugin) من JetBrains Marketplace، وبُنى 2026.3 EAP من بيئات JetBrains. أي أنه ليس تطبيقاً مستقلاً مغلقاً، بل طبقة تُضاف إلى بيئات تعرفها أصلاً.
النقاط المؤكَّدة في الإعلان:
- يعمل Air مع وكلاء مثل Codex وGitHub Copilot وJunie وCursor، ومع أي وكيل يدعم بروتوكول ACP.
- يكتشف تلقائياً الوكلاء المثبّتة على جهازك ويدمجها داخل البيئة.
- لا يتطلب اشتراك JetBrains AI، إذ يمكنك استخدام اشتراكاتك الحالية لدى مزوّدي الذكاء الاصطناعي، بما فيها Claude، أو شراء JetBrains AI إن أردت.
- تمنح أدوات البيئة المدمجة الوكلاءَ قدرات متخصصة: التنقيح، وتحليل الأداء، واستكشاف قواعد البيانات، والبحث الدلالي في الكود.
لم يتضمن الإعلان، في ما اطّلعنا عليه، أرقاماً للأداء ولا جدولاً زمنياً للإصدار المستقر ولا تسعيراً مستقبلياً. وهذه فجوة يجب أن تبقيها في ذهنك قبل أي قرار اعتماد.
لماذا يهمّ أن النظام «مفتوح»؟
حتى الآن كانت معظم أدوات البرمجة الوكيلية تأتي كحزمة واحدة: المحرّر مع الوكيل مع النموذج. إن أردت تغيير أحدها خسرت الباقي. نهج Air يعكس هذا الترتيب: البيئة هي الثابت، والوكيل هو القطعة القابلة للاستبدال.
دور بروتوكول ACP
اعتماد Air على ACP هو الجزء الأهم تقنياً. فبدل أن تكتب كل بيئة تكاملاً خاصاً لكل وكيل، يكفي أن يلتزم الوكيل ببروتوكول مشترك ليظهر داخل أي بيئة تدعمه. الفكرة مألوفة لمن عاصر بروتوكول خادم اللغة (LSP) الذي وحّد دعم اللغات في المحرّرات؛ وقد شرحنا نسخة قريبة منها في سياق الوكلاء في مقالنا عن بروتوكول MCP.
ما الذي تكسبه البيئة من الوكيل؟
الوكيل الذي يعمل في طرفية معزولة يرى ملفات نصية فقط. أما الوكيل المدمج في بيئة تطوير فيستطيع، نظرياً، أن يسأل البيئة عن الرموز والمراجع والأنواع بدل أن يقرأ المشروع كله. ويلمّح إعلان JetBrains إلى أن هذا قد يقلّل استهلاك الرموز (tokens) في بعض المهام، لكنه لم يقدّم قياساً يثبت ذلك، فالأفضل التعامل مع الادعاء كفرضية تُختبر على مشروعك.
مقارنة سريعة: ثلاثة نماذج لتشغيل الوكلاء
| النموذج | من يملك الوكيل؟ | حرية الاستبدال | مثال |
|---|---|---|---|
| وكيل مدمج مع المحرّر | مزوّد المحرّر | منخفضة | محرّرات برمجة بوكيل خاص |
| وكيل في الطرفية | مزوّد النموذج | متوسطة | أدوات سطر الأوامر |
| بيئة مضيفة لعدة وكلاء | أنت | عالية | Air وفق وصف JetBrains |
الفارق الحقيقي في هذا الإعلان ليس وكيلاً جديداً، بل تحوّل موقع بيئة التطوير من منافس للوكلاء إلى مضيف لهم.
ما الذي يعنيه هذا لفريقك؟
فرصة: فصل الاشتراك عن الأداة
بما أن Air لا يشترط اشتراك JetBrains AI، فيمكن لفريق يدفع أصلاً لمزوّد نماذج أن يستخدم اشتراكه داخل بيئة يعرفها. هذا يخفّض احتكاك التجربة، ويسهّل مقارنة أكثر من وكيل على المهمة نفسها دون تغيير المحرّر.
مخاطرة: اتساع سطح الصلاحيات
كلما زاد عدد الوكلاء المثبّتين على جهازك واكتشفتها البيئة تلقائياً، زادت الأسئلة عن الصلاحيات: أي وكيل يصل إلى أي ملف؟ وأي أداة يستطيع تشغيلها؟ ننصحك قبل التفعيل بمراجعة الإعدادات الافتراضية بدقة، وتجربة Air في مستودع غير حسّاس أولاً. وقد تناولنا هذا الجانب في مقالات سابقة عن عزل الوكلاء وصلاحياتهم.
خطوات عملية للتجربة
- ثبّت بناء 2026.3 EAP أو الإضافة في بيئة اختبار، لا على جهاز العمل الأساسي.
- اترك Air يكتشف وكلاءك، ثم راجع قائمة ما اكتشفه قبل منحه أي صلاحية.
- اختر مهمة صغيرة قابلة للقياس، مثل إصلاح اختبار فاشل أو إعادة تسمية عبر عدة ملفات.
- نفّذ المهمة نفسها بوكيلين مختلفين وقارن الوقت وعدد الرموز المستهلكة.
- دوّن النتائج قبل أن تقرّر هل يستحق الأمر التوسّع.
الصورة الأوسع: IBM Bob وتوجّه المؤسسات
في الأسبوع نفسه أعلنت IBM خيار نشر ذاتي الاستضافة لمنصتها الوكيلية IBM Bob، يستهدف البيئات المحلية والسحابة الخاصة والسحابة السيادية والبيئات المعزولة عن الإنترنت. هذا يشير إلى اتجاه آخر في السوق: المؤسسات الخاضعة لقواعد إقامة البيانات تريد وكلاء لكن تحت سيطرتها. وبين نهج JetBrains المفتوح للأفراد والفرق ونهج IBM للمؤسسات المنظّمة، يتّضح أن سوق أدوات البرمجة الوكيلية يتفرّع بدل أن يتوحّد.
كيف تقيّم أداة كهذه دون الانبهار بالإعلان؟
الإعلانات تعرض أفضل سيناريو، أما قرارك فيحتاج معايير واضحة. نقترح أربعة أسئلة قبل أن تعتمد Air أو أي بيئة مضيفة للوكلاء:
- الشفافية: هل ترى بوضوح ما يفعله الوكيل وما الملفات التي قرأها والأوامر التي نفّذها؟
- التحكّم: هل تستطيع إيقاف وكيل بعينه أو تقييد صلاحياته دون تعطيل البيئة كلها؟
- التكلفة: هل يبقى استهلاك الرموز قابلاً للتتبع عبر الوكلاء المختلفين، أم يضيع في فواتير متفرقة؟
- الاستمرارية: إن غيّر مزوّد وكيل ما شروطه أو أوقف خدمته، فهل يستمر عملك بوكيل بديل في المكان نفسه؟
السؤال الأخير هو الأهم على المدى الطويل. فقد رأينا في 2026 كيف يمكن لواجهة برمجية أن تُغلق فجأة، ومن بنى سير عمله على منتج واحد دفع الثمن. البيئة المضيفة المفتوحة تقلّل هذا الخطر نظرياً، لكنها لا تلغيه: ستبقى معتمداً على جودة التكامل نفسه وعلى استمرار JetBrains في دعمه.
ملاحظة للفرق الصغيرة
إن كنت مطوّراً مستقلاً أو فريقاً من عدة أشخاص، فأكبر فائدة قريبة هي تجربة أكثر من وكيل على مشروعك دون تبديل أدواتك. أما إن كنت في مؤسسة ذات قيود امتثال، فاسأل أولاً أين تُعالَج بياناتك عند استخدام كل وكيل، فبيئة مفتوحة لا تعني بالضرورة بيانات تبقى في مكانها.
أسئلة شائعة
هل يحتاج Air إلى اشتراك JetBrains AI؟
لا وفق الإعلان؛ يمكن استخدام اشتراكاتك الحالية لدى مزوّدي الذكاء الاصطناعي، مع إمكانية شراء JetBrains AI اختيارياً.
هل Air جاهز للاستخدام في الإنتاج؟
لا. هو في مرحلة الوصول المبكر ضمن بُنى EAP، وهذه البُنى عرضة للتغيّر وقد تحتوي أخطاء. استخدمه للتجربة والتقييم.
أي الوكلاء يعمل معها؟
Codex وGitHub Copilot وJunie وCursor، إضافة إلى أي وكيل متوافق مع ACP.
الخلاصة
JetBrains لم تُطلق وكيلاً جديداً، بل راهنت على أن قيمة بيئة التطوير ستبقى في ما تعرفه عن مشروعك، وأن الوكلاء سيتبدّلون من حولها. إن صحّ الرهان فسيصبح اختيار الوكيل قراراً قابلاً للتغيير كل شهر دون هجرة المحرّر. لكن ما دام المنتج في الوصول المبكر ودون أرقام منشورة، فالموقف العملي هو التجربة المحدودة والقياس على مشروعك، لا الاعتماد على الوعود. راقب إصدار 2026.3 المستقر لتعرف هل تحوّل الإعلان إلى منتج.
