الحادثة تبدو دائماً بالشكل نفسه. ميزة أُطلقت قبل ثلاثة أسابيع. كانت تعمل. الاختبارات كانت خضراء. ثم يتعطل شيء مجاور — تحويل عملة، فحص صلاحية، حلقة إعادة محاولة تبتلع الأخطاء بصمت — وعندما يفتح أحدهم الملف أخيراً، لا أحد في الفريق يتعرّف على الكود. ليس لأنه كود سيئ، بل لأن لا أحد كتبه فعلياً. لقد تم توليده، وتصفّحه سريعاً، والموافقة عليه، ودمجه.
هذا هو الجزء من قصة vibe coding الذي لا يظهر في العروض التوضيحية. أنا أدير الهندسة على محفظة من المنتجات المؤسسية، وقد رأيت النمط نفسه يتكرر في نحو اثنتي عشرة قاعدة كود خلال الثمانية عشر شهراً الماضية: الزيادة في السرعة حقيقية، وكبيرة، ويتم سدادها لاحقاً — مع فوائد — إلا إذا وضع أحدهم حواجز وقائية هيكلية أولاً.
دعني أكون دقيقاً بشأن موقفي، لأنه يُساء تمثيله في الاتجاهين. أنا لست ضد vibe coding. في Lasting Dynamics تستخدم فرقنا مساعدي الذكاء الاصطناعي كل يوم ولن أعود إلى الوراء. كل مهندس نوظفه يمرّ عبر LD Academy، حيث تُعدّ البرمجة مع وكلاء الذكاء الاصطناعي جزءاً من المنهج منذ اليوم الأول. لكن هناك فرق بين استخدام الذكاء الاصطناعي لكتابة الكود وترك الذكاء الاصطناعي يقرر معماريتك، ومعظم الفرق المؤسسية لم ترسم هذا الخط في أي مكان بعد.
رأي ميكيلي
السؤال ليس ما إذا كان على فريقك أن يستخدم vibe coding. هم يفعلون ذلك بالفعل — بسياستك أو بدونها. السؤال الحقيقي الوحيد هو ما إذا كان الكود الذي ينتجونه بهذه الطريقة يمكنه الوصول إلى الإنتاج دون المرور ببوابة يملكها إنسان. إذا كان الجواب نعم، فأنت لا تملك استراتيجية ذكاء اصطناعي. أنت تملك مسؤولية غير مُسعَّرة.
ما يعنيه Vibe Coding فعلياً في السياق المؤسسي
Vibe coding هو ممارسة بناء البرمجيات عبر وصف النية بلغة طبيعية وقبول الكود الذي ينتجه نموذج ذكاء اصطناعي، بمراجعة محدودة سطراً بسطر أو بدونها. صيغ المصطلح للمطورين المنفردين الذين يطلقون النماذج الأولية بسرعة، وفي هذا السياق هو رائع بحق. المشكلة أن الممارسة انتقلت إلى قواعد الكود المؤسسية دون أن ينتقل معها التعريف.
في البيئة المؤسسية، يُفهم vibe coding بشكل أفضل على أنه تحوّل في المكان الذي يُطبَّق فيه الحكم الهندسي. لم يختفِ الحكم — بل انتقل. كان يسكن في فعل الكتابة. الآن عليه أن يسكن في فعل التحديد والتقييد والتحقق. الفرق التي أنجزت هذا الانتقال بوعي تُطلق أسرع وبعيوب أقل. الفرق التي لم تفعل ذلك أزالت الحكم من خط الإنتاج وسمّت ذلك إنتاجية.
ثلاثة سلوكيات مختلفة تُجمع تحت التسمية نفسها، ومعاملتها بشكل متطابق هي حيث تبدأ معظم إخفاقات الحَوْكمة:
- التأليف المُساعَد — المطور يعرف ما يريد، يستخدم الذكاء الاصطناعي ليكتبه أسرع، ويقرأ كل سطر. مخاطرة منخفضة. هذه مجرد لوحة مفاتيح أفضل.
- التنفيذ المُفوَّض — المطور يحدد السلوك، الذكاء الاصطناعي ينتج وحدة كاملة، المطور يراجع الواجهة ويتحقق عيّنياً من الداخل. مخاطرة متوسطة. قابلة للإدارة بالبوابات الصحيحة.
- التوليد غير المُراقَب — أمر نصي ينتج كوداً يعمل، الاختبارات تنجح، ويُدمج. لا أحد يملك نموذجاً ذهنياً لداخله. هنا تتراكم التكلفة الحقيقية، وهو الوحيد من الثلاثة الذي يستحق القلق فعلاً.
تقريباً كل سياسة راجعتها إما تحظر الثلاثة أو تسمح بالثلاثة. كلا الجوابين خطأ، وكلاهما عَرَض للخطأ نفسه: التعامل مع vibe coding كمسألة أدوات بدلاً من كونها مسألة تصنيف مخاطر.
رقم الإنتاجية الذي يقتبسه الجميع — والرقم الذي لا يقتبسه أحد
الرقم الموجود في كل عرض تقديمي هو تجربة GitHub المضبوطة على 95 مطوراً: إنجاز المهام أسرع بنحو 55% مع مساعد ذكاء اصطناعي. نتيجة حقيقية ولا خلاف لي معها. خلافي هو أنها تقيس بُعداً واحداً — الزمن حتى أول تنفيذ يعمل — والبرمجيات المؤسسية لا تُحكَم على هذا البُعد.
هذه هي الصورة الأكمل، مستخلصة من الذي أرصده فعلياً عندما يتبنى فريق مساعدي الذكاء الاصطناعي دون تغيير أي شيء آخر في طريقة عمله:
| البُعد | الاتجاه | ما يحدث فعلياً |
|---|---|---|
| الزمن حتى أول كود يعمل | أفضل بقوة | رقم 55% يصمد. هذا الجزء غير خلافي. |
| حجم الكود المُنتَج | يرتفع بحدة | كود أكثر، فروق أكبر، مساحة سطح أوسع لكل pull request. |
| جودة مراجعة الكود | تنخفض | المراجعون يواجهون فروقاً أكبر 3–4 مرات بالميزانية الزمنية نفسها. الموافقة تصبح تصفّحاً. |
| الاتساق المعماري | ينخفض | كل توليد يحل مشكلته محلياً. الأنماط تتباعد بصمت بين الوحدات. |
| معدل تسرّب العيوب | يرتفع | أخطاء تعبر الاختبارات لكنها تخالف ثوابت غير مُعلَنة — الفئة الأغلى. |
| الزمن اللازم لفهم الكود لاحقاً | يرتفع بحدة | لا أحد يملك نموذجاً ذهنياً. التنقيح يبدأ من الصفر كل مرة. |
اقرأ الجدول ككل ويصبح النمط لا لبس فيه. vibe coding لا يلغي العمل الهندسي — بل ينقله إلى أسفل التيار، من التأليف إلى المراجعة والتنقيح والصيانة. إذا لم تعزز مؤسستك بالمقابل قدرتها على المراجعة والتنقيح والصيانة، فأنت لم تحقق ربحاً في الإنتاجية. أنت أخذت قرضاً.
المقياس الذي يكشف ذلك
توقف عن تتبع السرعة وابدأ بتتبع متوسط الزمن حتى الفهم: عندما يفتح مهندس غير مُلِم ملفاً في الإنتاج، كم يمضي قبل أن يستطيع تغييره بأمان؟ إنه المقياس الوحيد الذي يكشف دَين vibe coding، لأنه الوحيد الذي يسوء كلما ارتفع حجم الكود المولَّد. إذا كان يتحرك في الاتجاه الخاطئ بينما ترتفع نقاط قصصك، فقد حصلت على جوابك.
الطرق الأربع التي يكسر بها Vibe Coding قواعد الكود المؤسسية
هذه ليست فرضيات. كل واحدة من الأربع شيء استُدعيت لتشخيصه، ولا واحدة منها تعلن عن نفسها مبكراً — وهذا تحديداً ما يجعلها مكلفة.
1. الانحراف المعماري
نموذج الذكاء الاصطناعي يُحسِّن للأمر النصي الذي أمامه، لا للسبعة عشر اتفاقاً تراكمت في قاعدة كودك. اطلب طبقة تخزين مؤقت وستحصل على طبقة جيدة — تتجاهل التجريد الذي تستخدمه ثلاث وحدات أخرى بالفعل. كرّر ذلك أربعين مرة ولن تعود تملك معمارية. ستملك مجموعة من القرارات المعقولة محلياً التي لا يمكن لأحد استيعابها في وقت واحد. هذا النمط من الفشل بطيء وصامت، وبمجرد أن يصبح مرئياً تكون تكلفته إعادة كتابة.
2. ثغرات أمنية تُقرأ ككود نظيف
الكود المولَّد ممتاز أسلوبياً، وهذه هي المشكلة بالضبط — إنه لا يبدو مريباً. المخالفات المتكررة التي أراها هي فحوص تصريح تتحقق من الهوية لكن لا تتحقق من الصلاحية، تحقق من صحة المدخلات بالشكل لا بالنطاق، معالجات أخطاء تُسرّب التفاصيل الداخلية في الاستجابات، واختيارات اعتماديات مبنية على شعبيتها في بيانات التدريب لا على حالة صيانتها. المراجع الذي يتصفح بحثاً عن روائح لا يجد شيئاً، لأنه لا توجد رائحة. لهذا يتوقف الأمن بالتصميم عن كونه اختيارياً لحظة تبنّي مساعدة الذكاء الاصطناعي على نطاق واسع.
3. اختبارات تتحقق من التنفيذ، لا من المتطلب
هذا هو نمط الفشل الأقل نقاشاً، وفي تجربتي الأخطر. عندما يكتب النموذج نفسه الكود واختباراته، تصف الاختبارات ما يفعله الكود — لا ما يحتاج العمل منه أن يفعله. التغطية تبدو رائعة. الحزمة خضراء. وهي عاجزة هيكلياً عن التقاط فئة الأخطاء الأهم، لأن سوء الفهم موجود بشكل متطابق في الأثرين معاً. اختبارات خضراء كتبها مؤلف الخطأ لا تثبت شيئاً.
4. فراغ المعرفة
تقليدياً، كتابة وحدة برمجية كانت أيضاً الطريقة التي يفهمها بها المهندس — الصراع كان هو التعلّم. أزل الصراع وستحتفظ بالأثر لكن تفقد الفهم. بعد ستة أشهر لا يستطيع من أطلقها أن يشرحها، وقدرة المؤسسة الحقيقية أقل بكثير مما يوحي سجل الالتزامات. هذا النمط هو الأسوأ تراكماً، لأنه يقوّض القدرة نفسها التي تحتاجها لإصلاح الثلاثة الآخرين.
بنية الحواجز الوقائية: ست طبقات تعمل فعلاً
هذا ما أطبّقه عندما يريد فريق الحفاظ على سرعة العمل المدعوم بالذكاء الاصطناعي دون قبول التكلفة اللاحقة. إنه مملّ بشكل متعمَّد، وغير مكلف، والترتيب مهم — كل طبقة تفترض أن التي قبلها موجودة بالفعل.
- دوّن اتفاقاتك في صيغة يقرأها الحاسوب. قراراتك المعمارية، قواعد التسمية، المكتبات المعتمدة والأنماط الممنوعة تنتمي إلى ملف يقرأه الذكاء الاصطناعي في كل طلب. الاتفاقات غير المُوثَّقة هي، من منظور النموذج، اتفاقات غير موجودة. هذه الخطوة وحدها تُزيل معظم الانحراف المعماري مقابل يوم عمل.
- افصل مؤلف الكود عن مؤلف الاختبارات. إذا ولّد الذكاء الاصطناعي التنفيذ، فليكتب إنسان معايير القبول أولاً — أو ليكتب نموذج مختلف الاختبارات من المتطلب، لا من الكود أبداً. اكسر الارتباط وتستعيد الاختبارات القدرة على الفشل بشكل ذي معنى.
- ضع البوابة على نطاق التأثير، لا على الحجم. حجم الفرق مؤشر مخاطر سيئ. ما يمكن للكود الوصول إليه — الأموال، البيانات الشخصية، المصادقة، العقود الخارجية، الترحيلات — مؤشر جيد. القسم التالي يعالج هذا بشكل صحيح، لأنه يؤدي عملاً أكثر من الطبقات الخمس الأخرى مجتمعة.
- اجعل مراجعة الكود بالذكاء الاصطناعي إلزامية وخصامية. شغّل نموذجاً ثانياً على كل فرق مع تعليمات صريحة بإيجاد العيوب الأمنية والحالات الحدّية المفقودة ومخالفات الاتفاقات — لا بالتلخيص. رخيص وسريع، ويلتقط نسبة معتبرة من الذي يفوته إنسان يتصفّح. إنه يُكمّل المراجعة البشرية؛ لا يحل محلها أبداً.
- ضع حداً أدنى للفهم البشري، وافرضه في الطقس اليومي. القاعدة التي نستخدمها: لا يجوز لمهندس أن يوافق على فرق لا يستطيع الدفاع عنه في مراجعة تصميم. ليس شعاراً — بل سؤال يُطرح فعلاً في الاجتماع اليومي. إنه الضابط الوحيد الذي يعالج فراغ المعرفة مباشرة.
- راقب الثوابت، لأن الاختبارات لن تفعل. أكّد قواعد عملك في الإنتاج: الأرصدة تتوازن، المجاميع غير سالبة، كل إجراء مُميَّز له سجل تدقيق. الكود المولَّد بالذكاء الاصطناعي يفشل على الافتراضات غير المُعلَنة، والتأكيدات في وقت التشغيل هي الطبقة الوحيدة التي تلتقط الافتراضات التي لم يفكر أحد في كتابتها.
ابدأ بالطبقتين 1 و3
إذا لم تطبّق شيئاً آخر هذا الربع، فنفّذ ملف الاتفاقات القابل للقراءة آلياً وتصنيف نطاق التأثير. معاً هما نحو يومَي عمل، وهما يعالجان نمطَي الفشل — الانحراف المعماري والوصول غير المُراجَع إلى المسارات الحرجة — اللذين يسببان الحوادث التي ستُستدعى لها فعلاً.
نطاق التأثير هو القاعدة الوحيدة التي تهم حقاً
معظم سياسات البرمجة بالذكاء الاصطناعي التي أقرأها مكتوبة كتصاريح شاملة — الذكاء الاصطناعي مسموح، أو ممنوع، أو مسموح «مع مراجعة». الثلاثة عديمة الفائدة، لأنها تتعامل مع صفحة تسويقية ودفتر مدفوعات كأنهما الشيء نفسه. المقاربة العملية هي تصنيف قاعدة كودك بحسب ما يمكن للكود إتلافه، وتحديد البوابة لكل مستوى.
| المستوى | ما يسكن فيه | سياسة vibe coding |
|---|---|---|
| أخضر | الأدوات الداخلية، النماذج الأولية، شاشات الإدارة، السكربتات، اختبارات المسارات غير الحرجة، التوثيق | بلا قيود. أطلقه. لا تُضِف إجراءات هنا — هنا تُكسب السرعة. |
| أصفر | ميزات المنتج، واجهة المستخدم، واجهات API غير الحرجة، التكاملات بلا بيانات مالية أو شخصية | التوليد مسموح، والمراجعة البشرية مطلوبة مع فرض الحد الأدنى للفهم. |
| أحمر | المصادقة والصلاحيات، المدفوعات والدفاتر، البيانات الشخصية أو الصحية، الترحيلات، العقود الخارجية، سجلات التدقيق | يمكن للذكاء الاصطناعي أن يصوغ ويقترح. إنسان مُسمّى يملك ويعيد الكتابة ويوقّع سطراً بسطر. لا استثناءات ولا ضغط زمني على هذه البوابة. |
عملياً، التصنيف الصادق لقاعدة كود مؤسسية نموذجية يقع قريباً من 70% أخضر، 25% أصفر، 5% أحمر. وهذه هي الفكرة كلها: يمكنك استخدام vibe coding في الغالبية العظمى من نظامك بلا أي طقوس، تحديداً لأنك جعلت الـ5% غير قابلة للتفاوض بحق. السياسات الشاملة تفشل لأنها إما تخنق الـ70% أو تعرّض الـ5%. التصنيف هو ما يتيح لك التوقف عن الاختيار بينهما.
“الفرق التي تحصل على أكبر قيمة من مساعدة الذكاء الاصطناعي ليست تلك ذات القواعد الأكثر تراخياً ولا الأكثر تشدداً. إنها تلك التي تعرف بالضبط أي 5% من قاعدة كودها يجب أن يظل إنسان مالكاً لها.”
— ميكيلي تشيمينو · المدير التنفيذي والمؤسس، Lasting Dynamics
كيف يبدو هذا في فريق حقيقي
بعض التفاصيل التشغيلية، لأن الأطر سهلة الموافقة عليها وصعبة التشغيل فعلياً. في فرقنا داخل Lasting Dynamics، يسكن التصنيف في المستودع نفسه — قواعد مبنية على المسارات في CI، بحيث أن أي pull request يمسّ مجلداً من المستوى الأحمر يستلزم تلقائياً المالك المُسمّى ولا يمكن لأي شخص آخر دمجه. السياسة ليست وثيقة يُفترض أن يتذكرها الناس. إنها خط إنتاج يرفض.
يُعامَل ملف الاتفاقات ككود إنتاج: مُراجَع، ومُدار بالإصدارات، ويُحدَّث لحظة تغيّر أي قرار معماري. عندما يظهر انحراف في المراجعة، الحل عادةً ليس محاضرة للمهندس — بل سطر ناقص في ذلك الملف. هذه الإعادة للصياغة أهم مما تبدو، لأنها تحوّل مشكلة انضباط إلى مشكلة توثيق، ومشاكل التوثيق قابلة للحل.
أما الحد الأدنى للفهم فيُفرَض اجتماعياً، لا تقنياً. في مراجعة التصميم نختار ملفاً مدموجاً حديثاً بشكل عشوائي ونطلب من الموافق عليه أن يشرحه. لا أحد يُعاقَب على الفشل — لكن الحافز يصحّح نفسه فوراً تقريباً، وبعد أسبوعين توقفت الموافقات السطحية. إنه أرخص ضابط في القائمة وأكثرها إفادة للقدرة طويلة الأمد. هذه هي الحجة نفسها التي أطرحها بشأن تملّك أنظمتك بدلاً من استئجارها: القيمة في الفهم الذي تتراكمه، لا في الأثر الذي تنتهي إليه فقط.
إذا أردت الصورة الأوسع لكيفية إعادة الذكاء الاصطناعي تشكيل اقتصاديات التسليم لا مراجعة الكود فحسب، فقد كتبت نسخة موجهة للمؤسسين من تلك الحجة في دليلي بلا مبالغات عن الذكاء الاصطناعي في تطوير البرمجيات. هذا المقال هو النظير المؤسسي للحَوْكمة — التقنية نفسها، سؤال مختلف.
خطة الإطلاق في 30 يوماً
لا تحتاج إلى برنامج تحوّل. تحتاج إلى أربعة أسابيع وإلى شخص يملك سلطة قول «لا».
- الأسبوع 1 — صنّف قاعدة الكود. اجمع كبار مهندسيك في غرفة وصنّف كل مجلد رئيسي أخضر أو أصفر أو أحمر. اختلفوا حول الحدود؛ الاختلاف هو الجزء القيّم. ثبّت النتيجة في المستودع.
- الأسبوع 2 — اكتب ملف الاتفاقات. القرارات المعمارية، الاعتماديات المعتمدة، الأنماط الممنوعة، التسمية، معالجة الأخطاء. اربطه بأي أدوات ذكاء اصطناعي يستخدمها فريقك ليُحمَّل تلقائياً بدلاً من أن يُتذكَّر.
- الأسبوع 3 — اربط البوابات. قواعد CI مبنية على المسارات لملكية المستوى الأحمر، خطوة مراجعة خصامية بالذكاء الاصطناعي على كل pull request، وتأكيدات في وقت التشغيل على أهم ثلاثة ثوابت في عملك.
- الأسبوع 4 — ثبّت الطقس وخط الأساس. ابدأ الاستعراض العشوائي في مراجعة التصميم، وقِس متوسط الزمن حتى الفهم الآن لتملك رقماً تقارنه بعد ربع سنة.
الجزء الذي لا يريد أحد سماعه
vibe coding ليس مرحلة عابرة ولن يُلغى تنظيمياً من الداخل. مهندسوك يستخدمونه الآن، والربح في الإنتاجية حقيقي، وأي سياسة مبنية على المنع سيُتحايل عليها ببساطة — بهدوء، وبأشخاص جيدين، تحت ضغط المواعيد. هذا ليس فشلاً في الانضباط. إنه ما يحدث عندما تجعل سياسةٌ الناسَ أبطأ في عملهم الفعلي.
لكن المؤسسات التي ستبقى قادرة على تغيير برمجياتها بعد ثلاث سنوات ليست تلك التي ولّدت أكبر قدر من الكود. إنها تلك التي ظلت قادرة على فهمه. الفهم هو المورد النادر الآن — لا سرعة الكتابة، ولا حجم الالتزامات، ولا نقاط القصص. كل ما في هذا الدليل يخدم في النهاية حماية ذلك المورد.
الخبر الجيد أن لا شيء من هذا مكلف أو بطيء. ست طبقات، أربعة أسابيع، ومحادثة واحدة غير مريحة عن أي 5% من نظامك يجب أن يظل إنسان مالكاً لها. المؤسسات التي تجري هذه المحادثة الآن ستكون بالسرعة نفسها بعد عامين. أما التي تؤجلها فستقضي هذين العامين في شرح حوادث في كود لم يكتبه أحد.
رأي ميكيلي
إن أخذت شيئاً واحداً من هذا: الهدف ليس إبطاء الذكاء الاصطناعي، بل جعل السرعة قابلة للنجاة. الحواجز الوقائية ليست الضريبة التي تدفعها لاستخدام الذكاء الاصطناعي — إنها السبب الذي يتيح لك الاستمرار في استخدامه بقوة دون مراجعة حوادث ربع سنوية. صنّف قاعدة كودك، احمِ الـ5%، ودع فريقك يطير في الباقي.