شهد عام 2026 انتشارًا واسعًا لوكلاء AI المخصصين للبرمجة، لكن فعاليتهم تتفاوت بشكل كبير من مهمة لأخرى. ففي حين قد يتفوق نموذج في بناء موقع ويب مثالي، قد لا يكون بنفس الكفاءة في كتابة نصوص Bash المعقدة. لاختبار قدرات هذه النماذج في بيئة عملية، تم إجراء تجربة على مشروع إلكتروني حقيقي: لوحة تحكم بسيطة تعتمد على وحدة ESP32، وشاشة OLED، ومستشعر درجة حرارة، تؤدي عدة وظائف في آن واحد. وقد وضعت ثلاثة من أبرز هؤلاء الوكلاء تحت الاختبار: Claude Code، و OpenAI Codex، و Google Antigravity، وكانت النتائج مثيرة للاهتمام، حيث أظهرت أن اختيار المساعد البرمجي المناسب ليس بالأمر الهين.
تحدي لوحة تحكم ESP32 الذكية
تم تصميم مشروع لوحة التحكم هذا لحل مشكلة شخصية تتعلق بمراقبة استخدام خطة Claude Pro، بالإضافة إلى دمج بيانات درجة الحرارة والرطوبة مع نظام Home Assistant، وعرض حالة الطقس الخارجية. كان الهدف بناء لوحة تحكم تعرض ثلاثة أشياء رئيسية:
- عرض حدود استخدام خطة Claude.
- عرض قراءة درجة الحرارة والرطوبة من مستشعر DHT22 وإرسالها إلى Home Assistant.
- عرض الطقس ودرجة الحرارة في مدينة نيودلهي.
يتكون المشروع من لوحة ESP32 Devkit V1، ومستشعر DHT22، وشاشة OLED أحادية اللون من نوع SH1106 بحجم 128×64 بكسل، وزر دفع رباعي الأطراف للتنقل بين الأوضاع المختلفة. وقد تم تزويد الوكلاء الثلاثة بنفس الموجه (prompt) بالتفاصيل المذكورة أعلاه، وكان الهدف هو الوصول إلى نموذج أولي يعمل بكامل المهام بأقل عدد ممكن من الأوامر البسيطة.
ESP32 هو متحكم دقيق منخفض التكلفة مزود بتقنيات Wi-Fi و Bluetooth مدمجة، ويُستخدم على نطاق واسع في مشاريع إنترنت الأشياء (IoT) والإلكترونيات المنزلية الصنع.
تجارب الوكلاء: Antigravity، Codex، و Claude Code
اختلفت أساليب الوكلاء بشكل كبير في التعامل مع هذا المشروع، مما أدى إلى نتائج متباينة.
Antigravity: السرعة في التخطيط، التعقيد في التنفيذ
بدأ Antigravity، الذي يعمل بنموذج Gemini 3.1 Pro من Google، بسرعة مذهلة في التخطيط. فبمجرد تلقيه الموجه، قام بالبحث عن كيفية التحقق من حدود استخدام Anthropic API وقدم خطة تنفيذ مع بعض الأسئلة الإضافية. بينما بدأ Codex و Claude Code في إنتاج أكواد برمجية جاهزة للتحميل على ESP32، أصر Antigravity على الموافقة على خطته قبل كتابة سطر واحد من الكود.
بعد توضيح الشكوك، قدم Antigravity خطة تنفيذ أخرى وذكر بوضوح أنه لن يتمكن من جلب حدود استخدام اشتراك Claude Pro نظرًا لعدم وجود API رسمي من Anthropic لهذه الوظيفة. ومع ذلك، وبعد تزويده برابط لمستودع Clawdmeter على GitHub، تمكن النموذج من اكتشاف إمكانية استخدام رمز الوصول OAuth الذي يولده Claude CLI وإرساله إلى نقطة نهاية API تجريبية معينة لجلب الحدود. ومع ذلك، لم ينتج Antigravity سطرًا واحدًا من الكود حتى هذه المرحلة.
بمجرد الموافقة على خطة العمل النهائية، أنشأ Antigravity مشروع PlatformIO يعمل لمدة دقيقتين تقريبًا، منتجًا سلسلة من الملفات لطلب بيانات اعتماد Wi-Fi ورمز OAuth بشكل منفصل عن الكود المصدري الرئيسي. هذا النهج جيد من الناحية الأمنية، لكنه يضيف تعقيدًا غير ضروري لجهاز لن يغادر الشبكة المحلية، وقد يكون مربكًا للمبتدئين.
Codex: سوء فهم المهمة والتركيز على حل واحد
وكيل OpenAI's Codex، الذي يستخدم GPT 5.5، لم يضيع الوقت وأنتج ملفي YAML في حوالي ثلاث دقائق من تلقيه الموجه، لكنه اتجه في اتجاه غير متوقع تمامًا. فقد استخدم ESPHome لتكوين ESP32 كمستشعر يظهر بشكل طبيعي في Home Assistant. كان هذا النهج مثاليًا إذا كان المشروع مخصصًا فقط لمستشعر DHT22، لكنه لم يكن مناسبًا للوحة تتعامل مع مهمتين أخريين.
أشار Codex أيضًا إلى عدم وجود API رسمي لجلب حدود استخدام Claude Pro، لكنه لم يسمح لهذه العقبة بإيقافه. فقد أنشأ `input_number` في Home Assistant باسم `input_number.claude_plan_usage_percent`، لتعيين رقم يدويًا (أو عبر أتمتة) للإشارة إلى الاستخدام. وعند تزويده برابط مشروع Clawdmeter على GitHub، فهم Codex النهج لكنه استمر في مسار ESPHome والأرقام اليدوية. ومع ذلك، فقد قدم مخططًا واضحًا للأسلاك لتوصيل جميع المكونات.
يتطلب هذا النهج الكثير من الحلول البديلة والممارسات غير المثلى التي تضيف تعقيدًا دون سبب وجيه. بدا وكأن Codex ركز على جزء مستشعر درجة الحرارة من التعليمات (ربما لأنه موثق بشكل أفضل) وحاول تكييف كل شيء آخر ليعمل ضمن هذا النظام البيئي، بدلاً من تغيير الهيكل ليناسب المهمة بشكل أفضل.
Claude Code: البطء في البداية، الدقة في النهاية
كان Claude Code، الذي يستخدم Sonnet 4.6 من Anthropic، الأبطأ بين الوكلاء الثلاثة في البداية، ويرجع ذلك أساسًا إلى التحميل الزائد على الخادم. ومع ذلك، بعد بعض التفكير، أنتج Claude ملف INO واحدًا (يستخدمه Arduino IDE) قام بجميع المهام الثلاثة بشكل صحيح من الإصدار الأول.
على عكس رفض Antigravity أو انحراف Codex، حل Claude Code مشكلة جلب حدود الاستخدام عن طريق إرسال POST /v1/messages مع `max_tokens:1` إلى Haiku، وإرجاع الرؤوس التي تظهر الطلبات والرموز المتبقية في النافذة الحالية. كان واضحًا للغاية بشأن ما ستظهره النتائج وما لن تظهره (لم يتضمن استهلاك الرموز الشهرية). وعند تزويده برابط مشروع Clawdmeter، تكيف Claude Code على الفور، وقام بتحديث كود Arduino بالرؤوس الجديدة، وقدم معاينة لما سيظهر، وملف INO واحد جاهز للتحميل على ESP32، بالإضافة إلى تعليمات حول مكان العثور على رمز OAuth الخاص بـ Claude.
مثل Antigravity، استخدم Claude Code واجهة REST API المدمجة في Home Assistant لإرسال بيانات درجة الحرارة من المستشعر، لكنه أشار بذكاء إلى أن التكامل لن يستمر بعد إعادة تشغيل خادم Home Assistant إلا إذا قامت اللوحة بنشر البيانات مرة أخرى قبل اكتمال إعادة التشغيل. واقترح استخدام MQTT لتكامل أنظف، والذي سيتطلب بعض الإعدادات الإضافية في Home Assistant.
ماذا يعني هذا لك؟
بالنسبة لمثل هذا المشروع، كان Claude Code هو النموذج الذي قدم أفضل النتائج. فقد وفر مخطط أسلاك نظيف وملف INO واحد للعمل به، مما قلل من تعقيد المشروع بشكل كبير. بالنسبة لجهاز سيبقى على شبكتك المحلية، لا يوجد سبب لإضافة ملفات إضافية لرموز OAuth أو بيانات اعتماد Wi-Fi. علاوة على ذلك، إذا كنت تستخدم Claude Code بشكل متكرر، فقد يكون لديه بالفعل مخزون اللوحات والمستشعرات المحفوظة في ذاكرته، ويعرف عنوان IP المحلي لمثيل Home Assistant الخاص بك، ويقوم بتضمين كل ذلك مباشرة في الكود، مما يقلل من عدد التعديلات المطلوبة قبل تحميل ESP32.
كان Antigravity منافسًا قويًا، فقد حاول القيام بكل شيء بشكل صحيح، لكنه أضاف تعقيدًا غير ضروري، وكان يجب تصحيح الكود يدويًا قبل أن يعمل. كما أن Antigravity لم يقدم مخططًا للأسلاك، مما يعني الاضطرار إلى البحث في الكود لمعرفة كيفية توصيل الأجهزة.
أخيرًا، اتخذ Codex القرار الصحيح باستخدام ESPHome، ولكن فقط في سياق لوحة التحكم كونها محطة استشعار درجة حرارة في المقام الأول. على الرغم من تقديم الإرشادات حول كيفية جلب حدود الاستخدام، استمر في مسار ESPHome، مما أضاف تعقيدًا غير ضروري وأجبر على إعداد كل شيء في YAML، بينما كان تحميل اللوحة عبر Arduino IDE أسهل بكثير لهذا النوع من المهام.
اختيار الأداة المناسبة يعتمد على المشروع: لا توجد أداة واحدة أفضل عالميًا من الأخرى. تكشف البرامج الثابتة المضمنة الفجوة بين الأدوات التي تولد الكود والأدوات التي تفهم المشكلة بالفعل. ستختلف نتائجك اعتمادًا على الأداة التي تستخدمها غالبًا والنهج الذي ترغب في اتباعه.
خاتمة
في النهاية، أثبتت التجربة أن جميع الأساليب الثلاثة يمكن أن تعمل، لكن بعضها يتطلب تعديلات أكبر من البعض الآخر. بالنسبة لمشروع يتطلب تعاون أنظمة فرعية مختلفة على أجهزة محدودة، أنتج نهج Claude Code الأكثر بطئًا وتأنياً وبساطة النتائج الوحيدة التي يمكن تحميلها على اللوحة واستخدامها فورًا دون الحاجة إلى تعديلات كبيرة. يؤكد هذا على أن فهم متطلبات المشروع واختيار وكيل AI المناسب الذي يمتلك القدرة على التفكير المنطقي وتقديم حلول متكاملة، هو مفتاح النجاح في عالم تطوير الإلكترونيات باستخدام AI.
