تتجه صناعة البرمجيات إلى مرحلة جديدة لا يكفي فيها قياس عدد الأسطر المكتوبة أو سرعة إنتاج الكود للحكم على الأداء. فمع دخول أدوات الذكاء الاصطناعي والأنظمة الوكيلة إلى دورة التطوير، أصبحت المشكلة الأكبر لدى كثير من المؤسسات هي فهم ما يحدث فعلاً داخل عملية التسليم البرمجي، وليس مجرد تسجيل ما تم إنجازه بعد وقوعه.
هذا التحول يفسر الرؤية التي تدافع عنها شركة Allstacks، المتخصصة في استخبارات هندسة البرمجيات وإدارة تدفق القيمة، والتي تبني منصتها على جمع البيانات المتناثرة عبر أدوات التخطيط، ومستودعات الشيفرة، وأنظمة النشر، ثم تحويلها إلى سياق عملي يساعد الفرق على توقع المخاطر واتخاذ قرارات أفضل.
وبحسب Jeremy Freeman، الشريك المؤسس والمدير التقني للشركة، فإن المشكلة الأساسية في كثير من المؤسسات ليست نقص البيانات، بل غياب العلاقة بين هذه البيانات. فالمهمة لا ترتبط تلقائياً بفرع برمجي، والفرع لا يرتبط دائماً بطلب السحب، وطلب السحب لا يرتبط بالضرورة بهدف السبرنت أو المبادرة التجارية. ومن دون بناء هذه الروابط، يبقى الذكاء الاصطناعي قادراً على رؤية أجزاء من الصورة فقط.
من بيانات كثيرة إلى فهم ضعيف
يشير Freeman إلى أن الفرق الهندسية تمتلك اليوم كماً هائلاً من الإشارات، لكن المشكلة أن الكثير منها لا يجيب عن السؤال الأهم: أين يكمن الخطر؟ فهناك مؤشرات مفيدة، وأخرى تشخيصية، وثالثة مجرد ضوضاء. لذلك يرى أن البداية الصحيحة لا تكون من لوحة قياس جاهزة، بل من المشكلة التي يشعر بها الفريق بالفعل: لماذا يبدو التسليم أبطأ من العام الماضي؟ لماذا تتراكم المراجعات؟ لماذا تستغرق الاختبارات وقتاً أطول؟
من هذا المنطلق، يقترح نهجاً يعتمد على ثلاثة مستويات من القياس: أولاً، التأكد من أن المشكلة حقيقية عبر مؤشرات مثل عدد طلبات السحب لكل مطور عبر الزمن. ثانياً، تتبع أثر التغيير الذي يتم تطبيقه، سواء كان تبنّي أداة مراجعة مدعومة بالذكاء الاصطناعي أو تحسين إجراءات الاختبار. وثالثاً، ربط المشكلة بالتأثير التجاري حتى يمكن معرفة إن كانت القضية مجرد تراجع تقني محدود أم أنها تتحول إلى كلفة تشغيلية أو تأخير في الإطلاق.
هذا الأسلوب يعكس اتجاهاً أوسع في سوق أدوات هندسة البرمجيات، حيث لا يعود الهدف هو جمع مزيد من البيانات بقدر ما هو تحويلها إلى سياق قابل للتنفيذ. فالقيمة لا تأتي من القياس وحده، بل من القدرة على تفسير العلاقة بين النشاط التقني ونتائج الأعمال.
الذكاء الاصطناعي يسرّع الكود ويكشف الاختناقات
أحد أكثر التحولات وضوحاً في تطوير البرمجيات اليوم هو أن الذكاء الاصطناعي أصبح يختصر أجزاء كبيرة من كتابة الكود. ومع ظهور الأدوات الوكيلة، يمكن أحياناً الانتقال من الفكرة إلى نسخة تشغيلية في ساعات قليلة فقط. لكن هذه السرعة تحمل معها اختناقاً جديداً: لم تعد الكتابة هي العقبة الأساسية، بل جودة المواصفة، ودقة التخطيط، واستعداد المتطلبات قبل بدء التنفيذ.
يوضح Freeman أن أدوات المساعدة على الكتابة التقليدية تعمل ضمن حلقة مراجعة قصيرة، إذ يرى المطور اقتراح الذكاء الاصطناعي ثم يقبله أو يرفضه فوراً، ما يحد من أثر الخطأ. أما الأنظمة الوكيلة فتعمل بشكل مختلف؛ فهي تنفذ خطة متعددة الخطوات، ثم يعاد تقييم الناتج في النهاية. وإذا كانت المواصفة غير دقيقة، فإن النظام قد يبني منتجاً كاملاً على أساس خاطئ، لتظهر المشكلة متأخرة عند المراجعة.
من هنا، تصبح مواصفات المنتج، ووضوح المتطلبات، والاستعداد المبكر قبل التنفيذ، عناصر أكثر أهمية من أي وقت مضى. فالذكاء الاصطناعي لم يلغِ العمل التحضيري، بل رفع من قيمة الإعداد الجيد. وما كان سابقاً يُترك لتكرار المراجعة البشرية والتجريب أصبح الآن يحتاج إلى انضباط أعلى في تعريف المشكلة وقياس أثر الحل.
إعادة تعريف الإنتاجية في عصر الوكلاء
تؤكد هذه الرؤية أن مقاييس الإنتاجية التقليدية لم تعد كافية. فقياس عدد الساعات أو حجم الكود المنتج لا يعبّر بالضرورة عن القيمة الفعلية، خاصة عندما يصبح المطور أشبه بمدير لوكلاء ذكاء اصطناعي بدلاً من كاتب مباشر للكود. في هذا النموذج، لا تكفي مؤشرات السرعة أو الكم، بل تحتاج المؤسسات إلى فهم نسبة ما تم قبوله من أول مرة، ومقدار إعادة العمل، وموقع الأخطاء التي تمر عبر خطوط التكامل المستمر من دون اكتشافها مبكراً.
ويحذر Freeman من أن الذكاء الاصطناعي قد يوسّع الفجوة بين المطورين. فالمطورون الأكثر خبرة يملكون سياقاً أعمق وقدرة أفضل على توجيه المخرجات ومراجعتها، بينما قد ينتج المطورون الأقل خبرة حجماً مشابهاً من الكود لكن مع وقت أطول في التقييم والتصحيح. وفي لوحات القياس التقليدية، قد تبدو الإنتاجية مستقرة، رغم أن الواقع داخل الفريق يتغير جذرياً.
لهذا السبب، يرى أن أي نموذج قياس جديد يجب أن يضع الجودة وإعادة العمل في قلبه، لا أن يكتفي بتتبع الإنتاج الخام. فالسؤال الأهم لم يعد: كم أسرعنا؟ بل: كم من العمل كان صحيحاً من المرة الأولى؟
أهمية ربط أدوات التطوير في سياق واحد
تعتمد Allstacks على بناء ما يشبه “الرسم البياني للسياق” الذي يربط بين البيانات القادمة من أدوات متفرقة داخل المؤسسة. ووفق هذا التصور، فإن قيمة الذكاء الاصطناعي في إدارة البرمجيات لا تأتي من النموذج نفسه بقدر ما تأتي من وفرة السياق الذي يغذيه. فإذا كانت البيانات منفصلة، فسيظل التحليل سطحياً حتى لو كان النموذج متقدماً للغاية.
فعلى سبيل المثال، قد يرى النظام تأخراً في التسليم داخل أداة إدارة المشاريع، أو زيادة في التعديلات داخل مستودع الشيفرة، لكنه لن يعرف سبب التعثر إذا لم تكن العلاقات بين هذه الإشارات واضحة في طبقة البيانات. وقد يقود ذلك إلى توصيات واثقة لكنها خاطئة، وهو ما يجعل المشكلة بنيوية وليست تقنية فقط.
هذا الربط بين الأدوات هو ما يسمح بفهم لماذا تأخر العمل، وأين بدأ الانحراف، وما الكلفة المتوقعة، وما الذي كان يمكن رؤيته مبكراً قبل أن يتحول إلى أزمة. وبالنسبة للمؤسسات التي تعتمد على قرارات هندسية ومالية دقيقة، فإن هذه القدرة تصبح جزءاً من البنية التحتية لاتخاذ القرار.
ما الذي يميز الفرق الجاهزة للذكاء الاصطناعي
عندما تدخل الأنظمة الوكيلة إلى بيئة التطوير، فإن الفريق الجاهز لها لا يشبه الفريق غير المستعد إلا في الظاهر. فالأول يمتلك اختبارات آلية قوية، وتوثيقاً واضحاً، وخطوط دمج ونشر ناضجة، إضافة إلى قواعد تشغيل مضبوطة يمكن للأنظمة الالتزام بها. أما الثاني، فيتعامل مع الذكاء الاصطناعي وكأنه إضافة تجريبية فوق عملية غير منظمة أصلاً.
ويشدد Freeman على ضرورة تحديث القواعد الخاصة بالوكلاء باستمرار، مثل تعليماتهم الداخلية والملفات المنظمة لسلوكهم، لأن الاعتماد على الإعداد الأولي فقط قد يترك أنماطاً سيئة تتكرر تلقائياً. كما أن أحد الأسئلة التشخيصية المهمة لأي قائد هندسي اليوم هو: ماذا أنجزت الأنظمة الوكيلة في السبرنت الماضي، وكم من ذلك قُبل كما هو، وكم احتاج إلى تعديل، وأين تركزت المراجعة؟
الإجابة عن هذه الأسئلة لا تساعد فقط في تحسين الأداء، بل تكشف مدى نضج بيئة التطوير نفسها. فالفريق الذي يملك هذه الرؤية يمتلك القدرة على التحسين، بينما يبقى الآخر يعمل بالحدس.
ربط الهندسة بنتائج الأعمال
أحد المحاور الأساسية في رؤية Allstacks هو أن التقنية لا ينبغي أن تعمل بمعزل عن أهداف المؤسسة. ففي بعض الشركات، تنفصل فرق الهندسة عن فرق المنتجات، وتتشابك الملكيات والمسؤوليات بين عدد كبير من المشاريع، ما يجعل من الصعب فهم أين يذهب الجهد وما إذا كان يتوافق مع أولويات العمل.
كما أن هناك طبقة كبيرة من العمل الهندسي لا تظهر مباشرة في مخططات الإدارة، مثل تحديث الحزم البرمجية، وصيانة الاعتمادية، والالتزام الأمني، وهي أعمال غالباً ما تكون غير مرئية لغير المتخصصين. لكن عندما تُصنف هذه الأنشطة ضمن فئات استثمار واضحة، يصبح من الممكن مناقشتها بلغة الأعمال، لا بلغة التفاصيل التقنية فقط.
وتشير التجارب التي تستعرضها Allstacks إلى أن الأتمتة في تصنيف العمل وربط البيانات قد تختصر وقت التقارير المالية أو تقارير رسملة البحث والتطوير بشكل كبير، لأن المشكلة في النهاية ليست في إعداد الجداول، بل في توحيد مصدر الحقيقة. فبدلاً من الاعتماد على ملفات متفرقة، تصبح البيانات المترابطة هي الأساس.
المرحلة المقبلة: من التحليل التفاعلي إلى الرصد الاستباقي
يتوقع Freeman أن السنوات الثلاث إلى الخمس المقبلة ستشهد سباقاً واسعاً في ميزات أدوات التطوير المدعومة بالذكاء الاصطناعي. ومع انخفاض تكلفة إنتاج الكود، ستواجه المؤسسات تحدياً جديداً: كيف تضمن أن ما يُبنى يستحق أن يُبنى أصلاً؟ فالمشكلة لن تكون في القدرة على التنفيذ، بل في فرز الأفكار والتحقق من الجودة والتأكد من أن ما يصل إلى الإنتاج يحمل قيمة حقيقية.
ويرى أن التفوق المستقبلي لن يأتي من جودة النموذج وحدها، لأن النماذج ستصبح متاحة على نطاق واسع لكل المنافسين تقريباً. العامل الحاسم سيكون عمق السياق واتساعه: كيف تفهم الأداة بنية الفريق، وسجل التسليم، وأنماط النشر، وسلوك المستودعات، والعلاقات بين العمل والنتيجة. ومن ينجح في بناء هذه الطبقة اليوم سيملك أفضلية يصعب نسخها لاحقاً.
كما يتوقع أن تنتقل الأدوات من الرد على الأسئلة بعد طرحها إلى رصد المخاطر بشكل استباقي قبل أن يلاحظها الفريق نفسه. وهذا يعني أن الاستثمار الحقيقي لم يعد في الأتمتة فقط، بل في بناء طبقة فهم دائمة فوق دورة التطوير، تجعل القرارات التقنية أكثر ارتباطاً بالسياق وأكثر قابلية للقياس.
في المحصلة، تعكس تجربة Allstacks اتجاهاً أوسع داخل قطاع التقنية: الذكاء الاصطناعي لا يغيّر فقط طريقة كتابة البرمجيات، بل يفرض إعادة تعريف كاملة لكيفية قياسها وإدارتها وربطها بالأعمال. وفي هذا المشهد، تصبح البيانات المترابطة والسياق العميق أكثر أهمية من مجرد السرعة في الإنتاج.