في هذا المقال
أضافت جوجل إلى بيئة التطوير Antigravity أمرا جديدا اسمه boost/، يشغل عند استدعائه خط تفكير متعدد الوكلاء بدل مساعد برمجي واحد. الفكرة باختصار: وكيل منسق يقرأ المشكلة ويفككها إلى مهام، ثم يوزعها على وكلاء متخصصين يعملون في نطاقات معزولة، ثم تمر النتيجة على جولات تحقق مستقلة تشغل الاختبارات فعليا قبل أن يصلك الجواب. الأهم في الخبر ليس أن الذكاء الاصطناعي صار يكتب كودا أسرع، بل أن أدوات البرمجة بدأت تبني التحقق داخل الأداة نفسها.
ما الذي أعلنته جوجل بالضبط
حسب وثائق Antigravity الرسمية، أمر boost/ مصمم لمهام الهندسة البرمجية الصعبة تحديدا: أخطاء التزامن وحالات السباق، تحسين الخوارزميات، الانحدارات الخفية التي تظهر ثم تختفي، وإعادة الهيكلة المتشابكة عبر ملفات متعددة. هذه أنواع المشكلات التي يفشل فيها المساعد التقليدي الذي يجيب في جولة واحدة، لأن حلها يحتاج تجريبا وتراجعا لا توليدا مباشرا.
يعمل الأمر عبر ثلاث مراحل واضحة:
- التخطيط: وكيل منسق رئيسي يقرأ طلبك ويفحص سياق مساحة العمل، ثم يصوغ استراتيجية تنفيذ ويقسم التحدي إلى مهام فرعية قابلة للتحقق.
- التنفيذ الموزع: يرسل المنسق المهام إلى وكلاء متخصصين: وكلاء تنفيذ يكتبون الكود والاختبارات، ووكلاء تحقيق يتتبعون جذر المشكلة ومسارات الاستدعاء دون تعديل أي ملف، ووكلاء يشغلون أوامر البناء ومجموعات الاختبار محليا للتأكد من الفرضيات قبل رفع النتيجة.
- التحقق قبل التسليم: يجمع المنسق النتائج ويشغل فحوص الانحدار على مجموعات الاختبار الكاملة والحالات الحدية. وإذا سقط تأكيد، تعاد رسائل الخطأ إلى الجولة التالية للتصحيح الآلي، ولا يصل إليك ملخص التغييرات إلا بعد اجتياز الاختبارات.
ويعمل كل هذا داخل أشجار عمل معزولة ومؤقتة، بمعنى أن الوكلاء لا يعبثون بنسختك من المشروع أثناء التجريب.
ثلاثة أوضاع لا وضع واحد
وثقت جوجل ثلاثة أنماط تشغيل متمايزة، والفرق بينها هو المهم عمليا:
- الوكيل الافتراضي: برمجة تفاعلية وتنقل في الكود وإعادة هيكلة عامة. أفق المهمة ثوان إلى دقائق، وحلقة وكيل واحد، وتحقق بمرور واحد. متاح في كل الخطط.
- boost/: التفكير العميق والأخطاء المستعصية. أفق المهمة ثوان إلى ساعات، هرمية من ثلاث مراحل، وتحقق مستقل متعدد الجولات. متاح في الخطط المدفوعة.
- teamwork-preview/: فرق وكلاء تعمل أياما على هجرات ضخمة أو بناء أنظمة فرعية كاملة، بأدوار مسماة مثل المستكشف والعامل والناقد والمدقق، وبوابات تحقق تحاول كسر الكود عمدا قبل اعتماد أي مرحلة.
لاحظ التدرج: كلما كبرت المهمة، زاد الاستثمار في المراجعة لا في السرعة. هذه إشارة تستحق الانتباه من أي شخص يدير مشروعا برمجيا.
لماذا يهم هذا صاحب العمل لا المبرمج فقط
خلال العامين الماضيين تحول النقاش حول الذكاء الاصطناعي في البرمجة إلى نقاش سرعة: كم سطرا تولد في الدقيقة. المشكلة أن السرعة ليست عنق الزجاجة في المشاريع الحقيقية. عنق الزجاجة هو الثقة: هل هذا الكود يعمل فعلا في الحالات التي لم يجربها أحد؟
ما تقوله بنية boost/ ضمنيا هو أن الصناعة اكتشفت الحقيقة نفسها. لا قيمة لكود يصل أسرع إذا كان يحتاج أسبوعين من التصحيح بعد التسليم. لذلك بنيت الأداة حول ثلاث قواعد تصلح لأي فريق تقني، بذكاء اصطناعي أو بدونه:
- من يكتب لا يصدق نفسه: الجهة التي تتحقق منفصلة عن الجهة التي نفذت. هذا هو مبدأ مراجعة الكود منذ عقود، لكنه صار الآن مفروضا في الأداة.
- الدليل تشغيل لا ادعاء: الاختبارات تشغل فعليا وتقارن مخرجاتها الحقيقية، لا يكتفى بقول إنها ناجحة.
- العزل يحمي الأصل: التجريب يجري في نسخة معزولة، فلا تنتقل التجارب الفاشلة إلى المشروع.
إن كنت تشتري تطويرا برمجيا، فهذه بالضبط الأسئلة الثلاثة التي يجب أن تسألها لمزودك: من يراجع؟ وما دليل نجاح الاختبارات؟ وأين تجري التجارب؟
ما الذي لا يتغير
من السهل أن يقرأ هذا الخبر على أنه إعلان استغناء عن المهندسين. الوثائق نفسها تقول عكس ذلك بوضوح: الوكلاء يرثون صلاحيات الملفات وسياسات الأوامر المضبوطة لمساحة العمل، وأي أمر محمي أو تعديل خارج النطاق الموثوق يرفع طلب موافقة إلى المستخدم. أي أن هناك إنسانا مسؤولا في نهاية السلسلة.
وهناك ما هو أبعد من الصلاحيات. الوكيل يحل المشكلة التي وصفتها له، ولا يعرف أن الوصف نفسه خاطئ. لا يعرف أن دورة الفوترة في شركتك تنتهي يوم 25 لا 30، ولا أن هذا الحقل يجب ألا يظهر لموظف المبيعات، ولا أن العميل يقصد بكلمة «طلب» شيئا مختلفا عما تقصده أنت. تحديد المتطلبات وفهم المجال وتحمل مسؤولية القرار تبقى بشرية بالكامل.
كيف نقرأ هذا في أوريجامي
نتعامل مع أدوات الوكلاء المتعددة كما نتعامل مع أي أداة إنتاجية: تسرع التنفيذ، ولا تسقط المسؤولية. المشروع عندنا يمر بمواصفات مكتوبة ومراجعة بشرية واختبارات وبيئة تجريبية قبل الإنتاج، سواء كتب الكود إنسان أو ولده وكيل. الأداة التي تشغل اختباراتها بنفسها إضافة مرحبا بها إلى هذه السلسلة، لكنها حلقة فيها لا بديل عنها.
الخلاصة العملية لصاحب العمل: توقع أن تقصر مدد التطوير في المهام المعقدة تحديدا، لكن لا تقبل تسليما بلا اختبارات ولا توثيق ولا مالك بشري. الأدوات التي تراجع نفسها ترفع سقف الجودة الممكنة، ولا تلغي حاجتك إلى من يضمن أن ما بني هو ما طلبت.
المصادر
أسئلة شائعة
ما الفرق بين أمر boost والمساعد البرمجي العادي؟
المساعد العادي يجيب في جولة واحدة بوكيل واحد، ويناسب كتابة الميزات والتنقل في الكود. أما boost فيشغل ثلاث مراحل: منسق يفكك المشكلة، ووكلاء متخصصون ينفذون في نطاقات معزولة، ثم جولات تحقق مستقلة تشغل الاختبارات وفحوص الانحدار قبل التسليم. صمم تحديدا للأخطاء الصعبة مثل حالات السباق وإعادة الهيكلة المتشابكة، وهو متاح في الخطط المدفوعة حسب وثائق جوجل.
هل تعني هذه الأدوات أنني لن أحتاج شركة تطوير؟
لا. الوكيل ينفذ ما وصفته له، ولا يستطيع أن يكتشف أن الوصف نفسه خاطئ أو ناقص. تحديد المتطلبات وفهم قواعد عملك ودورات الفوترة والصلاحيات وربط الأنظمة القائمة واتخاذ القرار عند التعارض تبقى مهام بشرية. وثائق جوجل نفسها تنص على أن أي أمر محمي أو تعديل خارج النطاق الموثوق يحتاج موافقة صريحة من المستخدم.
كيف أعرف أن مزود البرمجيات لدي يعمل بهذا المستوى من الجودة؟
اسأل ثلاثة أسئلة محددة: من يراجع الكود غير من كتبه؟ وهل توجد مجموعة اختبارات تشغل آليا قبل كل نشر، وهل أستطيع رؤية نتائجها؟ وهل يوجد بيئة تجريبية منفصلة عن الإنتاج؟ إن كانت الإجابات غامضة، فالمشكلة ليست في الأدوات المستخدمة بل في العملية نفسها.
هل بياناتي أو كودي في خطر إذا استخدم فريقي وكلاء برمجة؟
الخطر يعتمد على الضبط لا على الأداة. راجع ثلاثة أمور قبل التبني: أين يخزن الكود ومن يطلع عليه حسب شروط المزود، وما الصلاحيات الممنوحة للوكيل على الملفات والأوامر، وهل الأسرار ومفاتيح الإنتاج مفصولة عن بيئة التطوير. وضع سياسة مكتوبة لهذه النقاط قبل أن يبدأ الاستخدام أسهل بكثير من معالجتها بعده.
تابع أوريجامي في نتائج قوقل
ثبت أوريجامي كمصدر مفضل، فتظهر لك مقالاتنا أولا في نتائج قوقل وفي الأخبار الرائجة.
الإضافة إلى المصادر المفضلة في Google
