تصور کنید حجم کدهای پروژه شما ۱۰ برابر شود چون عامل‌های هوش مصنوعی هرگز نمی‌خوابند و شبانه‌روز کد می‌زنند. در چنین دنیایی، سیستم‌های سنتی بازبینی کد که برای گفتگو میان دو انسان طراحی شده‌اند، به سرعت فرو می‌پاشند. وقتی نویسنده کد یک قطعه نرم‌افزار است، شما دیگر به یک محیط چت نیاز ندارید، بلکه به یک سیستم زمان‌بندی و تأیید (Verification) نیاز دارید.
طبق گزارش‌های داخلی Cursor، در حال حاضر ۳۵ درصد از درخواست‌های ادغام (Pull Request) که در این ویرایشگر پذیرفته می‌شوند، توسط عامل (Agent) — شبیه به دستیاری هوشمند که می‌تواند به‌طور مستقل ابزارها را مدیریت کند — در ماشین‌های مجازی ابری ایجاد شده‌اند. این تغییر بنیادین در نحوه تولید نرم‌افزار، دلیل اصلی عرضهٔ Origin در ۱۷ اوت ۲۰۲۶ است.
برای دو دهه، انتخاب محل ذخیره کد برای مدیران فنی یکی از بی‌اهمیت‌ترین تصمیمات بود و گیت‌هاب (GitHub) به پیش‌فرض مطلق تبدیل شد. اما وقتی عامل‌ها از نوشتن تکه‌های کوچک کد به مدیریت کامل شاخه‌های ویژگی (Feature Branches) می‌رسند، زیرساخت‌های فعلی برای بازبینی و ادغام کد به یک گلوگاه تبدیل می‌شوند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، هرچه اتوماسیون بیشتر شود، نیاز به سیستم‌های تأیید دقیق‌تر جایگزین گفتگوهای انسانی می‌شود. این چالش‌های امنیتی در محیط‌های اتوماتیک را می‌توان در بررسی رخنه امنیتی پروژه OpenClaw که ناشی از اولویت دسترسی بر ایزوله‌سازی بود، مشاهده کرد.
زمان‌بندی عرضه و اتفاقات عجیب
عرضهٔ Origin با یک اتفاق عجیب و کنایه‌آمیز همراه بود. در صبح ۱۷ اوت ۲۰۲۶، درست سه ساعت و نیم پس از فعال‌سازی این سرویس برای کاربران پولی، گیت‌هاب دچار اختلالی جهانی شد که حدود ۷ ساعت به طول انجامید. در این بازه، نرخ خطای درخواست‌های ادغام، گزارش مشکلات (Issues) و API به حدود ۲۰ درصد رسید. وضعیت دانلود فایل‌های خام و آرشیوها بدتر بود و نرخ خطا به ۵۰ درصد نزدیک شد. همچنین سیستم‌های ورود یکپارچه سازمانی (Enterprise SSO) و Copilot نیز با شکست مواجه شدند.
مت پالمر از Cursor در این باره گفت: «قصد داشتیم زودتر منتشرش کنیم، اما گیت‌هاب قطع بود.» اگرچه برخی ممکن است به زمان‌بندی این اتفاق مشکوک شوند، اما معمولاً زمان عرضه محصولات هفته‌ها قبل تثبیت می‌شود. با این حال، این اتفاق به عنوان یک نمایش زنده از استدلال اصلی Origin عمل کرد: اینکه لایه میزبانی کد دوباره به یک مسئله حیاتی و جذاب تبدیل شده است. این رقابت تنگاتنگ را در مقایسه جامع Origin و گیت‌هاب که هم‌زمان با این اختلال جهانی تحلیل شد، بیشتر بررسی کرده‌ایم.
معماری و ساختار Origin
Origin یک میزبان گیت (Git Forge) است که در آدرس origin.cursor.com قرار دارد و به‌صورت یک تب بومی به نام Codebase در ویرایشگر Cursor نمایش داده می‌شود. کاربران می‌توانند نام یک پایگاه کد (Codebase name) را رزرو کنند که این نام بخشی از URL هر مخزن می‌شود (مثلاً cursor.com/codebase/acme-corp). ارسال مخازن از طریق پروتکل استاندارد گیت روی HTTPS انجام می‌گیرد.
جزئیات فنی و دسترسی به این سرویس به شرح زیر است:
- ابزارها: یک ابزار خط فرمان (CLI) اختصاصی به نام
originبرای احراز هویت و مدیریت امور فراهم شده است. این ابزار شامل دستورorigin apiاست که بر اساس مدلgh apiطراحی شده و به نقطه انتهایی REST در api.cursor.com اشاره می‌کند. - دسترسی: سرویس در مرحله بتای اولیه است و در اشتراک‌های پولی Cursor گنجانده شده؛ هیچ قیمت جداگانه‌ای برای آن وجود ندارد، طرح رایگانی در نظر گرفته نشده و در حال حاضر از مخازن عمومی (Public Repositories) پشتیبانی نمی‌شود.
- مدیریت سازمانی: برای مدیران سازمانی، این سرویس به‌طور پیش‌فرض فعال است، هرچند امکان غیرفعال کردن آن برای کل سازمان وجود دارد.
- سازگاری: در حال حاضر از ویندوز به‌صورت بومی پشتیبانی نمی‌شود و کاربران برای استفاده از CLI باید از WSL استفاده کنند.
- قابلیت‌های CLI: این ابزار چرخه کامل Pull Request، از جمله بازبینی‌ها، رشته‌های کامنت، ادغام و نسخه‌های اسنپ‌شات PR را پشتیبانی می‌کند. همچنین مدیریت کلیدهای SSH، ایجاد مخازن آینه‌ای از گیت‌هاب و تعریف قوانین برای زمان ادغام و ارسال (Merge-time/Push-time rulesets) را بر عهده دارد.
استراتژی نفوذ: گوه گیت‌هاب
Cursor از تیم‌ها نمی‌خواهد که کل تاریخچه کدهای خود را یک‌شبه منتقل کنند. در عوض، آن‌ها یک مکانیسم استراتژیک «همگام‌سازی با گیت‌هاب» (GitHub sync) را پیاده کرده‌اند:
- کاربران سازمان گیت‌هاب خود را متصل کرده و مخازن خاصی را آینه (Mirror) می‌کنند.
- مخازن آینه‌ای در کنار مخازن بومی Origin ظاهر شده و به‌صورت لحظه‌ای به‌روز می‌شوند.
- کامنت‌های Pull Request در هر دو طرف در عرض چند ثانیه منتقل می‌شوند.
- گیت‌هاب برای هر پروژه‌ای که در آنجا شروع شده، همچنان «منبع حقیقت» (Source of Truth) باقی می‌ماند.
این طراحی یک نقطه ورود با اصطکاک کم ایجاد می‌کند. Cursor امیدوار است با ارائه یک سطح بازبینی برتر در داخل ویرایشگر، توجه برنامه‌نویسان به سمت خود جلب کند و در نهایت سیستم ثبت اصلی را بی‌اهمیت سازد. توماس رایمرز در Hacker News صادقانه پذیرفت که Origin فعلاً از نظر قابلیت‌ها با گیت‌هاب برابر است و گفت: «امروز، تقریباً هیچ چیز اضافه‌ای نیست. ما عمداً این را به عنوان جایگزینی برای گیت‌هاب عرضه کردیم تا در زمینه قابلیت‌ها شانه به شانه با آن‌ها پیش برویم.»
زیرساخت بومی برای عامل‌ها (Agent-Native)
اگرچه نسخه بتا معمولی به نظر می‌رسد — با ارائه تایم‌لاین، تاریخچه کامیت‌ها، بررسی وضعیت و کامنت‌های سطح Diff — اما منطق زیربنایی آن برای عامل‌ها ساخته شده است. Origin قابلیت «درخواست‌های ادغام پشته‌ای» (Stacked PRs) را از استارتاپ Graphite — که در دسامبر ۲۰۲۵ خریداری شد — به ارث برده است. در زمان خرید، Cursor اشاره کرد که مرز بین نوشتن کد و همکاری روی آن «به‌طور فزاینده‌ای قراردادی و بی‌معنا» شده است.
این میراث به عامل‌ها اجازه می‌دهد چندین PR را به‌صورت زنجیروار به هم متصل کنند که توسط یک صف ادغام آگاه از پشته (Stack-aware merge queue) پشتیبانی می‌شود. توماس رایمرز، هم‌بنیان‌گذار Graphite و اکنون مدیر Origin، این محصول را در کنفرانس Compile در ژوئن ۲۰۲۶ رونمایی کرد.
عامل‌ها در Origin اکنون می‌توانند:
- روی PRهای خود مشترک شوند و هنگام شکست خوردن یک تست یا دریافت کامنت از بازبین، به‌طور خودکار بیدار شوند.
- بر اساس نظر بازبین، کد را در همان PR اصلاح کنند.
- به‌طور مستقل و با استفاده از مهارت‌های داخلی ویرایشگر، مخازن جدید ایجاد و ارسال کنند.
به نقل از توماس رایمرز، هدف نهایی رسیدن به ویژگی‌های «عامل‌محور» است؛ یعنی اتوماسیونی که PRها را بدون دخالت انسان به وضعیت قابل ادغام برساند. او یک گردش‌کار داخلی برای حل تداخلات توصیف کرد که در آن عامل در درخت کاری (Worktree) خود کار می‌کند و خروجی را به صف ادغام می‌فرستد؛ اگر تداخلی رخ دهد، صف آن را برای حل به عامل برمی‌گرداند. رایمرز نوشت: «حل تداخلات توسط عامل از طریق صف ادغام در عمل بسیار خوب جواب می‌دهد» و اشاره کرد که به دلیل افزایش سرعت تغییرات، این سیستم تقریباً ضروری است.
اکوسیستم یکپارچه‌سازی
Origin با شرکای خاصی عرضه شده تا تیم‌ها مجبور به بازنویسی خط لوله‌های ساخت (Build Pipelines) خود نباشند:
- Vercel: استقرار پیش‌نمایش (Preview Deployments) برای هر PR فراهم می‌کند و پس از ادغام، کد را به محیط تولید می‌فرستد.
- Depot و Buildkite: خدمات یکپارچه‌سازی مداوم (CI) را ارائه می‌دهند. نکته حیاتی این است که هر دو می‌توانند گردش‌کارهای موجود GitHub Actions را بدون هیچ تغییری اجرا کنند.
ارتباط با اسپیس‌اکس (SpaceX)
زمان عرضه این محصول با یک تغییر مالکیت بزرگ هم‌زمان شد. در ژوئن ۲۰۲۶، شرکت SpaceX در قراردادی ۶۰ میلیارد دلاری (به صورت سهام)، شرکت Anysphere (مالک Cursor) را تصاحب کرد. این قرارداد در ۱۴ اوت نهایی شد و Origin را به نخستین محصول منتشر شده توسط یکی از زیرمجموعه‌های اسپیس‌اکس تبدیل کرد.
این مالکیت لایه‌ای از پیچیدگی را برای پذیرندگان سازمانی اضافه می‌کند. VentureBeat به شکاف‌های موجود در مستندات منتشر شده درباره سیاست‌های حفظ داده‌ها، معماری امنیتی، سیاست‌های استفاده از داده‌ها برای آموزش مدل‌ها و ابزارهای خروجی (Export) اشاره کرده است. برای شرکتی که اکنون متعلق به یک آزمایشگاه مدل‌های پیشرو و یک غول فضایی است، گزینه «opt-out» پیش‌فرض برای Origin جزئیاتی است که افسران امنیتی به‌دقت بررسی خواهند کرد.
تقابل با غول مستقر: چالش‌های گیت‌هاب
GitHub سال دشواری را پشت سر گذاشته است. تحلیل‌ها نشان می‌دهد بین مه ۲۰۲۵ تا آوریل ۲۰۲۶، حدود ۲۵۷ حادثه در گیت‌هاب رخ داده که ۴۸ مورد آن «بزرگ» طبقه‌بندی شده‌اند. حتی GitHub Actions به تنهایی ۵۷ بار در یک سال شکست خورد. مدیر فنی (CTO) گیت‌هاب اذعان کرده است که پلتفرم باید برای ۳۰ برابر بار فعلی طراحی شود.
این ناپایداری‌ها پیش از این پروژه‌هایی مانند Zig و Ghostty را به سمت جایگزین‌هایی مانند Codeberg سوق داده است. حتی گزارش‌هایی وجود دارد که OpenAI پس از آنکه قطعی‌ها مانع از ارسال کد توسط مهندسانش شد، شروع به ساخت جایگزین داخلی کرده است.
پاسخ گیت‌هاب، سرویس Agent HQ است که سعی می‌کند عامل‌های شخص ثالث را روی پلتفرم فعلی مدیریت کند. اما Origin، عامل‌ها را به‌عنوان شهروند درجه یک زیرساخت می‌بیند.
با این حال، GitHub هنوز برتری عظیمی در عمق اکوسیستم دارد. گیت‌هاب CI بومی، بازار گسترده‌ای از افزونه‌ها و ابزارهای سازمانی تکامل‌یافته‌ای مانند SAML، SCIM، لاگ‌های حسابرسی (Audit logs)، CODEOWNERS و حفاظت از شاخه‌ها (Branch protections) را ارائه می‌دهد که Origin در حال حاضر فاقد آن‌هاست یا مستند نکرده است. گیت‌هاب دارای ۱۸ سال اثرات شبکه‌ای است که یک بتای محدود در یک ویرایشگر نمی‌تواند به راحتی با آن رقابت کند.
جمع‌بندی نهایی
برای اکثر تیم‌ها، منطقی‌ترین حرکت در حال حاضر اجرای موازی هر دو سیستم است. با آینه‌سازی یک مخزن، می‌توانید تست کنید که آیا بازبینی کد داخل ویرایشگر سرعت شما را بالا می‌برد یا خیر، بدون اینکه منبع اصلی کدتان را به خطر بیندازید. این شرط‌بندی به‌گونه‌ای طراحی شده که قابل بازگشت است.
اگر روند کدهای نوشته شده توسط عامل‌ها ادامه یابد — و گزارش Octoverse گیت‌هاب نشان می‌دهد ماهانه ۴۳.۲ میلیون PR ادغام می‌شود که ۲۳ درصد رشد سالانه دارد — میزبان (Forge) که بتواند ریتم تولید نرم‌افزار را مدیریت کند، پیروز خواهد شد. تحلیلگران از همین حالا ویژگی‌هایی مانند سوابق منشأ (Provenance records) برای کامیت‌های عامل‌ها و سطوح بازبینی سازمان‌یافته بر اساس «قصد» (Intent) به جای Diffهای خام را درخواست می‌کنند. اگرچه نسخه «قاتل گیت‌هاب» از Origin با این دسترسی‌های دقیق برای عامل‌ها هنوز عرضه نشده، اما فرضیه آن‌ها درست است. Cursor ابزار نفوذ درست و پشتیبانی مالی قدرتمندی دارد؛ حالا فقط باید چشم‌انداز کامل «زیرساخت بومی عامل‌ها» را به واقعیت تبدیل کند.
گام بعدی شما
- اگر کاربر پولی Cursor هستید، یک مخزن غیرحساس را در Origin آینه کنید تا تجربه بازبینی بومی را بسنجید.
- بررسی کنید آیا گردش‌کارهای CI فعلی شما با Depot یا Buildkite سازگار است یا خیر.
- در تنظیمات سازمان، سطح دسترسی‌های Origin را با سیاست‌های امنیتی شرکت خود تطبیق دهید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو