کسی AI بلڈر کو کہیں کہ ایک مکمل لاگ ان فلو تیار کرے — فارم، ویلیڈیشن، ایک روٹ، ایک ڈیٹابیس چیک — تو عام طور پر 35 سے 90 سیکنڈز کے درمیان انتظار کرنا پڑتا ہے جب تک کوئی diff نظر آئے۔ اس درخواست کو سرے سے آخر تک پروفائل کریں تو ماڈل خود، وہ حصہ جو دراصل ٹوکنز بناتا ہے، اس میں سے صرف 3 سے 4 سیکنڈز کا حصہ دار ہے۔ نیٹ ورک راؤنڈ ٹرپس مزید 1 سے 2 سیکنڈ کا اضافہ کرتے ہیں۔ باقی 30 سے زیادہ سیکنڈز، وہ حصہ جسے آپ "AI کے سوچنے" کے طور پر محسوس کرتے ہیں، تقریباً مکمل طور پر کچھ اور ہے: آپ کی ایجنٹ ٹیم فائلیں پڑھتی ہے، بلڈ چلاتی ہے، اور آپ کو کچھ دکھانے سے پہلے اپنا کام خود جانچتی ہے۔
یہ تناسب جب پہلی بار ماپ کر دیکھا جائے تو تقریباً ہر کسی کو حیران کر دیتا ہے، بشمول ان انجینئرز کے جو یہ چیزیں بنانے کا کام کرتے ہیں۔ عمومی خیال یہ ہوتا ہے کہ ایک بڑا، سست ماڈل ہی رکاوٹ ہوگا، اس لیے سست بلڈ کا حل یہ ہوگا کہ ایک تیز ماڈل استعمال کیا جائے۔ کبھی کبھار یہ درست ہوتا ہے۔ زیادہ تر ایسا نہیں ہوتا، اور یہ سمجھنا کہ کیوں، اس بات کو بدل دیتا ہے کہ آپ کو پرامپٹ کے سائز، پروجیکٹ کے سائز، اور جب کوئی بلڈ "اٹکا ہوا" محسوس ہو تو کیا توقع رکھنی چاہیے۔
اصل میں وقت کہاں لگتا ہے
ایک "فیچر شامل کریں" کی درخواست کو مراحل میں تقسیم کریں تو فوراً ایک پیٹرن سامنے آتا ہے: ماڈل اپنا وقت مختصر، سستے بہاؤ میں گزارتا ہے — یہ فیصلہ کرنا کہ آگے کیا کرنا ہے، ٹول کال لکھنا، نتیجہ پڑھنا — جبکہ مہنگے، سست حصے ان بہاؤ کے درمیان، ڈسک پر اور شیل میں پیش آتے ہیں۔
| مرحلہ | کل وقت میں عام حصہ | کیا ہو رہا ہے |
|---|---|---|
| ماڈل انفرنس (جنریشن) | 5–10% | ٹوکنز تیار کیے جا رہے ہیں — منصوبہ، کوڈ، ٹول-کال کے دلائل |
| فائل ریڈز / کانٹیکسٹ اسمبلی | 10–15% | موجودہ فائلیں، پچھلی رن کی ہسٹری، پروجیکٹ کے کنونشنز حاصل کرنا |
| ٹول ایگزیکیوشن (رائٹس، شیل، پیکیج انسٹالز) | 35–45% | فائلوں کو دراصل تبدیل کرنا، لنٹر چلانا، ڈیپینڈنسی انسٹال کرنا |
| بلڈ / کمپائل مرحلہ | 15–25% | فریم ورک بلڈز، ٹائپ چیکس، بنڈلنگ — یہ پروجیکٹ کے سائز کے مطابق بڑھتا ہے، پرامپٹ کے سائز کے مطابق نہیں |
| ویری فیکیشن ایجنٹس | 15–20% | دکھانے سے پہلے ایک دوسرا پاس چیک کرتا ہے کہ diff واقعی وہی کرتا ہے جو مانگا گیا تھا |
| نیٹ ورک / سٹریمنگ اوورہیڈ | 2–5% | ماڈل، سینڈ باکس، اور آپ کے براؤزر کے درمیان راؤنڈ ٹرپس |
اس ٹیبل سے دو باتیں سامنے آتی ہیں جو ایک ساتھ دیکھنے سے پہلے واضح نہیں ہوتیں۔ پہلی، بلڈ مرحلہ پورے پروجیکٹ کے سائز کے مطابق بڑھتا ہے، آپ کے پرامپٹ کے سائز کے مطابق نہیں — 400 فائلوں والی ایپ میں ایک سطر کی CSS تبدیلی کو ویری فائی کرنے میں ایک نئے پروجیکٹ میں شامل کی گئی پانچ فائلوں کی فیچر سے زیادہ وقت لگ سکتا ہے، کیونکہ کمپائلر کو دونوں صورتوں میں زیادہ چیز چیک کرنی پڑتی ہے۔ دوسری، سب سے بڑا واحد لیور ماڈل بالکل نہیں ہے۔ یہ اس بات پر منحصر ہے کہ کتنا کچھ چھوا جاتا ہے۔
یہ فریب کیوں قائم رہتا ہے
سٹریمنگ انٹرفیس کا اس میں کچھ حد تک، ایک اچھے انداز میں، ہاتھ ہے۔ پہلا ٹوکن عام طور پر ایک سیکنڈ کے اندر ظاہر ہوتا ہے، اس لیے UI فوری طور پر ریسپانسو محسوس ہوتا ہے — آپ ایک منصوبہ بنتا ہوا، ایک جملہ ٹائپ ہوتا ہوا، ٹول کالز اسکرول ہوتی دیکھتے ہیں۔ وہی پہلا-ٹوکن لیٹنسی ہے جسے لوگ ذہنی طور پر "AI کی رفتار" سمجھتے ہیں۔ جو وہ واضح طور پر نہیں دیکھتے وہ یہ ہے کہ ایک بار جب ماڈل یہ فیصلہ کرنے کا کام مکمل کر لیتا ہے کہ کیا کرنا ہے، تو وہ ایک بلڈ پائپ لائن کے حوالے کر دیتا ہے جس کا اب لینگویج ماڈلنگ سے کوئی تعلق نہیں رہتا۔ ایک `docker build`، ایک `npm install`، ایک ٹائپ-چیکر جو امپورٹ گراف پر چل رہا ہو — ان میں سے کوئی بھی چیز تیز نہیں ہوتی صرف اس لیے کہ GPT-5 نے GPT-4 کی جگہ لے لی، یا Sonnet نے پرانے Sonnet کی جگہ لے لی۔ یہ تیز ہوتی ہے کیونکہ کسی نے ڈیپینڈنسی لیئر کیش کیا یا کوئی فالتو چیک چھوڑ دیا۔
میں نے بلڈرز کو دیکھا ہے کہ وہ کسی "سست" بلڈ کو ٹھیک کرنے کی امید میں پروجیکٹ کے درمیان ماڈل بدل دیتے ہیں، ایک ہی ہفتے میں دو بار، اس بات کا احساس ہونے سے پہلے کہ اصل رکاوٹ ایک ویری فیکیشن پاس تھا جو ہر سیو پر پورا ٹائپ چیک انکریمنٹل کے بجائے دوبارہ چلا رہا تھا۔ ماڈل بدلنے سے کچھ تبدیل نہیں ہوا، کیونکہ ماڈل کبھی سست حصہ تھا ہی نہیں۔
یہ عملی طور پر کہاں مسئلہ بنتا ہے
عملی نتیجہ چند متوقع جگہوں پر ظاہر ہوتا ہے:
- بڑے، پھیلے ہوئے پرامپٹس غیر متناسب طور پر سست محسوس ہوتے ہیں — اس لیے نہیں کہ ماڈل انہیں سمجھنے میں دقت محسوس کرتا ہے، بلکہ اس لیے کہ ایک ایسی درخواست جو بارہ فائلوں کو چھوتی ہے، بارہ فائل ریڈز، بارہ رائٹس، اور ایک ایسا بلڈ متحرک کرتی ہے جسے اب ان سب کو ملانا پڑتا ہے۔
- پروجیکٹس جیسے جیسے بڑھتے ہیں ان پر کام کرنا سست ہوتا جاتا ہے، چاہے ہر انفرادی پرامپٹ سادہ ہی کیوں نہ رہے، کیونکہ بلڈ اور ویری فیکیشن مراحل کا انحصار کل پروجیکٹ کے سائز پر ہوتا ہے۔
- "یہ اٹک گیا ہے" شاذ و نادر ہی ماڈل کے رکنے کی وجہ سے ہوتا ہے۔ یہ تقریباً ہمیشہ ایک بلڈ مرحلہ ہوتا ہے جو پیکیج رجسٹری کا انتظار کر رہا ہے، یا ایک ویری فیکیشن ایجنٹ جو ایک چیک دوبارہ چلا رہا ہے جسے دوبارہ چلانے کی ضرورت نہیں تھی۔
- ایک بڑی درخواست کو کئی چھوٹی درخواستوں میں تقسیم کرنا اکثر مجموعی طور پر تیزی سے مکمل ہوتا ہے، کیونکہ ہر چھوٹی درخواست ایک تنگ بلڈ اور ہلکا ویری فیکیشن پاس متحرک کرتی ہے، اگرچہ اب آپ زیادہ انفرادی مراحل سے گزر رہے ہوتے ہیں۔
ہمارے Discord پر ایک بنانے والے نے اسے اچھی طرح بیان کیا: "میں مسلسل ایک تیز دماغ مانگتا رہا جبکہ مجھے دراصل ایک چھوٹے diff کی ضرورت تھی۔"
اصل میں انتظار کو کیا کم کرتا ہے
حقیقی حل میں سے کوئی بھی بڑے ماڈل کا استعمال شامل نہیں کرتا۔ انکریمنٹل بلڈز جو صرف تبدیل شدہ حصے کو دوبارہ کمپائل کرتے ہیں، پورے پروجیکٹ کے بجائے، بلڈ-مرحلے کے حصے کو نمایاں طور پر کم کر دیتے ہیں — یہ دستیاب سب سے بڑا واحد لیور ہے، اکثر ہر دوسری اصلاح کو ملا کر بھی اس سے زیادہ قیمتی۔ رنز کے درمیان ڈیپینڈنسی انسٹالز کیش کرنا ٹول-ایگزیکیوشن مرحلے کا وہ حصہ ہٹا دیتا ہے جس کا آپ کے مخصوص پرامپٹ سے کوئی تعلق نہیں۔ ویری فیکیشن کو اصل diff تک محدود رکھنا، ہر بار پورے کوڈبیس کو دوبارہ چیک کرنے کے بجائے، اس مرحلے کو اس چیز کے متناسب رکھتا ہے جو تبدیل ہوئی نہ کہ جو موجود ہے۔ اور آزاد ٹول کالز کو متوازی طور پر چلانا — تین غیر متعلقہ فائلوں کو ترتیب کے بجائے ایک ساتھ پڑھنا — ماڈل کو چھوئے بغیر فائل-I/O مرحلے سے حقیقی سیکنڈز بچاتا ہے۔
ان میں سے کوئی بھی چیز شاندار نہیں ہے۔ یہی وجہ بھی ہے کہ دو بلڈرز ایک ہی دن ایک ہی پلیٹ فارم پر تقریباً ایک جیسے پرامپٹس ٹائپ کر سکتے ہیں اور ان کا تجربہ اس بات میں انتہائی مختلف ہو سکتا ہے کہ یہ کتنا "سمارٹ" یا "تیز" محسوس ہوتا ہے، جبکہ اصل فرق پروجیکٹ کی ساخت ہے، نہ کہ ماڈل کا معیار۔ ماڈل کبھی حقیقت میں وہ گھڑی نہیں تھا جسے آپ دیکھ رہے تھے۔ بس ایسا لگتا تھا۔
