خلال الفترة الماضية تابعت النقاش حول التكاليف “الفلكية” لاستخدام أدوات الـ AI في البرمجة، خصوصاً في ما يُعرف بـ Vibe Coding.
وأحد الأمثلة التي لفتت انتباهي:
5.7 مليون توكن بتكلفة 4.5$ لطلب واحد.
لو حسبناها ببساطة: 10 طلبات يومياً = 45$ ومع استهلاك حقيقي يتراوح بين 30–50 طلب يومياً، نحن نتحدث عن 135$ – 225$ يومياً… أي آلاف الدولارات شهرياً.
لكن بعد تجربة شخصية عميقة، اكتشفت أن المشكلة لم تكن في الأداة أبداً بل فينا نحن.
المشكلة كانت في الـ Context الضخم الذي نلقيه على النموذج.
الحقيقة التي اكتشفتها
كنت أتعامل مع مشاريعي بطريقة Monolith:
أفتح المشروع بالكامل، أرسل مئات الملفات أو آلاف الأسطر دفعة واحدة، وأتوقع من النموذج أن يكون “ذكيًّا” ويستخلص المطلوب.
لكن وفقاً لتوثيقات OpenAI الرسمية، تكلفة الاستخدام تعتمد مباشرة على عدد التوكنز المدخلة والمخرجة، وكلما زاد الـ Context زادت التكلفة بشكل خطي تقريباً.
بل وأكثر من ذلك
أبحاث حديثة من Stanford وMIT حول سلوك النماذج الكبيرة تشير إلى أن أداء النموذج يتدهور تدريجياً مع تضخم السياق، وتبدأ ظاهرة تسمى:
Context Dilution
حيث يفقد النموذج تركيزه على الجزء المهم من المشكلة كلما زادت المعلومات غير الضرورية.
وهذا يفسر لماذا كانت الحلول أحياناً “غير دقيقة” رغم أني أرسلت له كل شيء!
الحل الذي غيّر المعادلة: العزل المعماري (Modular Architecture)
قررت أن أغير طريقة تعاملي بالكامل مع الـ AI.
توقفت تماماً عن فتح المشروع كاملاً أمام النموذج.
بدلاً من ذلك، بدأت أطبق مبدأ Modular Architecture بشكل صارم:
1️⃣ Sub-projects / Packages
كل وحدة في النظام أصبحت مشروعاً مستقلاً:
– مكتبة UI منفصلة وحدة
– منطق الأعمال منفصلة
– طبقة API مستقلة
– أدوات مساعدة كـ Packages خارجية
وأتعامل معها كـ Dependencies، لا كجزء من مشروع ضخم واحد.
2️⃣ بيئات اختبار معزولة
كل وحدة لديها:
– شاشة أو شاشتين لاختبار الـ UI
– Unit Tests خاصة بها
– Mock Data مستقل
بمعنى: يمكنني تشغيلها واختبارها بدون الحاجة إلى النظام كاملًا.
3️⃣ الاستخدام المحدد للـ AI
عندما أحتاج مساعدة في جزئية معينة:
– أفتح فقط مشروع هذه الوحدة.
– أرسل فقط الملفات المتعلقة بها.
– لا شيء أكثر.
ماذا حدث على أرض الواقع؟
✅ النتائج الإيجابية
– انخفاض كبير جداً في عدد التوكنز لأن السياق أصبح صغيراً ومركّزاً.
– سرعة أعلى في الاستجابة (وهذا منطقي لأن زمن المعالجة يتأثر بطول المدخلات).
– دقة أعلى في الحلول لأن النموذج لم يعد “يغرق” في بحر من الأكواد غير المتعلقة بالمهمة.
– قابلية صيانة أفضل وهذا أصلاً جوهر البناء المعياري في الأنظمة القابلة للتوسع.
وتجربتي أثبتت فعلياً أن تقليل السياق بنسبة 70–80% يقلل التكلفة بنفس النسبة تقريباً، لأن التسعير يعتمد مباشرة على حجم التوكنز.
❌ التحديات
لكن دعني أكون صريحاً… هذا الأسلوب ليس سهلاً.
– يتطلب تخطيطاً معمارياً عميقاً في بداية المشروع.
– يحتاج انضباطاً صارماً في إدارة الاعتماديات.
– يجب تصميم Contracts واضحة بين الوحدات (Interfaces / APIs).
– يحتاج عقلية مختلفة تماماً عن عقلية “نفتح المشروع كله ونحل المشكلة”.
الخلاصة التي خرجت بها
الذكاء الاصطناعي ليس مكلفاً بطبيعته.
الطريقة التي نستخدمه بها هي التي تجعله مكلفاً.
إذا تعاملت معه كأنك ترمي عليه مشروعاً كاملاً ليحلّه دفعة واحدة… ستدفع الثمن.
أما إذا تعاملت معه كمهندس يعمل داخل وحدة محددة بوضوح… ستحصل على نتائج أدق، أسرع، وأرخص.
