مصطلح katamari architecture يصف الكود الذي تبنيه الـ agents بإضافة الميزات فوق بعضها
الكود المتراكم من الـ agents لا ينتج عن ضغط الوقت أو المال كما عند البشر، بل عن تعليمات تطلب الإضافة ولا تطلب الدمج، وهذا ما يغيّر سؤال المراجعة.
نشر موقع nove.dev في 23 سبتمبر 2026 مقالًا يطرح مصطلحًا جديدًا لوصف الكود الذي تكتبه الـ agents: katamari architecture. أصل المصطلح تعليق لمستخدم باسم marginalia على موقع lobste.rs، وبنى عليه المقال مقارنة مفصلة.
الاسم مأخوذ من لعبة Katamari Damacy، حيث يدحرج اللاعب كرة يلتصق بها كل ما تمر عليه من الخارج. وهذا بالضبط شكل الكود حين تُطلب من agent ميزة بعد أخرى: كل إضافة توضع بجوار ما قبلها، ولا يندمج شيء في شيء.
مقارنة مع كرة الطين
يقارن المقال المصطلح بنمط قديم معروف في هندسة البرمجيات، هو Big Ball of Mud الذي وصفه Foote وYoder، ويمر على القوى السبع التي ذكراها واحدة بعد أخرى. يصل البشر إلى كرة الطين تحت ضغوط معروفة، منها الوقت والمال والخبرة والمهارة ووضوح المتطلبات.
لكن الـ agent لا يخضع لأي من هذه الضغوط تقريبًا. فالوقت متاح له، والتوكنز متاحة، وقد تدرّب على كم هائل من الكود المكتوب. أي أن سبب التراكم ليس الضغط.
السبب، بحسب المقال، أن الـ agent يسلك أقصر طريق يحقق المطلوب في الـ prompt. والـ prompt يقول “أضف هذه الميزة”، ولا يقول “واحرص على أن تبقى الأجزاء التي تؤدي الوظيفة نفسها جزءًا واحدًا”. فتظهر دالة ثالثة تؤدي ما تؤديه دالتان موجودتان.
وهذا يغيّر ما تحتاج مراجعة الكود إلى السؤال عنه. فالمراجعة التقليدية تسأل هل الكود صحيح. أما مع كود الـ agents، فيصبح السؤال الناقص: هل اندمج هذا الجزء في النظام، أم التصق به من الخارج؟