تصور کنید برنامه‌نویسی را استخدام کنید که در حالی که روی صندلی‌اش نشسته، تصمیم بگیرد پایه‌های همان صندلی را تعویض کند. این دقیقاً همان اتفاقی است که هفته گذشته در محیط آزمایشگاهی Talon رخ داد.
به گزارش وب‌سایت dev.to، یک عامل (Agent) — شبیه به دستیاری که نه فقط دستور می‌گیرد، بلکه می‌تواند به‌طور مستقل ابزارها را اجرا کند — موفق شد بین ۱۱ تا ۱۷ ژوئیه ۲۰۲۶، سه درخواست تغییر کد (Pull Request) را در کدبیس خودش ادغام کند. این تلاش برای بازنویسی کد در حالی که مدل در حال اجرای همان کد بود، واقعیت آشفته‌ای از «ایستادن روی زمینی که در حال جایگزینی است» را برملا کرد.
زمینه: محیط فعالیت عامل
Talon یک فرآیند عامل‌محور پایدار است که در پس‌زمینه پلتفرم‌هایی مثل تلگرام، دیسکورد، مایکروسافت تیمز و همچنین یک ترمینال فعالیت می‌کند. این سامانه به تجهیزاتی نظیر حافظه اختصاصی، اهداف تعریف‌شده، ضربان قلب پس‌زمینه (background heartbeat) و وظایف زمان‌بندی‌شده (Cron Jobs) مجهز است. در تلاش برای بهینه‌سازی این جریان‌های کاری، ابزارهایی مانند Familiar با هدف حذف فاصله میان ترمینال و IDE معرفی شده‌اند تا بازبینی کد در محیط‌های متنی تسهیل شود.
این سناریو، بحث درباره خودمختاری هوش مصنوعی را از مقالات تئوریک «ایمنی» به میدان عملی توسعه منتقل می‌کند. برای اکثر توسعه‌دهندگان، ایده‌ی عاملی که محیط اجرای (Runtime) خود را تغییر می‌دهد، شبیه به یک کابوس بازگشتی (Recursive) است. با این حال، ساختار Talon با هوش مصنوعی نه به عنوان یک جعبه جادویی، بلکه به عنوان یک همکار غیرقابل‌اعتماد در یک گردش‌کار استاندارد گیت (Git) برخورد می‌کند. عامل از طریق حساب گیت‌هاب خودش مشارکت می‌کند و دقیقاً همان چرخه‌ای را طی می‌کند که هر همکاری انسانی طی می‌کند: ایجاد شاخه (Branch)، ارسال PR، انتظار برای چراغ سبز تست‌ها و در نهایت ادغام به صورت Squash-merge.
بر اساس گزارش‌های منتشر شده، اپراتور سیستم تنها یک دستور کلی و دائمی به عامل داده بود: «باگ‌ها را بگیرید، کد را تمیز کنید و سیستم را مقاوم‌تر کنید». پس از دریافت این دستور، عامل شروع به اصلاح پروژه TypeScript کرد که در آن لحظه دقیقاً در حال اجرا در محیط داخلی بود. این رویکرد خودکار برای پاک‌سازی کد، در تضاد با مدل‌های تجاری جدیدی است که مانند سرویس Slopfix برای بازسازی اپلیکیشن‌های «وایب‌کد شده» هزینه‌های گزافی دریافت می‌کنند.
جزئیات: سه شکست فنی
این فرآیند بازنویسی با سه شکست فنی جدی و آموزنده همراه بود:
اولین وظیفه عامل، حذف یک طرح مسیر قدیمی در سیستم فایل مجازی (VFS) بود. این بخش در واقع یک لایه سازگاری بود که پیشوندهای فضای نام قدیمی را پیش از اجرای دستورات شل (Shell)، به مسیرهای واقعی سیستم فایل تبدیل می‌کرد. عملیات پاک‌سازی شامل حذف شش شاخه بلااستفاده، یک Wrapper قدیمی و یک بخش منسوخ از مستندات بود.
از آنجایی که دیمون (Daemon) فعال سیستم همچنان در حال اجرای کد قدیمی در زمان حذف بود، عامل با علائم «به‌طرز عجیبی گیج‌کننده» مواجه شد:
- بهم‌ریختگی نتایج: اجرای دستور
grepبرای یافتن پیشوندهای قدیمی، داده‌های فاسد و تغییر‌یافته‌ای را برمی‌گرداند. - تغییر فایل‌ها: محتوایی که از طریق heredoc در یک فایل نوشته می‌شد، در هنگام ذخیره تغییر می‌کرد.
- کامیت‌های مخدوش: موضوع یک کامیت خراب شد زیرا پیام آن حاوی همان مسیری بود که در حال حذف شدن بود.
دستوراتی که حاوی رشته‌های مسیر قدیمی بودند، توسط محیط اجرا به‌طور بی‌صدا بازنویسی می‌شدند، در حالی که عامل فعالانه سعی می‌کرد منطقی را که این بازنویسی را انجام می‌داد، حذف کند. عامل مجبور شد برای دور زدن این مشکل، از به‌کار بردن رشته‌های متنی مستقیم در دستورات خودداری کند تا زمانی که دیمون پس از ادغام کد، دوباره ری‌استارت شود.
علاوه بر مسئله VFS، عامل با دو خطای بحرانی دیگر نیز مواجه شد:
- تله‌ی پیوند نمادین (Symlink): مخزن کد به‌طور تصادفی یک پیوند نمادین داخلی به پوشه
node_modulesرا ردیابی کرده بود. عامل این پیوند را از ردیابی خارج کرد و آن را به.gitignoreاضافه نمود. با این حال، وقتی اپراتور یک کامیت قدیمی‌تر را بازگرداند (Checkout)، آن پیوند مسموم بازگشت و پوشه‌ی واقعی را پاک کرد. چون مسیر اکنون نادیده گرفته شده بود، گیت پوشه واقعی را غیرضروری دانست و این منجر به خطاهای گسترده ELOOP شد. در نهایت، عامل یک تست CI برای «بهداشت مخزن» و یک دستورالعمل بازیابی (شامل git rm --cached، بازگردانی هدفمند و soft reset) را در یادداشت‌های خود ثبت کرد. - مدیریت نسخه‌ها (Semantic Versioning): عامل کامیت حذف VFS را با برچسب
refactor!علامت زد. چون این تغییر باعث حذف یک طرح قابل‌مشاهده برای مصرف‌کننده می‌شد، ابزار release-please علامت تعجب را به عنوان یک «تغییر شکننده» (Breaking Change) تفسیر کرد. این اتفاق به‌طور خودکار باعث جهش نسخه اصلی از ۲.x به ۳.۰ شد. عامل بعدها با نگاهی طنزآمیز یادداشت کرد که شماره نسخه‌ها «ابزاری برای ارتباط هستند، نه اعتراف به گناه».
این حوادث فاجعه‌بار نشدند، چون Talon از یک حفاظ سخت‌گیرانه استفاده می‌کند: حدود ۴۰۰۰ تست خودکار، استفاده از Conventional Commits و بررسی‌های اجباری CI برای هر PR. در واقع اعتماد نه به هوش عامل، بلکه به «شفافیت بی‌سیم‌سانی» او و قابلیت رصد اشتباهاتش بود.
این تغییر دیدگاه نشان می‌دهد که پاسخ به چالش اصلاح خودکار کد توسط AI، نه در قفل‌های پیچیده و تخصصی «ایمنی هوش مصنوعی»، بلکه در همان انضباط مهندسی است که تیم‌های انسانی به کار می‌گیرند. وقتی یک عامل از شاخه‌ها، تست‌ها و فرآیندهای بازبینی پیروی می‌کند، به جای اینکه یک فرآیند سرکش باشد، به بخشی قابل‌مدیریت از نیروی کار تبدیل می‌شود.
شما اکنون می‌توانید این تغییرات خاص را در تاریخچه نسخه v3.0.x در مخزن Talon با لایسنس MIT در گیت‌هاب (github.com/dylanneve1/talon) بررسی و ممیزی کنید.
گام بعدی شما
- اگر از عامل‌های خودکار برای کدنویسی استفاده می‌کنید، هرگز اجازه ادغام مستقیم (Direct Merge) را به آن‌ها ندهید.
- برای هر تغییر ساختاری، یک تست CI اختصاصی بنویسید تا اثرات جانبی در محیط اجرا (Runtime) شناسایی شود.
- تاریخچه تغییرات نسخه ۳.۰.x در مخزن Talon در گیت‌هاب را بررسی کنید تا با خطاهای واقعی یک عامل آشنا شوید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.
گفتگو