ثلاثة أسابيع من الانزعاج إلى منتج SaaS: كيف كتب Claude 90% من كود خدمة البحث عن تذاكر الطيران

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

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

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

يستحق الجانب التقني للمشروع وقفة مستقلة. فقد اختار المطوّر عن قصد نهج «كل الكود يكتبه الذكاء الاصطناعي»، وأوكل الجزء الأكبر من التطوير إلى Claude. وبحسب تقديره، أنجز النموذج تسعين بالمئة من المهام، من منطق الـ backend إلى إعدادات DevOps. وليس الأمر مجرد توليد لكود نمطي جاهز، بل بنية معقدة تشمل هندسة عكسية لواجهات API المغلقة لشركات الطيران ومواقع التجميع، وتجاوز أنظمة مكافحة البوتات، وبناء بنية تحتية تحليلية بمقاييس مثل CTR وretention ومسارات التحويل. ثلاثة أسابيع من الصفر إلى منتج يعمل بمستخدمين حقيقيين، وهي وتيرة كانت تتطلب قبل عامين فريقًا صغيرًا وشهرين من العمل.

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

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

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

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