تطوير ممارسات الهندسة بمساعدة الذكاء الاصطناعي

مدونة Tabby الهندسية، أبريل 2026

الكاتب: ديميتري غلازكوف
Senior Frontend Engineer
LinkedIn

ترجمة: رغد بن عسكر
QA Engineer
LinkedIn

السلام عليكم، أنا ديمتري غلازكوف، مهندس برمجيات أشتغل في Tabby.

مقالاتي السابقة موجودة هنا وهنا. كتبتها قبل ما الذكاء الاصطناعي يكون جزء من حياتنا اليومية، لكن إذا تبي تعرف أكثر عن كيف محرك React يعمل من الداخل وعن concurrent rendering،فهي لا تزال مفيدة. لكننا الآن نعيش في عالم مختلف تماماً، واليوم أبي أتكلم عن كيف تطورت طريقتي في الشغل مع الذكاء الاصطناعي.

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

الهدف مو إني أسوي مراجعة لكل أداة موجودة، بل أبي أساعدك تفهم الطريقة الأنسب لكل نوع من المهام وكيف تطبقها في شغلك.

هذي أدوات مألوفة لأغلبنا، والكثير يستخدمها في شغله اليومي.

الشات

يعمل مع السياق اللي تقدمه له فقط
ممتاز للأسئلة المجردة و الـDebugging
مفيد جداً في وضع Deep Research لما تبي تجمع أكبر قدر من المعلومات من الإنترنت عن موضوع معين

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

بس خذ بالك - الموديل ممكن يرجع لك معلومات قديمة. عشان تتجنب هذا، استخدم Deep Research أو Web Search، أو وفّر مستند محدّث عن طريق أدوات زي Context7 MCP.

الوكلاء

عندهم وصول إلى المستودع (Repository)، الأدوات المحلية، ويقدرون يجمعون سياق أكبر بكثير
حسب الأداة، ممكن يشمل: قواعد، مهارات، هوكات، ووكلاء فرعيين (subagents)، تكاملات MCP، وآليات مشابهة
يقدرون يشتغلون مع أدوات CLI

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

يعمل بشكل أفضل على المشاريع الجديدة اللي تبدأ من الصفر
المواصفات تصير القطعة الأساسية اللي الوكيل يشتغل منها
استراتيجية صيانة المواصفات على المدى الطويل غالباً هشة

Spec-Driven Development - SDD هي طريقة لتطوير البرمجيات بمساعدة الذكاء الاصطناعي تبدأ فيها بكتابة المواصفات قبل ما تكتب أي كود. في هذا النموذج، المواصفات تصبح المدخل الأساسي للوكيل .

في أحد التفسيرات المميزة لـ SDD، يتم تقسيمه إلى ثلاثة مستويات:

Spec-first: الشغل يبدأ بمواصفات واضحة ومحددة، والوكيل يتبعها وقت التنفيذ
Spec-anchored: المواصفات تنحفظ بعد التسليم وتستمر كمرجع للتحديثات والصيانة الجاية
Spec-as-source: مع الوقت المواصفات تتحول للقطعة الأساسية، بينما تعديلات الكود المباشرة من البشر تقل أو تختفي تماماً

واحد من مسارات العمل الشائعة في SDD (مثلاً في أدوات زي Junie من JetBrains) يشمل ثلاث مراحل رئيسية:

requirements.md - وصف إيش المفروض النظام يسوي
plan.md - جسر بين المتطلبات العامة والكود الجاي
tasks.md - الخطة متقسمة لمهام صغيرة محددة

أنا ما أشوف Spec-anchored و Spec-as-source مناسبين للمشاريع الكبيرة اللي فيها مطورين كثير. بالآخر المواصفات تتوقف عن التحديث، ولما يصير كذا، ما تعود أوثق من الكود نفسه.

اللي نأخذه من SDD هو الانضباط في تعريف المهام. قبل ما تطلب من الوكيل ينفذ شي، خلّ المهمة واضحة: حدد الهدف، سجّل القيود، وصف السلوك المتوقع، وقسّم الشغل لخطوات صغيرة يقدر الوكيل ينفذها ويتابعها مباشرة. هذا الجزء فعلاً مفيد عملياً.

تقسيم الشغل لشي زي plan.md و tasks.md يصير مهم أكثر بعدين، لأنه يعطينا أساس للتنفيذ والتحقق والتكرار.

تحسين الاستقلالية وجودة الكود

لحد هنا العملية تبدو كالتالي : البشر خارج الحلقة. نكتب خطط، نقسم الشغل لمهام، ونسلمها للوكيل . هذا ممكن يمشي بشكل جيد بشكل مفاجئ على المهام البسيطة.

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

