Claude و Ralph: نهجان لبناء DatePicker معقد مدعوم بـ AI في تطوير المنتجات

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

المنطق بسيط: خذ رسالة تفصيلية تعتمد على توصيات WAI-ARIA APG وسلمها إلى نموذج مثل Claude. النتيجة هي DatePicker جاهز تقريباً يحل فعلاً معظم المشكلة في البداية. لكن بعد ذلك تظهر مشاكل نادراً ما تكون مرئية في تلك الإجابة الأولى الجميلة.

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

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

json وقواعد نظام تمنع الانحراف عن المعمارية المستهدفة. تضمنت الشروط الإجبارية واجهة برمجية محكومة فقط، ملاحة كاملة بلوحة المفاتيح، وترميز ARIA صحيح. بعد كل خطوة، يمر الكود عبر حلقة تحقق خارجية: اختبارات الوحدة ومدقق a11y عبر Vitest و Playwright، ومراجعة Vite والتحكم في نوع TypeScript.

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

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

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

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

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

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