ما هو Vibe Coding بالفعل؟

انتشر مصطلح "vibe coding" بسرعة في 2024-2025 لأنه يسمي شيئًا كان الكثير من المطورين يفعلونه بالفعل في الخفاء: وصف ما يريدونه باللغة الإنجليزية العادية لنموذج مثل GPT-4 أو Claude، أو لأداة مثل Cursor أو GitHub Copilot، والسماح له بإنشاء معظم الكود الفعلي. المبرمج يبقى في الحلقة، لكن الحلقة تبدو مختلفة عن البرمجة التقليدية.

التعريف الفعلي

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

هذا يختلف عن مجرد استخدام الإكمال التلقائي. الاقتراحات المضمنة بأسلوب Copilot تفترض بعد أن تكتب الدالة بنفسك مع بعض المساعدة في إنهاء الأسطر. vibe coding يفترض أن النموذج يكتب الدالة أو الملف أو أحيانًا الميزة بأكملها، وأنت تراجع وتعيد التوجيه بدلاً من التأليف من الصفر.

كيف تبدو جلسة حقيقية

حلقة vibe coding نموذجية مع أداة مثل Cursor أو وضع Agent في Replit تسير بهذا الشكل تقريبًا:

1. أمر: "أضف محدد سرعة إلى هذا API من Express، 100 طلب لكل 15 دقيقة لكل IP، أعد 429 مع body خطأ JSON."
2. النموذج يعدل middleware/rateLimit.js، ويربطها إلى app.js، وربما يسحب express-rate-limit.
3. تشغل npm test أو تضرب النقطة النهائية مع curl في حلقة للتحقق من فعل 429 بالفعل.
4. هناك شيء خاطئ — محدد السرعة يعاد تعيينه في كل نشر لأنه في الذاكرة. تخبره بذلك.
5. النموذج يبدل متجر مدعوم بـ Redis، يضيف تبعية ioredis، يحدث ملف docker-compose.
6. تختبر مجددًا، تعمل، تلتزم.

لم يتم كتابة أي سطر من middleware تلك يدويًا. لكن تم اتخاذ ست أو سبع قرارات حكم بواسطة إنسان: ما يجب أن يكون الحد، أن تخزين الذاكرة كان خطأً للإنتاج، أن ملف docker-compose احتاج إلى التحديث أيضًا.

حيث يعمل بشكل جيد

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

إنه سريع حقًا بالفعل بالنسبة للمطورين الفرديين والفرق الصغيرة التي تشحن الأدوات الداخلية أو MVPs حيث تكون تكلفة الخلل منخفضة وسرعة التكرار مهمة أكثر من نقاء العمارة.

حيث تنهار

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

هذا يهم أكثر في الكود الحساس للأمان من أي مكان آخر تقريبًا. أشار Simon Willison والآخرون إلى أن المشاريع ذات رموز vibe-coded التي تحتوي على بيانات مستخدم حقيقية تحتاج إلى نفس الصرامة في المراجعة مثل أي كود آخر، بل أكثر من ذلك، لأن الشخص الذي "كتبها" قد لا يتمكن من شرح ما يفعله سطر تلو الآخر.

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

المهارة التي تهم الآن بالفعل

إذا كنت تقوم بـ vibe coding، فإن المهارة القيمة ليست سرعة الكتابة، بل المواصفات. الأوامر الغامضة تحصل على كود غامض وخاطئ. الأوامر المحددة — مع أسماء المكتبات الدقيقة وتوقعات معالجة الأخطاء والحالات الحدية المُشار إليها — تحصل على مخرجات أفضل بكثير. ثاني أكثر مهارة قيمة هي قراءة الكود بسرعة كافية للعثور على ما هو خاطئ، مما يعني أنك لا تزال بحاجة إلى فهم اللغة والمجال حتى لو لم تكن تكتب كل حرف.

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

هل تريد الخوض أعمق في كتابة الكود باستخدام أدوات الذكاء الاصطناعي دون فقدان السيطرة على الجودة؟ تحقق من مقاطع AI و Python في Korra Studio للتطبيقات العملية.