تصور کنید مدیر فنی تیمی هستید که ۹۴٪ کدهای پروژه را هوش مصنوعی نوشته، اما در تاریخچه گیت‌هاب، نام یک نفر به عنوان نویسنده تمام خطوط ثبت شده است. این وضعیت باعث می‌شود درک دلیل یک تصمیم فنی یا محاسبه هزینه واقعی توسعه عملاً غیرممکن شود. در واقع، یک توسعه‌دهنده تنها می‌تواند در یک روز چهار عامل مختلف را روی شش مدل متفاوت اجرا کند، که این امر باعث می‌شود ستون «نویسنده» (Author) در گیت‌هاب به دلیل حذف جزئیات، به یک دروغ تبدیل شود.
Origin که در ۷ اکتبر ۲۰۲۶ عرضه شد، با بازطراحی صفحه مخازن کد، پاسخ سوالاتی را می‌دهد که در گردش‌کارهای عامل‌محور (Agentic) حیاتی هستند: کدام مدل کد را نوشت، هزینه آن چقدر بود و چه پرامپتی باعث تولید این خطوط شد؟
سیستم‌های کنترل نسخه سنتی برای دنیایی ساخته شده بودند که انسان‌ها هر خط را می‌نوشتند و دلیل آن را به یاد داشتند. اما در مخازن مدرن که به شدت متکی به AI هستند، این موضوع دیگر صادق نیست. برای مثال، در یکی از مخازنی که توسط Origin مدیریت می‌شد، ۹۳.۹٪ کدها توسط عامل‌ها نوشته شده بود، در حالی که سهم انسان‌ها تنها ۰.۸٪ بود. این تغییر، یک شکاف دیدبانی عظیم ایجاد می‌کند که در آن «چه کسی» کامیت کرده، بسیار کم‌اهمیت‌تر از «چگونه» و «به چه قیمتی» است.
زمینه مخازن عامل‌محور
گیت‌هاب فایل‌ها، کامیت‌ها و افراد را نشان می‌دهد. زمانی که انسان‌ها کد می‌نوشتند، این تصویر درست بود. اما اکنون، شخصی که در ستون نویسنده قرار دارد، احتمالاً فقط یک پرامپت تایپ کرده و دکمه اینتر را زده است. صفحه گیت‌هاب هنوز از نظر فنی درست است، اما به سوالات اشتباه پاسخ می‌دهد.
گیت‌هاب به شما می‌گوید چه کسی کد را Push کرده است، اما نمی‌گوید کدام عامل کد را نوشته، از چه مدلی استفاده شده، چه پرامپتی باعث تحریک آن شده، هزینه عملیات چقدر بوده یا عامل در مسیر تصمیم‌گیری به چه نتایجی رسیده است. همچنین، گیت‌هاب نمی‌تواند نشان دهد که عامل چه بخش‌هایی را ناتمام رها کرده است.
Origin صفحه مخزن را بازسازی می‌کند تا به این سوالات خاص پاسخ دهد. این ابزار عمداً ساختار گیت‌هاب را آینه می‌کند — از همان تب‌ها، درخت فایل‌ها و لیست کامیت‌ها استفاده می‌کند — تا هیچ منحنی یادگیری جدیدی برای کاربر ایجاد نشود. با این حال، هر نما (View) اکنون زمینه AI را در لایه بالایی خود حمل می‌کند.
ردیابی هزینه‌های هوش مصنوعی
Origin یک نوار وضعیت در سطح بالا معرفی می‌کند که مالکیت کد را بین عامل‌ها و انسان‌ها تقسیم می‌کند. در نمونه نمایش داده شده، این تقسیم‌بندی به این صورت است: Claude ۹۳.۹٪، Cursor ۳.۸٪، Codex ۱.۵٪ و انسان ۰.۸٪. این اعداد از طریق ثبت واقعی جلسات (Session Captures) اندازه‌گیری شده‌اند و نه از طریق حدس زدن بر اساس پیام‌های کامیت.
این پلتفرم شامل یک نقشه حرارتی (Heatmap) آشنای مشارکت‌ها است، اما با یک تغییر کلیدی: هر مربع بر اساس عاملی که در آن روز کامیت‌ها را انجام داده، رنگ‌آمیزی شده است. این قابلیت به تیم‌ها اجازه می‌دهد دقیقاً روزی را که از کدنویسی دستی به مدیریت عامل‌ها تغییر مسیر دادند، تجسم کنند.
در پایین نقشه حرارتی، یک کارت امتیاز (Scorecard) برای توجیه هزینه‌های AI قرار دارد. این کارت موارد زیر را ردیابی می‌کند:
- تعداد کل کامیت‌ها
- خطوط اضافه شده
- تعداد جلسات کاری
- هزینه هر کامیت
- مقدار کدهایی که بعداً بازگشت (Revert) داده شدند
- مقدار کدهایی که در بازبینی (Review) رد شدند
در این مخزن خاص، Claude تعداد ۳,۸۲۱ کامیت با هزینه متوسط ۵.۱۸ دلار برای هر مورد انجام داده است، در حالی که Cursor تعداد ۱۲۲ کامیت با هزینه ۰.۰۲ دلار و Codex تعداد ۸۲ کامیت با هزینه ۰.۵۱ دلار ثبت کرده‌اند. این داده‌ها هنگام تصمیم‌گیری برای اینکه کدام عامل را برای وظیفه بعدی منصوب کنیم یا تعیین اینکه آیا هزینه AI با خروجی به‌دست آمده متناسب است یا خیر، حیاتی هستند.
انتساب دقیق کد (Granular Attribution)
Origin قابلیت استاندارد git blame را با یک سیستم گروه‌بندی مبتنی بر پرامپت جایگزین کرده است. در یک مخزن که توسط عامل‌ها نوشته شده، blame سنتی تقریباً بی‌فایده است زیرا نام یک نفر (پرامپت‌نویس) روی تمام خطوط ظاهر می‌شود.
سیستم blame در Origin خطوط را بر اساس پرامپتی که آن‌ها را نوشته گروه‌بندی می‌کند. هر بلوک، عامل و مدل (مثلاً Claude, Opus 5)، شخصی که آن را اجرا کرده و شماره پرامپت را شناسایی می‌کند.
کاربران می‌توانند با نگه داشتن نشانگر روی هر خط، متن دقیق پرامپت را ببینند؛ مثلاً پرامپتی مانند «آن‌ها را ادغام کن، cli را منتشر کن و مستقر کن» و کامیت دقیقی که این کد در آن قرار گرفته است. هدر فایل یک خلاصه سطح بالا ارائه می‌دهد: برای مثال، یک فایل ممکن است ۱۰۰٪ توسط Claude در دو مدل مختلف نوشته شده باشد، توسط دو شخص اجرا شده و به PR #1977 مرتبط باشد.
نکته حیاتی این است که هدر نشان می‌دهد چند جلسه کاری پشت یک فایل بازبینی شده است. اگر از ۵ جلسه، ۰ مورد بازبینی شده باشد، سیستم آن را به عنوان یک منطقه پرریسک در کدبیس علامت‌گذاری می‌کند که هیچ انسانی واقعاً آن را نخوانده است. برای جلوگیری از چنین ریسک‌هایی، برخی تیم‌ها از قلاب‌های گیت برای کنترل خروجی‌های AI استفاده می‌کنند تا از تخریب ناگهانی مخزن جلوگیری شود.
افزایش دید‌پذیری فایل‌ها و کامیت‌ها
- درخت فایل‌ها (File Tree): مشابه گیت‌هاب عمل می‌کند، اما هر پوشه نشان می‌دهد چه مقدار از آن توسط AI نوشته شده و هزینه کل آن چقدر است. هر فایل، عامل، شخص اجراکننده، هزینه و قدمت را نمایش می‌دهد. این به مدیران اجازه می‌دهد «پوشه‌ای که بودجه را بلعیده» را در چند ثانیه پیدا کنند.
- پنل About: به جای یک توضیحات ایستا، این بخش به یک «خلاصه تداوم» (Continuation Brief) تبدیل شده است. این پنل ردیابی می‌کند که آخرین جلسات روی چه چیزی کار کرده‌اند، چه مواردی در حال حاضر در جریان است و چه چیزهایی ناتمام مانده است.
- لیست کامیت‌ها: استایل گیت‌هاب را حفظ می‌کند اما عامل و مدل را به هر کامیت اضافه می‌کند و پرامپت را مستقیماً زیر عنوان لیست می‌کند. کاربران می‌توانند بر اساس عامل یا مدل فیلتر کنند یا مستقیماً پرامپت‌ها را جستجو کنند. کوئری‌هایی مانند «کامیت جایی که خواستیم فاصله زمانی همگام‌سازی را تغییر دهد پیدا کن» به یک جستجوی ساده تبدیل می‌شود، نه یک پروژه باستان‌شناسی در تاریخچه کد.
حل مشکل فراموشی عامل‌ها (Agent Amnesia)
یکی از بزرگ‌ترین موانع در گردش‌کارهای عامل‌محور این است که هر جلسه معمولاً از صفر شروع می‌شود. عامل‌ها اغلب کدها را دوباره می‌خوانند و همان باگ‌های قبلی را دوباره کشف می‌کنند زیرا فاقد حافظه مشترک از تصمیمات قبلی هستند. در تیم‌هایی با چندین عامل و انسان، این تکرار در تمام طول روز اتفاق می‌افتد.
Origin یک «خلاصه تداوم» را پیاده‌سازی کرده است که در git notes (در مسیر refs/notes/origin-memory) ذخیره می‌شود. این کار تضمین می‌کند که حافظه همراه با کد جابه‌جا شود و به‌صورت آفلاین نیز کار کند. پس از هر جلسه، Origin موارد زیر را ثبت می‌کند:
- چه کاری انجام شد
- چه تصمیمی گرفته شد و چرا
- چه مواردی هنوز باز هستند
این حافظه توسط عامل بعدی از طریق CLI یا سرور MCP (پروتکل زمینه مدل) خوانده می‌شود، فارغ از اینکه مدل چه باشد. این قابلیت اجازه می‌دهد Claude دقیقاً از جایی شروع کند که Codex متوقف شده بود. این رویکرد مکمل ابزارهایی مانند CodeGraph MCP است که با رفع کورسوزی عامل‌ها، درک عمیق‌تری از ساختار مخازن بزرگ را فراهم می‌کند.
تب Memory به انسان‌ها اجازه می‌دهد این سوابق را مشاهده کنند. لیست تصمیمات، هر انتخاب را به جلسه اصلی‌اش لینک می‌کند و زمانی که یک توسعه‌دهنده می‌پرسد «چرا کد این رفتار عجیب را دارد»، پاسخ را فراهم می‌کند. تب History نیز اجازه می‌دهد کاربران حافظه را در هر تاریخ خاصی بازخوانی کنند.
ردیابی خودکار مسائل (Issue Tracking)
عامل‌ها مکرراً «سرنخ‌های رها شده» در لاگ‌های چت می‌گذارند، جملاتی مانند «این مورد هنوز نیاز به بررسی در ویندوز دارد»، «هنوز مستقر نشده» یا «داده‌های قدیمی هنوز غلط هستند». معمولاً این متون در لاگ‌هایی دفن می‌شوند که هرگز دوباره باز نمی‌شوند.
Origin به‌طور خودکار این موارد باز را به Issueهای مخزن تبدیل می‌کند. این Issueها شامل موارد زیر هستند:
- سطور اولویت
- جلسه‌ای که این مورد را ایجاد کرده است
- تگ‌های [Verify] برای بررسی‌هایی که عامل صراحتاً گفته است یک انسان باید انجام دهد
این Issueها زمانی که یک جلسه بعدی کار را به پایان برساند، به‌طور خودکار بسته می‌شوند. این فرآیند، تک‌گویی‌های داخلی عامل را به یک بک‌لاگ (Backlog) قابل مشاهده و عملی تبدیل می‌کند که عامل بعدی نیز از طریق حافظه مشترک آن را می‌بیند.
این تغییر در ابزارها نشان می‌دهد که «منبع حقیقت» در مهندسی نرم‌افزار از خودِ کد به سمت پرامپت‌ها و تصمیماتی که آن را تولید کرده‌اند در حال حرکت است. وقتی ۹۴٪ از یک کدبیس مصنوعی است، پرامپت تبدیل به اثر (Artifact) واقعی می‌شود.
برای مدیران مهندسی، این بدان معناست که شغل اصلی از بازبینی کد به حسابرسی عملکرد عامل‌ها و بودجه تغییر می‌کند. ریسک دیگر فقط یک باگ در منطق نیست، بلکه یک «نشتی بودجه» در پوشه‌ای است که هزاران دلار توکن مصرف می‌کند بدون اینکه یک ویژگی کاربردی تحویل دهد.
برای شروع، یک مخزن گیت‌هاب یا گیت‌لب را در getorigin.io متصل کنید و CLI را نصب کنید تا تاریخچه را از جلسات موجود پر کنید.
گفتگو