کدی که ایجنتها مینویسن باید کجا زندگی کنه؟
خلاصهٔ کاملتر
مت ریکارد (Matt Rickard) با یه فرض ساده شروع میکنه: بهزودی هر شرکتی ایجنت خواهد داشت و هر ایجنتی کد مینویسه. سؤال اینه که این همه کد تولیدشده با ایجنت باید کجا نگهداری بشه؟ آمارها هم این انفجار رو نشون میدن: در ۲۰۲۵ حدود یک میلیارد کامیت ثبت شده و حالا سرعتش به ۲۷۵ میلیون کامیت در هفته رسیده.
این کامیتها از کجا میان؟ ابزارهای app builder هوش مصنوعی برای هر پروژه یه مخزن جدید میسازن و هر نوبتِ ایجنت یه کامیت میزنن؛ ایجنتهای sandboxed هر بار که نیاز به اجرای کد دارن از صفر کلون میکنن و برای ذخیرهی وضعیت کامیت میزنن؛ و توسعهدهندهها از کامیت بهعنوان checkpoint ایجنت استفاده میکنن. نکته اینه که این کدها به اون مجموعهی همکاری انسانی که گیتهاب براش بهینه شده نیاز ندارن — ایجنتها رابط کاربری، issue، فید اجتماعی و استار نمیخوان.
چیزی که واقعاً لازم دارن یه لایهی گیت بادوام و برنامهپذیره با سه ویژگی. اول، اعتبارنامهی sandbox: وقتی هزاران مخزن روی تقاضا میسازی، باید بتونی توکنهای دقیق و کوتاهعمر رو همون لحظه بسازی و به ایجنتها بدی. دوم، کلون سریع از صفر: ارائهدهندههای sandbox دارن سر کاهش زمان راهاندازی به میلیثانیه رقابت میکنن، ولی اگه آمادهشدن خودِ کد دهها ثانیه طول بکشه چه فایده. سوم، مخزن روی تقاضا: هر کد تولیدشده یه «پروژه» نیست، ولی بازم به تاریخچه، rollback و یه remote نیاز داره.
ریکارد میگه این مسیر رو توی هر پروژهای تکرار میکرده: ساخت برنامهای مخزن برای کاربر، ساخت یه اعتبارنامهی کوتاهعمرِ محدود به همون مخزن، کلون داخل sandbox، اجازهی کار به ایجنت (Claude یا Codex)، و آخرش commit و push. عمداً نگهش داشته ساده — نه یه سیستم کنترل نسخهی جدید، نه قاتل گیتهاب، بلکه مکمل اون؛ اگه مخزنی همکارانه شد، باید به گیتهاب ارتقا پیدا کنه. همین primitive رو داره با پروژهی corigin.dev میسازه: ساخت مخزن با API، اعتبارنامهی کوتاهعمرِ محدود به مخزن، و remoteهای عادی گیت که داخل sandbox کار میکنن.
نکات کلیدی:
- با فراگیرشدن ایجنتها، حجم کد و کامیت تولیدشده منفجر شده
- کد ایجنتها به امکانات همکاری انسانی گیتهاب (issue، استار، فید) نیاز نداره
- نیاز واقعی: توکنهای کوتاهعمر، کلون سریع و ساخت مخزن روی تقاضا با API
- corigin.dev قراره همین لایه باشه؛ مکمل گیتهاب، نه جایگزینش




