مهندس واحد أطلق وكيل macOS دون أن يعرف Swift

تتيح ميزة Computer Use الجديدة من Qoder للذكاء الاصطناعي تشغيل سطح مكتب حقيقي: رؤية الشاشة، والنقر على الأزرار، والكتابة، والسحب، والاستمرار في الخلفية. لم يتمكن المهندس الذي بنى الميزة من قراءة الكود الذي أنتجته، لأنه لم يكن يعرف Swift. هذه التفاصيل، المذكورة في سجل بناء الفريق على مجتمع Alibaba Cloud، أكثر إثارة للاهتمام من الميزة نفسها.

يصف منشور المشروع الأمر بصراحة: "لم أكن أعرف ما إذا كان الكود صحيحًا، لكنني كنت أستطيع معرفة ما إذا كانت الأداة تشغّل الكمبيوتر بشكل صحيح." شخص واحد، دون معرفة بـ Swift، كان عليه تقديم برنامج macOS أصلي بجودة إنتاجية. التعريف الوحيد القابل للتطبيق لكلمة "منجز" كان السلوك.

مهندس واحد، دون Swift، وأداة سطح مكتب تنقر نيابة عنك

تبدو Computer Use بسيطة حتى تدوّن ما يتطلبه "النقر على زر". يجب أن يكون للإجراء تأثير فعلي. يجب أن تكون الحالة بعد الإجراء قابلة للقراءة. ويجب ألا تستولي الأداة على الواجهة الأمامية، لأن وكيلًا يسحب التركيز بعيدًا عن المستخدم في كل مرة يتصرف فيها ليس شيئًا سيشغله أي شخص مرتين. يسرد سجل البناء هذه التحديات الثلاثة الملموسة للمشروع.

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

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

من طلب واستجابة إلى حلقة تعمل طوال الليل

كانت الخطوة الأولى بناء خط أنابيب يمكن للوكيل إكماله بمفرده. تعتمد Computer Use على أذونات النظام، ويجب توقيع كل بناء بنفس الشهادة، وإلا سيتعامل معه macOS كتطبيق جديد ويلغي أذونات تسجيل الشاشة وإمكانية الوصول الممنوحة بالفعل. طوّر الفريق المسار بأكمله، من بناء المصدر إلى التوقيع المستقر إلى الإطلاق إلى الاختبارات، في أمر واحد. لا يحتاج الوكيل أبدًا إلى فهم التوقيع. يحتاج فقط إلى طريق موثوق إلى حزمة صالحة.

التشغيل مرة واحدة لا يكفي. محادثة الوكيل العادية هي طلب واستجابة: تنتهي المهمة، ويتوقف الوكيل. بناء أداة يتطلب دورات عديدة، لأن الترجمة تفشل، والاختبارات تفشل، والسلوك خاطئ في تطبيق واحد، أو أن الإصلاح يكسر شيئًا في مكان آخر. إجابة Qoder هي وضع الهدف. أعطِ الوكيل هدفًا، مثل "نفّذ أداة النقر واجتاز الاختبار الشامل"، وسيستمر في العمل والتنفيذ والاختبار والإصلاح وإعادة المحاولة حتى يتقارب أو يحتاج بوضوح إلى قرار بشري.

الاختبار الأخضر الذي لم يُثبت شيئًا

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

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

إصلاح الاثنين يعود يوم الأربعاء

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

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

يستشهد المقال بفشلين حقيقيين بجذر واحد: لم تكن للوكيل ذاكرة عبر الجولات. وضع كل المعرفة في المطالبة (Prompt) لا يعمل، لأن نافذة السياق ليست كبيرة بما يكفي والشرح اليدوي يفوّت دائمًا شيئًا ما. حل الفريق هو الاحتفاظ بالذاكرة في نظام الملفات، مقسمة إلى طبقتين. تحتفظ ذاكرة المشروع بالمعرفة المستقرة: البنية، والقيود، واستنتاجات البحث. تحتفظ ملاحظات الاستعرض (Retrospectives) بما تغير في كل جولة، وما تبقى، وأين يجب أن تبدأ الجولة التالية.

دليل docs/ هو تخطيط الذاكرة:

docs/
├── specs/              المتطلبات ومعايير القبول
├── architecture/       البنية والقيود الأساسية
├── implementation/     ملاحظات حول وحدات التنفيذ الرئيسية
├── research/           البحث التقني وأساس القرارات
├── plans/              خطط التكرار للمرحلة التالية
├── retrospectives/     مراجعات كل جولة، والمسائل المفتوحة، والمخاطر
├── evidence/           نتائج الاختبار وسجلات التحقق من السلوك
└── test-cases/         مصدر سيناريوهات الاختبار وتغطيتها وتاريخها

في بداية كل جولة، يقرأ الوكيل ذاكرة المشروع والاستعرض السابق. وفي النهاية، يكتب التحديثات. الحلقة الكاملة هي الهدف، ثم التنفيذ، ثم التحقق، ثم الاستعرض، ثم الهدف التالي. لا تبدأ أي جولة من الصفر بعد الآن.

هندسة الحلقات، والحاجز الذي تحرك

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

تحول دور الإنسان من كتابة الكود ومراقبة التنفيذ إلى تحديد المعايير، وتصميم التحقق، واختيار الاتجاه. أصبح مصطلح "هندسة الحلقات" (Loop Engineering) شائعًا مؤخرًا، ويقول الفريق إنه تعرف على ممارسته الخاصة في هذا التصنيف. إذا عملت الحلقة، لم يعد المهندس بحاجة إلى أن يكون خبيرًا في حزمة تقنية معينة لتقديم برامج بجودة إنتاجية. تتوقف الحزمة عن كونها الحاجز الرئيسي. المهم هو القدرة على تحديد الهدف والتحقق من النتيجة.

يتضمن Qoder Desktop بالفعل وضع الهدف وقدرات Spec، ويقوم الإصدار الأخير بترقية UltraPlan وUltraReview. أدوات التحقق العامة مثل Computer Use وBrowser Use مصممة لمساعدة الفرق على بناء أنظمة التكرار الذاتي الخاصة بها. الادعاء الأكثر هدوءًا في المنشور هو الذي يستحق التأمل: لم يعد المهندس بحاجة إلى خبرة عميقة في حزمة تقنية لشحن برامج إنتاجية بها. لم تكن الحزمة أبدًا الحاجز الحقيقي. كان التحقق هو الحاجز.