ما يجيده الذكاء الاصطناعي في البرمجة وأين يكلّفك وقتاً

ما يختصره النموذج فعلاً

نبدأ بالـ boilerplate لأنه الأقل إثارة والأكثر ثباتاً: ملف Dockerfile لبيئة لها عشرة آلاف مثال منشور، أو المعالِج الأربعون من نوع CRUD في خدمة فيها تسعة وثلاثون قبله. أنت تعرف شكل هذا النص قبل أن تقرأه، وتحكم على صحته في ثوانٍ.

والنقل بين اللغات والصيغ هو الحيلة نفسها بثوب آخر: من Python إلى TypeScript، ومن مخطط قاعدة إلى migration، ومن جدول بيانات إلى fixture للاختبار. البنية مثبّتة بالمصدر، والمصدر أمامك، والتحقق هنا مقارنة لا استرجاع من الذاكرة. والنموذج بارع في هذا براعة طابعٍ سريع يعرف صياغات لغات كثيرة، لا أكثر.

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

ثم التعاويذ: regex، ومرشّح jq، وأمر git الذي لا تحفظه أبداً. صياغة صعبة القراءة، لها رصيد عام ضخم من الأمثلة، وفحصها لا يتجاوز خمس ثوانٍ: شغّلها على عيّنة. البديل تصفّح طويل في صفحة man، فالربح حقيقي حتى مع نسبة نجاح متوسطة.

وليست المسألة في هذا كلّه صعوبة؛ بل أن التحقق رخيص، وفي مجال لا تستطيع تقييمه أنت لا توفّر وقتاً بل تؤجّله.

أين يبدأ بأخذ وقتك بدل توفيره

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

والموضع الثاني كل ما يعتمد على مكتبة أحدث من بيانات التدريب. صورة الـ API عنده مجمّدة تقريباً عند تاريخ قطع بياناته (cutoff)؛ والأداة التي تقرأ ملف القفل (lockfile) أو الشيفرة المثبّتة عندك تستطيع أن تعرف أي إصدار لديك فعلاً، أما النموذج الذي يجيب من أوزانه وحدها فيخمّن، والجواب في الحالتين بالمظهر نفسه. تتغيّر أسماء التوابع وتتبدّل القيم الافتراضية، والنبرة واحدة سواء أكان التابع موجوداً في إصدارك أم حُذف قبل إصدارين.

والموضع الثالث التزامن الدقيق والأمان: كلاهما خاصية للنظام كلّه لا للمقطع الظاهر على الشاشة. الـ race condition ادعاءٌ عن ترتيب تشابك التنفيذ، والنموذج وهو يقرأ دالة واحدة لا يرى من يستدعيها ولا أي قفل يمسكه المستدعي؛ وكون تركيب نص داخل استعلام قابلاً للاستغلال يتوقف على مصدر القيمة، وقد يكون على بعد ثلاثة إطارات في المكدس (stack). هو يلتقط ثغرة مدرسية داخل diff تعرضه عليه، لكنه لا يعطيك برهاناً على أن الكود آمن. وفحص الصلاحية الموضوع بعد العملية التي جاء ليحرسها يبدو على الصفحة مطابقاً تماماً للموضوع قبلها.

العطل الأغلى: دالة لا وجود لها

سمِّه باسمه: هو أكثر ما يكلّفك في هذه الأدوات. النموذج يخترع دالة أو تابعاً (method) أو flag أو اسم حزمة، ويمنحه توقيعاً يبدو صحيحاً تماماً، ويصف ما يُرجعه بجملة واثقة. هو ينتج أرجح امتداد ممكن لكودك، وتابعٌ اسمه parseTimestamp في مكتبة تواريخ احتماله عالٍ جداً سواء كتبه أحد أم لا.

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

الوقاية آلية، وتستغرق ثوانيَ لا أكثر: أي اسم API لا تعرفه يُفحص في الشيفرة المثبّتة عندك أو في التوثيق الحقيقي قبل أن تبني عليه شيئاً. اذهب إلى التعريف، وابحث في مصدر الحزمة، وشغّل الأمر بـ --help. التزم بذلك، فيتحوّل أسوأ أعطاله إلى أرخصها.

طريقة عمل تصمد

راجع كل diff كما تراجع مساهمة من شخص كفؤ لم يرَ مشروعك قط، لأن هذا وصفه بالضبط. ماذا يحدث عند مدخل فارغ، وعند انتهاء المهلة، وعند الاستدعاء الثاني؟ وأبقِ التغيير صغيراً بحيث تقرؤه فعلاً؛ فالتغييرات المولَّدة الكبيرة هي المكان الذي ينجو فيه "المعقول الخاطئ" من المراجعة.

وشغّل الكود ولا تصدّق الشرح: الفقرة التي تصف ما تفعله الدالة نصٌّ مولَّد منفصل عن الدالة نفسها، وقد يتناقضان دون أن يبدو أحدهما خاطئاً. التشغيل دليل، والكلام تحته ادعاء. وحين يتعطّل شيء، الصق المخرَج الحقيقي — الـ stack trace كاملاً، ورسالة الـ compiler برقم سطرها، والـ assertion الفاشلة بقيمتيها — فالنص الحرفي يحمل الملف والسطر ونوع الاستثناء والقيمة المخالفة، وإعادة الصياغة تمحوها.

ولهذا كلّه فإن "compile ناجح" ليس "صحيحاً". الـ compiler يفحص الأنواع والصياغة ولا رأي له في نيّتك؛ واختبارات خضراء تعني أن الاختبارات نجحت، وربما كتبها النموذج نفسه من سوء الفهم ذاته الذي أنتج الكود. أما ما يؤلم فعلاً فيمرّ في الـ compile بلا شكوى: الفارق بواحد عند الحدّ، والشرط المقلوب في فرع لا يمرّ به أحد إلا في نهاية الربع.

لماذا لا تحسم أرقام الإنتاجية المسألة

التقديرات المنشورة عن مقدار التسريع تتباين تبايناً هائلاً، لأنها لا تقيس النشاط نفسه. أشهر رقم كبير فيها يعود إلى تجربة واحدة سنة 2023 أجراها باحثون من GitHub وMicrosoft: خمسة وتسعون مطوّراً مستقلاً طُلب منهم كتابة خادم HTTP بلغة JavaScript من الصفر، فأنهى من كان معه Copilot المهمة أسرع بنحو 56%. اقرأ وصف المهمة قبل أن تقرأ النسبة: مشروع جديد، مكتفٍ بذاته، لا بنية قائمة يجب أن يندمج فيها، وصحّته تظهر خلال دقيقة. وأوضح مثال مضاد هو تجربة METR سنة 2025: ستة عشر مطوّراً خبيراً في مشاريع مفتوحة المصدر عالجوا 246 مشكلة حقيقية في مستودعات عملوا فيها خمس سنوات وسطياً، فاستغرقوا وقتاً أطول بنسبة 19% حين سُمح لهم باستعمال أدوات الذكاء الاصطناعي، ثم قدّروا بعدها أنهم كانوا أسرع بنسبة 20%. ستة عشر شخصاً وجيل واحد من الأدوات ليسا قانوناً طبيعياً، لكن الفجوة بين 19% أبطأ مقيسة و20% أسرع محسوسة هي ما ينبغي أن يقلقك.

وثمة متغيّرات تبتلع الأثر المقيس: مدى معرفتك بالمشروع، وكم من الكود العام كُتب بلغته، وهل تُحسب مدة المراجعة أصلاً، وماذا تعني كلمة "انتهى" — دُمج، أم دُمج وبقي سليماً بعد ستة أشهر.

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