العائد على الاستثمار في تطوير الويب القائم على الوكلاء: كيف يغيّر Claude Code اقتصاديات التجارة الإلكترونية

كل فريق تجارة إلكترونية تعاملت معه لديه نفس المستند تقريبًا: قائمة ميزات من الواضح أنها ستفيد العمل، مرتبة تقريبًا حسب قناعة الفريق بها، مع جدولة اثنتين منها فقط لهذا الربع.

القائمة ليست قصيرة بسبب نقص الأفكار، بل بسبب الحسابات. كل ميزة تتطلب عددًا معينًا من أيام العمل الهندسي، وهذه الأيام مكلفة، لذا ينتظر تنفيذ معظم القائمة.

ما تغير خلال العامين الماضيين هو ذلك الرقم الثاني. والتغير كبير.

ما المقصود فعليًا بـ «القائم على الوكلاء» هنا

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

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

يمكن تشغيله من الطرفية، أو من إضافة أصلية لـ VS Code أو JetBrains، أو من تطبيق سطح المكتب، أو عبر المتصفح. كما يعمل دون واجهة في CI باستخدام وضع الطباعة (claude -p)، وهذا أكثر أهمية مما يبدو — سنعود لهذه النقطة لاحقًا.

مثال عملي: خمسة عشر يومًا تصبح يومين

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

لا شيء معقد. معظم المتاجر تحتاجها. كثير منها لا يملكها لأسباب معروفة.

البناء التقليدي — لنقل 15 يوم عمل

• اليومان 1–2 · الاستكشاف. يراجع أحد الأعضاء كود الكتالوج والسلة والتسعير الحالي لفهم كيفية تفاعل المتغيرات والضرائب والخصومات.
• اليومان 3–4 · التحديد. إعداد المواصفات الفنية، قرارات نموذج البيانات، تسليم التصميم، والتقدير.
• الأيام 5–9 · الواجهة الخلفية. استعلام التوصيات، نقطة نهاية جديدة، قواعد تسعير الحزم، وكيفية تفاعل كل ذلك مع العروض الترويجية الحالية.
• الأيام 10–12 · الواجهة الأمامية. المكون، الحالات التفاعلية، معالجة التحميل والأخطاء، تكامل السلة.
• اليوم 13 · الاختبارات. غالبًا ما تكون أول ما يُستبعد عند تجاوز التقدير.
• اليوم 14 · ضمان الجودة وإصلاح الأعطال. المتغيرات غير المتوفرة، العملات المتعددة، التسعير الشامل للضريبة.
• اليوم 15 · النشر. المراقبة والتوثيق.

شخصان أو ثلاثة مشاركون خلال ثلاثة أسابيع تقويمية. وفقًا لمعظم أسعار الوكالات أو فرق العمل الداخلية، تُعد هذه ميزة تكلفتها من خمس خانات، ولهذا السبب تحديدًا لا تزال مدرجة في قائمة الأعمال.

نفس المهمة باستخدام وكيل — تقريبًا يومان

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

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

لذا هناك مسار عمل لمنطق النقطة النهائية والتسعير، وآخر لمكون الواجهة الأمامية، وآخر للاختبارات. مرحلة الاستكشاف التي استغرقت يومين يدويًا، استغرقت حوالي عشرين دقيقة فقط لأن الوكيل قرأ قاعدة الشيفرة بدلًا من تعلمها.

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

اليوم الثاني، بعد الظهر. ضمان الجودة، بيئة الاختبار، النشر. الاختبارات والتوثيق موجودة مسبقًا، لأن إنتاجها أصبح شبه مجاني.

أين ذهبت الأيام الثلاثة عشر

من المفيد النظر في ذلك، لأنه يوضح التحول الكامل:

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

وما لم يتقلص: تحديد ما يجب بناؤه، وضع القواعد، ومراجعة النتائج. هذه بقيت مهام بشرية. كما أنها أصبحت تشكل الجزء الأكبر من العمل.