كيف نحسّن جودة الكود اللي يعطينا إياه الإيجنت؟

شفت-لفت لتطوير الوكلاء - Shift-Left

عشان نسوي هذا، نقدر نستعير تفكير shift-left الكلاسيكي. الفكرة الأساسية بسيطة: كل ما اكتشفت الغلط بدري، كل ما كان أرخص تصلحه. أصل فكرة shift-left جاية من عالم الاختبارات، وبعدين انتشرت في ممارسات Agile. لو نطبقها على تطوير الوكلاء المبدأ نفسه: ما ننتظر للنهاية عشان نكتشف إن الإيجنت فهم المهمة غلط أو انحرف عن الفكرة الأصلية.

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

الفحص الذاتي للإيجنت

فيه ثلاث طرق رئيسية الإيجنت يتأكد فيها إنه لا يزال يكتب كود شغّال يلبي المتطلبات، أو إنه بدأ يولّد ديون تقنية للمستقبل :

Linters - تحليل الكود
Type checking - فحص الأنواع
الاختبارات

الطريقتين الأولى والثانية بديهيات ونستخدمها بالفعل. لكن الثالثة - الاختبارات - هذا اللي كثير نتهاون فيها.

وبصراحة، الأسباب مفهومة. مو دايم يستاهل تقضي وقت تكتب اختبارات لكود قديم بدل ما تبني خصائص جديدة. وأحياناً، خلنا نكون صريحين، بس كسل.

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

ليش الاختبارات صارت الاعتماد الأساسي

في الدايقرام اللي سوّيته، حاولت أبيّن عدة أجزاء من شغلنا اللي تعزز بعض. في النص - القيمة التجارية. نبي ننمّي المنتج والشركة، وبالتالي ننمو كمهندسين.

هنا النسخة المختصرة لكيف هذي الروابط تشتغل:

Architecture ← Refactoring:

أي نظام يجمع الإرث التقني مع الوقت. الريفاكتورينق المنتظم يحافظ على صحة المعمارية (Architecture) ومرونتها. يعطينا طريقة نحسّن فيها هيكل الكود بدون ما نغير السلوك الخارجي للنظام. كل ما كانت خطوات الريفاكتورينق أصغر وأكثر تكراراً، كل ما كان أحسن

Agent ← Architecture:

إذا البشر يتوهون في كود فوضوي، الوكلاء يتوهون أكثر. معمارية نظيفة واتفاقيات موثّقة تخلي شغل الإيجنت أكثر موثوقية بكثير.

Time ← Agent:

الوكلاء يساعدون في توفير الوقت وتسريع التنفيذ وتقليل الأعمال الروتينية اليدوية

Tests ← Time:

جزء من الوقت الموفر نقدر نستثمره في الاختبارات. كتابة اختبارات جيدة تكلفة مقدمة، بس بدون هذا الاستثمار، التنفيذ السريع يتحول بسرعة لتنفيذ هش

Agent ← Tests:

الاختبارات هي اللي تخلي الشغل مع وكلاء الذكاء الاصطناعي موثوق عملياً. تعطي الوكيل إشارة موضوعية: إما التغيير يشتغل أو لا

Refactoring ← Tests:

Refactoring للوظائف الأساسية بدون اختبارات دايم فيه مخاطرة. الاختبارات تخليه آمن

