الشرائح الرفيعة تمنع /sdd-flow من إغراق طاقتي

كومة ضخمة من القمامة

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

قبل نحو ستة أشهر، بنيت إضافة سير عمل SDD لتطبيق دورة بحث-تخطيط-تنفيذ على المشاريع البرمجية. من خلال التجربة، واصلت تعديلها وأضفت مراحل مراجعة إضافية وخطوات تصحيح ذاتي للثغرات. نجحت بشكل ممتاز لدرجة أنني ظننت أن بالإمكان أتمتة العملية بالكامل، فأوجدت مهارة /sdd-flow. مكّنتني هذه المهارة من تنفيذ الميزات دفعةً واحدة (أستخدم "دفعةً واحدة" بمعنى فضفاض هنا، إذ تتخللها خطوات توضيح ومراجعة). نجح ذلك جيداً حتى تعقّدت مشاريعي وباتت "الدفعة الواحدة" تعني التعامل مع متطلبات وتوقعات كثيرة في آنٍ واحد. باختصار، شربت من كأس الوهم وصدّقت أن الذكاء الاصطناعي قادر على التسليم.

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

شرائح أرفع

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

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

المشكلة التالية، وهنا المفارقة، أنني كنت أحصل على نتائج أسوأ رغم أن التطبيق كان مختبَراً بشكل شامل باختبارات الوحدة (unit tests) والاختبارات الشاملة (end-to-end tests). اتكائي الزائد على هذه الاختبارات كضمان للجودة والاكتمال جعلني أتخطى المراجعة الشخصية. تحت الضغط، اخترت الطريق الأسهل: أدخلت الطلب التالي، رميت النرد، وواصلت المقامرة. كان ذلك غباءً.

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

نهج تطوير الشرائح العمودية هذا، حين يُطبَّق على وكلاء البرمجة، من شأنه أن:

1. يُجبر الوكيل على التركيز بشكل أكثر إحكاماً.
2. يُسهّل عليّ اختبار ومراجعة ما يُسلَّم.
3. يُساعدني على تتبّع ما يُسلَّم بشكل أفضل وتصحيح الانحرافات بشكل أسرع.

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

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

التطوير البرمجي أمر شخصي. هذا ما يتوافق مع أسلوبي وقيودي وتجربتي.

في السيطرة من جديد

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

كنت سعيداً جداً بالنتائج، سواء في كيفية تصرّف الوكيل الآن أو في كيف أُجبَر أنا على التصرّف. التطبيق الآن يمتلك مجموعة مركّزة من الميزات الأولية. لديّ إمساك أفضل بما أفعله وكيف أواصل تنميته.

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

تكبير الصورة — الأثر الأشمل

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

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

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

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

استخدم وضع Slice

تتطلب المهارة راية لاستدعاء التطوير في شرائح عمودية: /sdd-flow delivery_mode: per-slice

هذه المهارة جزء من إضافة agent-engineering.