هذا ليس مجرد تمرين ذهني

Rakuten — التي تدير أكثر من 70 نشاطًا في التجارة الإلكترونية والسفر والتقنية المالية والاتصالات — نشرت أرقامها مع Anthropic.

الوقت للوصول إلى السوق

24 يومًا ← 5

الخفض

79%

البرمجة الذاتية

7 ساعات متواصلة

دقة الكود

99.9%

تم تحقيق رقم السبع ساعات في مشروع إعادة هيكلة مفتوح المصدر معقّد، أُنجز بالكامل بدقة بلغت 99.9٪ في تعديلات الكود الناتجة. لذا، فإن التحوّل من 15 إلى 2 كما في المثال أعلاه يحدث فعليًا على نطاق واسع.

نتائج منشورة أخرى أكثر تواضعًا، وهذا أمر مهم معرفته. وكالة التطوير Boldare أفادت بزيادة سرعة السبرينت بنسبة تصل إلى 31% في ربع واحد، مع مساهمة الذكاء الاصطناعي في حوالي 75–85% من الشيفرة والاختبارات الجديدة. HubSpot أفادت بانخفاض وقت معالجة المشكلات التقنية المعقدة من ثلاثة إلى خمسة أيام إلى أقل من ساعة، واستخدمت Claude Code لتسريع ترحيل الواجهة الأمامية أثناء إعادة العلامة التجارية، وهو ما كان سيستغرق شهورًا. تشير HubSpot إلى أن هذه الأرقام مستندة إلى تحليل داخلي لتطبيقات مختارة وتعتبر توضيحية.

الحجم هو الأساس، وليس التوفير

هذه النقطة غالبًا ما تُغفل في نقاشات التكلفة.

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

اقرأ هذه الأرقام كنسبة وليس كتنبوء بالقدرة. لا يوجد مطور يقضي 240 يومًا في السنة على ميزات جديدة فقط — هناك صيانة، حوادث، اجتماعات، وإجازات. كلا الصفين مبنيان على نفس الافتراض، لذا تظل العلاقة بينهما صحيحة حتى لو لم تصمد الأرقام أمام لوحة سبرينت حقيقية. كما أن مراجعة ثمانين ميزة في السنة تتجاوز قدرة معظم الفرق، وهو قيد سأعود إليه.

لم يتغيّر عدد الموظفين. ولم تتغيّر الميزانية. ما تغيّر هو عدد المحاولات المتاحة لكم.

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

تأمل في ما يمكن للمتجر أن يبرر تطويره فجأة:

• تنبيهات عند توفر المنتجات غير المتوفرة في الرصيد لكل متغيّر
• أداة لبناء الحزم، أو وحدة "استكمل المظهر"
• إدارة المرتجعات والتبديلات ذاتيًا، مما يقلل من تذاكر الدعم
• أدلة المقاسات مع بيانات ملاءمة فعلية، مما يساهم غالبًا في خفض معدلات المرتجعات
• بيانات منظمة عبر كامل الكتالوج لتحسين نتائج البحث
• قائمة رغبات ترسل بريدًا عند انخفاض الأسعار
• تحسين سرعة الصفحات للقوالب الأكثر احتياجًا
• تحسينات الدفع للزوار واسترجاع عربات التسوق المتروكة بشكل مقسم وفعّال
• أدوات تسعير داخلية، بحيث لا يحتاج فريق المبيعات لتقديم تذاكر عند تغيير القواعد

كل واحدة من هذه التحسينات صغيرة الأثر بمفردها، لكنها تتراكم على مدار عام — والتراكم هو بالضبط ما كانت تمنعه هيكلية التكاليف القديمة. إذا استغرق تنفيذ كل منها 15 يومًا، فهذه خطة تمتد لعدة سنوات. أما إذا استغرق التنفيذ 3 أيام فقط، فهي لا تتجاوز بضعة أرباع سنوية.

