ماهو Vibe Engineering: كيف يتحول المطور من كاتب كود إلى قائد لفريق من الـAI Agents؟
 |
| ماهو Vibe Engineering: من كتابة الكود إلى هندسة طريقة بناء البرمجيات |
هناك سؤال قد يبدو بسيطًا، لكنه سيصبح أكثر أهمية مع كل جيل جديد من أدوات الذكاء الاصطناعي:
إذا أصبح الذكاء الاصطناعي قادرًا على كتابة جزء كبير من الكود، فما الذي يجب أن يتقنه مهندس البرمجيات بعد ذلك؟
ربما ليست الإجابة: كتابة الكود بشكل أسرع.
وربما ليست حتى كتابة Prompts أفضل.
الإجابة الأعمق قد تكون: هندسة النظام الذي يجعل الذكاء الاصطناعي قادرًا على بناء البرمجيات بطريقة صحيحة.
من هنا تظهر فكرة Vibe Engineering.
لكن يجب توضيح شيء منذ البداية:
Vibe Engineering ليس حتى الآن معيارًا رسميًا موحدًا في هندسة البرمجيات. المصطلح حديث ومرن، ويُستخدم لوصف اتجاه ناشئ أكثر من كونه منهجية أكاديمية محسومة.
وهذا المقال يقترح استخدامه كإطار عملي لفهم مرحلة تتجاوز Vibe Coding: مرحلة يصبح فيها الذكاء الاصطناعي جزءًا من عملية هندسية كاملة، وليس مجرد مولد للكود.
ما هو Vibe Engineering؟
يمكن تبسيط الفكرة هكذا:
Vibe Engineering هو تصميم وإدارة دورة تطوير البرمجيات حول قدرات الذكاء الاصطناعي، مع إبقاء الإنسان مسؤولًا عن النية، والهندسة، والقرارات، والتحقق.
أي أن السؤال لم يعد:
"كيف أجعل AI يكتب هذا الكود؟"
بل أصبح:
"كيف أصمم Workflow يجعل AI يفهم المشكلة، ويخطط، وينفذ، ويختبر، ويراجع، ويتعلم من النتائج ضمن حدود واضحة؟"
وهذا فرق كبير.
في البرمجة التقليدية، يكتب المهندس جزءًا كبيرًا من التنفيذ بنفسه.
في Vibe Coding، يصف الشخص ما يريد، ثم يترك النموذج يولد قدرًا كبيرًا من الكود ويكرر العملية من خلال المحادثة.
أما Vibe Engineering، كما نقترحه هنا، فيضيف طبقة هندسية كاملة بين الفكرة والنتيجة:
الفكرة → السياق → التصميم → الوكلاء → الأدوات → التنفيذ → الاختبار → المراجعة → النشر → المراقبة → التحسين
وهذه هي النقطة الجوهرية.
لماذا ظهر هذا المفهوم الآن؟
لأن أدوات الذكاء الاصطناعي نفسها تغيرت.
في البداية، كان الاستخدام الأساسي للنماذج اللغوية قريبًا من:
سؤال → إجابة
ثم أصبح:
Prompt → Code
ثم تطورت أدوات البرمجة المدعومة بالذكاء الاصطناعي إلى أنظمة تستطيع قراءة المستودع، تعديل عدة ملفات، تشغيل أدوات، تنفيذ اختبارات، تحليل الأخطاء، والعمل عبر خطوات متعددة.
Claude Code، مثلًا، يُقدَّم كوكيل برمجي يستطيع العمل على قاعدة الشيفرة، كتابة الكود والاختبارات وفتح Pull Requests بدل الاكتفاء بالإكمال التلقائي.
وفي 2026، تصف Anthropic هذا الاتجاه بأنه انتقال نحو Agentic Coding، حيث يتولى الوكلاء أجزاء متزايدة من دورة التنفيذ، بينما تظل الخبرة البشرية مهمة في التخطيط والإشراف والقرارات.
وهنا يتغير السؤال.
إذا كان AI يستطيع تنفيذ عشرات الخطوات، فإن جودة النتيجة ستعتمد بدرجة أكبر على:
ما الذي طلبته منه؟
ما السياق الذي أعطيته؟
ما الأدوات التي يستطيع استخدامها؟
ما الحدود التي وضعتها؟
كيف يتحقق من عمله؟
كيف تكتشف أخطاءه؟
من يملك القرار النهائي؟
هذه كلها مسائل هندسية.
Vibe Coding ليس هو Vibe Engineering
من السهل الخلط بين المصطلحين.
Vibe Coding ظهر كمصطلح يصف أسلوبًا يعتمد بدرجة كبيرة على وصف النتيجة باللغة الطبيعية وترك النموذج يولد الكود، وقد ارتبط المصطلح بـAndrej Karpathy في فبراير 2025.
لكن المشكلة تظهر عندما نأخذ هذا الأسلوب إلى مشروع حقيقي دون إضافة طبقة من الهندسة.
يمكن تلخيص الفرق هكذا:
| Vibe Coding | Vibe Engineering |
|---|---|
| التركيز على توليد الكود | التركيز على النظام كاملًا |
| Prompt ثم Code | Intent ثم Architecture ثم Execution |
| سرعة الوصول إلى Prototype | قابلية بناء نظام يمكن الاعتماد عليه |
| AI ينفذ | AI ينفذ ضمن Workflow |
| مراجعة محدودة أو متغيرة | Verification جزء أساسي من العملية |
| التركيز على النتيجة المرئية | التركيز على النتيجة + الجودة + الأمان |
| غالبًا Agent واحد | يمكن استخدام عدة Agents متخصصة |
| Prompt هو نقطة التحكم الأساسية | Context + Tools + Agents + Tests + Policies |
إذن:
Vibe Coding قد يكون طريقة للتعامل مع AI.
أما:
Vibe Engineering فهو طريقة لتصميم عملية العمل نفسها.
من Prompt Engineering إلى Context Engineering
وهنا يحدث تحول آخر مهم.
لسنوات، كان السؤال:
كيف أكتب Prompt أفضل؟
لكن مع الأنظمة الوكيلة طويلة الأمد، أصبح هذا السؤال غير كافٍ.
Anthropic تصف Context Engineering بأنه تطور من Prompt Engineering؛ فالمشكلة لم تعد فقط في التعليمات، وإنما في إدارة كل ما يصل إلى النموذج: التعليمات، الأدوات، الملفات، التاريخ، البيانات الخارجية، ونتائج الخطوات السابقة.
وهذا مهم جدًا.
لأن إعطاء AI كل شيء لا يعني إعطاءه سياقًا جيدًا.
أحيانًا:
المزيد من السياق = ضوضاء أكثر.
السياق الجيد هو السياق الذي يحتاجه النموذج في اللحظة المناسبة.
ولهذا أصبحت مفاهيم مثل:
الاسترجاع عند الحاجة
الذاكرة
تلخيص السياق
الأدوات
MCP
Sub-agents
Compaction
Structured Notes
جزءًا من هندسة الأنظمة الوكيلة الحديثة.
المطور لم يعد مجرد "كاتب كود"
هذه ربما أكبر نقطة في التحول.
لا يعني ذلك أن البرمجة ستختفي.
بل يعني أن قيمة بعض المهارات ستتحرك إلى مستويات أعلى.
بدل أن يقضي المطور كل وقته في كتابة التنفيذ، قد يقضي وقتًا أكبر في:
تعريف المشكلة.
ثم:
اختيار المعمارية.
ثم:
تقسيم العمل.
ثم:
تحديد الأدوات.
ثم:
توجيه Agents.
ثم:
مراجعة النتائج.
ثم:
اختبار النظام.
ثم:
اتخاذ القرارات التي لا يستطيع AI تحمل مسؤوليتها.
وهذا يقترب من وصف التحول الذي تشير إليه تقارير Anthropic عن Agentic Coding: المهندسون يتحركون أكثر نحو التنسيق، وتصميم الأنظمة، والقرارات الاستراتيجية، بدل التركيز الحصري على التنفيذ اليدوي.
لكن هل هذا يعني أن المطور يحتاج إلى معرفة أقل بالكود؟
هنا يجب الحذر.
العكس قد يكون صحيحًا.
كلما زادت قدرة AI على كتابة الكود، أصبح فهم الكود الذي تنتجه أكثر أهمية.
لماذا؟
لأن AI يستطيع إنتاج حل يبدو صحيحًا.
لكن "يبدو صحيحًا" لا يعني:
أنه آمن.
أنه قابل للتوسع.
أنه يحافظ على المعمارية.
أنه لا يحتوي على Technical Debt.
أنه يتعامل مع الحالات الطرفية.
أنه لا يكشف بيانات حساسة.
أنه لا يكسر جزءًا آخر من النظام.
ولهذا لا يجب أن يتحول المطور إلى شخص لا يفهم الكود ويعتمد على AI بشكل أعمى.
بل إلى شخص يفهم النظام بما يكفي ليحكم على عمل AI.
Vibe Engineering Loop
ولتحويل الفكرة إلى ممارسة قابلة للتطبيق، أقترح إطارًا أسميه:
Vibe Engineering Loop — VEL
وهو يتكون من ثماني مراحل:
1. Intent — النية
ما المشكلة الحقيقية؟
ليس:
"ابنِ تطبيقًا."
بل:
"ما المشكلة التي يجب أن يحلها التطبيق؟ ولمن؟ وما معيار نجاحه؟"
2. Context — السياق
اجمع فقط المعلومات التي يحتاجها AI:
متطلبات المشروع.
الملفات المهمة.
القيود.
قرارات التصميم.
البيانات.
أمثلة السلوك المطلوب.
لا تغرق النموذج بمعلومات لا يحتاجها.
3. Architecture — المعمارية
قبل كتابة الكود، حدد:
المكونات.
البيانات.
الواجهات.
الخدمات.
الحدود.
الاعتماديات.
المخاطر.
AI يمكن أن يقترح.
لكن الإنسان يجب أن يفهم لماذا اختير التصميم.
4. Delegate — التفويض
قسم العمل إلى مهام.
قد يكون Agent واحد مناسبًا لمهمة صغيرة.
لكن المشروع الكبير قد يستفيد من Agents متخصصة:
Planner → Coder → Tester → Reviewer → Security
مع وجود Agent أو Workflow رئيسي ينسق بينها.
هذا يتوافق مع اتجاه الأنظمة متعددة الوكلاء الذي تستكشفه Anthropic في المهام طويلة الأمد والمعقدة.
5. Execute — التنفيذ
هنا يأتي دور AI في:
كتابة الكود.
تعديل الملفات.
تشغيل الأدوات.
إنشاء الاختبارات.
إصلاح الأخطاء.
البحث داخل المشروع.
لكن التنفيذ ليس النهاية.
إنه منتصف الحلقة.
6. Verify — التحقق
كلما زادت قدرة AI على الإنتاج، يجب أن تزيد قدرتك على التحقق.
اختبارات.
Linting.
Type checking.
Security scanning.
Code review.
Integration tests.
CI/CD.
والأهم:
دليل على أن النتيجة تعمل.
7. Evaluate — التقييم
هل ما تم بناؤه يحل المشكلة أصلًا؟
هذه نقطة مختلفة عن:
"هل الكود يعمل؟"
قد ينجح الاختبار بينما يكون المنتج نفسه يحل المشكلة الخطأ.
لذلك نحتاج إلى تقييم تقني وتقييم وظيفي.
8. Iterate — التكرار
النتيجة ليست نهاية العملية.
كل فشل يجب أن ينتج معرفة:
ما الذي لم يفهمه AI؟
ما السياق الذي كان ناقصًا؟
ما الاختبار الذي لم يكن موجودًا؟
هل المشكلة في الكود أم المعمارية؟
ثم تعود إلى بداية الحلقة.
وهكذا:
Intent → Context → Architecture → Delegate → Execute → Verify → Evaluate → Iterate
ثم تبدأ الدورة من جديد.
وهذه هي الفكرة التي أعتقد أنها تجعل Vibe Engineering مختلفًا عن مجرد "البرمجة بالـPrompt".
مثال عملي: مطور واحد يبني منتجًا بمساعدة AI
لنفترض أنك تريد بناء منصة صغيرة لإدارة السيارات.
الطريقة السريعة قد تكون:
"ابنِ لي تطبيقًا لإدارة السيارات."
سيبدأ AI بإنشاء مشروع.
وقد يبدو رائعًا بعد دقائق.
لكن ماذا يحدث بعد أسبوع؟
تظهر مشاكل:
بنية غير واضحة.
تكرار في الكود.
قاعدة بيانات غير مناسبة.
صلاحيات ضعيفة.
اختبارات ناقصة.
اعتماديات غير ضرورية.
هذه نتيجة طبيعية عندما يكون التركيز على التوليد فقط.
أما في Vibe Engineering Loop:
أولًا: Intent
تحدد:
من المستخدم؟
ما المشكلة؟
ما العمليات الأساسية؟
ما الذي يعتبر نجاحًا؟
ثانيًا: Context
تعطي AI:
متطلبات المشروع، الهوية، التقنيات، قواعد البيانات، القيود والملفات ذات الصلة.
ثالثًا: Architecture
تطلب منه اقتراح معماريتين أو ثلاثًا، ثم تناقش نقاط القوة والضعف.
رابعًا: Delegate
تقسم المشروع:
Agent للتخطيط.
Agent للواجهة.
Agent للـBackend.
Agent للاختبارات.
Agent للمراجعة.
خامسًا: Execute
كل Agent يعمل داخل حدود واضحة.
سادسًا: Verify
تشغّل الاختبارات.
سابعًا: Evaluate
تسأل:
هل المنتج يحقق المتطلبات؟
ثامنًا: Iterate
تصلح ما فشل.
هنا لم يعد AI مجرد "مولد كود".
لقد أصبح جزءًا من نظام هندسي يديره المطور.
أخطر مشكلة: سرعة إنتاج Technical Debt
هناك مفارقة خطيرة في عصر AI:
يمكنك الآن إنشاء كود سيئ بسرعة مذهلة.
قبل AI، قد يستغرق بناء حل سيئ وقتًا طويلًا.
اليوم يمكن لنظام وكيل أن يضيف عددًا كبيرًا من التغييرات خلال جلسة واحدة.
وهذا يجعل السرعة سلاحًا ذا حدين.
DORA في تقرير 2025 حول AI-assisted Software Development خلصت إلى أن AI يعمل كمُضاعِف: يقوي الفرق والأنظمة الجيدة، لكنه يمكن أن يضخم المشكلات الموجودة أيضًا. كما أشارت إلى أن تسارع التغييرات يحتاج إلى ممارسات قوية مثل الاختبارات الآلية والتحكم في الإصدارات وحلقات التغذية الراجعة السريعة.
لذلك:
زيادة سرعة كتابة الكود ليست مساوية تلقائيًا لزيادة جودة البرمجيات.
6 مخاطر يجب ألا تختفي خلف الحماس
1. Hallucinations
AI قد يخترع API أو مكتبة أو سلوكًا غير موجود.
الحل:
تحقق، لا تفترض.
2. Technical Debt
الكود الذي يبدو جيدًا اليوم قد يصبح مشكلة غدًا.
3. Security Vulnerabilities
AI ليس مسؤولًا قانونيًا أو هندسيًا عن قرارك النهائي.
الأمان يحتاج إلى اختبارات ومراجعة وأدوات متخصصة.
4. Bad Architecture
يمكن للنموذج أن يبني عشرات الملفات بسرعة داخل تصميم سيئ.
5. Copy-paste development
إذا كانت عملية التطوير مجرد نسخ ولصق لما يقوله AI، فأنت لم تبنِ Workflow هندسيًا.
6. False confidence
أخطر مشكلة ربما هي:
أن يعمل كل شيء… بينما يكون النظام خاطئًا.
المهارة الجديدة: معرفة متى تثق بالـAI ومتى لا تثق به
هذا قد يكون أحد أهم Skills في المرحلة القادمة.
المطور الجيد مع AI ليس من يقول:
"AI يعرف كل شيء."
وليس من يقول:
"AI لا يمكن الوثوق به."
بل يعرف:
أين يكون AI قويًا؟
وأين يحتاج إلى تحقق؟
وأين يحتاج إلى إنسان؟
وأين يجب منعه من التصرف أصلًا؟
هذه الفكرة تتوافق مع نتائج أبحاث Anthropic حول استخدام Claude Code: الخبرة البشرية ترتبط باتخاذ قرارات التخطيط، بينما يمكن للنموذج تنفيذ جزء أكبر من كيفية الوصول إلى النتيجة.
ما المهارات التي يحتاجها مهندس Vibe Engineering؟
قد تتغير قائمة المهارات، لكنها لن تصبح أقل هندسية.
بل قد تصبح أكثر اتساعًا:
Software Architecture
فهم الأنظمة أهم من معرفة كتابة Function منفردة.
Context Engineering
معرفة ما الذي يجب أن يصل إلى النموذج ومتى.
Agent Orchestration
تقسيم المهام بين Agents وأدوات مختلفة.
Testing
لأن سرعة التوليد تحتاج إلى سرعة تحقق.
Security
لأن الخطأ الآلي يمكن أن يتكرر على نطاق واسع.
Observability
إذا أصبح AI جزءًا من النظام، يجب أن تعرف ماذا فعل ولماذا وأين فشل.
Product Thinking
لأن بناء الكود ليس الهدف؛ حل المشكلة هو الهدف.
Critical Thinking
لأن أفضل استخدام للـAI ليس أن توافقه، بل أن تعرف متى تعارضه.
هل Vibe Engineering هو مستقبل تطوير البرمجيات؟
ربما.
لكن من المبكر تقديمه كحقيقة محسومة.
الأدلة الحالية تشير إلى تحول واضح نحو Agentic Software Development، وليس بالضرورة إلى أن مصطلح Vibe Engineering نفسه سيصبح معيار الصناعة.
هناك مؤشرات قوية على انتشار coding agents: دراسة أكاديمية منشورة في 2026 حللت أكثر من 128 ألف مشروع على GitHub وقدرت وجود نشاط لوكلاء البرمجة في نسبة تتراوح بين 22.20% و28.66% من المشاريع في فبراير 2026، مع اتجاه تصاعدي.
كما وجد استطلاع JetBrains لعام 2026 أن أدوات coding agents أصبحت جزءًا متزايدًا من أدوات المطورين المحترفين، مع استخدام أسبوعي مرتفع بين المشاركين.
لكن هذا لا يعني أن المستقبل سيكون:
AI يكتب كل شيء والإنسان يختفي.
الأقرب حاليًا هو:
إنسان يحدد الاتجاه + AI ينفذ أجزاء متزايدة + أنظمة تحقق تراقب النتيجة.
وهذا فرق جوهري.
ربما لا يكون مستقبل البرمجة "AI بدل المطور"
قد يكون مستقبل البرمجة:
مطوّر واحد + مجموعة Agents + أدوات + اختبارات + منصة قوية.
وهذا لا يعني أن كل مطور سيصبح مديرًا لعشرات Agents.
بل يعني أن حدود الإنتاجية قد تنتقل من:
كم سطرًا يستطيع الإنسان كتابته؟
إلى:
كم نظامًا يستطيع الإنسان تصميمه وإدارته والتحقق منه؟
وهنا تصبح الخبرة أكثر قيمة، لا أقل.
الفكرة التي أريد أن تبقى معك
إذا أردت تلخيص Vibe Engineering في جملة واحدة:
لا تستخدم الذكاء الاصطناعي فقط لكتابة البرمجيات؛ هندس الطريقة التي يعمل بها الذكاء الاصطناعي لبناء البرمجيات.
هذه هي النقلة.
Prompt Engineering يسأل:
ماذا أقول للنموذج؟
Context Engineering يسأل:
ماذا يجب أن يعرف النموذج الآن؟
Agent Engineering يسأل:
ما الذي يمكن للنموذج أن يفعله؟
أما Vibe Engineering — بهذا المعنى الناشئ — فيسأل:
كيف أصمم دورة كاملة تجعل الإنسان والـAI والأدوات والاختبارات يعملون كنظام هندسي واحد؟
وهنا لا يصبح المطور أقل أهمية.
بل تتغير طبيعة أهميته.
من:
كاتب لكل سطر.
إلى:
مهندس للأنظمة، وقائد للـAI، وحارس للجودة، وصاحب القرار.
وهذا ربما هو التحول الحقيقي الذي يجب أن نستعد له.
ليس مستقبلًا يستبدل فيه الإنسان بالآلة.
بل مستقبلًا تصبح فيه قدرة الإنسان على هندسة التعاون مع الآلة نفسها مهارة هندسية أساسية.