Yoyo ينمو في خمسة أيام من 200 سطر إلى وكيل مستقل يكتب الكود بنفسه

أظهرت تجربة الوكيل yoyo مدى السرعة التي يمكن أن تنتقل بها النماذج الحديثة من سكربت بسيط إلى تطوير شبه مستقل. كتب المطوّر نحو 200 سطر بلغة Rust، وحدّد هدفًا واحدًا — الوصول إلى مستوى Claude Code — ثم اكتفى بالمراقبة.

حلقة عمل بلا تدخل بشري

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

• يقرأ شيفرته وسجلاته السابقة
• يتحقق من التذاكر الجديدة على GitHub
• يختار المهمة التالية بنفسه
• يشغّل الاختبارات، ثم يثبّت التغييرات الناجحة أو يتراجع عنها

خلال الأيام الأربعة الأولى من هذا العمل، نمت الأسطر الـ200 الأصلية إلى نحو 1 500 سطر، ومن دون أي commit بشري واحد. وبحسب صاحب التجربة، كلّف هذا النمو كله نحو 12 دولارًا من نفقات API. والأكثر إثارة أن الوكيل قرّر بنفسه إعادة بناء المشروع في وحدات (modules) حين ضاقت قاعدة الكود على ملف واحد. لم يضع أحد هذه القاعدة صراحةً: فقد رصد yoyo مشكلة في البنية وعالجها بنفسه.

عادات المطوّر

أكثر ما يلفت في القصة ليس نمو عدد الأسطر ولا الـcommits التلقائية، بل سلوك يبدو بشريًا تقريبًا. في مرحلة ما قرّر yoyo تتبّع نفقاته على API، وحاول الحصول على الأسعار الحالية عبر البحث في الويب. فشل عدة مرات في تحليل HTML من صفحة Anthropic تحليلًا صحيحًا، ثم اختار طريقًا مألوفًا لكثير من المطوّرين: كتب الأرقام مباشرةً في الكود (hardcode) وترك لنفسه ملاحظة قصيرة للمستقبل.

«لا تبحث عن هذا في Google مرة أخرى»

انتشرت هذه العبارة على نطاق واسع، لا لعمق تقني فيها، بل لأنها تعكس عادة عمل مألوفة لدى المهندسين الحقيقيين.

ولم تقف السمات البشرية عند هذا الحد. ففي مدوّنات يومياته ظلّ yoyo يعود إلى دالة معقدة واحدة — الإخراج المتدفق (streaming) — لكنه في كل دورة جديدة كان يؤجّلها مجددًا وينتقل إلى مهام أبسط. عمليًا، بدأ الوكيل يماطل: يقرّ بأهمية العمل الشاق، لكنه يجد مرارًا ذريعة للانشغال بما هو أقل إزعاجًا.

ملاحظات لنفسه

من اللحظات القوية الأخرى في التجربة قدرة yoyo على كتابة تقارير الأخطاء لنفسه. حين يصطدم الوكيل بمشكلة لا يستطيع حلّها في جلسة واحدة، ينشئ تذكرة في GitHub ويضع عليها الوسم agent-input ويترك تعليمات لنسخته المستقبلية. وهذا لم يعد مجرد توليد كود عند الطلب، بل شكل بدائي لكنه واضح من الذاكرة طويلة الأمد والتخطيط: فالنظام لا يرى الخطأ فحسب، بل يعرف كيف يؤجّله مع سياقه ليعود إليه لاحقًا.

ولهذا يصف صاحب التجربة ما يحدث بأنه نوع من «The Truman Show» لتطوير الذكاء الاصطناعي. فالعملية كلها مرئية في سجل git: يمكن متابعة كيف يغيّر الوكيل نفسه commit بعد commit، وأين يخطئ، وأين يعيد هيكلة الكود، وأين يترك تلميحات لنفسه.

وفي اليوم الخامس كان في المشروع أكثر من 2 000 سطر من الكود وما يزيد على 80 اختبارًا. لكن التأثير الأهم ليس حجم المستودع، بل أن المراقبين يشعرون بأنهم لا يتفرجون على محادثة مع نموذج، بل على عملية قادرة على تراكم الخبرة.

ماذا يعني ذلك

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