اطلب من أداة بناء بالذكاء الاصطناعي ربط تدفق تسجيل دخول عامل — نموذج، تحقق، مسار، فحص قاعدة بيانات — وعادةً ستنتظر ما بين 35 و90 ثانية قبل ظهور أي تغيير. حلّل هذا الطلب من البداية إلى النهاية، وستجد أن النموذج نفسه، الجزء الذي يولّد الرموز فعليًا، يستحوذ على نحو 3 إلى 4 ثوانٍ فقط منه. تضيف رحلات الشبكة ذهابًا وإيابًا 1 إلى 2 ثانية أخرى. أما الثواني الثلاثين المتبقية أو أكثر، وهي الجزء الذي تختبره كـ "تفكير الذكاء الاصطناعي"، فهي في الغالب شيء آخر تمامًا: فريق الوكلاء لديك يقرأ الملفات، يشغّل عملية بناء، ويراجع عمله الخاص قبل أن يعرض لك أي شيء.
تفاجئ هذه النسبة تقريبًا كل من يراها مقاسة لأول مرة، بمن فيهم المهندسون الذين يبنون هذه الأشياء لكسب عيشهم. الحدس السائد هو أن النموذج الأكبر والأبطأ لا بد أن يكون عنق الزجاجة، وبالتالي فإن حل بطء البناء يكمن في نموذج أسرع. هذا صحيح أحيانًا. لكنه غير صحيح في معظم الأحيان، وفهم السبب يغيّر طريقة تفكيرك في حجم الطلب، وحجم المشروع، وما يجب توقعه عندما يبدو البناء وكأنه "متجمد".
ما الذي يملأ الوقت فعليًا
قسّم طلب "أضف ميزة" واحدًا إلى مراحل وسيظهر نمط على الفور: يقضي النموذج وقته في دفعات قصيرة ورخيصة — يقرر الخطوة التالية، يكتب استدعاء أداة، يقرأ نتيجة — بينما تحدث الأجزاء المكلفة والبطيئة بين هذه الدفعات، على القرص وفي الطرفية (shell).
| المرحلة | الحصة النموذجية من إجمالي الوقت | ما الذي يحدث |
|---|---|---|
| استدلال النموذج (التوليد) | 5–10% | الرموز التي يتم إنتاجها — الخطة، الكود، وسيطات استدعاء الأداة |
| قراءة الملفات / تجميع السياق | 10–15% | جلب الملفات الموجودة، وسجل التشغيل السابق، واصطلاحات المشروع |
| تنفيذ الأدوات (الكتابة، الطرفية، تثبيت الحزم) | 35–45% | تغيير الملفات فعليًا، تشغيل أداة فحص الأسلوب (linter)، تثبيت اعتمادية |
| خطوة البناء / التجميع | 15–25% | عمليات بناء إطار العمل، فحوصات الأنواع، التجميع (bundling) — تتوسع مع حجم المشروع، وليس حجم الطلب |
| وكلاء التحقق | 15–20% | مراجعة ثانية للتحقق من أن التغيير يفعل ما طُلب فعليًا قبل عرضه عليك |
| النفقات العامة للشبكة / البث | 2–5% | رحلات الذهاب والإياب بين النموذج، وبيئة العزل (sandbox)، والمتصفح |
يظهر أمران من هذا الجدول لا يكونان واضحين حتى تراهما جنبًا إلى جنب. أولًا، خطوة البناء تتوسع مع حجم المشروع بأكمله، وليس مع حجم طلبك — تعديل CSS من سطر واحد على تطبيق مكوّن من 400 ملف يمكن أن يستغرق وقتًا للتحقق أطول من ميزة مضافة من خمسة ملفات في مشروع جديد، لأن المُجمّع لديه المزيد ليفحصه في كلتا الحالتين. ثانيًا، أكبر رافعة على الإطلاق ليست النموذج مطلقًا. إنها مقدار ما يتم لمسه.
لماذا يستمر هذا الوهم
واجهات البث مسؤولة جزئيًا عن ذلك، بشكل جيد. عادةً ما يظهر الرمز الأول خلال ثانية واحدة، لذا تبدو الواجهة سريعة الاستجابة فورًا — ترى خطة تتشكل، جملة تُكتب، استدعاءات أدوات تمر أمامك. زمن الاستجابة الأول هذا هو ما يسجله الناس ذهنيًا كـ "سرعة الذكاء الاصطناعي". ما لا يرونه بوضوح هو أنه بمجرد أن ينتهي النموذج من تحديد ما سيفعله، فإنه يسلّم المهمة إلى خط أنابيب بناء لا علاقة له بنمذجة اللغة بعد ذلك. عملية `docker build`، أو `npm install`، أو فاحص أنواع يمر عبر رسم بياني للاستيراد — لا شيء من ذلك يصبح أسرع لأن GPT-5 حلّ محل GPT-4، أو لأن Sonnet حلّ محل نسخة أقدم من Sonnet. يصبح أسرع لأن أحدهم خزّن طبقة اعتمادية مؤقتًا أو تخطى فحصًا زائدًا عن الحاجة.
شاهدت بناة يستبدلون النماذج في منتصف المشروع أملاً في إصلاح بناء "بطيء"، مرتين في الأسبوع نفسه، قبل أن يدركوا أن عنق الزجاجة الفعلي كان تمريرة تحقق تعيد تشغيل فحص أنواع كامل مع كل حفظ بدلاً من فحص تراكمي. لم يغيّر استبدال النموذج شيئًا، لأن النموذج لم يكن قط الجزء البطيء.
أين يظهر أثر ذلك فعليًا
تظهر النتيجة العملية في بضعة أماكن يمكن توقعها:
- تبدو الطلبات الكبيرة والممتدة بطيئة بشكل غير متناسب — ليس لأن النموذج يواجه صعوبة في تحليلها، بل لأن طلبًا يمس اثني عشر ملفًا يستدعي اثنتي عشرة عملية قراءة، واثنتي عشرة عملية كتابة، وعملية بناء يجب أن توفّق الآن بينها جميعًا.
- تصبح المشاريع أبطأ في التكرار عليها كلما كبرت، حتى عندما يبقى كل طلب فردي بسيطًا، لأن مراحل البناء والتحقق تتوسع مع الحجم الإجمالي للمشروع.
- "إنه عالق" نادرًا ما يعني أن النموذج متجمد. غالبًا ما تكون خطوة بناء تنتظر سجل حزم، أو وكيل تحقق يعيد تشغيل فحص لم يكن بحاجة لإعادة تشغيله.
- غالبًا ما يكون تقسيم طلب كبير إلى عدة طلبات صغيرة أسرع في الإجمالي، لأن كل طلب أصغر يستدعي عملية بناء أضيق وتمريرة تحقق أخف، حتى لو كنت الآن تنتظر خطوات فردية أكثر.
عبّر أحد الصانعين في Discord الخاص بنا عن ذلك بشكل جيد: "كنت أطلب دماغًا أسرع بينما كل ما احتجته فعليًا هو تغيير أصغر (diff)."
ما الذي يقلّص الانتظار فعليًا
لا يتضمن أي من الحلول الحقيقية نموذجًا أكبر. عمليات البناء التراكمية التي تعيد تجميع ما تغيّر فقط بدلاً من المشروع بأكمله تقلّص حصة مرحلة البناء بشكل كبير — وهذه هي أكبر رافعة متاحة، وغالبًا ما تفوق قيمة كل تحسين آخر مجتمعًا. تخزين عمليات تثبيت الاعتماديات مؤقتًا بين عمليات التشغيل يزيل جزءًا من مرحلة تنفيذ الأدوات لا علاقة له بطلبك المحدد. وتحديد نطاق التحقق ليقتصر على التغيير الفعلي بدلاً من إعادة فحص قاعدة الكود بأكملها في كل مرة يبقي تلك المرحلة متناسبة مع ما تغيّر بدلاً مما هو موجود. وتشغيل استدعاءات أدوات مستقلة بالتوازي — قراءة ثلاثة ملفات غير مترابطة في آن واحد بدلاً من التسلسل — يوفّر ثوانٍ حقيقية من مرحلة إدخال/إخراج الملفات دون المساس بالنموذج على الإطلاق.
لا شيء من ذلك برّاق. وهذا أيضًا هو السبب في أن بانيين يمكن أن يكتبا طلبات متطابقة تقريبًا في المنصة نفسها في اليوم نفسه، وتكون تجربتهما مختلفة تمامًا من حيث مدى "ذكاء" أو "سرعة" ما يشعران به، بينما الفارق الفعلي هو شكل المشروع، وليس جودة النموذج. لم يكن النموذج قط الساعة الحقيقية التي كنت تراقبها. بدا فقط كأنه كذلك.
