Claude وRalph: نهجان لبناء DatePicker معقّد بالذكاء الاصطناعي في تطوير المنتجات

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

يسمّي المؤلفون الطريق الأول «AI-drafting» أو المسودات بالذكاء الاصطناعي. والمنطق بسيط: يُكتب prompt مفصّل يستند إلى توصيات WAI-ARIA APG ويُسلَّم إلى نموذج مثل Claude. والنتيجة DatePicker شبه جاهز يغطي فعلًا معظم المهمة عند الانطلاق. لكن بعد ذلك تظهر مشكلات نادرًا ما تُرى في الإجابة الأولى اللافتة. فاتباع المواصفة حرفيًا قد يتعارض مع سلوك قارئات الشاشة الحقيقية، وتبدأ معالجات مثل onBlur وonClick بالتنازع فيما بينها وتسبب أعطالًا بصرية، أما إعدادات إتاحة الوصول الدقيقة، مثل نمط الإعلان الصوتي عن التغييرات عبر aria-live، فلا يمكن تخمينها دون اختبار حي. وفي النهاية لا يحصل الفريق على بنية مكتملة بقدر ما يحصل على مسودة جيدة يضطر لاحقًا إلى تثبيتها يدويًا.

الطريق الثاني هو الهندسة المنهجية. هنا لا يُكلَّف الذكاء الاصطناعي بمهمة من نوع «اصنع DatePicker»، بل يُوضع داخل حلقة إنتاج مصمَّمة بصرامة. استخدم المؤلفون وكيلًا مستقلًا وفق نهج Ralph يعمل على codex cli ونموذج صغير، لكن العنصر الحاسم لم يكن النموذج بل البيئة المحيطة به.

فقد وُضعت في مجلد العمل الخاص بالوكيل وثيقة PRD بمتطلبات ثابتة، ومجموعة من المهام الذرّية في ملف tasks.json، وقواعد نظام تمنع الانحراف عن البنية المستهدفة. ومن الشروط الإلزامية: واجهة API من نوع controlled-only، وتنقّل كامل بلوحة المفاتيح، وترميز ARIA صحيح.

وبعد كل خطوة كان الكود يمرّ بحلقة تحقق خارجية: اختبارات الوحدات وفحوص a11y عبر Vitest وPlaywright، وبناء Vite، وفحص الأنواع في TypeScript. وما دامت المهمة الحالية لا تجتاز التحقق، لم يكن بوسع الوكيل الانتقال إلى ما بعدها.

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

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

ومن هنا الاستنتاج العملي: المسودات السريعة مناسبة للـ MVP والنماذج الأولية والهاكاثونات والأدوات المؤقتة التي تكون السرعة فيها أهم من الصيانة بعيدة المدى. أما النهج المنهجي فيبرَّر حين يكون المكوّن جزءًا من نظام تصميم أو من نواة المنتج أو من مشروع طويل العمر.

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