(Integration ← Continuous Integration (CI:

CI يساعد في إطلاق خصائص أسرع ويدعم Refactoring أصغر وأكثر تكراراً قبل ما يصير قديم أو صعب الدمج

CI ← Tests:

الاختبارات تعطي ثقة في الإصدارات خصوصاً في بيئة CI. وايضا تصير توثيق حي للسلوك المتوقع

هذا نظام حلقة مغلقة. كل عنصر في الحلقة أساسي. شيل أي واحد منهم والنظام يتدهور.

إيش تضيف على هذا الدايقرام؟

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

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

عشان كذا الاختبارات تصير أكثر من مجرد ممارسة جودة. تصير جزء من البنية التحتية اللي تخلي التطوير المستمر ممكن. تسمح للبشر والوكلاء يسوون تغييرات في نظام يكبر بدون ما يعتمدون على معرفة كاملة بكل شيء حولهم. عشان هذا يشتغل، الاختبارات لازم تغطي متطلبات البزنس بشكل كافي عشان تلقط التراجعات (regressions) وبنفس الوقت تبقى سريعة ومفهومة وموثوقة.

ونقطة مهمة ثانية: الاختبارات طريقة لتقييم شغل الوكيل . كل ما نفوّض مهمة للوكيل ونبي نتيجة موثوقة، نحتاج إشارة نجاح موضوعية. الاختبارات توفر هذي الإشارة بإنها تبيّن إذا الوكيل فعلاً سوّى اللي طُلب منه.

حلقة التغذية الراجعة - Feedback Loop

أتمنى قدرت أقنعك إن الاختبارات مهمة. الحين أبي أجمع كل شي مع بعض وأبيّن المراحل اللي وكيل الذكاء الاصطناعي يمر فيها قبل ما يخلّص مهمة.

في هذا السير، الوكيل يتبع نهج test-first. من وجهة نظري، هذي أفضل طريقة تتحكم فيها في الوكيل : الاختبارات تخليك تتأكد بشكل صارم جداً إنه ما انحرف عن المهمة وما نسى متطلب مهم. أنا عمداً أختار test-first مو TDD الكلاسيكي بمعنى Red-Green-Refactor. بعدين بأوضح بالتفصيل ليش.

بس قبل ما نكتب اختبارات، نحتاج مرحلة تحضير: الهيكلة (Scaffolding). هذا يعني بناء هيكل الحل المستقبلي اللي الاختبارات والتنفيذ يُبنون عليه. إيش بالضبط تحتاج تبنيه كهيكل يعتمد كثير على المهمة واللغة اللي تشتغل فيها.

المراحل

بعد كذا تجي مرحلة كتابة الاختبارات. في حلقة التغذية الراجعة حقتي، أطلب من الوكيل يكتب كل الاختبارات للمهمة مقدماً، والمفروض تفشل بالطريقة المتوقعة أول شي. هنا أنا عمداً أبتعد عن TDD الكلاسيكي اللي تكتب فيه اختبار ضيق لجزء صغير من السلوك وبعدين تكتب تنفيذ ضيق بس عشان يمرره - هذا النهج يحتاج مراجعة مستمرة للاختبارات في الطريق. في نموذجي، نراجع مجموعة الاختبارات الكاملة للمهمة مرة وحدة.

بعدين تجي المرحلة الأمتع: التنفيذ.

في هذي النقطة، الوكيل يكتب الكود لحاله بدون تدخلنا. بعد ما ينكتب الكود، الوكيل يقدر يضيف أي اختبارات ناقصة إذا احتاج، وبعدين يدخل مرحلة الفحص الذاتي:

فحص الأنواع - type checking
فحص الكود - linting
اختبارات - tests

لو شي فشل، يرجع يحاول يصلح المشكلة ويعيد الفحص مرة ثانية. وحتى لو كل شي نجح، معاناته ما خلصت. لا يزال لازم يستدعي الوكيل الفرعي مراجع (https://code.claude.com/docs/en/sub-agents) يشيك على اللي انكتب، ينتج قائمة ملاحظات، ويرجع الوكيل للتنفيذ عشان يصلحها.

ليش الاستقلالية الكاملة لا تزال تفشل

آخر شي يستاهل نناقشه هنا هو متى المفروض نراقب شغل المتدرب الصغير حقنا.

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

الوكيل يقدر ينفذ ويشغّل فحوصات ويصلح مشاكل واضحة، بس فقط ضمن الحدود اللي حددناها أصلاً. اللي ما يقدر يسويه بشكل موثوق هو يقرر متى المهمة نفسها لازم تُعاد تفسيرها.

وهنا يبقى تدخل الإنسان ضروري. إذا الوكيل يبي يخفف التحقق، أو يتخطى اختبارات، أو يغير السلوك المتوقع - الإنسان لازم يتدخل. الهدف مو استقلالية كاملة، بل استقلالية مضبوطة: الوكيل يتحرك لحاله طالما باقي ضمن النية الأصلية، بس موافقة الإنسان تبقى مطلوبة كل ما ممكن تتغير هذي النية.

عملياً

عملياً، نبدأ بتعريف المهمة - وهنا تجربة SDD تنفعنا أكثر شي. من هنا نأخذ فكرة Spec-first: نسوي خطة ونقسم الشغل لمهام. كل ما كانت الخطة مجمّعة أحسن والتقسيم أوضح، كل ما كانت النتيجة النهائية أحسن عادةً.

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

المهام تُكتب بصيغة كذا:

[ ] [TaskID] [P?] Description with file path

P? باراميتر اختياري يحدد المهام اللي ممكن تتنفذ بالتوازي مع مهام ثانية.

من هنا، الإنسان يدير العمل: نجهز الخطة مع الوكيل ، نقسمها لمهام، نوزعها، ونخلي الوكلاء تنفذها عبر حلقة التغذية الراجعة اللي وصفناها قبل. بالآخر، الإيجنت يعلّم المهمة كـ Done مباشرة في وثيقة المهام ويقدر اختيارياً يترك معلومات هناك تفيد الوكيل اللي بعده اللي يشتغل على المهمة الجاية.

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

بعد هذي المراحل، نحتفظ بعدة نقاط تحكم للحالات اللي الوكيل يحاول يغير فيها النية الأصلية. إذا قرر إن بعض الاختبارات ما تلزم أو إن السلوك المتوقع لازم يتغير - ما يقدر يعدل لحاله، لازم موافقة الإنسان. نقاط التوقف بالضبط تختلف من مشروع لمشروع، بس المبدأ يبقى بسيط: الإنسان يبقى الحارس كل ما المهمة نفسها يُعاد تفسيرها.

بنفس الوقت، أغلب شغل التنفيذ يصير بشكل مستقل. كل وكيل ينفذ مهمته باستخدام مبادئ shift-left داخل حلقة تغذية راجعة، يتحقق من شغله خطوة بخطوة قبل ما يتقدم. هذا يخلي الوكيل يلتقط مشاكل كثيرة بدري ويزيد بشكل كبير فرصة إن الكود الناتج يشتغل كما هو متوقع.

هذا سير عمل human-in-the-loop.

الوكلاء يأخذون أدوار مختلفة، يسوون جزءهم من الشغل، ويتواصلون مع بعض
يستهلك موارد أكثر، بس يسمح بتوازي الشغل
المراجعة تبقى العنق الضيق

المشكلة الرئيسية في human-in-the-loop الصارم إن الإنسان بالآخر يصير العنق الضيق. الوكلاء يقدرون يولدون ويكررون الكود أسرع بكثير مما نقدر نراجع ونفك العوائق ونعيد توجيههم بشكل مستمر.

حلقة رالف - Ralph Loop

هنا تصير حلقة رالف مفيدة. Ralph طريقة يشغّل فيها وكلاء الذكاء الاصطناعي الكود بتكرارات قصيرة متكررة مع سياق محدود، ذاكرة خارجية، وفحص مدمج. عملياً، تشغّل نفس البرومبت بشكل متكرر: الوكيل يأخذ المهمة التالية من الـ PRD، ينفذها، يعمل كوميت، ويبدأ التكرار التالي. بدل ما تراقب كل خطوة يدوياً، ترجع بعدين لكود شغّال.

بالصدفة الحلوة، عندنا أصلاً برومبت يوصف بالضبط هذا النوع من التكرار - نفس الحلقة اللي وصفناها قبل في قسم حلقة التغذية الراجعة. تم اختبارها وتشتغل بفعالية.

فالمشكلة المتبقية ليست الحلقة نفسها، بل مسؤوليات الإنسان حولها - نفس المسؤوليات اللي تسبب العنق الضيق في العملية السابقة.

توزيع الأدوار

عشان نقلل العنق الضيق، المسؤوليات تتوزع على وكلاء الذكاء الاصطناعي بأدوار مختلفة. واحد يركز على التنفيذ، وغيره يتولى المراجعة أو الفحص أو حل العوائق. الوكيل المنسّق (orchestrator) مسؤول عن تشغيل الوكلاء الفرعيين ، توزيع المهام عليهم، وإدارة التدفق الكامل من التخطيط للمراجعة النهائية للمهمة كلها.

عملياً، يقدر يشغّل الوكلاء الفرعيين عبر سكربت باش - مثلاً يشغّل Codex أو Claude جديد من خلال CLI - أو عبر برومبتات تشغّل الوكلاء الفرعيين . نهج سكربت الباش أكثر صرامة ويخلي المنسّق أقرب للتدفق المقصود، وهذا ميزة وقيد بنفس الوقت.

الفكرة الأساسية بسيطة: ننقل أكثر تنسيق وتحقق داخل الحلقة نفسها، عشان الإنسان ما يحتاج يكون المنسق اليدوي في كل مرحلة.

وهذي المراحل اللي أميّزها لكل وكيل :

not_started
scaffold_created
tests_failed_as_expected
tests_need_fix
implementation_updated
lint_failed
lint_passed
typecheck_failed
typecheck_passed
tests_failed_due_to_tests
tests_failed_due_to_code
tests_passed
review_failed
review_passed
docs_sync_required
docs_synced
blocked

كما تشوف، ما أدخل في تفاصيل كل سطر وكل ستاتس وكل برومبت. هذي أصلاً تفاصيل تنفيذ تعتمد على مشروعك المحدد، وتقدر تشتغلها بنفسك - بمساعدة الوكيل طبعاً.

نبني بنية تحتية حول الوكلاء عشان يشتغلون بحرية والأهم يتحققون من أنفسهم
نقلل المراجعة كعنق ضيق ونثق أكثر بالكود اللي كتبته الوكلاء

في محاولة لتقليل تدخل الإنسان في تسليم البرمجيات أكثر، شركات كثيرة تتجه لنهج AI-first. في هذا النموذج، نراجع كود الوكلاء أقل ونعتمد أكثر على البنية التحتية حولهم تتحقق من شغلهم تلقائياً.

Harness engineering هي الفكرة الأوسع وراء هذا. تتعلق بتصميم البيئة، التعبير الواضح عن النية، وبناء حلقات تغذية راجعة تخلي الوكلاء تشتغل بشكل أوثق وبإشراف مباشر أقل.

هذا ما يحل محل حلقة الوكيل بقدر ما يضيف طبقة ثانية فوقها. هذي الطبقة ممكن تشمل مثلاً:

فحص E2E عبر المتصفح يشيك على السلوك الوظيفي ومقارنة لقطات الشاشة
وصول السجلات (logs) والتتبعات (traces) في أدوات زي Datadog عشان الوكلاء يتحققون من سلوك السيرفس ويحققون حتى في الأخطاء (bugs) في بيئات حقيقية
قراءة سجلات الـ Debug أثناء التشغيل المحلي للتطبيق

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

وبشكل منفصل، أبي أبرز أهمية تحسين مراجعة كود الوكيل وجودة المهارات (skills). هذا اللي يمنع تراكم الديون التقنية ويقلل المراجعة اليدوية مع الوقت. بس لين ما تطور مهارات حلوة فعلاً، تأكد تراجع الكود يدوياً. حدد أنماط الأخطاء اللي وكلائك يكررونها أكثر في مشروعك، وحوّلها لقواعد أو مهارات.

فعلاً نقدر نخلي وكلاء الذكاء الاصطناعي تشتغل لحالها ونتوقع كود جيد؟

في بعض الحالات، أكيد. الحلقات المستقلة تشتغل أحسن للخصائص الصغيرة المعزولة بأسلوب يوتيليتي بمتطلبات واضحة وفحص سهل.

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

هل هذا فعلاً يسرّع التطوير؟

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

أبي أختم بتأكيد إن جودة الكود لا تزال مهمة. مهما صار مع موجة الذكاء الاصطناعي الحالية، ممكن بالآخر نرجع ندخل الكود بأنفسنا. الكود السيء يخلق مخاطرة منفصلة - يؤدي لديون تقنية، وايضا يصعّب على وكلاء الذكاء الاصطناعي نفسها فهم قاعدة الكود (codebase). ونتيجة لذلك، أكثر احتمال يرتكبون أخطاء إضافية.

لا نزال لا نعرف أين ستصل تجارب Claude Code و Codex بنهجها "الذكاء الاصطناعي أولاً" (AI-first) ، أو ما هي الاستنتاجات التي سيصلون لها بأنفسهم من هذي التجربة وإلى أي حد المفترض نثق بهذي الاستنتاجات. بعض الرهانات ممكن تنجح، وبعضها ممكن يعطينا مكاسب قصيرة المدى تتركنا بكود صعب صيانته و تطويره وبتكلفة عالية لدرجة أننا قد ندفع أكثر لإعادة العمل أو حتى إعادة كتابة الكود بالكامل مقارنةً بما كسبناه من السرعة الأولية.

كل اللي وصفته في المقال مجموعة أدوات موجودة اليوم. كل وحدة لها مكانها وهدفها. لا تأخذ Ralph loop وتحاول تدق مسامير فيها. لازم نكون ماهرين بكل هذي الأدوات عشان نفهم أيها الأنسب لكل مهمة.

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

المصادر

Book: Refactoring - Martin Fowler, with Kent Beck

مقالات ثانية تستاهل تطّلع عليها

رحلتنا مع Feature Store: من Spark إلى التوسّع (الجزء الرابع)

تجربة عملية نروي فيها كيف طوّرنا ميزة Feature Store من نموذج أولي مبني على محرك Spark إلى منصة إنتاجية قابلة للتوسّع، مع دروس في المعمارية، والمعالجة المتدفقة، والميزات الفورية، ومعالجة فجوة التدريب والتشغيل على نطاق واسع.

اقرأ المقال

إدارة تبادل البيانات في مستودع البيانات لدينا (الجزء الثالث)

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

اعرف المزيد