البرمجة بالذكاء الاصطناعي تكتب أسرع… لكن من يراجع هذا السيل قبل أن يتحول إلى ثغرات؟

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

لماذا يتحول الكود المولّد بالذكاء الاصطناعي من مكسب سريع إلى عبء أمني؟

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

والأرقام العامة تؤكد أن هذه ليست حالة منفردة. Google DORA وجدت أن 90% من المشاركين يستخدمون الذكاء الاصطناعي في العمل، وأن أكثر من 80% يرون أنه رفع إنتاجيتهم، لكن 30% قالوا إنهم يثقون قليلًا أو لا يثقون أصلًا بما تنتجه هذه الأدوات. كذلك أظهر استطلاع Stack Overflow أن 66% من المطورين ينزعجون من حلول “تكاد تكون صحيحة”، بينما قال 45% إن تصحيح الكود الذي يولّده الذكاء الاصطناعي يستهلك وقتًا أكبر. بعبارة أوضح: نعم، الأداة تسرّع البداية، لكنها لا تضمن نهاية هادئة.

ثم جاءت أرقام SonarSource لتضيف زاوية أكثر حساسية: 72% من المطورين الذين جرّبوا أدوات الذكاء الاصطناعي يستخدمونها يوميًا، كما أن 42% من الكود الذي يلتزمون به حاليًا أصبح مولّدًا أو مدعومًا بالذكاء الاصطناعي. عندما يصل هذا الحجم من الاعتماد إلى الكود اليومي، فإن أي خلل صغير لا يبقى “خطأ صغيرًا” طويلًا؛ بل قد يتحول إلى نمط يتكرر عشرات أو مئات المرات داخل المنتج نفسه. لهذا السبب، لم يعد السؤال: هل نستخدم الأداة؟ بل: كيف نمنعها من مضاعفة أخطائنا بسرعة غير مسبوقة؟

أين تبدأ الفوضى فعلًا؟

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

تقرير New York Times أعاد تسليط الضوء على عقدة معروفة داخل القطاع: ليس هناك عدد كافٍ من مهندسي أمن التطبيقات لمراجعة هذا الفيضان. جو سوليفان قالها بوضوح: حتى احتياج الشركات الأميركية وحدها لا يغطيه العدد المتاح من هؤلاء المختصين. كما أن دراسة ISC2 أظهرت أن 32% من العاملين في الأمن السيبراني يشعرون بالإرهاق بسبب نقص الكفاءات، و47% يشعرون بأن عبء العمل يطغى عليهم كثيرًا. لذلك، حين ترفع البرمجة بالذكاء الاصطناعي الإنتاج بعشرة أضعاف، بينما يظل عدد المراجعين شبه ثابت، فنحن عمليًا لا نحل مشكلة؛ نحن ننقلها من عنق زجاجة إلى انفجار زجاجة.

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

هل الذكاء الاصطناعي هو المشكلة أم طريقة استخدامه؟

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

والأفضل من ذلك أن بعض الحوادث المنتشرة إعلاميًا تكشف لنا أن الأزمة الحقيقية ليست دائمًا “كودًا كتبه الذكاء الاصطناعي ثم كسر الدنيا”. في حالة أمازون، ظهرت تقارير داخلية نشرتها Business Insider ربطت إحدى الحوادث بأداة AI مساعدة وبخسارة تقارب 120 ألف طلب و1.6 مليون خطأ على الموقع، لكن Amazon ردت رسميًا قائلة إن التغطيات ضخّمت المسألة، وإن حادثة واحدة فقط تضمنت أداة AI مساعدة، ولم يكن السبب “كودًا مكتوبًا بالذكاء الاصطناعي”، بل اتباع نصيحة غير دقيقة استندت إلى ويكي داخلي قديم. هذا التفصيل مهم جدًا، لأنه يعيدنا إلى أصل الدرس: الخطر كثيرًا ما يكون في الحوكمة، والمراجعة، والاعتماد الأعمى، والوثائق الرديئة، لا في الأداة وحدها.

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

اللافت أن السوق نفسه بدأ يعترف بالمشكلة. OpenAI أطلقت Codex Security بوصفه وكيلًا لأمن التطبيقات، وقالت صراحة إن تسارع تطوير البرمجيات جعل المراجعة الأمنية عنق زجاجة أكثر حرجًا. Anthropic بدورها تحدثت عن Claude Code Security، وقالت إن نماذجها ساعدت على اكتشاف أكثر من 500 ثغرة في قواعد كود مفتوحة المصدر كانت موجودة منذ سنوات. وحتى Cursor، بدل أن تتصرف كأن المشكلة غير موجودة، اتجهت إلى الاستحواذ على Graphite، وهي منصة متمرسة في مراجعة الكود، في إشارة واضحة إلى أن الكتابة أصبحت أسرع من المراجعة والدمج الآمن. السوق يقول لنا عمليًا: إذا كان الذكاء الاصطناعي يكتب، فنحن نحتاج ذكاءً اصطناعيًا آخر يراجع، لكن مع إنسان يعرف متى يثق ومتى يوقف كل شيء.

المشكلة ليست في كثرة الكود، بل في ملكيته

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

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

ماذا نتوقع بعد ذلك؟ وما أثره علينا نحن؟

المشهد المقبل لن يتجه إلى التراجع عن البرمجة بالذكاء الاصطناعي، بل إلى تأطيرها. المنتدى الاقتصادي العالمي أشار إلى أن نسبة المؤسسات التي لديها عملية لتقييم أمن أدوات الذكاء الاصطناعي قبل نشرها ارتفعت من 37% في 2025 إلى 64% في 2026، وهذا يوحي بأن السوق بدأ ينتقل من مرحلة الانبهار إلى مرحلة التنظيم. نحن غالبًا أمام مستقبل يصبح فيه “مراجع الكود الذكي” وظيفة مرافقة لـ “كاتب الكود الذكي”، وتصبح مهارات التحقق والفهم والهندسة الأمنية أكثر قيمة من مجرد القدرة على إنتاج أسطر أكثر.

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

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

المصادر:

• The New York Times
• Google DORA
• Stack Overflow Developer Survey
• SonarSource State of Code Developer Survey