قائد تقني في أحد البنوك يوصل بوت Telegram لـ OpenCode إلى 1298 نجمة على GitHub بمساعدة وكلاء الذكاء الاصطناعي

حوّل روسلان، القائد التقني في بنك كبير ولديه خبرة 15 عامًا، تجربة جانبية خلال بضعة أشهر إلى أبرز مشاريعه المفتوحة المصدر. opencode-telegram-bot هو عميل Telegram لـ OpenCode، وهو وكيل شائع لسطر الأوامر في كتابة الشيفرة. وقت نشر هذا العرض على Habr كان للمستودع 1298 نجمة على GitHub و48 مساهمًا. كتب الوكلاء الشيفرة بالكامل تقريبًا، أما المؤلف نفسه فيقول إنه لم يكد يطّلع عليها.

من الفكرة إلى حزمة npx في بضعة أسابيع

ولدت الفكرة في عطلة رأس السنة 2026: ثبّت روسلان Claude Code وأراد التحكم به من الهاتف. نصحه Gemini بتحليل مخرجات واجهة TUI النصية، فاضطر إلى تأجيل الفكرة. أنقذه OpenCode، إذ يمكن تشغيله كخادم والعمل معه عبر API، فصار بناء عميل Telegram مهمة تستغرق يومين تقريبًا. اختار الاثنان لغة البرمجة معًا مع الذكاء الاصطناعي: بدلًا من Kotlin المعتادة اعتمدا TypeScript لسهولة API.

يعمل البوت محليًا، والوصول إليه مقصور على مستخدم واحد، إذ يُحدَّد معرّفه (id) في الإعدادات. ويصل إلى المحادثة كل ما يفعله الوكيل: تعديلات الملفات وأوامر وحدة التحكم وعمل الوكلاء الفرعيين. يمكن فتح الفروقات (diffs) من الهاتف على شكل ملف نصي، كما يدعم البوت التعرف على الكلام والتحويل إلى صوت. وقد نُقلت خيارات النموذج والوكيل وeffort والسياق إلى reply keyboard. يعمل البوت في خيط واحد كما تعمل الطرفية، ويفصل الأمر /detach الجلسة الحالية ويرسل إشعارًا عند اكتمالها.

استغرق الإعداد للنشر نحو ثلاثة أسابيع، وجرى وفق خطة وضعها المؤلف مع الوكيل. أُعدّ ملف .gitignore والترخيص وملف CONTRIBUTING.md وعملية CI/CD مع linter وبناء واختبارات. أزال الوكيل شيفرة التصحيح، وترجم التوثيق إلى الإنجليزية، ونظّف التعليقات الروسية التي ظهرت لأن المؤلف تحدث مع الوكلاء بالروسية ولم يضع قواعد لذلك. أُنجزت الترجمة والتوطين مبكرًا، وفيها الآن 688 سطرًا بـ 12 لغة. وضُبط النشر على npm في نحو ساعة، فصار التثبيت أمرًا واحدًا عبر npx. ونُشر الإصدار 0.1.0 بـ commit واحد في مستودع جديد، حتى لا يُكشف سجل فوضوي.

ما الذي جلب النجوم وما الذي لم يجلبها

وضع الأصدقاء النجوم الأولى، فبلغ العدد 8 عند الانطلاق. ثم تباطأ النمو إلى 2–3 نجوم أسبوعيًا. نصح الوكيل بالنشر على Reddit وHacker News. كتب الوكيل المنشور في r/opencodeCLI وعدّله المؤلف وفق ملاحظاته، فحصد +65 و31 ألف مشاهدة. وصلت 30 نجمة في اليوم الأول، وتجاوز العدد 100 بعد أسبوع، وتفوّق المشروع على منافسين اثنين لدى كل منهما نحو 20 نجمة. حققت بقية منشورات Reddit 10–15 ألف مشاهدة لكنها لم تجلب زيادة ملحوظة. أما على Hacker News فلم يتفاعل أحد.

جاء الزخم الدائم من محركات البحث. بعد 5–6 أسابيع احتل المستودع المراتب الأولى في Google عند البحث بعبارات مثل «OpenCode Telegram Bot». يزور الصفحة الآن نحو 100 شخص يوميًا، وهذا يعني 3–5 نجوم في اليوم. ويرى المؤلف أنه كان ينبغي جعل المستودع عامًا منذ البداية، ليكون مفهرسًا بالفعل عند بدء الترويج.

كيف يعمل مسار الوكلاء

في البداية عمل روسلان في Claude Code على Sonnet 4.5. ولم يستخدم Opus 4.5 لأنه كان يستنفد سريعًا حدود اشتراك بقيمة $20. ولم تعجبه جودة Sonnet: نادرًا ما كانت الميزات تعمل من المحاولة الأولى، وكثيرًا ما كان النموذج يتخطى الاختبارات المذكورة في التعليمات. فربط اشتراك ChatGPT عبر OpenCode وانتقل إلى GPT-5.3-Codex ثم إلى GPT-5.4. وبحسب تقديره، انخفض عدد دورات التصحيح بشكل ملحوظ، وأنجز الجزء الأكبر من ميزات الربيع على GPT-5.4.

بعد ذلك بنى المؤلف مسار عمل خاصًا به من ثلاثة أوضاع في OpenCode: Ask لمراجعة الشيفرة والأسئلة، وSpec للتخطيط مع تدوين الخطة في ملف منفصل، وCode للتنفيذ. وفي الصيف أضاف Playwright MCP، فبدأ الوكيل يختبر البوت بنفسه عبر نسخة الويب من Telegram. الآن يراجع وكيل فرعي مراجِع الخطة، ويراجع وكيل فرعي آخر الشيفرة، ويشغّل وكيل فرعي مختبِر السيناريوهات. ويعدّ روسلان هذا النهج سبب إقدامه على إعادة هيكلة (refactoring) كان يؤجلها من قبل. وتذهب بعض المهام الآن أبعد من ذلك: بعد تنقيح المهام (grooming) وكتابة المواصفات، يطلق وكيل مدير وكلاء مطورين في جلسات منفصلة ويرفع تقريرًا إلى المؤلف في Telegram.

ظهر المساهمون بعد 4 أيام: أضاف أول pull request دعم البروكسي. ويعترف المؤلف بأنه شك في وجود شيفرة خبيثة، فتحقق من التعديلات بواسطة وكيل. ويراجع دائمًا الشيفرة المرسلة بواسطة الوكلاء ويشغّل الميزة يدويًا. ويقبل الإصلاحات الصغيرة بعد جولة أو جولتين من التعديلات، بينما يرفض في الغالب التحسينات الكبيرة. ويرفض تحديدًا دعم المواضيع (topics) في Telegram: فالبنية مصممة لخيط واحد، وإعادة كتابتها تتطلب دقة واختبارات. تصدر الإصدارات تقريبًا مرة أسبوعيًا، وأحيانًا مع hotfixes، وكان بعضها مؤلفًا بالكامل من pull requests قدمها المجتمع.

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