المكوّن كان موجود بالفعل

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

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

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

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

بص أبعد من الـ ticket#

وأنا بكتب في سبتمبر 2026، أتوقع إن Coding Agent قوي يخلّي بناء الميزة دي أسهل بكتير. ما عنديش قياس أحطّه كنسبة للتسريع. الـ Agents بيقدروا يفحصوا مستودعات الكود، وينفّذوا تعديلات، ويتحققوا من النتيجة. إعلان Anthropic في يوليو، مثلًا، بيعرض تحسّن في تشخيص الأخطاء ومراجعة الشغل في تقييمات الشركة وتجارب المستخدمين الأوائل.

لكن لو مهمة الـ Agent وصلاحياته واقفين عند تطبيق التأجير، مش هتوقع منه يكتشف بشكل معتاد مكوّن في مشروع حجز الدورات المنفصل. هوضّح له مكانه، أو أخلي العلاقة بين المشروعين موجودة في توثيق يقدر يرجع له.

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

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

النسخة الأطول بتدّي نموذج محلي زي Qwen3.8-27B نقطة بداية بطريقة zero-shot، يعني تعليمات من غير أمثلة محلولة. نسخة مكمّمة لـ 4-bit تقدر تشتغل على كارت شاشة من الفئة العليا بذاكرة 24 GB، زي RTX 4090؛ دليل Unsloth للتشغيل المحلي بيشرح اختيارات التكميم. إتاحة المشروعين للـ Agent خطوة في التجهيز: خلّي المستودعين متاحين ووجّهه للكود المرتبط بالمهمة.

بستخدم إعدادات مختلفة لحجم السياق في شغلي المحلي على OpenCode. هشرح الإعداد ده، وإمتى بختار كل واحد، في مقالة منفصلة.

مع النماذج الأقوى دلوقتي، زي GPT-6 Astra أو Claude Fable 5.1، غالبًا هبدأ بطلب أقصر:

شوف إذا كان تقويم حجز الدورات مناسب لتأجير الأدوات قبل ما تبني واحد جديد.

لو الـ Agent يقدر يفحص المشروعين، أتوقع إنه يقدر يعمل جزء كبير من المقارنة بنفسه. الطلب القصير بيلفت نظره لمكوّن موجود قبل ما يبدأ تنفيذ جديد.

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

هسجّل القاعدة دي في مكان يقدر الـ Agent والمطوّر اللي بعدي يرجعوا له. تجربة OpenAI في البناء باستخدام Codex بتوصف الشغل المطلوب عشان معرفة المشروع تبقى متاحة، ومعاها أدوات للتحقق. تجهيز البيئة دي للـ Agent محتاج مجهود هندسي برضه.

يعني إيه يوم متاح؟#

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

التأجير من الجمعة للاثنين شامل يوم الاثنين؟ الأداة اللي بترجع الصبح ينفع تتأجّر تاني بعد الضهر؟ لو محتاجة وقت للفحص، التقويم لازم ياخد الوقت ده في الحسبان.

الـ Agent يقدر يطرح الأسئلة دي ويقترح إجابات معقولة. والشخص المسؤول عن الورشة لسه محتاج يحسم القواعد. افتراض شكله منطقي ممكن يوعد شخصين بنفس الأداة في نفس الوقت.

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

جرّب الحجز اللي المفروض يترفض#

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

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

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

هات من الشغل السابق اللي يفيد دلوقتي#

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

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

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

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

بستخدم planning-with-files لتسجيل الشغل ده، وبحتفظ بإجابات المناقشات اللي بنختبر فيها قرارات التصميم. السجل ده بيشرح إيه اللي وصّلنا لقرار، بما فيه البدائل اللي رفضناها. حدّثه لما الخطة تتغيّر، وسيب خطوة جاية واضحة. لما Agent تاني يستلم المهمة، اطلب منه يقرأ الملاحظات ويراجعها على الكود الحالي. توثيق قديم ممكن يوجّهه لطريق غلط، زي طلب ناقص بالضبط.

وبطلب كمان commits وإحنا شغّالين. “خلّص الميزة” مش بيحدّد المراحل اللي عايز أسجّلها في الطريق. حسب إعداداته، الـ Agent ممكن يحقّق الطلب ويسيب تعديلات شغّالة في مجلد المشروع. بكتب المراحل اللي عايزها في تعليمات المستودع:

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

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

كده التعافي من المشكلة بيبقى أقل اعتمادًا على إن الـ Agent يفتكر المحادثة أو يشرح تعديلاته صح. الاختبارات بتسجّل السلوك اللي متوقعينه، والـcommits بتحفظ الكود اللي أنتجه، وملاحظة قصيرة عن القرار بتشرح ليه اخترنا الحل ده.

اعرف إمتى ترجع خطوة#

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

هكتب في التعليمات كمان إمتى المراجعة دي مطلوبة:

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

الـ Agent يقدر يعمل المقارنة دي ويقترح الرجوع. طلبها أثناء التطوير بيدّينا فرصة نرجع لحل أبسط قبل ما شغل أكتر يعتمد على آخر تعديل.

خلّي طريقة تفكيرك واضحة#

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

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

فيه دليل حديث بيدعم الاستثمار في الفهم ده. تحليل Anthropic في يونيو 2026 لحوالي 400 ألف جلسة Claude Code لقى علاقة بين زيادة الخبرة في مجال المهمة وتحسّن النتائج. دي دراسة رصدية على منتج واحد، والفرق بين أصحاب المستوى المتوسط والخبراء كان محدود. النتائج بتدعم تطوير معرفة المجال، من غير ما توعد إن الخبرة تضمن النجاح.

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