لا أحد يخطط لأن ينسى كيف يكتب الكود. الأمر يحدث بالطريقة نفسها التي تُفقد بها أغلب المهارات: اختصار مريح تلو الآخر. كنت تكتب التعبير النمطي (regex) بنفسك؛ أما الآن فأنت تصف ما تريده وتلصق أيًّا كان ما يعطيك إياه النموذج. كنت تتتبّع تتبّع المكدّس (stack trace) سطرًا سطرًا؛ أما الآن فتُلقيه في نافذة محادثة وتقرأ الملخّص. كل استبدال من هذه الاستبدالات عقلاني بمفرده. ومجموعها، على مدى عام من العمل بمساعدة الذكاء الاصطناعي، هو مطوّر قادر على إطلاق الميزات بسرعة عندما تكون الأداة مُفعّلة، ويتجمّد قليلًا حين تكون الأداة معطّلة.
هذا هو المضمون المُقلق الكامن وراء ازدهار "البرمجة بالإحساس" (vibe coding) هذا الشهر — إذ تفيد التقارير أن Lovable تقترب من تقييم قدره 13.2 مليار دولار، بينما تجمع Replit وFactory كلٌّ على حدة تمويلات بمليارات الدولارات، وتخفض SpaceX أسعار النماذج المتقدّمة عبر Grok 4.5 المصمّم من أجل "الوكلاء المستقلّين". كل ذلك مُحسَّن لتحقيق شيء واحد: دفعك إلى كتابة كود أقل بنفسك. وهذا هو المقصود بالضبط، وبالنسبة لكثير من الأعمال فهذه مقايضة مشروعة. لكنها تعني أن الصناعة أمضت العامين الماضيين في تجربة غير مضبوطة حول مقدار القدرة اليدوية على البرمجة التي يمكن توكيلها للخارج قبل أن تكلّفك شيئًا، والفاتورة بدأت تُستحق بطرق ملموسة يمكن التحقّق منها.
أين تظهر الفجوة فعليًّا
ضمور المهارة ليس قلقًا مبهمًا — بل يظهر في ثلاث حالات ملموسة، ومن المفيد أن تكون صادقًا مع نفسك بشأن أيٍّ منها يخصّك:
- المقابلات. معظم المقابلات التقنية، باستثناء اختبارات "خذها إلى المنزل"، لا تزال تُقيّد استخدام مساعدة الذكاء الاصطناعي أو تحظرها تمامًا. فإذا كانت طلاقتك اليومية قد انتقلت بهدوء من "أستطيع كتابة هذا" إلى "أستطيع توجيه نموذج ليكتب هذا"، فإن جولة على السبورة أو كتابة كود مباشرة ستكشف الفجوة في الوقت الفعلي، أمام الشخص الذي يقرّر توظيفك.
- الأعطال (Outages). عندما يتعطّل نظام الإنتاج، غالبًا ما يكون أسرع طريق للإصلاح هو قراءة كود غير مألوف تحت الضغط والتفكير فيه مباشرة — لا صياغة موجّه (prompt) جيّد عن نظام لا وقت لديك لشرحه. فالاستجابة للحوادث تكافئ بالضبط تلك المهارات (سرعة قراءة الكود، التصحيح الذهني، معرفة سطح واجهة البرمجة عن ظهر قلب) التي تُمارَس أقل ما يكون حين يتولّاها نموذج نيابة عنك يوميًّا.
- لا اتصال، لا مساعد. رحلة طيران، أو موقع عميل بشبكة مُقفَلة، أو انقطاع في خدمة مزوّد النموذج — أيٌّ من هذه يعيدك إلى البرمجة دون مساعدة لفترة. ولا يلزم أن يكون ذلك دائمًا ليكون مهمًّا؛ يكفي أن يحدث في يوم كنت تحتاج فيه إلى إنجاز شيء ما.
لا شيء من هذا حالات افتراضية اختُلقت لترويج منتج. إنها الظروف الاعتيادية لمسيرة مهنية عملية. والسؤال هو ما إذا كنت ستلاحظ التآكل قبل أن تضعك إحدى هذه الحالات في موقف حرج.
أدوات التدريب تدخل المشهد
هذه هي الفجوة التي تستهدفها أداة جديدة تُدعى Atrophy CLI، وفقًا لتقرير نشرته The Register هذا الشهر. والفكرة صريحة: عامل القدرة على البرمجة كتصنيف إيلو (Elo) في الشطرنج، لا كثنائية "يستطيع البرمجة / لا يستطيع". تبدأ باختبار أساسي يحدّد موقعك الحالي، ثم تدرّبك الأداة عبر عدد من فئات المهارة المنفصلة — استذكار الصياغة اللغوية، التصحيح، قراءة الكود، تذكّر واجهات البرمجة، وتفكيك المسائل — وتتتبّع تصنيفك عبر الزمن، تمامًا كما يتتبّع محرّك شطرنج ما إذا كنت تتحسّن فعلًا أم مجرّد تشعر بذلك. والشعار يلخّص الأطروحة كلّها في سطر واحد: "إن كانت مساعدة الذكاء الاصطناعي تُضعف بهدوء قدرتك على البرمجة دون مساعدة، فإن الرسم البياني يريك ذلك — قبل أن تفعله مقابلة عمل، أو عطل، أو يوم بلا واي فاي".
الخيار التصميمي الجدير بالملاحظة هو التقسيم إلى فئات منفصلة بدلًا من درجة إجمالية واحدة. فالبرمجة بالإحساس لا تُضعف كل مهارات البرمجة بالتساوي — إذ قد تبقى بارعًا في التفكيك (تقسيم المسألة إلى خطوات) لأن هذا لا يزال في معظمه من مسؤوليتك حتى مع وجود مساعد ذكاء اصطناعي، بينما يضعف بهدوء استذكارك للصياغة اللغوية وعضلة التصحيح الخام دون مساعد، لأن هذه بالضبط هي الأجزاء التي كنت تُفوّضها. درجة واحدة كانت ستُخفي ذلك. أما التصنيف لكل فئة على حدة فيخبرك على الأقل بأيّ عضلة تحديدًا عليك إعادة تدريبها، وهو مؤشّر أكثر فائدة من إحساس عام بالصدأ.
تحفّظ ضروري
يستحق الأمر أن يُقال بوضوح: Atrophy CLI أداة جديدة، ولم أطّلع على بيانات مستقلّة حول ما إذا كانت تصنيفاتها تتنبّأ فعلًا بالأداء في المقابلات أو الحوادث، أو ما إذا كان التدريب المنتظم يعكس فعليًّا تراجع المهارة بشكل ملموس، مقابل أن يجعلك جيّدًا في التمارين نفسها فحسب — وهذا خطر حقيقي في أي أداة تدريب ليست هي المهمة الفعلية نفسها. تعامل معها بوصفها أداة تشخيصية تستحق التجربة، لا حلًّا مثبتًا. أما الفئة التي تُرسي أساسها — قياس تراجع المهارة الناتج عن مساعدة الذكاء الاصطناعي، بمعزل عن الإنتاجية الناتجة عنها — فهي الفكرة المفيدة هنا، سواء تبيّن أن هذه الأداة بعينها هي التي ستستمر أم لا.
ماذا تفعل حيال ذلك دون التخلّي عن الإنتاجية
لست بحاجة إلى الإقلاع نهائيًّا عن البرمجة بمساعدة الذكاء الاصطناعي لتحمي نفسك هنا؛ فذلك سيعني التخلّي عن مكسب إنتاجية حقيقي للتحوّط ضدّ خطر يمكنك إدارته بتكلفة أقل بكثير. بضع عادات ملموسة تقوم بمعظم المهمّة:
- بين الحين والآخر، حلّ شيئًا كنت ستُسنده عادة إلى النموذج — علّة، أو دالة صغيرة، أو تحويل بيانات — دون أي مساعدة على الإطلاق، واحسب الوقت الذي تستغرقه. لاحظ أين تتردّد.
- قبل جولة مقابلات أو مناوبة عمل تحت الطلب، اخصص عمدًا فترة من البرمجة دون ذكاء اصطناعي، تمامًا كما تُذاكر بكثافة قبل امتحان لم تكن بحاجة إلى مادّته منذ أشهر.
- عندما تستخدم مساعدة الذكاء الاصطناعي فعلًا، اقرأ الكود المُولَّد بعناية كافية لتتمكّن من شرحه لشخص آخر، بدلًا من لصقه والانتقال مباشرة إلى ما بعده — فهذه هي الخطوة الأكثر تحديدًا لما إذا كان هذا التعرّض يبني فهمك أم يكتفي بغسله فحسب.
- إذا كانت أداة على غرار التصنيف مثل Atrophy CLI تناسبك، فاستخدمها كجهاز إنذار للدخان لا كبرنامج تدريب بحدّ ذاته — تحقّق منها دوريًّا، وإذا كانت إحدى الفئات في تراجع، فاذهب وأنجز عملًا حقيقيًّا دون مساعدة في ذلك المجال بدلًا من التدرّب على بطاقات تعليمية له.
الإطار الصادق للأمر هو أن البرمجة بمساعدة الذكاء الاصطناعي والقدرة على البرمجة دون مساعدة أصبحتا الآن مهارتين منفصلتين تُديرهما، لا مهارة واحدة بها اختصار. وأصحاب العمل ولجان المقابلات وقنوات الحوادث في الساعة الثالثة فجرًا لم يستوعبوا ذلك بعد تمامًا، لكنهم سيلاحظون أيّ المرشّحين حافظوا على كلتا المهارتين حيّتين.