إذا كُسرت يدك لمدة شهرين… هل توقف عن العمل؟
Erik Schluntz، الباحث في Anthropic ومؤلف دليل "بناء وكلاء الأداء العالي"، لم يتوقف. قرر أن يترك كل شيء لـ Claude — وكانت التجربة درسًا عميقًا في طريقة التفكير الجديدة.
خطابه الأخير انتشر بشكل واسع على X، ووصفه أحد المتابعين بأنه "أفضل من 100 كورس مدفوع." في هذا المقال: كل ما قاله، مترجمًا وشرحه بأسلوب عملي للمطور العربي.
أولاً: ما هو Vibe Coding فعلاً؟
كثيرون يظنون أن استخدام Cursor أو Copilot لكتابة الكود = Vibe Coding. هذا خطأ.
طالما أنت تراجع كل سطر وتعدّل يدويًا، فأنت لم تدخل بعد في الـ "Vibe".
التعريف الدقيق جاء من Andrej Karpathy:
"انغمس تمامًا في الـ Vibe، استقبل النمو الأسي للتقنية، وانسَ تمامًا أن الكود موجود."
المعنى العملي: أنت تركّز على المنتج والنتيجة — لا على الكود السطر بسطر.
ثانياً: لماذا لا نتجاهل Vibe Coding؟
السبب: النمو الأسي لقدرات الـ AI.
- الآن: الـ AI يكمل مهمة برمجة تأخذ ساعة — ويمكنك مراجعتها.
- العام القادم: سيكمل مهمة تأخذ يومًا كاملاً.
- بعد عامين: أسبوع من العمل في ساعات.
إذا بقيت تراجع سطرًا بسطر، ستصبح أنت نفسك هو عنق الزجاجة.
ثالثاً: استراتيجية "Leaf Nodes" — أين تثق بالـ AI؟
المشكلة الحقيقية في إنتاج Vibe Coding هي: الدين التقني. الكود الذي يكتبه AI قد يعمل… لكنه غير قابل للصيانة لاحقًا. الحل: ركّز الـ Vibe Coding على Leaf Nodes فقط.
ما هي Leaf Nodes؟ هي الدوال النهائية أو المكونات الإضافية التي:
- لا تعتمد عليها أجزاء أخرى من النظام
- نادرًا ما تتغير
- الدين التقني فيها مقبول لأنها معزولة
ماذا تحمي بيدك؟
- المعمارية الأساسية للنظام (Architecture)
- منطق المصادقة (Auth)
- قاعدة البيانات والعلاقات الجوهرية
كلما كان أعمق في القلب ← راجعه بنفسك.
رابعاً: كن مدير منتج لـ Claude — لا مبرمجًا تقليديًا
النقلة الذهنية الأهم في المقالة:
"لا تسأل ماذا يستطيع Claude أن يفعل لك — اسأل ماذا يمكنك أن تفعل لـ Claude."
طريقة Erik العملية قبل كل مهمة كبيرة:
- 15-20 دقيقة تحضير قبل أي سطر كود
- اطلب من Claude استكشاف الكودبيس وفهمه أولاً
- اتفقا معًا على خطة تنفيذ واضحة
- ادمج كل السياق في prompt واحد متكامل
- ثم أطلق Claude ليعمل
خامساً: قصة حقيقية — 22,000 سطر كود في يوم واحد
هذه القصة من داخل Anthropic نفسها. الفريق أضاف 22,000 سطر كود على codebase خاص بـ Reinforcement Learning — في بيئة إنتاج حقيقية — ومعظمه كتبه Claude.
كيف فعلوا ذلك بأمان؟
| الاستراتيجية | التفاصيل |
|---|---|
| التخطيط المسبق | أياماً كاملة في التخطيط قبل أي كود |
| تحديد النطاق | التغييرات محصورة في Leaf Nodes فقط |
| تدخل يدوي | المنطق الأساسي راجعه الفريق بأنفسهم |
| نقاط تحقق | اختبارات stress طويلة الأمد + معايير واضحة |
النتيجة: مهمة تأخذ أسبوعين من مهندسين بشريين — أُنجزت في يوم واحد.
سادساً: أسئلة وأجوبة عملية
س: كيف نتعلم الآن بدون "التعب" التقليدي؟
التعلم لم يختفِ — تسارع. اسأل Claude: "لماذا اخترت هذه المكتبة؟ ما البدائل؟" قرار معماري كان يحتاج سنتين للتحقق — يمكن الآن اختباره في 6 أشهر.
💡 نصيحة: لا تقبل كود Claude بدون فهم. اسأله دائمًا عن السبب.
س: كم من التفاصيل أعطي Claude في الـ prompt؟
يعتمد على إلمامك بالكودبيس. لا تهتم بالتفاصيل؟ أعطه النتيجة فقط. تعرف الكودبيس جيداً؟ حدد الكلاسات والملفات.
🎯 القاعدة الذهبية: لا تُثقله بقيود صارمة. تحدث معه كمبرمج جديد في الفريق — لا كآلة تستقبل أوامر.
س: الأمان والثغرات — كيف نتجنبها؟
معظم الثغرات المنتشرة كتبها أشخاص لا يفهمون البرمجة أصلاً. إذا كنت مطوراً، أنت تعرف ما هو خطر. الأشياء التي لا تتركها لـ Vibe Coding أبداً: Auth وإدارة الجلسات، المدفوعات وأي شيء مالي، التحقق من صلاحيات المستخدمين، مفاتيح API في الكود.
س: TDD مع Claude — كيف تتجنب الاختبارات الميتة؟
المشكلة: Claude يكتب اختبارات مرتبطة بالتنفيذ — تكسر عند أي تغيير. الحل العملي من Erik: اطلب منه 3 اختبارات E2E فقط: المسار الناجح (Happy Path)، سيناريو خطأ رقم 1، سيناريو خطأ رقم 2.
✅ القاعدة: اختبارات E2E هي الوحيدة التي تثق بها فعلاً. إذا نجحت ← الكود سليم.
الخلاصة للمطور العربي
Vibe Coding ليس تخلياً عن المهارة — بل تطوراً لدورها.
| قبل | بعد |
|---|---|
| تكتب الكود | توجّه الـ AI لكتابته |
| تراجع كل سطر | تصمم اختبارات تثبت الصحة |
| تتعلم بالتعب | تتعلم بالأسئلة والتجريب السريع |
| تحمي وقتك | تحمي المعمارية والأمان |
الأدوات قوية… لكن المطور الذي يفهم يصنع الفرق.