تصور کنید برنامه‌نویسی که دیگر منتظر دستورات تک‌تک شما نمی‌ماند، بلکه خودش می‌داند هدف نهایی پروژه چیست و هر روز صبح لیست کارهای لازم برای رسیدن به آن را به‌روز می‌کند. این دقیقاً همان تغییری است که در Imprint رخ داده تا عامل‌های هوش مصنوعی از نقش «دستیار» به نقش «مدیر پروژه» ارتقا یابند. استراتژی جدید اتوماسیون در این شرکت، عامل‌های AI را از پذیرنده‌های ساده‌ی وظایف به مدیران مستقل پروژه تبدیل کرده است. آن‌ها به‌جای ارسال پرامپت‌های پراکنده برای هر زیر-وظیفه، از الگوی «کارخانه نرم‌افزار» استفاده می‌کنند تا عامل‌ها به‌جای انتظار برای دستورات دستی، روی اهداف کلان پروژه در یک چرخه مداوم فعالیت کنند.
زمینه: چرخه پذیرش ۲۰۲۶
به گزارش lethain.com در ۲۰ سپتامبر ۲۰۲۶، این گذار نتیجه‌ی تکامل سریع گردش‌کارهای هوش مصنوعی در طول سال ۲۰۲۶ است. Imprint برای حذف گلوگاه‌های انسانی در توسعه نرم‌افزار، یک مسیر مهاجرتی تهاجمی را طی کرد:
- ژانویه: هر یک از مهندسان شرکت شروع به استفاده روزانه و مداوم از Claude Code کردند. این ابزار در واقع بخشی از استراتژی گسترده‌تر آنتروپیک برای تبدیل دستیارهای چت به موتورهای ارکستراسیون است تا مدیریت پروژه‌های پیچیده تسهیل شود.
- مارس: دامنه استفاده گسترش یافت و Claude Cowork برای تمامی کارکنان به صورت روزانه به کار گرفته شد.
- آوریل: برای حل گلوگاه‌های توسعه محلی که توسط مدل checkout و worktree ایجاد شده بود، Imprint حدود ۱۰ فضای کاری محلی (local workspaces) ایجاد کرد. هر یک از این فضاها دارای یک checkout مستقل از تمام مخازن بود. این زیرساخت به عامل‌ها اجازه داد تا درخواست‌های ادغام (Pull Request) متقاطع را در سراسر مونو-ریپوزیتوری‌های فرانت‌اند، بک‌اند، زیرساخت و داده ایجاد کنند.
- ژوئن: شرکت یک «توقف سخت» (hard stop) برای Jira اجرا کرد و کل سازمان را به Linear منتقل نمود. هدف از این کار کاهش پیچیدگی مجوزهای دسترسی و افزایش شفافیت برای توسعه‌های مبتنی بر عامل بود.
- ژوئیه: Imprint یک سیستم ارکستراسیون به نام Agent Fleet را مستقر کرد. این سیستم با الگوبرداری از «Minions» در شرکت Stripe طراحی شده بود تا مدیریت بلیت‌های پیش‌پاافتاده‌ای را که در محیط توسعه محلی قابل مدیریت نبودند، در مقیاس وسیع اجرا کند.
این پیشرفت‌ها نشان‌دهنده یک نیاز رو به رشد در صنعت برای سیستم‌های مدیریت وظایف مشترکی است که عامل‌های AI بتوانند بدون برخورد با گلوگاه‌های مربوط به مجوزهای انسانی، در آن‌ها پیمایش کنند.
جزئیات: الگوی کارخانه نرم‌افزار
این سازوکار بر اساس الگوی «کارخانه نرم‌افزار» (Software Factory) عمل می‌کند که احتمالاً نخستین بار توسط جاستین مک‌کارتی در فوریه ۲۰۲۶ در مقاله‌ای با عنوان «کارخانه‌های نرم‌افزار و لحظه عامل‌محور» معرفی شد. این الگو به صورت یک حلقه مداوم عمل می‌کند. در Imprint، این پیاده‌سازی بر روی یک مهارت خاص از عامل به نام /linear-project-loop متکی است که در چهار مرحله مجزا عمل می‌کند:
- بازرسی هدف (Goal Auditing): عامل ابتدا به دنبال یک سند RFC در Notion می‌گردد که اهداف، روش‌های اندازه‌گیری و رویکرد کلی پروژه را توصیف کرده باشد. همچنین بررسی می‌کند که آیا داشبوردهای Datadog یا کوئری‌های Snowflake برای سنجش موفقیت پروژه وجود دارد یا خیر.
- پر کردن شکاف‌ها (Gap Filling): اگر اهداف یا ابزارهای رصد موجود نباشند، یا اگر پروژه در Linear اصلاً ایجاد نشده باشد، عامل با کاربر انسانی وارد گفتگو می‌شود تا این موارد را ایجاد کند.
- مدیریت وظایف (Task Management): عامل معیارها و مسائل را در Linear بررسی کرده و بر اساس وضعیت فعلی پروژه، کارهای جدید می‌افزاید یا بلیت‌های موجود را به‌روز می‌کند.
- اجرا (Execution): عامل وظایفی را که مسدود نشده‌اند (non-blocked) مدیریت می‌کند؛ کارهایی مانند نوشتن Pull Requestها، به‌روزرسانی آن‌ها یا ارسال پیام به هم‌تیمی‌ها برای بازبینی کد.
پس از اتمام هر وظیفه، عامل بررسی می‌کند که آیا توصیفات پروژه هنوز به‌روز هستند یا خیر. اگر مستندات قدیمی شده باشند، عامل کل چرخه را از مرحله بازرسی هدف دوباره آغاز می‌کند تا همراستاسازی (Alignment) با آخرین اهداف تضمین شود.
این رویکرد مشکل بحرانی «انحصار وضعیت» (state hoarding) در ذهن مدیران انسانی را حل می‌کند. پیش از این، عامل‌ها می‌توانستند روی بلیت‌های خاصی تکرار و اصلاح کنند، اما دید لازم برای اینکه بدانند آیا کل پروژه در جهت درست حرکت می‌کند یا خیر را نداشتند. با اجبار عامل به بازرسی RFC و معیارها، «وضعیت» پروژه بیرونی شده و قابل تایید است.
برای یک توسعه‌دهنده، این یعنی هوش مصنوعی اکنون می‌تواند نگهداری پس از انتشار (post-release maintenance) را بر عهده بگیرد. برای مثال، پس از پیاده‌سازی Passkeys، ممکن است یک انسان تا چندین ماه به آن پروژه نگاه نکند. اما عاملی که در حالت «پس از انتشار» با فرکانس پایین اجرا می‌شود، می‌تواند جهش در پذیرش کاربران یا افزایش نرخ خطا را رصد کند و پس‌رفت‌هایی (regressions) را شناسایی کند که احتمالاً از چشم انسان دور می‌ماند.
با این حال، این الگو یک ابزار مستقل نیست، بلکه یک قابلیت ترکیبی است. این سیستم نیازمند یک استک فنی خاص است: Linear به عنوان منبع واحد حقیقت (Single Source of Truth)، دسترسی به Datadog MCP و Snowflake برای رصد اهداف، و یک سیستم ارکستراسیون که قادر باشد مستقل از لپ‌تاپ محلی کاربر اجرا شود.
باید منتظر بود و دید آیا تیم‌های مهندسی دیگر نیز به سمت این استقلال «حلقه-محور» حرکت می‌کنند یا خیر، زیرا این رویکرد به معنای پایان عصر «پرامپت و پاسخ» برای مهندسی نرم‌افزارهای پیچیده است.
گام بعدی شما
- اگر از ابزارهای مدیریت پروژه استفاده می‌کنید، سعی کنید اهداف را در قالب RFCهای متنی دقیق بنویسید تا برای عامل‌های AI قابل فهم باشند.
- زیرساخت‌های رصد (مانند داشبوردهای متریسی) را به عنوان بخشی از تعریف «پایان کار» در پروژه بگنجانید.
- بررسی کنید آیا گردش‌کارهای شما اجازه می‌دهد یک عامل بدون تایید دستی، بلیت‌های کوچک را در سیستم مدیریت پروژه جابه‌جا کند یا خیر.
این تحول نشان می‌دهد که عصر «پرامپت و پاسخ» برای مهندسی نرم‌افزارهای پیچیده به پایان رسیده است؛ اما اثر این اتوماسیون بر ساختار تیم‌های مهندسی حتی تکان‌دهنده‌تر است — به تحلیل ما درباره‌ی آینده نقش مدیران محصول مراجعه کنید.
گفتگو