جدير بالتأمل: المنافس الذي يجري أربع تجارب في الربع مقابل اثنتي عشرة لديكم ليس أبطأ بثلاث مرات فقط. بل يتعلم أبطأ بثلاث مرات، وهذا الفارق لا يُعالج بمجرد التوظيف.

ثلاث مزايا تتجاوز السرعة الخام

سياق البنية لا يغادر مع الأشخاص

عند انتقال مهندس ذو خبرة، الخسارة الحقيقية غالبًا في السياق وليس في الشيفرة — أي أسباب بناء الأمور بهذه الطريقة. Claude Code يساعد هنا عبر ملف CLAUDE.md في جذر المشروع، يضم القرارات المعمارية والمكتبات المفضلة والمعايير الأمنية. كل جلسة تطلع عليه، فيلتزم الكود المولّد بقواعدكم الداخلية بدلاً من الأنماط العامة.

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

يعالج التعقيد على الخادم، وليس الواجهات فقط

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

أعمال تُنفذ دون ارتباط بشخص معين

نظرًا لإمكانية تشغيله دون واجهة باستخدام claude -p، يمكن دمجه مع GitHub Actions أو أي خط أنابيب CI وربطه بالأحداث القائمة — مثل تشغيله عند فتح Pull Request ليحصل كل طلب على مراجعة أولية قبل أن يطلع عليه شخص، أو عند فشل البناء ليتم تصنيف الخطأ قبل وصول التنبيه. بالإضافة إلى ذلك: تدقيقات أسبوعية للاعتمادات والأمان، ومزامنة التوثيق بعد الدمج. الروتينات المجدولة تعمل في السحابة بغض النظر عن تشغيل أجهزة المطورين.

هذه فئة كاملة من الأعمال كانت تتطلب سابقًا موظفًا مخصصًا أو، في الواقع، لم تُنجز على الإطلاق.

ما الذي يجب التخطيط له بواقعية

ثلاثة عوامل تحدد ما إذا كنتم ستحققون النتائج أعلاه أم ستواجهون تجربة تجريبية مخيبة.

المراجعة تصبح عنق الزجاجة. التوليد أصبح منخفض التكلفة؛ المراجعة لم تتغير. النمط المتكرر هو قفزة إنتاجية حادة في الأسابيع الأولى، يعقبها تراجع عندما يبدأ الكود في الوصول إلى الإنتاج أسرع من قدرة الفريق على مراجعته بشكل كافٍ، مما يؤدي إلى إعادة العمل على نفس الميزات. إذا ضاعفتم الإنتاج دون تعديل عملية المراجعة، فقد نقلتم عنق الزجاجة بدلًا من إزالته. عززوا بوابات CI والمراجعة الأولية الآلية قبل زيادة الحجم، وليس بعدها — لقد وثقنا سياسة مراجعة الكود التي نعتمدها فعليًا للتغييرات التي يكتبها الوكيل، والأنماط الأمنية التي ننصح بالبحث عنها في الشيفرة المولدة بـ PHP.

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

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

إلى أين يقودكم هذا

الطريقة العملية للنظر داخليًا ليست "يمكننا تقليل الإنفاق على نفس خطة العمل"، بل أن خطة العمل التي كنتم تعتبرونها سابقًا غير واقعية أصبحت الآن تستحق التقييم الفعلي.

كلا التفسيرين مقبول. الثاني هو الذي يظهر عادة في الإيرادات.

هل تقيّم خطة عمل كنت تعتبرها غير واقعية سابقًا؟

هذه هي طريقتنا في العمل. إذا كان لديكم تراكم مهام ينتظر الحسابات، يمكننا تحديد الأجزاء التي تصل إليها الأرقام الجديدة فعليًا — هذا هو عمل تطوير الذكاء الاصطناعي وتعلم الآلة وتطوير التجارة الإلكترونية بالنسبة لنا، وتغطي صفحة خدمات الذكاء الاصطناعي التطبيقي بقية ما نديره في الإنتاج. تواصلوا معنا.