يُعامَل الترميز الحدسي (vibe coding) وكأنه اعتراف. يعترف أحدهم بأنه بنى تطبيقًا يعمل دون قراءة سطر واحد كتبه النموذج، وتتفاعل الغرفة كما لو أنه اعترف للتو بتخطي فحص سلامة. إليك الادعاء الذي أريد الدفاع عنه: هذا التفاعل خاطئ في معظمه. عدم كتابة الصياغة البرمجية ليس هو نفسه عدم معرفة ما تفعله — إنه توزيع مختلف لمكان تركيز حكمك، وبالنسبة لجزء كبير مما يبنيه الناس، إنه التوزيع الصحيح.
الكلمة نفسها لا يتجاوز عمرها عامين أو ثلاثة، وهي تُستخدم بالفعل لأداء وظيفة أكبر من طاقتها. تُطلق على سلوكين مختلفين تمامًا يبدوان متشابهين من الخارج:
- شخص يصف ما يريده بدقة، ويتحقق من النتيجة وفق معايير حقيقية، ثم ينشرها.
- شخص يلصق فكرة غامضة، ويلمح لقطة شاشة سريعًا، ثم يدفعها إلى الإنتاج على أمل أن تنجح.
منتقدو "البرمجة بالإحساس" (vibe coding) يصفون عادةً، وبإنصاف، الشخص الثاني. لكنهم يتحدثون كما لو أن الشخص الأول غير موجود، أو كما لو أن الاثنين على نفس الطيف ولا يفرق بينهما سوى درجة الكسل. هما ليسا على الطيف نفسه على الإطلاق. أحدهما منهج عمل، والآخر غياب منهج تمامًا.
ما كانت المهارة القديمة موجودة من أجله فعليًا
قراءة الكود سطرًا بسطر، وتتبّع خطأ (stack trace) رجوعًا إلى مؤشر فارغ في ملف بعيد ثلاث ملفات — لم يكن هذا الهدف أبدًا. كانت الطريقة الوحيدة المتاحة لهدف لم يتغيّر: هل يفعل هذا الشيء ما أحتاجه، بأمان، وهل يمكنني الوثوق به غدًا. لثلاثين عامًا، كانت الطريقة الوحيدة للإجابة على هذا السؤال هي أن تكون بارعًا بما يكفي في اللغة لفحص الآلية مباشرة. فأصبحت البراعة مقياسًا بديلًا للكفاءة، وفي النهاية اختلط الأمر بين المقياس البديل والهدف الحقيقي نفسه. بدأ الناس يعاملون "القدرة على قراءة تعديل (diff)" كفضيلة أخلاقية بدلًا من كونها وسيلة لتحقيق غاية.
حين لا يعود التحقق يتطلب تلك البراعة — حين يُصدر البناء (build) سجلًا خاصًا به يوثّق ما تم اختباره، وما نجح، وما رصده وكيل مراجعة — يتوقف المقياس البديل عن كونه ضروريًا. تعود إلى السؤال الحقيقي: هل يعمل؟ هل يمكنني الوثوق به؟ لقد بنينا سجلات التحقق في كل بناء لهذا السبب بالتحديد، لأن هذا السؤال يحتاج إجابة لا تمر عبر "هل قرأ إنسان المصدر"، لأن ذلك لم يكن ليحدث أصلًا لدى معظم البانين، بوجود موجّه (prompt) أو بدونه. لم يكن أحد يقرأ كود PHP في إضافة ووردبريس التي بناها أيضًا.
إلى أين انتقلت المهارة فعليًا
انتقلت إلى التوصيف (specification)، والتوصيف أصعب مما يبدو. راقب شخصًا يكتب موجّه بناء جيدًا فعليًا وسترى نفس الانضباط الذي يطبّقه مهندس أول على وثيقة تصميم:
- ما هي معايير القبول؟
- ما الذي يقع صريحًا خارج النطاق؟
- ماذا يحدث في الحالة الحدّية حين تكون سلة الشراء فارغة عند الدفع؟
- من يمكنه رؤية هذه البيانات، ومن لا يمكنه؟
موجّه غامض يُنتج تطبيقًا غامضًا لنفس السبب الذي يُنتج فيه تذكرة عمل غامضة طلب سحب (pull request) غامضًا — قيود رديئة تعني مخرجات رديئة، ولا حاجة لأي نموذج ذكاء ليصح ذلك. الأشخاص الذين ينجحون في الشحن باستخدام أدوات الذكاء الاصطناعي لا يتخطون التفكير؛ بل نقلوه إلى وقت أبكر، إلى الدقائق الخمس عشرة قبل الرسالة الأولى بدلًا من الساعتين بعد أول خطأ.
بقية المهارة المنتقلة هي حُكم على مستوى المراجعة، وهو أشبه بقراءة ملخص البناء وسجل التحقق الخاص به وطرح السؤال الشكّي الصحيح، وليس قراءة الكود. هل "يعالج ردود المدفوعات" يعني فعليًا أنه يعالج حالة فشل الرد في منتصف العملية؟ هل اختُبرت الحالة الفارغة أم فقط المسار السعيد؟ هذه مهارة حقيقية، وقابلة للتعلّم بطريقة لم تكن "تعلّم قراءة بايثون" قابلة له سوى لشريحة من الناس ممن توافرت لهم الوقت والاستعداد. رأيت مالك متجر بلا أي خلفية برمجية يطرح أسئلة تحقق أدق حول تطبيق مخزونه من أسئلة كثير من المهندسين حول كود لم يكتبوه، لأنه يعرف عمله ويعرف بالضبط كيف يبدو العطل بالنسبة له. هذه ليست مهارة أدنى تحل محل الأصلية. بالنسبة لبنائه، هي أكثر صلة من قواعد اللغة على الإطلاق.
القصة التي تُبرّر السخرية فعليًا
الآن الاعتراف، لأن المنتقدين لا يخترعون هذا من العدم. هناك نسخة رديئة فعليًا من "البرمجة بالإحساس"، وهي شائعة بما يكفي لتجعل للسخرية هدفًا حقيقيًا:
- الشخص الذي يبني نظام تسجيل دخول، يرى علامة صح خضراء، وينشره دون أن يسأل أبدًا أي بيانات يمكن لهذا النظام الوصول إليها أو ماذا يحدث عند وصول طلب دون أي رمز مصادقة.
- نشر استعلام قاعدة بيانات مبني من موجّه بلغة طبيعية دون التحقق من وصول مدخلات المستخدم إليه دون تنقية.
سجل التحقق يمكنه أن يخبرك بأن البناء عمل وأن الاختبارات نجحت. لا يمكنه أن يخبرك بأن الاختبارات غطّت الشيء الصحيح، ولن يمنعك من النشر رغم ذلك إن لم تنظر إليه.
هذا هو الحد الأدنى الذي لا يتحرك، بغض النظر عن مدى تطور الأدوات: أنت لا تزال مسؤولًا عن معرفة ما يجب أن يعنيه "الانتهاء" لبنائك المحدد، وعن قراءة السجل فعليًا بدلًا من الثقة بعلامة الصح على سبيل الإيمان.
تخطي ذلك ليس نوعًا جديدًا من الكفاءة. إنه اللامبالاة القديمة بحلّة جديدة، وتستحق تمامًا السمعة التي تحصل عليها. الخطأ الذي يرتكبه المنتقدون هو افتراض أن هذا هو الوضع الوحيد المتاح — وأن وجود الفشل يعني استحالة الانضباط. لكنه ممكن. فقط لا يبدو كما كان الانضباط يبدو سابقًا، والأشخاص الذين قاسوا الكفاءة دائمًا ببراعة قواعد اللغة فقط لا يملكون طريقة لرؤيته بعد.
امنحها بضع سنوات أخرى وستتلاشى الكلمة على الأرجح كما ضاق معنى "هاكر" من "عابث ذكي" إلى شيء أكثر إثارة للقلق ثم توسّع مجددًا. ما سيبقى هو الفرق الحقيقي، الذي كان مهمًا طوال الوقت: بانون يوصّفون بدقة ويتحققون من عملهم، وبانون لا يفعلون ذلك. الأداة التي استخدموها للوصول إلى هناك لم تكن يومًا الجوهر الحقيقي.
