Cognition تتجاوز مليار دولار: ماذا يكشف صعود Devin عن اقتصاد وكلاء البرمجة؟

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

أولاً: ماذا يعني «معدل إيرادات سنوي»؟

من المهم قراءة الرقم بدقة. معدل الإيرادات السنوي المتوقّع أو Annualized Revenue Run Rate ليس بالضرورة إيراداً محققاً ومراجعاً خلال سنة مالية كاملة. غالباً يُحسب بأخذ وتيرة الإيرادات الحالية وإسقاطها على اثني عشر شهراً. لذلك فهو يصف سرعة النشاط الآن أكثر مما يصف ما دخل خزينة الشركة فعلياً خلال العام الماضي.

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

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

لماذا تدفع الشركات لوكيل برمجة؟

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

الشركات لا تشتري هذا النوع من الأدوات لأنها تحب العروض التقنية، بل لأنها ترى فرصاً في أعمال لها خصائص محددة:

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

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

ثلاثة تحولات وراء القفزة

1. الانتقال من المقعد إلى الاستهلاك

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

2. الإدارة أصبحت جزءاً من المنتج

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

3. أفضلية البيانات التشغيلية

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

مقارنة بين جيلين من أدوات البرمجة

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

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

هل المليار دليل على أن الوكلاء نجحوا تقنياً؟

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

أفضل تجربة مؤسسية تبدأ بعينة محدودة من المهام وتراقب مؤشرات قابلة للتحقق، مثل:

1. الزمن من فتح التذكرة إلى أول طلب دمج صالح.
2. نسبة التغييرات التي قُبلت دون إعادة كتابة كبيرة.
3. عدد مرات فشل الاختبارات أو التراجع بعد النشر.
4. تكلفة المهمة، بما فيها وقت المراجعة البشرية.
5. نوع المهام التي ينجح فيها الوكيل باستمرار.

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

ماذا يعني ذلك للمطورين؟

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

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

مهارات تستحق الاستثمار الآن

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

وماذا يعني لقادة الفرق؟

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

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

هل يتكوّن احتكار جديد؟

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

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

أسئلة شائعة

هل حققت Cognition مليار دولار فعلياً خلال سنة؟

التقارير تتحدث عن معدل إيرادات سنوي متوقّع، أي إسقاط وتيرة الإيرادات الحالية على سنة كاملة. هذا مقياس للنمو الحالي، وليس بالضرورة إجمالي إيرادات سنة مالية مكتملة ومدققة.

هل يعني النمو أن Devin أفضل من كل أدوات البرمجة؟

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

كيف أختبر وكيلاً برمجياً داخل شركتي؟

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

الخلاصة

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