كانت الساعة الثانية صباحًا من يوم الثلاثاء عندما أدركت أن نظام الفوترة يفرض على المستخدمين رسومًا مضاعفة. كان هذا الخطأ (bug) موجودًا في بيئة الإنتاج (production) لمدة ست ساعات. قام Claude Code بإنشاء منطق تسوية المدفوعات في ذلك المساء، وقد راجعته واختبرته ثم أطلقته. بدت الأكواد مثالية، واجتازت كل الاختبارات، لكنها كانت معطلة بشكل أساسي.
هذه هي قصة بناء LemonData: 274 مسار API، و46 نموذج قاعدة بيانات (database models)، وأكثر من 100,000 سطر من الأكواد البرمجية باستخدام مساعد برمجة بالذكاء الاصطناعي. ليست القصة المنمقة حول "انظر كيف يجعلك الذكاء الاصطناعي منتجًا"، بل القصة الحقيقية، بإخفاقاتها، وجلسات تصحيح الأخطاء (debugging) في الثالثة صباحًا، واللحظات التي تساءلت فيها عما إذا كان التطوير المدعوم بالذكاء الاصطناعي فكرة جيدة حقًا.
الوعود مقابل واقع التطوير المدعوم بالذكاء الاصطناعي
الوعود التي يقدمها مساعدو البرمجة بالذكاء الاصطناعي مغرية: تصف ما تريده، يكتبه الذكاء الاصطناعي، تراجعه ثم تطلقه. نظريًا، يمكن لمطور واحد الآن القيام بعمل فريق كامل.
في الواقع؟ كان أول أسبوعين مذهلين. فهم Claude Code قاعدة الأكواد الخاصة بي، وأنشأ ميزات كاملة، وقام بإعادة هيكلة الأكواد (refactoring) عبر ملفات متعددة. كنت أطلق الميزات بسرعة أكبر من أي وقت مضى في مسيرتي المهنية. كانت جرعة الدوبامين الناتجة عن إغلاق المهام بهذه السرعة مذهلة.
ثم بدأت الشقوق في الظهور.
ظهرت نفس الوظيفة (function) في ثلاثة ملفات مختلفة بتنفيذات مختلفة قليلاً. كانت قيم الإعدادات (configuration) مكتوبة بشكل جامد (hardcoded) في أماكن عشوائية. تناقضت تعريفات الأنواع (type definitions) عبر الحزم. كانت قاعدة الأكواد تنمو بسرعة، لكنها كانت تتحول أيضًا إلى متاهة من الأكواد التي "تعمل ولكن لست متأكدًا لماذا".
وماذا عن خطأ الفوترة؟ لقد أنشأ Claude وظيفة تسوية تبدو منطقية تمامًا. لكنها لم تأخذ في الحسبان حالة السباق (race condition) في تدفق تأكيد الدفع غير المتزامن (async) لدينا. لم يكن لدى الذكاء الاصطناعي طريقة لمعرفة تلك الحالة الاستثنائية (edge case) لأنني لم أخبره بها صراحة، كما أن مجموعة الاختبارات، التي تم إنشاؤها جزئيًا بواسطة الذكاء الاصطناعي أيضًا، لم تغطها.
الأنماط السبعة التي استمرت في التسبب بالأعطال
بعد شهر من البناء باستخدام Claude Code، بدأت في الاحتفاظ بقائمة. ليست قائمة بالأخطاء (bugs) تمامًا، بل بالأنماط. كانت نفس أنواع الإخفاقات تتكرر، ولم تكن خطأ Claude، أو على الأقل ليس بالكامل. كانت النتيجة المتوقعة لذكاء اصطناعي يحسن الأداء من أجل "كود يعمل الآن" بدلاً من "كود يعمل غدًا".
1. مشكلة الاتساق (Consistency)
كان Claude ينفذ نفس المنطق بشكل مختلف اعتمادًا على الملف الذي يعمل عليه، أو الأمثلة التي رآها مؤخرًا، أو ببساطة تنوع عشوائي. أحد نهايات API قد تعيد { data: users }، بينما تعيد أخرى { users }. كلاهما يعمل، لكن لا يتطابق أي منهما مع الآخر. أصبح تصحيح الأخطاء (debugging) أشبه بعلم الآثار.
2. مشكلة النسخ واللصق
لماذا يقوم الذكاء الاصطناعي بإنشاء أداة مشتركة (utility) بينما يكون تكرار الكود أسرع ولا يخاطر بكسر الوظائف الحالية؟ في كل مرة طلبت فيها ميزة جديدة تشبه ميزة موجودة، كنت أحصل على تنفيذ جديد بدلاً من حل مشترك معاد هيكلته. بعد ثلاثة أسابيع، كان لدي خمس وظائف مختلفة لـ "تنسيق العملة" منتشرة في قاعدة الأكواد.
3. مشكلة انحراف الأنواع (Type Drift)
تتم إضافة قيمة حالة جديدة إلى ملف واحد ولكن ليس إلى تعريف enum. يصبح الحقل اختياريًا في استجابة API ولكنه مطلوب في نوع frontend. التقط TypeScript بعضًا من هذه الحالات، ولكن ليس حالات عدم التطابق الدلالي، حيث تكون الأنواع صحيحة تقنيًا ولكنها غير متسقة منطقيًا.
4. مشكلة تشتت الإعدادات (Configuration)
عناوين URL لقواعد البيانات، ومفاتيح API، وأعلام الميزات (feature flags)، وحدود المعدل (rate limits) كانت تنتهي في أي مكان مناسب للمهمة الحالية. أحيانًا في متغيرات البيئة (environment variables)، وأحيانًا في ملف إعدادات، وأحيانًا مكتوبة بشكل جامد. أصبح العثور على جميع الأماكن التي تم فيها تحديد قيمة ما بمثابة رحلة بحث عن كنز.
5. وهم تغطية الاختبارات (Test Coverage)
تميل الاختبارات المولدة بالذكاء الاصطناعي إلى اختبار المسار السعيد (happy path) بدقة وتفويت الحالات الاستثنائية (edge cases) تمامًا. كان خطأ الفوترة مثالاً مثاليًا: غطت مجموعة الاختبارات تدفقات الدفع العادية بشكل جميل، لكنها لم تختبر أبدًا ما يحدث عندما يصل تأكيدان للدفع في نفس المللي ثانية.
6. مشكلة الفشل الصامت
كان Claude يضيف كتل catch (error) { console.log(error) } التي تبتلع الاستثناءات. في مرحلة التطوير، بدا هذا جيدًا لأن الأخطاء تظهر في الكونسول. في مرحلة الإنتاج (production)، كانت الإخفاقات الحرجة تُسجل بصمت وتُنسى.
7. فجوة التوثيق
يكتب Claude تعليقات كود ممتازة، لكنه يكتب توثيقًا معماريًا سيئًا. يمكنه شرح ما تفعله الوظيفة، لكنه لا يستطيع شرح سبب هيكلة النظام بهذه الطريقة، أو ما هي القيود التي أدت إلى قرار تصميم معين.
حل CLAUDE.md
جاءت نقطة التحول في الأسبوع الثالث، عندما أنشأت ملف CLAUDE.md في جذر المشروع، والذي يحتوي على كل اتفاقية وقيد وقرار معماري يحتاج Claude لمعرفته.
ليس توثيقًا للبشر، بل توثيقًا للذكاء الاصطناعي.
## API Response Format
Always use: { success: true, data: T } or { success: false, error: string }
Never return raw data without the wrapper.
## Currency
Internal storage: USD. Display: formatCurrency(amount, currency, rate).
Never hardcode exchange rates. Never store CNY directly.
## Error Handling
Never use catch(e) { console.log(e) }.
Always use the logger: logger.error('context', { error }).
كان التأثير فوريًا. بدأ Claude في اتباع الاتفاقيات باستمرار. عندما كان ينشئ كودًا ينتهك قاعدة ما، كنت أوجه نظره إلى السطر المحدد في CLAUDE.md وكان يصحح نفسه تلقائيًا.
لكن CLAUDE.md وحده لم يكن كافيًا. كنت بحاجة إلى فرض آلي.
بناء شبكة الأمان: بوابات CI للأكواد المولدة بالذكاء الاصطناعي
قمنا ببناء خط أنابيب CI مع بوابات قد تبدو مبالغًا فيها في قاعدة أكواد تقليدية، لأنها موجودة لالتقاط الأخطاء المولدة بالذكاء الاصطناعي قبل أن تصل للمستخدمين:
- فحص الأنواع (Type checking) عبر monorepo بالكامل
- عمليات تدقيق SSOT التي تتحقق من عدم وجود تنفيذات مكررة
- فحوصات مزامنة Enum بين enums قاعدة البيانات و TypeScript enums
- التحقق من تنسيق استجابة API
- بوابات أمان لأكواد الفوترة، والأذونات، والمصادقة (authentication)
الفكرة الجوهرية بسيطة: Claude هو مضخم (amplifier) وليس بديلاً. إنه يضخم إنتاجيتك، ولكنه يضخم أخطاءك أيضًا. إذا لم يكن لديك اتفاقيات قوية، فسيخترع Claude اتفاقياته الخاصة، ولن تكون متسقة. إذا لم يكن لديك فحوصات آلية، فستصل أخطاء Claude إلى الإنتاج بشكل أسرع مما قد تفعله الأخطاء البشرية.
لم يعد من الممكن حدوث خطأ الفوترة الآن. ليس لأن Claude أصبح أذكى، ولكن لأن خط الأنابيب يتطلب الآن معالجة صريحة لحالات السباق (race conditions) غير المتزامنة، ويتم التحقق منها بواسطة بوابة تفحص القفل (locking) المناسب في تدفقات الدفع.
ماذا يعني "التطوير الأصيل للذكاء الاصطناعي" (AI Native Development) حقًا
عندما أقول إن LemonData هي "بنية تحتية أصيلة للذكاء الاصطناعي" (AI Native Infrastructure)، فأنا لا أعني أننا أضفنا ميزات ذكاء اصطناعي إلى منتج موجود. أعني أن عملية التطوير بأكملها تشكلت من خلال واقع العمل مع شريك برمجة بالذكاء الاصطناعي.
توثيقنا أكثر تفصيلاً مما قد يكون عليه لولا ذلك، لأن Claude يحتاج إلى سياق صريح قد يستنتجه زميل بشري. نظام الأنواع لدينا أكثر صرامة من اللازم لأن Claude سيستغل أي غموض. يحتوي خط أنابيب CI الخاص بنا على بوابات قد تبدو مبالغًا فيها في قاعدة أكواد تقليدية لأنها موجودة لالتقاط الأخطاء المولدة بالذكاء الاصطناعي قبل أن تصل للمستخدمين.
النتيجة هي قاعدة أكواد أكثر قابلية للصيانة من معظم القواعد التي عملت عليها. ليس لأن الذكاء الاصطناعي يكتب كودًا أفضل من البشر، ولكن لأن البناء من أجل التطوير المدعوم بالذكاء الاصطناعي أجبرني على جعل كل الاتفاقيات والفحوصات التي تعيش عادةً في رؤوس كبار المطورين فقط، صريحة ومكتوبة.
لمزيد من المعلومات حول ما يعنيه AI Native كفلسفة، راجع ما هو AI Native؟
إذا كنت تريد الجانب العملي "كيف أبدأ في تطبيق هذا؟"، فإن أفضل قراءتين تاليتين هما دليل تصميم API الموجه للوكلاء (agent-first) و دليل الهجرة. أحدهما يشرح شكل API، والآخر يوضح مدى سرعة الفريق في تغيير اتجاهه بمجرد تصميم سير العمل للتبديل بين النماذج.
دروس للمطورين الذين يبنون باستخدام مساعدي البرمجة بالذكاء الاصطناعي
إذا كنت تبدأ مشروعًا باستخدام Claude Code أو Cursor أو أي مساعد برمجة بالذكاء الاصطناعي:
- أنشئ ملف
CLAUDE.mdفي اليوم الأول، وليس في الأسبوع الثالث كما فعلت أنا. - أتمتة فرض الاتفاقيات. لا تعتمد على تذكر الذكاء الاصطناعي للقواعد.
- راجع كود الذكاء الاصطناعي وكأن مطورًا مبتدئًا هو من كتبه. إنه سريع وقادر، لكنه يفتقر إلى السياق.
- اختبر الحالات الاستثنائية (edge cases) يدويًا. الاختبارات المولدة بالذكاء الاصطناعي تغطي المسارات السعيدة، وليس حالات السباق (race conditions).
- اجعل الإعدادات مركزية منذ البداية. مشكلة التشتت تتفاقم بسرعة.
- استخدم TypeScript الصارم. إنه أفضل دفاع لك ضد انحراف الأنواع (type drift).
- ابنِ بوابات CI مبكرًا. ستؤتي ثمارها خلال الأسبوع الأول.
هل سأفعل ذلك مرة أخرى؟
بكل تأكيد. لكنني سأبدأ بملف CLAUDE.md في اليوم الأول بدلاً من الأسبوع الثالث. وسأتذكر أن مضاعف الإنتاجية بمقدار 10 مرات يتضمن مضاعفًا بمقدار 10 مرات لعواقب الأخطاء.
المنصة التي بنيناها، أكثر من 300 نموذج ذكاء اصطناعي، و API موحد، وفوترة متعددة العملات، وتدويل بـ 13 لغة، كانت ستستغرق شهورًا من فريق تقليدي. لقد أطلقناها في 30 يومًا. كانت الأخطاء حقيقية، لكن السرعة كانت حقيقية أيضًا.
التطوير المدعوم بالذكاء الاصطناعي ليس سحرًا. إنه نوع جديد من الانضباط الهندسي. ومثل كل التخصصات، فإنه يكافئ أولئك الذين يحترمون قيوده.
الأسئلة الشائعة
هل يمكن لمطور واحد حقًا بناء منصة إنتاج باستخدام Claude Code؟
نعم، ولكن مع تحفظات. يتولى الذكاء الاصطناعي توليد الكود وإعادة الهيكلة بسرعة مذهلة، لكنك لا تزال بحاجة إلى حكم معماري قوي، وبوابات جودة آلية، والانضباط لمراجعة كل شيء بعناية. السرعة المضاعفة 10 مرات تتضمن أخطاء أسرع بـ 10 مرات إذا لم تكن حذرًا.
ما هو CLAUDE.md؟
ملف CLAUDE.md هو ملف تعليمات على مستوى المشروع يقرأه مساعدو البرمجة بالذكاء الاصطناعي للحصول على السياق. يحتوي على اتفاقيات البرمجة، والقرارات المعمارية، والقيود التي يجب على الذكاء الاصطناعي اتباعها. فكر فيه كوثيقة توجيه لزميلك في الفريق المعتمد على الذكاء الاصطناعي.
كيف تمنع الأخطاء المولدة بالذكاء الاصطناعي في بيئة الإنتاج؟
بوابات CI الآلية ضرورية: فحص الأنواع، وتدقيقات SSOT، والتحقق من مزامنة enum، وبوابات الأمان الخاصة بالمجال. الفكرة الأساسية هي أن الذكاء الاصطناعي يضخم الإنتاجية والأخطاء معًا، لذا فأنت بحاجة إلى فحوصات آلية لالتقاط الأخطاء المضخمة.
هل التطوير المدعوم بالذكاء الاصطناعي مناسب لأنظمة الفوترة والدفع؟
نعم، ولكن مع حذر إضافي. يحتاج كود الدفع إلى معالجة صريحة لحالات السباق، وقفل (locking) مناسب، واختبار شامل للحالات الاستثنائية. تميل الاختبارات المولدة بالذكاء الاصطناعي إلى تغطية المسارات السعيدة، لذا يجب عليك اختبار سيناريوهات الفشل والعمليات المتزامنة يدويًا.
تمنحك LemonData إمكانية الوصول إلى أكثر من 300 نموذج ذكاء اصطناعي من خلال API واحد. ابدأ مجانًا واختبر المنصة برصيد 1 دولار.
