10 مبادئ للبرمجة بالذكاء الاصطناعي من مؤسس OpenClaw
بيتر شتاينبرغر، مؤسس المشروع الأسرع في جمع النجوم في تاريخ GitHub، يشارك 10 مبادئ عملية للعمل مع وكلاء البرمجة بالذكاء الاصطناعي.
تأثرت بشكل حقيقي بمقابلة بيتر شتاينبرغر، مؤسس OpenClaw (المعروف سابقاً بـ Clawdbot) - المشروع الذي حقق أسرع نمو في النجوم في تاريخ GitHub.
بيتر مخضرم أدار شركة تضم 60-70 شخصاً لمدة 13 عاماً، باعها، أخذ استراحة ثلاث سنوات، ثم عاد. رؤيته للتطوير في عصر الذكاء الاصطناعي تختلف جذرياً عما يفترضه معظمنا.
بداية بسيطة
لم تكن هناك خطة عمل طموحة في البداية. أراد فقط “اللعب بالذكاء الاصطناعي”، وانتهى به الأمر ببناء أداة لأنه أراد الدردشة مع حاسوبه المنزلي عبر واتساب أثناء تنقله.
لحظة الإدراك
اللحظة الحاسمة جاءت خلال رحلة. أرسل رسالة صوتية إلى وكيله - لكنه لم يكن قد برمج دعم الصوت أبداً. اكتشف الوكيل تنسيق ملف Opus بنفسه، ووجد ffmpeg لتحويله، وحدد مفتاح API، ونسخ الرسالة وترجمها، ثم أرسل الرد. في تلك اللحظة أدرك أن الوكلاء “وحوش ذكية وواسعة الحيلة”.
بناءً على تجارب كهذه، صاغ بيتر مبادئه العشرة للبرمجة بالذكاء الاصطناعي.
تخلَّ عن الكمالية للعمل مع الذكاء الاصطناعي
إدارة فريق من 70 شخصاً علمته قبول عمل لا يتطابق مع أسلوبه الشخصي. الكود الذي لا يتوافق 100% مع ذوقك لكنه يعمل بشكل صحيح كافٍ. هذه المرونة أصبحت أكبر أصوله عند التعاون مع الوكلاء.
صمم أنظمة يتحقق فيها الوكيل من عمله بنفسه
يسمي بيتر هذا “إغلاق الحلقة (Close the loop)”. الترجمة، الفحص، التشغيل، التحقق - الوكيل يتولى كل شيء. عندما يحتاج البشر لتأكيد خطوات وسيطة، يصبحون عنق زجاجة يبطئ كل شيء.
طلبات السحب ماتت - مرحباً بطلبات البرومبت
الكود نفسه أقل أهمية من البرومبت الذي أنتجه. بيتر يرفض معظم طلبات السحب الخارجية، يستخلص فقط الفكرة الجوهرية ويعيد تدويرها كبرومبت. أخوه يعمل بنفس الطريقة - علامة على أن هذا النمط ينتشر بالفعل.
استبدل مراجعات الكود بنقاشات معمارية
حتى على Discord، الفريق الأساسي لا يتحدث عن الكود. يناقشون بنية النظام والقرارات الكبرى والاتجاه. الفريق بأكمله استوعب أن تفاصيل التنفيذ من مسؤولية الوكيل.
شغّل من 5 إلى 10 وكلاء في وقت واحد
بدلاً من التمسك بمهمة واحدة، ضع مهام متعددة في طابور متوازٍ. خطط، فوّض للوكيل، وانتقل فوراً إلى التالي. هكذا يحافظ بيتر على حالة التدفق طوال اليوم.
خصص وقتاً مفاجئاً للتخطيط
بيتر يتبادل الأفكار مطولاً مع الوكلاء خلال مرحلة التخطيط - يتحدى، يراجع، يعترض، ويكرر حتى تصبح الخطة متينة. يفضل Codex على Claude Code للتنفيذ لأن Claude Code يطرح أسئلة توضيحية أثناء التشغيل مما يقطع التدفق. عندما تكون الخطة محكمة، مرحلة التنفيذ لا تحتاج تقريباً أي تدخل.
أعطِ تعليمات غامضة عمداً
التعليمات المفرطة في التحديد تقيد الذكاء الاصطناعي بالعمل ضمن ذلك النطاق فقط. ترك مساحة عن قصد يتيح للوكيل اكتشاف اتجاهات لم تخطر ببالك. في تجربتي الشخصية، هذا يعمل فعلاً - تظهر حلول غير متوقعة بانتظام. بالطبع، ليس دائماً النهج المناسب.
اختبر محلياً بدل انتظار 10 دقائق لـ CI البعيد
انتظار 10 دقائق لتنفيذ خط أنابيب CI بعيد وقت ضائع. صمم النظام بحيث يشغل الوكلاء الاختبارات محلياً. كلما كانت حلقة التغذية الراجعة أقصر، كلما تسارعت الحلقات التكرارية.
معظم الكود مجرد تحويل بيانات مملة
الجزء الأكبر من كود التطبيقات هو “نقل البيانات من شكل إلى آخر”. لا داعي للتمسك بذلك - فوّضه للوكيل. وفّر طاقتك لتصميم النظام، لا لأعمال السباكة في البيانات.
من يحب إطلاق المنتجات يتكيف أسرع مع الذكاء الاصطناعي
المطورون الذين يستمتعون بحل ألغاز الخوارزميات يواجهون صعوبة أكبر في الانتقال إلى الذكاء الاصطناعي. من يهتم بالنتائج وإطلاق المنتجات يتكيف بسرعة. هذا نمط أراه باستمرار حولي.
رؤية بيتر للمستقبل
يتوقع أن تختفي تطبيقات لا حصر لها، ولا يبقى سوى واجهات برمجة التطبيقات. بدلاً من فتح MyFitnessPal لتسجيل الطعام يدوياً، سترسل صورة لوكيلك الذي سيحسب السعرات الحرارية ويعدّل أهدافك الصحية تلقائياً.
الخلاصة
هناك مجال للنقاش، لكن مبادئ بيتر العشرة تتقارب نحو اتجاه واحد: تخلَّ عن الكمالية، ناقش المعمارية بدل مراجعة الكود، دع الوكلاء يتحققون من عملهم بأنفسهم، وشغّل عدة وكلاء بالتوازي.
كل هذا يتجه نحو بناء بيئة لا يحتاج فيها المطور لكتابة الكود بنفسه. إذا كان هذا هو الاتجاه، فالمهارة الحقيقية في عصر الذكاء الاصطناعي ليست كتابة كود جيد - بل تصميم النظام الذي يحل المشكلات دون أن تكتب سطراً واحداً.
المراجع:
انضم إلى النشرة الإخبارية
احصل على تحديثات حول أحدث مشاريعي ومقالاتي وتجاربي في الذكاء الاصطناعي وتطوير الويب.