الزبدة في دقائق
الأقسام مرتّبة لتقرأ الفكرة الكبرى أولاً، ثم التفاصيل العملية والاقتباسات والمفاهيم.
يستحق هذا الفيديو وقتك تماماً لأنه يغير جذرياً طريقة تعاملك مع الذكاء الاصطناعي في البرمجة. فبدلاً من الاستسلام لموجة البرمجة بالافتراض أو الاعتقاد بأن الذكاء الاصطناعي يلغي الحاجة للمبادئ الهندسية، يثبت لك هذا المقطع أن أساسيات هندسة البرمجيات الكلاسيكية هي المفتاح الحقيقي للسيطرة على الوكلاء البرمجيين. ستتعلم كيف تتجنب منطقة الغباء للنماذج اللغوية، وكيف تبني نظام حوار تفاعلي يضمن التوافق التام قبل كتابة سطر كود واحد، وكيفية إعداد بيئة عمل ليلية برمجية تلقائية لتنفيذ المهام بشكل متوازٍ ومستقل عبر التطوير الموجه بالاختبار وتصميم الوحدات البرمجية العميقة. ستحصل على منهجية علمية وعملية تنقلك من مجرد مبرمج محبط من أخطاء الذكاء الاصطناعي إلى مهندس يدير أساطيل من الوكلاء البرمجيين بكفاءة وجودة عالية.
الفكرة الكبرى هي أن أساسيات هندسة البرمجيات التقليدية - مثل الموديولات العميقة والتطوير الموجه بالاختبار والشرائح الرأسية للمهام - ليست ملغاة في عصر الذكاء الاصطناعي، بل هي الأساس الجوهري لتمكين الوكلاء البرمجيين من العمل بكفاءة ودون الوقوع في منطقة الأخطاء والنسيان.
الرسالة الجوهرية للمتحدث هي ضرورة الانتقال من فكرة تحويل المواصفات إلى كود تلقائياً دون تدخل إلى منهجية تشاركية قوية يكون فيها الإنسان مديراً للتصميم والتحليل ومعايير الجودة، بينما يُترك للذكاء الاصطناعي العمل كوكيل تنفيذ مستقل في فترات الغياب ضمن بيئات معزولة تضمن سلامة البنية البرمجية وجودتها.
يبدأ المتحدث مات ورشته بالتأكيد على أن أساسيات هندسة البرمجيات هي الحل الأمثل للمشاكل الشائعة عند البرمجة بالذكاء الاصطناعي. يستعرض أولاً القيود الغريبة للنماذج اللغوية الكبيرة مبيناً مفهوم المنطقة الذكية والمنطقة الغبية حيث يتراجع ذكاء النموذج تدريجياً مع زيادة حجم السياق عن مئة ألف توكن بسبب تزايد علاقات الانتباه بشكل تربيعي، مما يستدعي تجزئة المهام. كما يشبه النماذج ببطل فيلم مومينتو الذي ينسى باستمرار، مفضلاً مسح السياق كلياً والبدء من جديد لتجنب تراكم البيانات القديمة. ينتقل بعد ذلك لشرح مهارة استجوبني كبديل لمنهجية تحويل المواصفات لكود الفاشلة، حيث يقوم الوكيل البرمجي بطرح أسئلة مكثفة على المطور للوصول إلى فهم مشترك وتصميم متوافق قبل أي كتابة للكود. بعد تحقيق التوافق، يتم تلخيص المخرجات في وثيقة متطلبات المنتج التي تحدد الوجهة والقصص البرمجية والقرارات خارج النطاق. يشدد المتحدث على تقسيم هذه المتطلبات إلى مهام برمجية عبر الشرائح الرأسية أو الرصاصات الكاشفة التي تعبر كافة طبقات النظام للحصول على تغذية راجعة فورية، بدلاً من التقسيم الأفقي التقليدي الذي يؤخر كشف الأخطاء. ثم يستعرض كيفية تشغيل الوكيل البرمجي في نمط الغياب باستخدام سكريبت رالف لوب في بيئة حاوية معزولة، حيث يبرز دور التطوير الموجه بالاختبار كعامل أساسي يمنع الذكاء الاصطناعي من الاحتيال على الاختبارات ويضمن جودة مخرجاته. يختتم المتحدث بالحديث عن بنية الكود وتطبيق مبادئ كتاب فلسفة تصميم البرمجيات لـ جون أوسترهوت عبر تصميم الموديولات العميقة ذات الواجهات البسيطة والوظائف الداخلية المعقدة، مستعرضاً أداة ساند كاسل التي تسمح ببرمجة الوكلاء بشكل متوازٍ ومستقل وتسهل عملية مراجعة الأكواد ودمج الفروع مع الحفاظ على دور الإنسان المحوري في فرض الذوق واللمسة البشرية ومراقبة الجودة.
- 1
كم عدد الأشخاص الذين قاموا بالبرمجة باستخدام الذكاء الاصطناعي من قبل؟
- 2
كم عدد الأشخاص الذين يبرمجون يومياً باستخدام الذكاء الاصطناعي؟
- 3
كم عدد الأشخاص الذين شعروا بالإحباط أثناء استخدام الذكاء الاصطناعي في البرمجة؟
- 4
لماذا يتعين علينا الانتظار حتى الساعة 3:45 بينما الغرفة ممتلئة والأبواب مغلقة؟
- 5
كيف يمكن معالجة المهام الكبيرة وتقسيمها إلى مهام صغيرة لتناسب المنطقة الذكية للنموذج اللغوي الكبير؟
- 6
لماذا لا نستخدم المرحلة (N) حيث نحدد نهاية الرحلة ونجعل الذكاء الاصطناعي يقوم بتغييرات صغيرة تدريجية؟
- 7
ما هي الإجراءات التي تمنح نقاطًا وكم قيمتها في نظام التلعيب (Gamification) المقترح؟
- 8
هل يجب أن تكون نقاط التلعيب بأثر رجعي مع وجود سجلات تقدم حالية؟
- 9
ما هو منحنى التقدم المقترح للمستويات؟
- 10
هل تمنح السلاسل المتتالية (Streaks) نقاطًا؟
- 11
أين يجب أن تعيش واجهة مستخدم التلعيب (Gamification UI)؟
- 12
هل جربت أدوات مثل specit أو open spec أو Taskmaster بدلاً من مهارة 'Grill me'؟ وهل تجدها أكثر إسهاباً أم بديلاً مهيكلاً؟
- 13
ما هي أداة الميتا-برومبتينج المفضلة لديك؟
- 14
كيف أستخدم المحادثة كأصل قيم بعد جلسة 'Grill me'؟
- 15
ما هو رأيك في قيام مديري المنتجات أو الأدوار غير البرمجية بكتابة الأكواد عبر الذكاء الاصطناعي (Vibe Coding)؟
- 16
لماذا لا تستخدم واجهة مستخدم طرح الأسئلة (Ask User Questions UI) في أداة Claude Code؟
- 17
الآن بعد أن أصبح لدينا سياق يتسع لمليون توكن، هل نريد فعلاً الاستفادة من ذلك في البرمجة؟
- 18
كيف نقوم بتقسيم خطة العمل بحيث لا تقع أجزاؤها في المنطقة الغبية للنموذج اللغوي؟
- 19
لماذا يجب على المطور مراجعة تقسيم المهام بدلاً من ترك الأمر كلياً للذكاء الاصطناعي؟
- 20
ما هو الخطأ في البرمجة الأفقية (طبقة تلو الأخرى) ولماذا يجب تفضيل الشرائح الرأسية (Vertical Slices)؟
- 21
متى سأتوقف عن استخدام نظام التشغيل ويندوز؟
- 22
كيف يقرر الذكاء الاصطناعي متى يتوقف عن طرح الأسئلة في جلسة 'Grill me'؟ وهل توجد طريقة أذكى لتحديد نقطة التوقف؟
- 23
هل ما زلت تستخدم توجيه 'كن موجزاً للغاية وضحي بالقواعد النحوية لصالح الاختصار'؟
- 24
ما الذي سيحدث مستقبلاً في الصراع والتداخل بين أدوار مديري المنتجات والمطورين؟
- 25
كيف نتعامل مع الوكلاء (Agents) الذين ينتجون كوداً أكثر مما يمكننا مراجعته؟ وكيف يمكن توازي العمل واستخدام وكلاء متعددين بشكل منفصل وصحيح؟
- 26
لماذا لا نجعل الذكاء الاصطناعي يقوم باختبار ومراجعة الكود الخاص به بنفسه؟
- 27
كيف تحتفظ بالقرارات السلبية (الأشياء التي قررت عدم القيام بها ومبرراتها) عند حفظ نتائج جلسة 'Grill me'؟
- 28
ما هو سير العمل الخاص بك في تطوير الواجهات الأمامية (Front-end Workflow)؟
- 29
كيف تضمن التزام الذكاء الاصطناعي بالهندسة المعمارية (Architecture)، قيود الأمان، وعقود واجهة برمجة التطبيقات (API contracts) الخاصة بالأنظمة الكبيرة؟
- 30
هل تحتفظ بخطط ومستندات ماركداون (Markdown) والمشكلات للرجوع إليها لاحقاً أم تتخلص منها لتفادي تلف الوثائق؟
- 31
كيف تجعل الذكاء الاصطناعي يبرمج بالطريقة التي تريدها والالتزام بالمعايير البرمجية الخاصة بك؟
قيود الذاكرة والانتباه في النماذج اللغوية الكبيرة: المنطقة الذكية والمنطقة الغبية (Smart Zone & Dumb Zone)
يستعرض المتحدث فكرة أن النماذج اللغوية الكبيرة تعاني من قيود جوهرية تتعلق بكيفية معالجة الانتباه والذاكرة، وهو ما ينعكس في وجود 'منطقة ذكية' (Smart Zone) يظهر فيها النموذج بأعلى مستويات الذكاء والقدرة الفنية في بداية المحادثة، و'منطقة غبية' (Dumb Zone) ينتقل إليها عندما يزداد حجم السياق بشكل مفرط. يشير النص إلى أن العلاقات التفاعلية بين الرموز (Tokens) تزداد بشكل تربيعي مع كل رمز إضافي مضاف إلى السياق، وهو ما يثقل كاهل آلية الانتباه في النموذج اللغوي ويجعله يرتكب أخطاء فادحة وغبية عند تجاوزه حاجز 100 ألف توكن تقريبًا، بغض النظر عن سعة نافذة السياق الإجمالية المعلنة للنموذج (سواء كانت 200 ألف توكن أو مليون توكن). للتغلب على هذه المشكلة الجسيمة، يتعين على المطورين تقسيم المهام البرمجية الكبيرة والمعقدة إلى مهام صغيرة جداً ومحكمة تناسب البقاء داخل 'المنطقة الذكية' لتفادي القرارات العشوائية والأخطاء الفنية، وهي ممارسة كلاسيكية مستوحاة من ممارسات إعادة هيكلة الكود التقليدية الكلاسيكية.
مهارة الاستجواب الفني الفعال وبناء الفهم المشترك (The Grill Me Skill vs. Vibe Coding)
ينتقد المتحدث بشدة حركة 'من المواصفات إلى الكود' (Specs-to-Code) التي تتجاهل الكود الفعلي وتركز فقط على تعديل مستندات الوثائق البرمجية وإعادة تجميعها، واصفاً إياها بأنها 'برمجة العشوائية' (Vibe Coding) التي تؤدي إلى فشل المشاريع وفقدان السيطرة على جودة الكود المعماري. بدلاً من ذلك، يطرح المتحدث أهمية أداة 'استجوبني' (Grill Me Skill)، وهي مهارة توجيهية تمكن المطور من الدخول في جلسة استجواب مكثفة ومتواصلة مع الذكاء الاصطناعي لحل كل التفرعات والمشكلات المعمارية المعقدة والتبعيات الفنية والأسئلة الحرجة قبل كتابة الكود. يهدف هذا النهج إلى بناء 'مفهوم تصميمي مشترك' (Shared Design Concept) يجعل المطور والذكاء الاصطناعي على موجة فهم واحدة، مما يساعد في كشف الثغرات والأسئلة المعمارية الغامضة مثل مسألة معالجة البيانات القديمة بأثر رجعي لضمان بقاء المطور كقائد فني مطلع على كافة التفاصيل الكودية.
هيكلة التخطيط البرمجي عبر لوحات كانبان والخطط التفرعية (Kanban Boards & Directed Acyclic Graphs)
بعد الانتهاء من جلسة الاستجواب الفعال، يفضل المتحدث تحويل الأفكار والحلول المقترحة إلى مستند متطلبات المنتج (PRD) كمرجع نهائي للمشروع، ثم تقسيم هذا مستند إلى لوحة تذاكر مهام 'كانبان' (Kanban Board) بدلاً من الخطط التسلسلية التقليدية ذات المراحل المتتابعة والمقيدة بنطاق زمني صارم. هذا النهج يتيح للوكلاء الأذكياء العمل بكفاءة عالية وبشكل متوازٍ لأن المهام تُصنف وتُربط بروابط حظر فنية واضحة ومستقلة (Directed Acyclic Graphs)، مما يسهل توزيع المهام غير المحظورة على وكلاء متعددين للعمل عليها في نفس الوقت، وتجنب بقاء الوكيل في حلقة تنفيذ مغلقة أو أحادية تستهلك الكثير من التوكنز وتسرع الدخول الفوري في المنطقة الغبية وتعرقل إنتاجية التطوير الإجمالية.
ممارسة الشرائح الرأسية والطلقات الكاشفة لضمان التغذية الراجعة (Tracer Bullets & Vertical Slices)
يشير النص إلى ميل الذكاء الاصطناعي الطبيعي إلى البرمجة بشكل أفقي (Horizontal Coding)، حيث يكتب طبقة تلو الأخرى، كإنشاء جداول قاعدة البيانات أولاً بشكل منفصل، ثم منطق واجهة التطبيقات، ثم واجهات المستخدم بشكل كلي، وهي طريقة تعوق الحصول على أي اختبار أو تغذية راجعة حقيقية ومتكاملة حتى المراحل الأخيرة من المشروع. لحل هذه المشكلة، يدعو المتحدث إلى تبني مفهوم 'الطلقات الكاشفة' (Tracer Bullets) أو الشرائح الرأسية (Vertical Slices)، وهي ممارسة تفرض على الذكاء الاصطناعي بناء شريحة برمجية رقيقة متكاملة تخترق جميع طبقات النظام دفعة واحدة في تذكرة العمل الأولى (قاعدة بيانات خفيفة، واجهة تطبيقات بسيطة، وربطها بالواجهة الأمامية)، مما يمنح المطور والنموذج تغذية راجعة فورية ومتكاملة تضمن عمل كافة المكونات البرمجية معاً بشكل حقيقي وصحيح منذ البداية.
دور التطوير القائم على الاختبار وحلقات التغذية الراجعة المؤتمتة (TDD & Automated Feedback Loops)
يؤكد المتحدث على أن ممارسة التطوير الموجه بالاختبار (TDD) وتحديداً منهجية (Red-Green-Refactor) تعد حجر الزاوية والركيزة الأساسية لتمكين وكلاء الذكاء الاصطناعي من العمل بشكل مستقل تماماً بعيداً عن لوحة المفاتيح (AFK). فكتابة اختبار فاشل أولاً ثم كتابة منطق العمل لجعله ينجح يمنع الذكاء الاصطناعي من التلاعب بالاختبارات أو محاولة الالتفاف عليها لكتابة أكواد وهمية، كما تضمن هذه الطريقة تزويد المشروع باختبارات برمجية حقيقية وذات جودة عالية وثابتة. ويرى المتحدث أن جودة مخرجات الذكاء الاصطناعي محدودة تماماً بجودة حلقات التغذية الراجعة المؤتمتة المتوفرة في المشروع (مثل اختبارات الأنواع والتصحيح التلقائي للأخطاء عبر المترجم والـ Linters)، وبالتالي فإن تحسين جودة هذه الحلقات يرفع مباشرة من كفاءة ومهارة الوكيل في كتابة كود سليم وقابل للصيانة.
هندسة البرمجيات وبنية الوحدات العميقة لتيسير عمل الوكلاء (Deep Modules vs. Shallow Modules in AI Era)
اعتماداً على كتاب 'فلسفة تصميم البرمجيات' لجون أوسترهوت، يبرهن المتحدث على أن جودة ومستوى بنية الكود تؤثر مباشرة على قدرة الذكاء الاصطناعي على الفهم والإنتاج؛ فالكود المعقد والوحدات الضحلة (Shallow Modules) التي تحتوي على واجهات معقدة ووظائف بسيطة ومبعثرة تشتت تركيز النموذج وترهق سياقه المعرفي في تتبع التبعيات المتشابكة. بدلاً من ذلك، يجب على المطورين تصميم وحدات عميقة (Deep Modules) تتميز بواجهات برمجية بسيطة للغاية وتخفي بداخلها وظائف برمجية معقدة وضخمة. هذا الهيكل المعماري يسهل عملية وضع حدود اختبار متكاملة واضحة حول الوحدة، ويتيح للمطور تصميم واجهة الخدمة وتفويض مهمة كتابة الكود الداخلي المعقد للذكاء الاصطناعي كصندوق رمادي (Gray Box) يحقق الكفاءة المطلوبة ويحمي المطور من الإرهاق الذهني ويحفظ وعيه بالبنية العامة للكود.
أتمتة العمل البرمجي المتوازي وبيئات الحاويات المعزولة عبر 'ساند كاسل' (Sand Castle & Parallel AFK Execution)
يقدم المتحدث نظاماً متقدماً لإدارة وبرمجة الوكلاء بشكل مؤتمت وتفرعي بالكامل من خلال مكتبة 'ساند كاسل' (Sand Castle) المطورة بلغة تايب سكريبت لتسهيل تشغيل تكرارات الوكلاء في بيئات معزولة داخل حاويات دوكر (Docker Sandboxes). يتيح هذا النظام للذكاء الاصطناعي العمل بشكل مستقل (AFK) على تذاكر كانبان في فروع جيت (Git Branches) متعددة ومتوازية بشكل مستقل تلقائي تماماً. يتضمن النظام استخدام نموذج ذكاء اصطناعي فائق مثل (Claude Opus) كمسؤول عن مراجعة الكود وحل صراعات الدمج (Merge Conflicts) وتطبيق الاختبارات الإجمالية وتطبيق معايير البرمجة الخاصة بالمشروع بأسلوب الدفع (Push)، بينما يتولى نموذج أسرع وموجه نحو المهام مثل (Claude Sonnet) كتابة الكود الفعلي بأسلوب السحب (Pull)، مما يخلق بيئة تطوير آلية متكاملة تضمن تسليم أكواد برمجية بجودة عالية قبل دمجها نهائياً.
- 1Keep tasks small to stay within the LLM's 'smart zone' (typically under 100k tokens)
- 2Track token usage closely during coding sessions to monitor proximity to the 'dumb zone'
- 3Use the 'Grill Me' skill to align on the design concept and reach a shared understanding with the AI before writing code
- 4Structure implementation tasks as vertical slices (tracer bullets) crossing all layers to secure instant feedback
- 5Implement Test-Driven Development (TDD) using a red-green-refactor loop to maintain robust feedback cycles and prevent AI from cheating
- 6Conduct manual QA to maintain product quality and inject human taste rather than automating the entire cycle
- 7Build 'deep modules' with simple interfaces and rich internal logic to make the codebase easier for AI to navigate and test
- 8Apply a pull-based strategy for coding standards during implementation and a push-based strategy during automated reviews
- 1Bloating the system prompt (e.g. with 250k tokens), pushing the LLM immediately into the 'dumb zone'
- 2Adopting 'specs to code' or 'vibe coding' where developers ignore the codebase and only edit specifications
- 3Coding horizontally (layer by layer) instead of vertically, resulting in delayed integration feedback
- 4Relying on sequential, multi-phase plans that prevent parallelization across multiple agents
- 5Allowing the AI to create shallow modules that complicate dependency tracking and automated testing
- 6Performing code reviews within the same bloated context window where implementation occurred instead of clearing the context
- 1Smart Zone vs. Dumb Zone (Context Window limitations)
- 2Tracer Bullets / Vertical Slices (The Pragmatic Programmer)
- 3Deep vs. Shallow Modules (John Ousterhout's Philosophy of Software Design)
- 4Ralph Wiggum Software Practice
- 5Push vs. Pull Coding Standards Framework
يروي المتحدث تجربته الشخصية عندما حاول تبني نهج المواصفات البرمجية أولا (Specs to Code) أو ما يعرف بـ البرمجة بالاستشعار (Vibe Coding). في هذا النهج، يقوم المطور بكتابة وثيقة مواصفات كاملة ويمرّرها للذكاء الاصطناعي لينتج الكود بالكامل، وإذا حدث أي خطأ في الكود الناتج، لا ينظر المطور إلى الكود بل يعود لتعديل وثيقة المواصفات وإعادة بنائها مجددا. يوضح المتحدث أنه حاول تطبيق هذا الأسلوب بكل جدية، لكنه اكتشف أنه سيء للغاية ولا يعمل على أرض الواقع. والسبب في ذلك هو أن المطور بحاجة دائما إلى الإمساك بزمام الأمور وفهم الكود وتشكيله وتوجيهه، لأن الكود البرمجي هو ساحة المعركة الحقيقية التي لا يمكن تجاهلها.
سياق القصة هو التحذير من الانسياق وراء وهم الاستغناء الكامل عن فهم الكود وكتابته. وتبرز القصة مغزى أساسيا وهو أن الذكاء الاصطناعي لا ينبغي أن يعزل المطور عن التفاصيل البرمجية، بل يجب استخدام أدوات لترسيخ الفهم المشترك والانسجام بين المطور والذكاء الاصطناعي قبل البدء في التنفيذ.
يسرد المتحدث تجربة طريفة ومحبطة حدثت معه عندما انتهى من تسجيل دورته التدريبية حول أداة Claude Code. لقد قام بتسجيل الدورة بالكامل مستندا إلى نافذة سياق بحجم 200 ألف توكن. ولكن، في نفس اليوم الذي أطلق فيه الدورة رسميا، أعلنت شركة Anthropic عن إتاحة نافذة سياق بحجم مليون توكن! هذه المصادفة جعلته يدرك سريعا كيف تسوق شركات الذكاء الاصطناعي لميزات النوافذ الضخمة؛ حيث يرى أن زيادة حجم السياق لا يعني بالضرورة زيادة المنطقة الذكية (Smart Zone) للنموذج، بل هو مجرد شحن لمزيد من المنطقة الغبية (Dumb Zone) التي تجعل النموذج يرتكب أخطاء غبية عند تراكم البيانات والرموز.
تأتي هذه التجربة في سياق شرح الحدود والقيود الغريبة التي تواجه النماذج اللغوية الكبيرة (LLMs)، وتحديدا مفهوم المنطقة الذكية والمنطقة الغبية. المغزى هو أن المطور يجب ألا ينخدع بالأرقام الضخمة لنوافذ السياق، بل عليه إبقاء المهام صغيرة ومحددة بحدود 100 ألف توكن لضمان أعلى جودة وموثوقية.
يشارك المتحدث تجربته العملية في إدارة مشروعه الخاص لإنتاج الفيديوهات التعليمية، وهو مشروع Course Video Manager المتاح علنا على منصة جيت هاب. يوضح المتحدث أنه يستخدم هذا التطبيق بشكل يومي لإدارة وتسجيل فيديوهاته، وقد قام من خلاله بحل وإغلاق أكثر من 744 تذكرة عمل بالاعتماد على ذكائه الاصطناعي وسير العمل الذي يدرسه. يستعرض هذا المستودع البرمجي أمام الحضور ليريهم كيف تتحول وثائق متطلبات المنتج (PRDs) إلى مهام فعلية مقسمة ومترابطة على لوحة كانبان مدمجة في المشروع.
سياق القصة هو تقديم إثبات عملي وواقعي من مشروع حقيقي لإثبات أن المنهجية التي يطرحها (تحويل وثائق المتطلبات إلى مهام مجزأة وقابلة للتنفيذ بشكل مستقل) ليست مجرد نظريات، بل هي ممارسة مطبقة وناجحة في مشاريع إنتاجية معقدة تحتوي على مئات المهام المنجزة.
يتحدث الكاتب عن شعوره بالإحباط وعدم الرضا تجاه الأدوات المتاحة حاليا في السوق لتشغيل وكلاء الذكاء الاصطناعي بشكل مستقل وبعيد عن لوحة المفاتيح (AFK). ومن واقع هذا الإحباط، قرر قضاء أسبوع كامل في برمجة أداة خاصة به أطلق عليها اسم Sand Castle. وهي عبارة عن مكتبة برمجية بلغة TypeScript تتيح تشغيل حلقات الوكلاء البرمجية بشكل مواز آمن داخل حاويات Docker، حيث تقوم الأداة بإنشاء فروع برمجية (Git branches)، وتكليف وكلاء مختلفين بمهام مستقلة، ثم الاستعانة بنموذج Claude Sonnet للتنفيذ، ونموذج Claude Opus الأكثر ذكاء للمراجعة، وفي النهاية دمج الكود وحل مشكلات التعارض برمجيا وبشكل مواز تماما.
تأتي هذه القصة في سياق شرح كيفية الانتقال من التنفيذ الخطي المتتابع للمهندسين المبرمجين إلى التنفيذ المتوازي والآلي بالكامل باستخدام وكلاء ذكاء اصطناعي متعددين يعملون بشكل مستقل وخلف الكواليس، مع ضمان بيئة عمل آمنة ومنعزلة.
يسترجع المتحدث تجربة معقدة جدا مر بها أثناء تطوير ميزة محرر الفيديو (Video Editor) الذي يعمل مباشرة داخل المتصفح كجزء من نظام إدارة الفيديوهات الخاص به. واجه المتحدث صعوبة بالغة في البداية لأن تطوير مديولات الفيديو داخل المتصفح يعتبر عملا هندسيا شاقا ومليئا بالتفاصيل، وكان جعل الذكاء الاصطناعي يكتب كودا له أمرا وحشيا وصعبا للغاية لعدم قدرة النموذج على رؤية مخرجات واجهة المستخدم وتجربتها. لحل هذه المعضلة، استخدم مهارة برمجية تسمى تحسين بنية الكود (Improve Codebase Architecture) لإعادة تجميع تدفق الكود بالكامل من الواجهة الأمامية إلى الخلفية داخل مديول واحد عميق (Deep Module) مغطى باختبار شامل. وبمجرد قيامه بذلك، تمكن الذكاء الاصطناعي من رؤية التدفق واختباره بالكامل، مما أحدث قفزة نوعية في قدرته على إجراء التعديلات وحل المشكلات بنجاح مذهل.
سياق هذه التجربة هو توضيح الفارق بين المديولات العميقة (Deep Modules) والمديولات الضحلة (Shallow Modules) استنادا إلى كتاب فلسفة تصميم البرمجيات لـ جون أوسترهوت. المغزى الأساسي هو أن الكود السيء والبنى البرمجية المفككة تؤدي بالضرورة إلى فشل وكلاء الذكاء الاصطناعي، بينما تسهم البنى البرمجية العميقة والمصممة جيدا والقابلة للاختبار في تمكين الذكاء الاصطناعي من العمل بأعلى كفاءة ممكنة.
منطقة الذكاء والغباء (Smart zone and dumb zone)
نموذج يصف سلوك النماذج اللغوية الكبيرة (LLMs)؛ حيث تكون في قمة فهمها للعلاقات السياقية في بداية المحادثة (منطقة الذكاء)، ولكن مع زيادة حجم سياق المحادثة وتراكم الرموز (بعد تخطي حاجز 100 ألف رمز أو 40% من مساحة السياق)، تضعف قدرتها على الانتباه تدريجياً وتبدأ في اتخاذ قرارات خاطئة (منطقة الغباء). مثال: بدء محادثة جديدة لحل مشكلة معقدة مقابل إكمال محادثة طويلة جداً ممتلئة بالبيانات القديمة.
أسلوب رالف ويغوم (Ralph Wiggum Practice / Ralph Loop)
ممارسة برمجية تعتمد على الاستغناء عن خطط التطوير متعددة المراحل والجامدة، والاكتفاء بتحديد الهدف النهائي فقط (مثل وثيقة متطلبات المنتج PRD) وتوجيه نموذج الذكاء الاصطناعي لإجراء تغييرات صغيرة وتدريجية متكررة حتى الوصول إلى هذا الهدف. مثال: إعطاء ملف المواصفات النهائي للعميل للذكاء الاصطناعي وتركه يعدل الكود شيئاً فشيئاً حتى يطابقه تماماً.
الضغط (Compacting)
عملية تلخيص وتقليص تاريخ المحادثة الطويلة مع النموذج اللغوي في مساحة أصغر لتجنب الوصول إلى منطقة الغباء، عوضاً عن مسح السياق تماماً. ورغم فائدتها، إلا أنها قد تخلف رواسب معلوماتية تؤثر على جودة الإجابات لاحقاً. مثال: ضغط محادثة مكوّنة من 10 خطوات نقاشية في سطر تلخيصي واحد داخل واجهة الذكاء الاصطناعي.
مهارة استجوابي (Grill me skill)
تقنية مخصصة لنماذج الذكاء الاصطناعي تقوم على توجيه أسئلة متتالية ومكثفة ومقترحات للمطور للوصول إلى فهم مشترك عميق للتصميم والافتراضات وحل التبعيات قبل البدء بكتابة أي كود برمجي. مثال: تزويد الذكاء الاصطناعي بمتمتطلبات العميل، ليقوم بطرح 40 سؤالاً توضيحياً حول آلية احتساب النقاط وتخزين البيانات.
البرمجة بالشرائح الرأسية (Tracer bullets / Vertical slices)
نهج برمجي مستوحى من كتاب المبرمج البراغماتي، يركز على بناء وتطوير ميزات كاملة تمتد بشكل رأسي عبر جميع طبقات النظام (من قاعدة البيانات مروراً بالواجهة البرمجية API وصولاً إلى واجهة المستخدم) بدلاً من البناء الأفقي طبقة تلو الأخرى. يهدف هذا الأسلوب لتوفير تغذية راجعة فورية للذكاء الاصطناعي حول جودة النظام المتكامل. مثال: تطوير واجهة نقاط مستخدم بسيطة تتضمن تعديل قاعدة البيانات والـ API وظهور النتيجة في الواجهة في مرحلة العمل الأولى مباشرة.
المهام غير التفاعلية (AFK Tasks - Away From Keyboard)
المهام البرمجية التي يمكن تفويضها بالكامل لعميل ذكاء اصطناعي ليعمل عليها بشكل مستقل وتلقائي دون الحاجة لمراقبة أو تدخل بشري مستمر، مثل كتابة كود ميزة برمجية واختبارها عبر بيئة معزولة. مثال: إرسال تذكرة برمجية محددة لعميل ذكاء اصطناعي لإجراء موازنة وتعديلات واختبار الكود تلقائياً أثناء غياب المطور.
الوحدات العميقة مقابل الضحلة (Deep vs Shallow Modules)
مفهوم مستوحى من فلسفة تصميم البرمجيات لـ John Ousterhout؛ حيث تتميز الوحدات العميقة بواجهة برمجية (Interface) بسيطة للغاية على لغة الاستدعاء الخارجي مع وجود منطق برمجي معقد وغني جداً بداخلها (وهو ما يسهل على الذكاء الاصطناعي فهمه وفحصه)، بينما الوحدات الضحلة تكون ملفات برمجية صغيرة ومشتتة تصدر الكثير من الدوال البسيطة وتجعل من الصعب تتبع التبعيات وفحصها. مثال: إنشاء وحدة برمجية واحدة عميقة للألعاب تحتوي بداخلها على منطق احتساب النقاط والمستويات وتصدير دالة استدعاء واحدة فقط.
- 1ساعتان (مدة ورشة العمل المتوقعة)
- 2ستة أشهر (المدة التي كان يعتمد فيها المتحدث على فرضيته)
- 340% (النسبة التي يضعف عندها انتباه الـ LLM)
- 4100 ألف رمز (حد بداية منطقة الغباء)
- 51 مليون رمز (حجم سياق الـ LLM الأكبر المتاح)
- 6200 ألف رمز (حجم سياق الـ LLM الأصغر المتاح)
- 7250 ألف رمز (حجم نصوص برومبت النظام التي يضعها بعض المطورين)
- 893.7 ألف رمز (معدل استهلاك الوكيل الفرعي لنموذج Opus)
- 918 قصة مستخدم (مكتوبة في وثيقة متطلبات المنتج PRD)
- 10744 تذكرة مغلقة (في مستودع كود إدارة الفيديوهات الخاص بالمتحدث)
- 11ألف فيديو (تم تسجيلها باستخدام برنامجه الخاص)
- 12284 اختبار برمجي (موجودة في مستودع الكود بعد تشغيل اختبارات التحديث)
- 1317 دقيقة (الوقت المتبقي من المحاضرة)
- 1Dex Hy (Human Layer)
- 2Martin Fowler (Refactoring)
- 3The Pragmatic Programmer (Book)
- 4Frederick P. Brooks (The Design of Design)
- 5John Ousterhout (A Philosophy of Software Design)
- 6Matt Pocock (AI Hero / Course Video Manager)
- 7Claude / Claude Code / Opus / Sonnet (Anthropic)
- 8Gemini Meetings
- 9Sand Castle (TypeScript Library)
- 10Steve (TL draw / beads framework)
"when we talk about AI being a new paradigm, we forget that actually software engineering fundamentals, the stuff that's really crucial to working with humans, also works super well with AI."
The speaker challenges the belief that AI completely discards old rules. He argues that foundational software principles like testing, task isolation, and deep modularity are what make AI agents successful.
"I needed to reach a shared understanding. I didn't need an asset. I didn't need a plan. I needed to be on the same wavelength as the AI as my agent."
Explaining the philosophy behind the grill me skill. Success with AI comes from conversational alignment and developing a shared design concept, rather than simply feeding specs to a code-generation pipeline.
"If you have a garbage codebase you're going to get garbage out of the agent that's working in that codebase."
The speaker argues against the idea that developers no longer need to care about clean code. A messy, poorly architected codebase confuses AI agents and severely degrades their output.
- 1LLMs experience a severe intelligence drop-off transitioning from a smart zone to a dumb zone around 100k tokens due to quadratic attention scaling, rendering massive context windows practically ineffective for complex coding tasks.
- 2The specs-to-code paradigm fails because ignoring the actual codebase isolates the developer from their primary battleground. True success requires constant hands-on steering and maintaining the codebase's structural integrity.
- 3AI naturally tends to implement code horizontally layer-by-layer, which leaves developers without integrated feedback until the very end. Forcing AI to build in thin vertical slices or tracer bullets ensures continuous validation.
- 4Software engineering with AI is best split into a high-touch human day shift for alignment, design, and breaking down plans, and an automated night shift where AI executes tasks independently.
- 5Structuring code into deep modules with rich internal logic behind clean, minimal interfaces allows developers to treat implementations as gray boxes, enabling AI to code and test safely within bounded feedback loops.
- 1عدم مراجعة أو قراءة وثيقة متطلبات المنتج (PRD) التي يولدها الذكاء الاصطناعي، بحجة أن مراجعتها تضيع الوقت وأن الذكاء الاصطناعي متميز في التلخيص وتجنب الأخطاء.
- 2رفضه لمنهجية 'التحول من المواصفات إلى الكود مباشرة' (Specs to Code) ووصفها بأنها غير عملية وتؤدي إلى تجاهل جودة الكود الحقيقية التي يجب أن تظل ساحة المعركة الأساسية للمطور.
- 3كرهه لعملية 'الضغط' (Compacting) لسياق محادثة الذكاء الاصطناعي وتفضيله مسح السياق بالكامل والبدء من جديد لتجنب دخول النموذج في 'المنطقة الغبية' (Dumb Zone).
- 4الادعاء بأن النماذج اللغوية الكبيرة تفقد ذكاءها وقدرتها على اتخاذ القرارات الصحيحة بعد تجاوز 100 ألف توكن في سياق المحادثة، بغض النظر عن حجم نافذة السياق المعلنة من الشركات المطورة (سواء كانت 200 ألف أو مليون توكن).