بنك يحوّل فريقه إلى tiny teams: الذكاء الاصطناعي يكتب 90% من الكود، والوكلاء يتولّون 20% من المهام

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

السبرنت الأول فشل، وهذا مفيد

كانت نقطة البداية فريقين متعدّدي التخصصات لتطوير الميزات، بإجمالي 14 شخصاً، مع Kotlin وSpring في الواجهة الخلفية، وTypeScript وReact في الواجهة الأمامية. خُصّص للتجربة شخصان، مطوّر واجهة خلفية ومختص QA، ومهلة شهرين. وكان الهدف إنجاز قصة المستخدم كاملة، من التحليل إلى بيئة الإنتاج.

لم يتمكّن الفريق من إيصال أول مهمة صغيرة إلى بيئة الإنتاج خلال أسبوعين. استغرق فهم المتطلبات وقتاً طويلاً، لكن الواجهة الأمامية استهلكت النصيب الأكبر. حاولوا تزويد الوكيل بتصاميم Figma، ثم دخلوا في تعديلات لا تنتهي على النتيجة استجابةً لملاحظات مراجعة الكود. ولم تكن تراخيص Figma Dev Mode وأداة MCP المقابلة متاحة إلا لمطوّر الواجهة الأمامية والمصمّم. لذلك كان من الأسهل أحياناً عرض لقطة شاشة للواجهة الجاهزة على الوكيل.

تسارع العمل بعد ذلك: قصرت دورة الإنجاز مع كل سبرنت. لكن المشكلات بقيت، وكانت كلّها مرتبطة بالسياق:

• المعرفة حبيسة الأذهان. تراكمت التوافقات المعمارية على مدى سنوات، وما دامت غير موجودة في سياق الوكيل، فإنه يخطئ.
• المراجعة تبطئ العمل. يصعب على مهندس المنتج تقييم الكود في مجال خارج اختصاصه، وتصبح كتابة الكود أسرع من مراجعته.
• طريقة عرض التصميم غير واضحة. المطلوب قناة سليمة تنقل التصميم إلى الوكيل، لا مجموعة من الحلول الترقيعية.

Harness بوصفه منتجاً

المقصود بـHarness هنا مجموعة من القواعد والمهارات وMCP والسياق، تساعد الوكيل على العمل داخل مشروعكم تحديداً. لم يُعِد الفريق اختراع العجلة، بل أعاد استخدام ما هو موجود بالفعل في البنك ومجال العمل.

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

قُسّم الفريق إلى أربع مجموعات tiny teams ومركز لاستكشاف المنتج، يضم مالك المنتج والمصمّم ومحلّل الأعمال. وتعمّدوا عدم وضع محلّل داخل مجموعات tiny teams لزيادة الدافع إلى استخدام الذكاء الاصطناعي. تُصنّف المهام بالألوان: الخضراء صغيرة وتُسند إلى وكلاء مستقلّين. والصفراء كبيرة، وتُنجز داخل الفريق محلياً بمساعدة الذكاء الاصطناعي. أما الحمراء فتتطلّب خبرة تخصصية عميقة، ولا تُحل إلا بتضافر الجهود.

الوكلاء على الخادم وثمن المكاسب

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

بدأوا بالأمن. عندما يرصد فحص AppSec مكتبة أو صورة برمجية فيها ثغرة أمنية، ينشئ الوكيل المهمة بنفسه، ويُدخل التعديلات، ويجهّز MR. وبحلول الصباح، تكون عدة طلبات جاهزة للمراجعة. والآن يسندون إليه بالطريقة نفسها مهام أعمال صغيرة، حين يكون واضحاً ما الذي يجب تغييره وكيف وأين.

الحصيلة خلال نصف عام: يكتب LLM نسبة 90% من الكود، وأُنجز أكثر من 70% من مهام الأعمال بمساعدة الذكاء الاصطناعي، ويتولّى الوكلاء على الخادم حل أكثر من 20%. لكن عدد المهام المنجزة انخفض في البداية، ثم ظهرت آثار جانبية:

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

ما الذي يمكنكم تطبيقه من هذه التجربة

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

وتكتسب فكرة مقاييس التقييم أهمية خاصة: فمن دونها، لا يتّضح إن كانت بيئة harness قد تحسّنت أم أنكم تغيّرون الإعدادات فحسب. لذلك يجدر إدارتها بوصفها منتجاً، وإدراجها بصراحة ضمن الدين التقني.

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