كاتب gonzo_ML: في فريقه لا تكتب الشيفرة سوى النماذج، بينما يراجعها البشر

عادة ما تنتهي قصص «انتقلنا إلى الوكلاء» بعرض تقديمي أنيق. أما هنا فهناك تسلسل زمني وأرقام ووصف صريح لما لم ينجح. يروي كاتب قناة gonzo_ML كيف انتقل بين عامي 2024 و2026 من مرحلة «تستكمل النماذج الشيفرة أحيانا» إلى مرحلة «لا أحد في الفريق يكتب الشيفرة يدويا».

العتبة التي تجاوزتها النماذج

أنجز الكاتب أول مشروعاته المكتملة عند الانتقال بين عامي 2024 و2025. وهو يرى أن النماذج هي التي تجاوزت العتبة، لا أنه أصبح أكثر جرأة. في يناير 2025، أنشأ له Gemini وClaude شيفرة محول، وتدخلات، وعرضا مرئيا لعمليات التنشيط ضمن مشروع جامعي عن قابلية التفسير. وفي الربيع، كتب خادم MCP للترجمة من دون أن يطبع بيده، من حيث المبدأ، سطرا واحدا. وبحلول ديسمبر، أعاد بناءه باستخدام Streamable HTTP ووصل به إلى بيئة الإنتاج. وكالمعتاد، كان جزء الإنتاج أضخم من الميزة نفسها: فقد أضاف التسجيل والمراقبة والأمان والتعامل مع الأحمال ومعالجة الأخطاء والنشر شيفرة أكثر مما أضافه بروتوكول النقل الجديد.

استقر أسلوب العمل على ما يلي: مواصفات مقسمة، واختبارات قبل التنفيذ، وسجلات ADR للقرارات المعتمدة. بدأ كل شيء مع speckit، أما الآن فيعمل الفريق بأكمله وفق هذه الممارسات داخل Claude Code، ولم يعد الأمر جهدا فرديا.

لماذا لم ينجح العمل على brownfield ثم نجح لاحقا

في عام 2025، حاول الكاتب إسناد شيفرة منصة عمرها عشر سنوات إلى النماذج. لكن إصلاحات الأخطاء والميزات الصغيرة كانت تخرج «على نحو غير صحيح». وعزا ذلك إلى طبيعة brownfield. ثم اتضح لاحقا أن السبب مختلف: كان السياق موجودا في رؤوس البشر، لا في مكان يستطيع الوكيل الوصول إليه.

لذلك انشغل الفريق بوضع الأسس. وأتاح للنماذج الوثائق داخل المستودعات، وعبر MCP محتوى Confluence، والمعايير وسجلات ADR، والمهام — في Jira أولا ثم في Linear — وسجلات الإنتاج عبر MCP، وعند الضرورة مراسلات Slack. أي كل ما يحتاج إليه شخص جديد ينضم إلى المشروع. الآن يحدد البشر المهام ويجرون المراجعات، بينما تتولى الوكلاء أيضا المراجعة الأولية والتوثيق ووثائق الإصدار والاختبارات. ويتدخل الإنسان عند بوابات الجودة لمنح الموافقة.

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

التسوق لاختيار اللغة وRust

ظهر أثر غير متوقع: أصبح من الممكن اختيار اللغة بحسب المهمة، لا بحسب مهارات الفريق. وكان المرشح الأول خدمة تحاكي واجهات API حقيقية بكل مشكلاتها، وكانت اختبارات الأداء تصطدم بحدودها. أعيدت كتابتها بلغة Rust، وكذلك بلغتي Go وNode، مع اختبار تكافؤ يغطي التطبيقات الأربعة جميعا.

داخل الحاوية نفسها ذات سعة 100 ميغابايت، تحافظ نسخة Rust على نحو 8 900 اتصال مفتوح، مقابل قرابة 3 400 للنسخة الأصلية المكتوبة بلغة Python. وفي وضع الخمول، تشغل 1 MiB بدلا من 33. أما Go مع fasthttp فكانت أفضل من Python بنسبة 11% فقط، ومع net/http القياسية كانت أسوأ بمرتين. ويضيف الكاتب تحفظا: الأرقام مأخوذة من منصة اختبار محلية، وفي نهج العمل اليدوي لم يكن أحد ليخصص حتى أسبوعا واحدا لإعادة كتابة كهذه لخدمة مساعدة.

ليس الشيفرة وحدها

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

القيود والخلاصة

هذه تجربة شخصية واحدة من دون قياسات مستقلة. معيار Rust محلي، والحالة الضريبية فردية، رغم أن الكاتب تحقق من المراجع يدويا. كما أن الظروف خاصة: فالشركة تعيد تنظيم نفسها عمدا وفق نهج AI-first.

الخلاصة العملية للفرق هي: إذا قدم الوكيل «شيئا غير صحيح»، فتحققوا أولا من مكان وجود السياق. ضعوا الوثائق وسجلات ADR والمهام والسجلات التشغيلية في المستودع وفي MCP، واكتبوا المواصفات والاختبارات قبل التنفيذ. واستعدوا مسبقا لعملية المراجعة أيضا، لأنها بالتحديد ستصبح عنق الزجاجة.