لعقود طويلة، انصبّ اهتمام قطاع كبير من صناعة التكنولوجيا على تسريع وتيرة التطوير. سعت الشركات إلى إطلاق منتجاتها في وقت أقرب، وتقليص الفترة الزمنية بين الفكرة والإنتاج، وتمكين فرق الهندسة من تقديم المزيد من الميزات في دورات أقصر. بدأت القصة بمنهجيات التطوير الرشيقة، ثم تلتها منهجية DevOps، والتكامل المستمر، والبنية التحتية كبرمجيات، ومنصات الحوسبة السحابية. واليوم، يعد الذكاء الاصطناعي بتسريع هذه العملية برمتها من جديد.
تستطيع أدوات التطوير المدعومة بالذكاء الاصطناعي توليد الميزات، وكتابة الاختبارات، وشرح المستودعات، واقتراح عمليات إعادة هيكلة، وإنتاج وحدات برمجية كاملة في غضون ثوانٍ. لم يعد توليد الشفرة نشاطًا يدويًا حصريًا، بل أصبح عملية تعاونية بين المطورين ونماذج اللغة.
التغيير واضح بالفعل. فقد أظهر استطلاع أجرته شركة سونار ونُشر في يناير 2026 أن 721% من المطورين الذين جربوا أدوات الذكاء الاصطناعي يستخدمونها يوميًا، وأنه وفقًا للمهنيين الذين شملهم الاستطلاع أنفسهم، فإن حوالي 421% من التعليمات البرمجية التي يساهمون بها يتم إنشاؤها بالفعل أو بمساعدة كبيرة من الذكاء الاصطناعي.
لكن هذا التسارع يخلق تناقضاً بدأت الصناعة للتو في فهمه: يمكننا إنتاج التعليمات البرمجية بشكل أسرع من قدرة مؤسساتنا على مراجعتها وفهمها وصيانتها..
قد لا تكون الأزمة الجديدة في هندسة البرمجيات نقصاً في الشيفرة البرمجية، بل قد يكون العكس تماماً.
نحن ندخل حقبة من الإفراط في إنتاج البرمجيات.
هناك فكرةٌ يُجبرنا الذكاء الاصطناعي على إعادة النظر فيها: كتابة الشفرة البرمجية وهندسة البرمجيات ليستا متطابقتين تمامًا. فالشفرة البرمجية تمثل قراراتٍ تتعلق بالبنية، والأعمال، والأمان، والأداء، والصيانة. وقد تُترجم الشفرة بشكلٍ صحيح، ومع ذلك تظل حلاً غير مناسب للنظام الذي ستُطبّق فيه.
يمكن لنموذج الذكاء الاصطناعي أن يتلقى تعليمات ويُنتج وظيفة صحيحة تقنيًا. مع ذلك، فإن هذه الوظيفة موجودة ضمن سياق أوسع بكثير. يجب أن تحترم الأعراف الداخلية، ونماذج المجال، والقرارات المعمارية، وسياسات الأمان، والسلوكيات التي قد لا تكون مُعبرًا عنها بالكامل في التعليمات المُعطاة.
ولهذا السبب تحديدًا يصف تقرير DORA 2025 حول التنمية المدعومة بالذكاء الاصطناعي الذكاء الاصطناعي في المقام الأول بأنه المضخم. وخلص البحث، الذي استند إلى ردود من حوالي 5000 متخصص في مجال التكنولوجيا وأكثر من 100 ساعة من البيانات النوعية، إلى أن الذكاء الاصطناعي يميل إلى تضخيم نقاط القوة والضعف الحالية للمؤسسة.
يمكن لفريق يتبنى ممارسات جيدة أن يحقق تقدماً سريعاً. ويمكن لنظام غير منظم أن يحقق تقدماً سريعاً أيضاً، ولكن في الاتجاه الخاطئ.
يقوم الذكاء الاصطناعي بتوليد التعليمات البرمجية. ولا يزال على قسم الهندسة أن يقرر ما إذا كان ينبغي أن توجد هذه التعليمات البرمجية أم لا.
لطالما كان لتطوير البرمجيات قيد طبيعي: إنتاج الكود يستغرق وقتًا. يقوم المطور بتحليل المشكلة، وتصميم الحل، وكتابة التنفيذ. وقد حدّت سرعة الإنسان نفسها من عدد التغييرات التي يمكن إضافتها إلى المستودع في وقت واحد.
يساهم الذكاء الاصطناعي جزئياً في إزالة هذا القيد.
الآن، يستطيع المطور إنتاج عدة بدائل في دقائق. ويمكن لوكيل تعديل عشرات الملفات. كما يمكن لأداة إنشاء اختبارات ووثائق، بينما يقترح نظام آخر إعادة هيكلة. يزداد حجم التغييرات المحتملة بشكل كبير، لكن القدرة البشرية على تقييم هذه التغييرات لا تنمو بنفس الوتيرة.
كشفت دراسة حديثة أجرتها GitLab عن هذه المفارقة تحديدًا. فبينما أفاد 781% من المطورين الذين شملهم الاستطلاع بكتابة أكواد أسرع باستخدام الذكاء الاصطناعي، ولاحظ 731% منهم تحسنًا في الجودة، أشار 851% إلى أن المراجعة والتحقق والحوكمة تُشكل قيودًا أكبر من عملية إنشاء الكود نفسها. علاوة على ذلك، أعرب 731% عن قلقهم بشأن إمكانية صيانة الكود المُولّد بواسطة الذكاء الاصطناعي على المدى الطويل.
المصنع ينتج بشكل أسرع، لكن مراقبة الجودة لا تفعل ذلك.
وعندما يحدث ذلك، يبدأ المخزون بالتراكم.
من أكثر التجارب إغراءً في مجال التطوير المدعوم بالذكاء الاصطناعي تلك التي تُنتج فيها أداة ما ما كنا نحتاجه تمامًا. يبدو الكود نظيفًا، والحل منطقيًا، والاختبارات الأولية ناجحة. في تلك اللحظة، يبرز إغراء خطير: قبول التغيير قبل فهمه فهمًا كاملًا.
تكمن المشكلة في الجانب المعرفي. قد يستغرق إيجاد حل ثوانٍ معدودة، لكن بناء نموذج ذهني دقيق لكيفية تفاعل هذا الحل مع نظام معقد لا يزال يتطلب انتباهاً بشرياً. يحتاج المطور إلى فهم التبعيات، والآثار الجانبية، والاستثناءات، والقرارات الضمنية.
كلما زاد حجم الكود المُولّد، زاد الجهد المطلوب للحفاظ على ذلك النموذج الذهني.
لا يقتصر الخطر على إدخال الأخطاء فحسب، بل يشمل أيضاً نوعاً جديداً من الانفصال بين الفريق وبرمجياته. يبدأ المطورون العمل على مكونات يديرونها تقنياً، لكنهم لم يصمموها أو يفهموها بعمق.
بمرور الوقت، قد يصبح المستودع نظامًا يمكن لأي شخص تعديله باستخدام الذكاء الاصطناعي، ولكن عددًا أقل فأقل من الناس يفهمونه من البداية إلى النهاية.
لا تُحل هذه المشكلة من خلال توليد المزيد من الوثائق الآلية، بل من خلال الحفاظ على الفهم التقني.
أجرت شركة METR إحدى أكثر الدراسات إثارة للاهتمام حول التطوير المدعوم بالذكاء الاصطناعي، وذلك بالتعاون مع مطورين ذوي خبرة يعملون على مشاريع مفتوحة المصدر ناضجة يعرفونها جيدًا. توقع المشاركون أن تقلل أدوات الذكاء الاصطناعي وقت عملهم بنحو 24%، ولكن بعد استخدامها، قدروا أنها أسرع بنحو 20%.
أظهرت النتائج المقاسة شيئاً مختلفاً.
في تلك البيئة التجريبية المحددة، أدى السماح باستخدام أدوات الذكاء الاصطناعي إلى زيادة وقت إنجاز المهمة بمقدار 19%.
لا تثبت الدراسة أن الذكاء الاصطناعي يُبطئ عمل المطورين دائمًا. يشرح مؤلفوها الخصائص المحددة للسيناريو المُحلل: وجود محترفين ذوي خبرة، ومستودعات برمجية ناضجة، ومهام معقدة. لكن النتيجة تكشف عن أمرٍ أكثر أهمية لقادة الهندسة: الشعور بالسرعة لا يعني بالضرورة إنتاجية حقيقية.
قد يبدو كتابة دالة بسرعة أمرًا مثمرًا. ولكن إذا احتجنا بعد ذلك إلى عشرين دقيقة لمراجعة النتيجة وتصحيحها وتعديلها، فإن هذا الشعور يتغير.
يجب على قسم الهندسة البدء بقياس دورة حياة المنتج بأكملها. ليس المقصود كمية التعليمات البرمجية التي يولدها الذكاء الاصطناعي، بل كمية البرامج الموثوقة التي تصل فعلياً إلى مرحلة الإنتاج.
لقد أدركت الصناعة منذ سنوات أن عدد أسطر البرمجة ليس مقياسًا دقيقًا للإنتاجية. فقد يحل مهندس مشكلةً ما بحذف ألفي سطر، بينما يُضيف آخر خمسة آلاف سطر جديدة، ما يزيد من التعقيد. إن قياس الكم يُكافئ النشاط، لا القيمة بالضرورة.
يهدد الذكاء الاصطناعي بتكرار هذا الخطأ في ظل معايير جديدة.
عدد طلبات السحب.
نسبة الكود المُولّد.
عدد المهام المنجزة.
تم تنفيذ التعليمات.
سرعة الجيل.
قد تتحول كل هذه المقاييس إلى مجرد مؤشرات شكلية إذا لم تكن مرتبطة بنتائج هندسية. يمكن لفريق ما أن يضاعف عدد التغييرات التي يُجريها، وفي الوقت نفسه يزيد من وقت المراجعة، وعيوب الإنتاج، وتعقيد النظام.
ينبغي أن يأخذ المؤشر الحقيقي في الاعتبار كامل العملية: من تحديد المشكلة إلى تقديم الحل بشكل مستقر وقابل للصيانة. وقد أمضت منظمة DORA سنوات في دراسة القدرات والظروف المتعلقة بأداء فرق التكنولوجيا؛ ويؤكد تقريرها حول الذكاء الاصطناعي المدعوم فكرة تحليل تبني هذه التقنيات ضمن النظام التنظيمي بأكمله، وليس كتحسين برمجي معزول.
يمكن للذكاء الاصطناعي أن يزيد الإنتاج. يجب على الهندسة ضمان النتائج.
من المفاهيم الخاطئة الشائعة في هذا النقاش افتراض أن الكود المُولّد بواسطة الذكاء الاصطناعي سيكون بالضرورة أفضل أو أسوأ من الكود المُولّد بواسطة البشر. لكن الواقع يبدو أكثر تعقيدًا. فكلاهما قد يعاني من مشاكل، إلا أن أنماط هذه المشاكل ليست بالضرورة متطابقة.
قارنت دراسة واسعة النطاق نُشرت عام ٢٠٢٥ أكثر من ٥٠٠ ألف عينة من التعليمات البرمجية المكتوبة بواسطة البشر وتلك المكتوبة بواسطة الذكاء الاصطناعي بلغة بايثون وجافا. ووجد الباحثون أن التعليمات البرمجية المكتوبة بواسطة الذكاء الاصطناعي تميل إلى أن تكون أبسط وأكثر تكرارًا، ولكنها تحتوي في كثير من الأحيان على بنيات غير مستخدمة وعناصر تصحيح أخطاء مُضمنة بشكل مباشر. في المقابل، أظهرت التعليمات البرمجية المكتوبة بواسطة البشر تعقيدًا هيكليًا أكبر ومشاكل صيانة أكثر. ومع ذلك، كشف التحليل أيضًا عن انتشار أكبر للثغرات الأمنية عالية الخطورة في التعليمات البرمجية المكتوبة بواسطة الذكاء الاصطناعي.
وهذا له دلالة مهمة: قد تحتاج عمليات المراجعة التقليدية إلى التطور.
إذا تغيرت طريقة إدخال العيوب، فلا بد من تغيير طريقة اكتشافها أيضاً. تحتاج الفرق إلى معرفة الأنماط الشائعة في التعليمات البرمجية المولدة بواسطة النموذج، وتصميم ضوابط محددة لها.
نحن لا نستبدل المؤلف البشري بمؤلف اصطناعي، بل نُدمج نوعًا جديدًا من مُنتجي التعليمات البرمجية في نظام التطوير.
يُعدّ الأمن على الأرجح أحد المجالات التي تتطلب فيها هذه التحولات اهتمامًا بالغًا. وقد حلّل تقرير Veracode لأمن البرمجيات GenAI 2025 أكثر من مئة نموذج لغوي في Java وJavaScript وPython وC#. ووفقًا لنتائجه، فشلت 45% من العينات المُولّدة في اختبارات الأمان.
لا يعني هذا الرقم أن جميع البرامج المكتوبة بواسطة الذكاء الاصطناعي معرضة للاختراق تلقائيًا. تستخدم الدراسة مهامًا واختبارات مصممة لتقييم سلوكيات البرمجة الآمنة المحددة. لكنها تكشف حقيقة مزعجة: مجرد أن يُنتج نموذج ما رمزًا برمجيًا يبدو فعالًا لا يعني بالضرورة أنه يُطبق ضوابط الأمان بشكل صحيح.
كما حذر تحالف أمن الحوسبة السحابية من أن مساعدي البرمجة يغيرون الطريقة التي تدخل بها التعليمات البرمجية غير الموثوقة إلى بيئات التطوير، وأن فرق الأمن والهندسة بحاجة إلى التعاون لاكتشاف المخاطر في مراحل مبكرة.
النتيجة المعمارية واضحة. فإذا زادت سرعة الإنتاج، يجب تطبيق الضوابط الآلية في مرحلة أقرب إلى نقطة الإنشاء. أما الانتظار حتى التدقيق النهائي فيعني السماح بمرور كمية كبيرة من التعليمات البرمجية التي قد تنطوي على مشاكل عبر مسار المعالجة.
يجب أن يتحرك الأمن بسرعة الذكاء الاصطناعي.
تخيل فريقًا من عشرة مطورين، حيث يستطيع كل مطور إنتاج ضعفين أو ثلاثة أضعاف التغييرات بفضل الأدوات التوليدية. إذا بقي عدد المراجعين كما هو، واستمرت عملية مراجعة الكود بالعمل كما كانت، فالنتيجة واضحة: ستظهر قائمة انتظار.
ستكون طلبات السحب أكبر حجماً.
ستكون المراجعات أسرع وأكثر سطحية.
ستتنافس التعليقات المهمة مع التغييرات التي يتم إنشاؤها تلقائيًا.
وفي النهاية سيبدأ الفريق في الثقة بأنه "إذا كتب الذكاء الاصطناعي البرنامج واجتاز الاختبارات، فمن المحتمل أنه جيد".
تمثل تلك اللحظة تحولاً خطيراً في ثقافة الهندسة.
لا تقتصر مراجعة الكود على اكتشاف أخطاء بناء الجملة فحسب، بل إنها تنقل المعرفة، وتحمي القرارات المعمارية، وتتيح لأعضاء الفريق المختلفين فهم كيفية تطور النظام.
إذا أصبحت مراجعة التعليمات البرمجية مجرد موافقة آلية على التغييرات التي يتم إنشاؤها بسرعة، فإن الشركة تفقد إحدى آلياتها الرئيسية للتعلم الجماعي.
لا يكمن الحل في مطالبة المهندسين بالقراءة بشكل أسرع، بل في إعادة تصميم سير عمل التطوير بحيث لا يُولّد الذكاء الاصطناعي كميات هائلة من التغييرات يصعب إدارتها.
قبل ظهور الذكاء الاصطناعي، كان تعديل آلاف الأسطر يتطلب جهداً كبيراً. أما الآن، فيمكن للبرامج تعديل مكونات متعددة خلال جلسة واحدة. من الناحية التقنية، يبدو هذا تحسناً هائلاً في الإنتاجية.
من وجهة نظر المراجعة، قد يكون ذلك كارثة.
يصعب فهم التغييرات الكبيرة لأنها تزيد من حجم المعلومات التي يجب على المراجع استيعابها في الوقت نفسه. علاوة على ذلك، إذا كان جزء كبير من التنفيذ يعتمد على نموذج، فقد لا يكون لدى كاتب طلب السحب فهم شامل لكل قرار تم اتخاذه.
يحتاج الهندسة المدعومة بالذكاء الاصطناعي إلى استعادة أحد مبادئها الأساسية: التغييرات الصغيرة، والأهداف الواضحة، والحدود المحددة. إن القدرة على توليد 5000 سطر من التعليمات البرمجية لا تعني أنه ينبغي علينا حشرها جميعًا في مراجعة واحدة.
ينبغي أن يساعدنا الذكاء الاصطناعي في تقليل الحجم المعرفي للتغييرات، لا في زيادته.
لا ينبغي تقييم مطور البرامج الجيد بناءً على كمية التعليمات البرمجية التي يكتبها، بل بناءً على قدرته على إنتاج تعديلات مفهومة وقابلة للتحقق ومتوافقة مع البنية الحالية.
تبدأ قابلية الصيانة قبل عملية الدمج.
ينشأ الدين التقني عندما تتخذ المؤسسة قرارات تُسهّل عملية التسليم الحالية، ولكنها تُنشئ تكاليف مستقبلية للصيانة أو التحديثات أو التصحيحات. ليس كل دين تقني سلبياً، ففي بعض الحالات، قد يكون افتراض وجوده قراراً تجارياً منطقياً.
تنشأ المشكلة عندما لا يعلم أحد أن الدين يتراكم.
يمكن لتوليد التعليمات البرمجية بكميات كبيرة باستخدام الذكاء الاصطناعي أن يُسرّع هذا النوع من الديون البرمجية غير المرئية. إذ يُمكن إدخال الدوال المكررة، والتجريدات غير المتناسقة، والمكتبات غير الضرورية، والحلول البديلة الصحيحة محليًا تدريجيًا دون التسبب في أخطاء فورية.
كل تغيير يبدو صغيراً.
يستمر النظام في العمل.
اجتازت الاختبارات.
بعد أشهر، تتطلب ميزة جديدة تعديل خمسة تطبيقات متشابهة تم إنشاؤها بواسطة جلسات ذكاء اصطناعي مختلفة. لا أحد يتذكر سبب وجود كل هذه الاختلافات، وكل تغيير يتطلب المزيد من السياق.
لم ينشأ الدين التقني من قرار سيئ واحد كبير. بل تراكم سطراً سطراً، واقتراحاً اقتراحاً، وطلب سحب طلب سحب.
بإمكان الذكاء الاصطناعي توليد التعليمات البرمجية بسرعة الآلة. وبدون ضوابط معمارية، يمكنه أيضاً توليد ديون تقنية بسرعة الآلة.
لسنوات، أشارت بعض النقاشات الدائرة حول الذكاء الاصطناعي إلى أن المعرفة التقنية المتعمقة ستصبح أقل أهمية لأن النماذج ستكون قادرة على كتابة التعليمات البرمجية. إلا أن التطور الفعلي لتطوير الذكاء الاصطناعي يُظهر عكس ذلك.
كلما كان إنتاج التنفيذ أسهل، كلما زادت أهمية تحديد أي تنفيذ يجب إنتاجه.
تحدد الهندسة المعمارية الحدود.
تحديد المسؤوليات.
التحكم في التبعيات.
حدد كيف تتطور المكونات.
يمكن للنموذج أن يُنتج عشر طرق صحيحة تقنياً لحل مشكلة ما. ويحتاج المهندس إلى تحديد الطريقة التي تتناسب مع استراتيجية الشركة التقنية.
هذا أحد الأسباب التي تجعل مهارات مثل تصميم الأنظمة، وتصحيح الأخطاء، والتقييم، والحوكمة تكتسب أهمية متزايدة في فرق التكنولوجيا. يمكن أتمتة الأعمال الروتينية تدريجياً، لكن تبقى مسؤولية النظام قائمة.
يساهم الذكاء الاصطناعي في خفض تكلفة كتابة التعليمات البرمجية، مما يزيد من قيمة المعيار.
من المرجح أن يكتب مهندس المستقبل عددًا أقل من الأسطر يدويًا، ولكنه سيكون مسؤولاً عن اتخاذ المزيد من القرارات المتعلقة بالبرمجيات التي تولدها الأنظمة الذكية.
تتضمن خطوط التكامل المستمر والتسليم المستمر بالفعل اختبارات مؤتمتة وتحليلات ثابتة وضوابط أمنية. ومع ذلك، فإن عصر التطوير المدعوم بالذكاء الاصطناعي سيتطلب تعزيز هذه الضمانات.
ينبغي التعامل مع الكود المُولّد مبدئياً على أنه كود غير موثوق به. ليس لأن الذكاء الاصطناعي خطير بطبيعته، بل لأن تكلفة إنتاجه منخفضة للغاية لدرجة أن التحقق منه يجب أن يكون منهجياً.
ستحتاج المؤسسات إلى دمج التحليل الثابت، والاختبار الآلي، وفحص التبعيات، والتحقق من صحة البنية، وسياسات الأمان قبل السماح بتنفيذ التغييرات. بالنسبة للأنظمة الحيوية، سيكون من الضروري أيضًا توثيق الأدوات المستخدمة في عملية البناء والمراجعات البشرية التي أُجريت.
كشف تحقيقٌ أُجري على 7703 ملفاتٍ نُسبت علنًا إلى أدوات الذكاء الاصطناعي عن 4241 حالة استغلالٍ حرجٍ للثغرات الأمنية على الإنترنت، موزعةً على 77 نوعًا من الثغرات. ولاحظت الدراسة نفسها اختلافاتٍ كبيرةً تبعًا للغة البرمجة والأداة المستخدمة، مما يُؤكد الحاجة إلى ضوابط مُصممة خصيصًا للسياق التقني.
لا يوجد مرشح سحري واحد لبرمجة الذكاء الاصطناعي.
يجب بناء الجودة كنظام من الحواجز المتتالية.
في العديد من المستودعات الحالية، يصعب تحديد الأجزاء المكتوبة يدويًا، وتلك التي اقترحها مساعد، وتلك التي أنشأها برنامج حاسوبي بالكامل تقريبًا. ووفقًا لدراسة حديثة أجرتها GitLab، فإن 431% من المطورين الذين شملهم الاستطلاع يجدون صعوبة في التمييز بين الكود المُنشأ بواسطة الذكاء الاصطناعي والكود المكتوب يدويًا.
هل يهم حقاً من كتب الكود؟
من منظور وظيفي بحت، قد يبدو الأمر غير ذي صلة. إذا كان يعمل ويلبي المتطلبات، فلا ينبغي للمؤلف تغيير النتيجة.
لكنّ إمكانية التتبع تصبح بالغة الأهمية عند ظهور مشكلات تتعلق بالأمان أو الترخيص أو التدقيق أو الصيانة. قد تحتاج المؤسسة إلى معرفة الأدوات المستخدمة في التغيير، والسياق الذي استُخدمت فيه، والجهة التي صادقت على التنفيذ.
هذا لا يعني وضع ملصقات على كل سطر بشكل مفرط، بل يعني بناء عملية تضمن المساءلة الواضحة عن كل تغيير.
لا يمكن للذكاء الاصطناعي أن يتحمل مسؤولية الشركات عن ثغرة أمنية تم إدخالها في الإنتاج.
يمكن للأداة أن تُنشئ.
يظل الفريق مسؤولاً عن التسليم.
يجب أن يظل هذا الاختلاف واضحاً داخل ثقافة الهندسة.
وهناك نتيجة أخرى أقل تداولاً. فالعديد من المهام التي ساعدت تاريخياً في تدريب المطورين المبتدئين هي تحديداً تلك التي يمكن للذكاء الاصطناعي أتمتتها بسهولة.
أنشئ دوالًا بسيطة.
اكتب التعليمات البرمجية المتكررة.
تصحيح الأخطاء الأساسية.
قم بإجراء الاختبارات الأولية.
لم تكن هذه الأنشطة مجرد أعمال ذات قيمة منخفضة، بل كانت بمثابة تدريب أيضاً. فقد سمحت للمطور بفهم المستودع، وارتكاب أخطاء بسيطة، وبناء حُكم تقني تدريجياً.
إذا قام الذكاء الاصطناعي بأداء كل هذه المهام تلقائيًا، فسيطرح سؤال مهم: كيف سنقوم بتدريب كبار المهندسين في المستقبل؟
يحتاج هذا القطاع إلى تجنب سيناريو يتعلم فيه المطورون المبتدئون في المقام الأول قبول التعليمات البرمجية المولدة دون تطوير القدرة على تقييمها.
لا ينبغي أن يؤدي استخدام الذكاء الاصطناعي إلى إلغاء التعلم التقني، بل ينبغي أن يُعدّله.
ستحتاج برامج التدريب الجديدة إلى تدريس هندسة البرمجيات، وتصحيح الأخطاء، وقراءة الشفرة، وتقييمها في وقت مبكر. ولن تقتصر المهارة الأساسية على حفظ قواعد اللغة، بل ستشمل فهم سبب صحة الحل، والتمييز بين الإجابات التي تبدو مقنعة وتلك التي لا تكون كذلك.
عادةً ما يطرح النقاش بين مؤيدي ومعارضي البرمجيات المولدة بالذكاء الاصطناعي موقفين متطرفين. فمن جهة، هناك من يعتقدون أن هذه النماذج ستحل محل جزء كبير من الهندسة التقليدية. ومن جهة أخرى، هناك من يعتبرون البرمجيات المولدة محفوفة بالمخاطر لدرجة لا تسمح باستخدامها بجدية.
ربما يغفل كلا النهجين بعض جوانب الواقع.
يُعدّ الذكاء الاصطناعي جزءًا لا يتجزأ من التطور الحديث. وقد أظهر استطلاع عام 2025... موقع ستاك أوفر فلو وقد تلقت أكثر من 49000 رد من 177 دولة، وخصصت تركيزًا خاصًا لأدوات الذكاء الاصطناعي والوكلاء ونماذج اللغة، وهو دليل واضح على مدى دخول هذه التقنيات في العمل اليومي للمطورين.
لا يكمن التحدي في إيقاف توليد التعليمات البرمجية، بل في جعلها عملية احترافية.
ستحتاج الفرق إلى مواصفات أفضل، وهياكل أكثر وضوحاً، وخطوط أنابيب أكثر صرامة، وعمليات مراجعة مُكيّفة مع حجم التغييرات الجديد.
المفارقة مثيرة للاهتمام: فكلما زاد عدد الأكواد التي يكتبها الذكاء الاصطناعي، زادت أهمية هندسة البرمجيات.
لأن هناك حاجة لحماية النظام.
على مجموعة السحابة نحن نعتبر الذكاء الاصطناعي مُسرِّعًا لعملية الهندسة، وليس بديلًا عن البنية أو الجودة أو الخبرة التقنية. إن القدرة على توليد التعليمات البرمجية بسرعة أكبر تُضيف قيمة هائلة عندما تكون جزءًا من نظام تطوير مُصمَّم للتحكم في الجودة والأمان وسهولة الصيانة.
يجمع نهجنا بين هندسة البرمجيات، وهندسة التكنولوجيا، وتحديث التطبيقات، والذكاء الاصطناعي، وإدارة الديون التقنية لبناء أنظمة قادرة على التطور المستدام. لا يقتصر الأمر على تقديم الميزات بشكل أسرع فحسب، بل يتعلق بضمان ألا تصبح السرعة الحالية هي التحدي التقني في السنوات القادمة.
يُغير الذكاء الاصطناعي طريقة تطوير البرمجيات. لذلك، يجب أن تتطور أيضًا عمليات مراجعة التعليمات البرمجية، والمراقبة، والأمن، والحوكمة.
لأن الشركة لا ينبغي أن تقيس نجاح فريقها بكمية التعليمات البرمجية التي يمكنه إنتاجها.
ينبغي قياس ذلك من خلال جودة البرامج التي يمكنه صيانتها.
لا يمكن افتراض أمانها تلقائيًا. فقد كشف تقرير Veracode's GenAI Code Security 2025 عن وجود ثغرات أمنية في عينة 45% التي تم اختبارها. وهذا يؤكد ضرورة إجراء تحليل ثابت واختبارات أمنية ومراجعة قبل نشر الكود المُولّد في بيئة الإنتاج.
يعتمد ذلك على السياق ونوع المهمة ومستوى خبرة الفريق. تُظهر الأبحاث تحسناً في بعض المهام، بينما في مهام أخرى، كما في دراسة METR مع مطورين ذوي خبرة في مستودعات ناضجة، زادت الأدوات المُحللة وقت الإنجاز بمقدار 19%. ينبغي قياس الإنتاجية على امتداد دورة العمل بأكملها، وليس فقط من حيث سرعة الكتابة.
إنها تراكم تكاليف الصيانة المستقبلية الناجمة عن استخدام برامج مدعومة أو مُولّدة بالذكاء الاصطناعي، والتي تُدمج دون فهم كافٍ أو مراجعة دقيقة أو اتساق معماري. وقد تتجلى هذه المشكلة في التكرار، أو الاعتماديات غير الضرورية، أو التجريدات غير المتناسقة، أو الحلول التي يصعب تطويرها.
لا ينبغي أن يتم ذلك بالكامل في أنظمة المؤسسة. يمكن للذكاء الاصطناعي أن يساعد في اكتشاف الأنماط وتحليل التغييرات، لكن المراجعة البشرية تظل مهمة للتحقق من صحة سياق العمل، والقرارات المعمارية، والمخاطر التي تعتمد على المعرفة الخاصة بالمنظمة.
ينبغي أن يخضع هذا الكود لنفس الضوابط التي تخضع لها أي شفرة برمجية أخرى، بالإضافة إلى عمليات تحقق إضافية حسب مستوى المخاطر. يُعدّ الاختبار الآلي، والتحليل الثابت، وفحص الأمان، ومراجعة التبعيات، والتقييم المعماري، عناصر أساسية في أي مسار تطوير حديث.
سيصبح تصميم الأنظمة، وهندستها، وتصحيح أخطائها، وأمنها، وفهم المجال، والقدرة على تقييم الحلول التي يولدها الذكاء الاصطناعي، أكثر أهمية. يمكن أتمتة بناء الجملة جزئيًا؛ لكن يبقى من الصعب تفويض الحكم التقني.
بدلاً من الاكتفاء بقياس حجم الكود أو عدد طلبات الدمج، ينبغي للمؤسسات تحليل وقت التسليم، والاستقرار، والعيوب، وإعادة العمل، ووقت المراجعة، وسهولة الصيانة، والنتائج التجارية. الهدف هو قياس جودة البرمجيات المُسلّمة بشكل موثوق، وليس مجرد النصوص المُولّدة.
يُزيل الذكاء الاصطناعي أحد القيود التاريخية لتطوير البرمجيات: الوقت اللازم لإنتاج تطبيق. يمكن تحويل فكرة إلى مئات الأسطر من التعليمات البرمجية في دقائق، ويمكن للذكاء الاصطناعي تعديل مكونات متعددة قبل أن ينتهي الشخص من مراجعة الملف الأول.
تمثل هذه الإمكانية فرصة استثنائية. إذ يمكن للفرق إجراء التجارب بوتيرة أسرع، وأتمتة الأعمال المتكررة، وتخصيص جزء من وقتها لمشاكل ذات قيمة أعلى. لكن السرعة تفرض أيضاً مسؤولية جديدة.
إذا أصبح توليد التعليمات البرمجية شبه مجاني،, يصبح فهمه مورداً نادراً.
لن تنشأ الأزمة القادمة في هندسة البرمجيات بالضرورة من نماذج غير قادرة على البرمجة، بل قد تنشأ تحديداً لأن النماذج تبرمج بكفاءة كافية تسمح لنا بقبول كميات هائلة من التعليمات البرمجية دون الحاجة إلى تطوير أنظمة قادرة على مراجعتها بنفس السرعة.
لهذا السبب، فإن هندسة البرمجيات، ومراجعة التعليمات البرمجية، والاختبار، والأمن، وإدارة الديون التقنية لا تفقد أهميتها، بل تدخل مرحلة أكثر أهمية.
من المرجح أن تكتسب الشركات التي تستخدم الذكاء الاصطناعي فقط لإنتاج المزيد من البرمجيات سرعةً مؤقتة. أما الشركات التي تعيد تصميم هندستها حول الجودة والتتبع والفهم، فستبني ميزةً أكثر استدامة.
لم يعد السؤال مطروحاً ما مقدار التعليمات البرمجية التي يستطيع فريقك كتابتها باستخدام الذكاء الاصطناعي؟.
السؤال الحقيقي هو:
هل تستطيع مؤسستك فهم ومراجعة وصيانة كل ما ينتجه الذكاء الاصطناعي؟
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
