وقتی Codex گیت را شکست: OpenAI چطور Pando را ساخت و Anthropic چطور گیت را ول کرد
نویسنده: آرش لطیفی
OpenAI گیت را نگه داشت و بکاندش را از نو نوشت (Pando)، Anthropic پنج ماهه به سیستم اختصاصی خودش (Scion) مهاجرت کرد — مقایسهی دو راهحل برای یک مشکل واحد: حجم کار ایجنتهای کدنویس.
TL;DR — در دو هفتهی اخیر دو پست مهندسی بزرگ منتشر شد: OpenAI با Pando بکاند گیتش را بازنویسی کرد (تأخیر median پوش ~۵ برابر کمتر، نزدیک یک پتابایت دادهی گیت در روز) و Anthropic پنج ماهه مونوریپو را از گیت به Scion برد (۳۰,۰۰۰ merge در روز) — هر دو چیز مشترکی برای پروژههای کوچک دارند، ولی نه جادویشان را.
مشکل واقعاً چیست
برای چند دهه «اسکیل» یعنی چه کار کردی که گیت باتجاربه کند — و گیت هم همیشه جواب داد. حالا دو شرکت که بیشترین حجم ایجنت کدنویس روی زمین را دارند، تقریباً همزمان اعلام کردند گیتِ سرو شده دیگر جواب نمیدهد. اعداد خودشان:
- OpenAI: از اواخر سال گذشته سیستمی که مونوریپو را سرو میکرد زیر فشار رفت — fetch و push کند، mergeهای شکسته، و قابلیت اطمینان گاهی زیر ۹۰٪. دلیلش Codex است: یک مهندس حالا چند تغییر همزمان آمادهی CI دارد و هر push چند job را بیدار میکند که همان commit را fetch کنند.
- Anthropic: در مه ۲۰۲۶ بهطور میانگین حدود ۲,۵۰۰ تغییر merge شده در روز؛ تا سپتامبر از ۳۰,۰۰۰ گذشت. تاریخچهی برنچ main بهتنهایی تقریباً ۱۰۰ گیگابایت است و روزانه حدود ۲۵ میلیون checkout فقط برای CI انجام میشود — که بهشکل خام یعنی بیش از ۶۰۰ پتابایت ترافیک گیت در روز.
نکتهی ظریف هر دو پست یکی است: گلوگاه دیگر نوشتن کد نیست؛ زیرساخت دوران «انسان-مقیاس» است.
دو پاسخ متفاوت به یک مشکل
| | OpenAI — Pando | Anthropic — Scion | | --- | --- | --- | | رویکرد | بکاند جدید، سازگار با پروتکل و کلاینت گیت | VCS کاملاً جدید، مهاجرت کامل از گیت در ۵ ماه | | سازش اصلی | سازش با «سازگاری لحظهای کل ریپو» — causal consistency | بیخیال مدل توزیعشدهی گیت — همهچیز سمت سرور | | نتیجهی سرانگشتی | تأخیر median پوش ~۵x کمتر؛ ~۱ پتابایت دادهی گیت در روز | footprint زیرساخت ۲۰۰x کوچکتر؛ checkout دو مرتبه بزرگی سریعتر (ثانیه به جای دقیقه) | | تیم | هسته توسط یک مهندس طراحی، پیادهسازی با تیمهای ایجنت — ۱۰ هفته تا production | تیم ۷ نفره، همراه code review و code search و IAM |
Pando چه میکند: بهجای اینکه برای هر کلاینت یک packfile اختصاصی بسازد (که CPU و I/O سنگین و تقریباً غیرقابل کش است)، packfileهای رسیده از pushها را نگه میدارد و همان بایتها را به همهی خوانندهها سرو میکند. برای fetch از قابلیت کمترشناختهشدهی پروتکل گیت به نام packfile-uri استفاده میکند — سرور یک packfile خالی inline میفرستد و لینک دانلود بقیهی packها را جدا میدهد؛ OpenAI برای همین به خود گیت آپستریم کانتریبیوت کرده. برای مقیاسپذیری نوشتن هم سازش کلیدی این است: خوانندهی چند برنچ نمیتواند فرض کند همهی برنچها را در یک لحظهی واحد میبیند — فقط ترتیب آپدیتِ تک-ref تضمین شده. پکها هم مثل LSM-tree در سطحهای L0 تا L4 در پسزمینه compact میشوند تا کلاینتِ عقبمانده مجبور نباشد دهها هزار فایل دانلود کند.
Scion چه میکند: کل مدل برعکس است — کلاینت تقریباً هیچ محاسبه و کش محدودی دارد؛ commit و merge و diff همه سمت سرور انجام میشود. واحد کار «changeset» است: بهجای pointer به کل tree، فقط لیست فایلهای تغییرکرده نسبت به والد اول را ذخیره میکند با pointerهای content-addressed به blob storage. چون هیچ data دائمیای تغییر نمیکند، هر سرور میتواند بیهماهنگی کش کند. مذاکرهی fetch هم مثل گیت نیست: کلاینت نمیگوید چه دارد، مستقیم tree و blobهای missing را آبشاری میخواهد — هر درخواست برای یک آبجکت تغییرناپذیر است، پس هر کشی جواب میدهد. حتی packfile وجود ندارد که نگهداری بخواهد.
چیزهایی که برای پروژهی کوچک تو بهدرد میخورد
هیچکدام از اینها را فردا روی GitLab خودت پیاده نمیکنی — خود Anthropic هم صریح میگوید Scion «جایگزین مناسبی برای گیت در استفادهی عمومی نیست». ولی سه درس قابل حمل هست:
۱. packfile-uri را جدی بگیر. اگر Git سرور خودش托管 میکنی، این قابلیت استاندارد پروتکل اجازه میدهد بستههای بزرگ از CDN یا آبجکت استوریج جدا سرو شوند — همان ترفندی که Pando بهصورت انحصاری استفاده میکند و آپستریم گیت هم بهبودهایش را گرفته.
۲. Content-addressed caching سادهترین اسکیل است. ایدهی مشترک هر دو سیستم: آبجکت تغییرناپذیر = کش بینهایت بدون هماهنگی. این اصل در CI خودت هم کار میکند (کش بیلد بر اساس hash ورودیها، نه timestamp).
۳. تعداد commit معیار کیفیت نیست. زیر پست OpenAI بحث HN داغ بود (۲۴۵ امتیاز)؛ یکی از کامنتهای پرتکرار این بود که حجم عظیم commit عمدتاً «slop، و slop برای تعمیر slop» است — ایجنتها commitهای ریز و تکراری میسازند و پایهی کد متورم میشود، و کد متورم یعنی کانتکست گرانتر برای هر ایجنت بعدی. برای تیم کوچک معنایش این است که squash و PRهای معنادار هنوز ارزش دارند، حتی وقتی ایجنت دارد کد مینویسد.
- [ ] کش بیلد/ریپو در CIات بر اساس hash ورودیهای تغییرناپذیر باشد، نه timestamp
- [ ] زنجیرههای commit ریزِ ایجنت را قبل از merge با squash به PR معنادار تبدیل کن
- [ ] چک کن گیت هاستت
packfile-uriرا ساپورت میکند (یا CDN جلوی packهای بزرگ)
و یک درس فرآیندی: Anthropic میگوید نقش اصلی مهندسها در پروژهی Scion این بود که به Claude «نه» بگویند — جلوی over-engineering و نقض قیود معماری را بگیرند. review همچنان روی تغییرها انجام میشود، ولی روی قصد تغییر، نه خط به خط.
Q: Pando و Scion در دسترس عموم هستند؟
نه هنوز. OpenAI گفته «دنبال راههایی برای اشتراک تکنولوژی Pando با کاربرانمان هستیم» و به همکاری با جامعهی متن-باز گیت ادامه میدهد (از جمله کانتریبیوتهای packfile-uri). Anthropic صریحاً گفته Scion را عرضه عمومی نمیکند چون به code review و CI و IAM اختصاصی خودش گره خورده.
Q: آیا گیت مرده؟
خیر — برعکس، هر دو شرکت روی سازگاری یا ارثیهی گیت تأکید کردهاند. OpenAI آگاهانه پروتکل و کلاینت گیت را نگه داشت؛ Anthropic هم میگوید ایدههای Scion را میشود داخل اکوسیستم گیت پیاده کرد (RPC سمت سرور، پروتکل مذاکرهی بهتر، sparse/shallow بهتر). برای هر ریپویی که نه مونوریپوی ۱۰۰ گیگابایتی است و نه ۳۰,۰۰۰ merge در روز دارد، گیت همان ابزار درست است.
Q: اگر تیم کوچکی و از ایجنت کدنویس استفاده میکنم، کی باید نگران شوم؟
وقتی نشانههای خود OpenAI را ببینی: کند شدن fetch/push، mergeهای مدام شکسته، و CIای که صف میشود چون دهها job همان commit را fetch میکنند. تا آن موقع، بهداشت ریپو (پکهای کوچک، squash، آینهی سبک) کافی است — به قول Anthropic، «این مشکلات فقط برای مونوریپوهای واقعاً عظیم معنا دارند»، هرچند حدسشان این است که در ۶ تا ۱۲ ماه آینده رایجتر شوند.