اگر امروز برای اجرای عامل‌های هوش مصنوعی هزینه می‌پردازید، احتمالاً بخش بزرگی از بودجه شما صرف «جست‌وجوهای کور» مدل می‌شود. آنتون آلمازوف، مهندس نرم‌افزار، استدلال می‌کند که ایجاد یک پیوند مستقیم بین یک نیازمندی و هزینه واقعی آن ضروری است. او معتقد است مدیریت پروژه اغلب به‌جای تصمیمات داده‌محور، بر پایه «احساسات» استوار است.
آلمازوف که متخصص مهندسی نرم‌افزار در PHP/Symfony و Go است، این ناکارآمدی را زمانی کشف کرد که در حال تبدیل یک سیستم یکپارچه (Monolith) قدیمی PHP به سرویس‌های Go بود. او متوجه شد که یک تکرار (Iteration) واحد از یک عامل هوش مصنوعی می‌تواند ۳۵۰,۰۰۰ توکن را صرف شناسایی‌های تکراری و زائد کند، بدون اینکه ردیابی دقیقی از این هزینه وجود داشته باشد. این چالش ردیابی در مقیاس وسیع‌تر نیز دیده می‌شود، به‌طوری که برخی توسعه‌دهندگان با جهش‌های ناگهانی در هزینه‌های مدل‌های مصرفی مواجه شده‌اند که نشان‌دهنده نبود کنترل دقیق بر مصرف منابع است.
از دیدگاه آلمازوف، سیستم ردیاب (Tracker) نباید صرفاً یک ابزار گزارش‌دهی یا یک تشریفات اداری باشد. بلکه تنها مکانی است که در آن یک نیازمندی، یک قرارداد، یک واحد کاری قابل اجرا، یک Pull Request و یک تصمیم پذیرش، همگی در یک رشته (Thread) واحد قرار می‌گیرند. هدف وجود این رشته پاسخ به یک سؤال مشخص است: «این مورد چقدر هزینه داشت؟». سؤال این نیست که آیا تیم مشغول بوده است یا خیر، بلکه سؤال این است که هزینه یک نیازمندی از لحظه‌ای که به زبان آورده شد تا لحظه‌ای که تغییرات پذیرفته شد، دقیقاً چقدر بوده است.
بدون وجود یک تخمین که پیش از شروع کار نوشته شده باشد و یک واقعیت (Fact) که پس از اتمام کار ثبت شود، این سؤال هیچ پاسخی ندارد و تنها «نظرات» باقی می‌مانند. جملاتی مانند «آن تسک گران تمام شد» یا «آن یکی مناسب بود»، صرفاً بازتابی از این است که یک هفته چگونه سپری شده است. در نتیجه، هر بحث درباره محدوده پروژه (Scope)، به بحثی بین دو احساس تبدیل می‌شود.
بسیاری از تیم‌های توسعه برای تخمین کار از Story Point یا پیچیدگی نسبی استفاده می‌کنند. اگرچه این روش برنامه‌نویسان را از تعهدات سخت‌گیرانه ساعتی محافظت می‌کند، اما هزینه واقعی یک ویژگی خاص را پنهان می‌سازد. در دنیای مجریان خودکار (Automated Executors)، این شکاف اجازه می‌دهد نشت‌های عظیم منابع نادیده گرفته شوند؛ زیرا کار از نظر فنی «تکمیل شده» است، حتی اگر به‌شدت ناکارآمد باشد.
نشت ۳۵۰ هزار توکنی و راهکار آن
سیستم آلمازوف یک شکست عینی را آشکار کرد: مجموعه‌های اولیه پرامپت در هر تکرار تقریباً ۳۵۰,۰۰۰ توکن مصرف می‌کردند. تسک‌ها تکمیل می‌شدند و هیچ خطایی رخ نمی‌داد، اما هزینه ثبت شده در کنار تخمین، بسیار فراتر از چیزی بود که تخمین اولیه پیش‌بینی کرده بود. برای مدیریت چنین هزینه‌هایی، ابزارهایی توسعه یافته‌اند که امکان محاسبه مبلغ قبض API را پیش از ارسال پرامپت فراهم می‌کنند تا از شوک‌های مالی جلوگیری شود.
او دریافت که بخش عمده این هزینه صرف «شناسایی» (Reconnaissance) می‌شد. مجری AI برای هر تسک به‌طور مستقل به دنبال انواع داده‌ها (Types)، مسیر فایل‌ها و امضاهای کد در سراسر کدبیس می‌گشت. مدل بسته‌های مجاور را می‌خواند تا بفهمد در آن ناحیه خاص کد، کارها چگونه انجام شده است. این بدان معنا بود که یک حقیقت واحد — مانند نام یک نوع داده خاص، یک امضا یا یک قرارداد کدنویسی — توسط هر مجری که به آن بخش از کد دسترسی داشت، دوباره کشف می‌شد. هزینه یک حقیقت واحد، در تعداد افرادی (یا عامل‌هایی) که به آن نیاز داشتند ضرب می‌شد، زیرا هیچ‌کس آن حقیقت را در جایی که برای دفعات بعد قابل دسترسی باشد، نمی‌نوشت.
برای حل این مشکل، آلمازوف مشخصات (Specifications) خود را به‌روزرسانی کرد تا دو عنصر جدید را شامل شود:
- یک لیست بسته از فایل‌ها برای هر تکرار.
- یک بخش اختصاصی به نام «حقایق مجموعه» (Facts of the set) که در آن هر حقیقت یک‌بار در مشخصات نوشته می‌شود.
او با محدود کردن خواندن به حداکثر سه فایل نام‌گذاری شده و ممنوعیت شدید جست‌وجوی درختی (Tree-searching)، فاز شناسایی تکراری را حذف کرد. این اقدام، وضعیت را از مجری‌ای که صرفاً «کارش را تمام کرد» به «یک نقص در مشخصات که قیمتی روی آن است» تبدیل کرد.
خط پایه: روش‌های معمول صنعت
آلمازوف اشاره می‌کند که رویکرد او با خط پایه معقول شیوه‌های رایج صنعت متفاوت است. در مدل استاندارد، شکل کار معمولاً به این صورت است:
- تخمین: واحدهای انتزاعی پیچیدگی (Story Points) که تعمداً نسبی هستند و نه ساعتی.
- وضعیت: جابجایی در یک بورد (Board) که عمدتاً برای گزارش‌دهی به مدیران استفاده می‌شود.
- بازتاب: یک جلسه رتروسپکتیو در پایان هر تکرار برای بحث درباره کل دوره.
- حوادث: گزارش‌هایی که پس از وقوع در یک Postmortem برای رویدادهای بزرگ نوشته می‌شوند.
دلیل اجتناب از ساعت‌ها در Story Pointها منطقی است: ساعت‌ها باعث می‌شوند تخمین به عنوان یک «تعهد» خوانده شود. همچنین، رتروسپکتیوهای دوره‌ای نمونه مفیدی از یک بازه زمانی ارائه می‌دهند. با این حال، مشکل آلمازوف این است که هیچ‌یک از این چهار روش، عددی را به یک «نیازمندی واحد» متصل نمی‌کنند. آن‌ها اعداد را به یک دوره، یک بورد یا یک قطعی (Outage) متصل می‌کنند.
چارچوب حسابداری چهارگانه
تا تاریخ ۱۶ اوت ۲۰۲۶، سوابق آلمازوف ۲۹۸ فایل مشخصات، بیش از ۲۰ مجموعه بسته شده، ۳ مجموعه در حال اجرا و ۵ مجموعه نوشته شده اما اجرا نشده را نشان می‌دهد. بزرگترین مجموعه واحد شامل ۴۱ فایل است. اندازه مجموعه‌های واقعی برای مقیاس‌بندی به‌شدت متفاوت است و برخی شامل ۱۲، ۱۳ یا ۴۰ تکرار هستند. دانستن این توزیع، تفاوت بین یک تخمین محاسبه‌شده و یک حدس ساده است.
او ردیاب را به عنوان ستون فقرات فرآیند توسعه در نظر می‌گیرد و چهار رویه اجباری را برای هر تسک اعمال می‌کند:
۱. تخمین‌های اجباری
هر تسک پیش از شروع کار، دارای یک تخمین است. مقیاس این تخمین «ساعات زمان مجری» است، به‌طوری که ۱ امتیاز تقریباً برابر با ۱ ساعت اجرای مجری است.
- زمان‌بندی: تخمین قبل از شروع کار تعیین می‌شود، هرگز بعد از آن نه.
- مقیاس: ساعات زمان مجری، نه پیچیدگی انتزاعی.
- تغییرات محدوده: هر تغییر در محدوده به‌طور صریح به عنوان یک ویرایش قابل مشاهده اصلاح می‌شود، نه اینکه به‌طور پنهانی جذب تسک شود.
- استثنائات: این تخمین ساعات انسانی را شامل نمی‌شود؛ بلکه زمان اجرای مدل را تخمین می‌زند، نه نیروی کار انسانی را.
آلمازوف در دفاع از این روش در برابر Story Pointهای سنتی می‌گوید که این مقیاس عملکرد یک شخص را اندازه نمی‌گیرد، بنابراین نمی‌توان از آن به عنوان تعهدی که از یک فرد گرفته شده استفاده کرد. تخمینی که با یک واقعیت در همان واحد مقایسه شود، بسیار ارزشمندتر از تخمینی است که صرفاً برای «امن بودن» در برابر سوءاستفاده طراحی شده است.
۲. انتقال وضعیت آنی
وضعیت تسک در لحظه وقوع انتقال تغییر می‌کند. جریان کاری از یک مسیر سخت‌گیرانه پیروی می‌کند:
شروع کار ────► باز شدن PR ────► پذیرش
اگر تسکی متوقف شود، به یک وضعیت خاص منتقل می‌شود: └──► مسدود شده توسط عامل خارجی. این یک وضعیت نام‌گذاری شده است، نه سکوت. از آنجایی که سکوت و مسدودیت از بیرون یکسان به نظر می‌رسند اما هزینه‌های بسیار متفاوتی دارند، این تمایز حیاتی است.
۳. ثبت لحظه‌ای حوادث
حوادث در لحظه وقوع ثبت می‌شوند و برای هر مورد یک خط اختصاص می‌یابد. آلمازوف از پنج دسته خاص برای شناسایی علت فراتر رفتن تسک از تخمین استفاده می‌کند:
- خطای مجری (Executor error): کار برخلاف مشخصاتی که شفاف بود، اشتباه انجام شد.
- تغییر محدوده (Scope change): نیازمندی پس از تخمین تسک تغییر کرد.
- ابهام در مشخصات (Spec ambiguity): مشخصات اجازه دو برداشت متفاوت را می‌داد و برداشت اشتباه انتخاب شد.
- غافلگیری فنی (Technical surprise): واقعیت با آنچه در مشخصات فرض شده بود متفاوت بود.
- مسدودیت خارجی (External block): پیشرفت به‌دلیل چیزی خارج از این تسک متوقف شد.
نکته حیاتی این است که بازسازی حوادث پس از اتمام کار، خود به عنوان یک «حادثه» ثبت می‌شود. این یک بیانیه درباره کیفیت داده‌ها است: اعدادی که در پایان تسک از حافظه جمع‌آوری می‌شوند، اعدادی هستند که نمی‌توان بر اساس آن‌ها اقدام کرد. عمل جمع‌آوری دیرهنگام داده‌ها، به عنوان همان نقصی ثبت می‌شود که هست.
۴. گزارش‌های نهایی استاندارد
هر تسک با گزارشی در قالبی ثابت بسته می‌شود تا اطمینان حاصل شود که تسک‌ها قابل مقایسه هستند. این گزارش جایگاه‌های مشخصی برای داده‌ها دارد:
- زمان: زمان مجری، زمان انسانی و توقف‌ها.
- منابع: توکن‌ها، هزینه مالی و فراخوانی‌های خارجی. برای کسانی که از چندین مدل مختلف استفاده می‌کنند، استفاده از یک داشبورد واحد برای ردیابی مصرف توکن‌ها می‌تواند دید جامع‌تری نسبت به توزیع هزینه‌ها ارائه دهد.
- متریک‌ها: حوادث، تخمین در مقابل واقعیت و نتیجه نهایی.
کالیبراسیون مشخصات به‌جای قضاوت انسان
آلمازوف پنج سیگنال خاص را شناسایی کرده است که نشان می‌دهد یک تسک «بیش از حد گران» بوده است. هر یک از این موارد به معنای آن است که هزینه کار بیشتر از تخمین بوده است:
۱. نیاز به پرسیدن یک سؤال شفاف‌ساز.
۲. فعال شدن یک قانون که مانع از پیشرفت شد.
۳. دو تکرار مختلف، یک فایل واحد را ویرایش کردند.
۴. یک تکرار پس از پذیرش، دوباره بازنویسی شد.
۵. یک تکرار، بافت متنی (Context) بیشتری نسبت به فایل‌های نام‌گذاری شده‌اش مصرف کرد.
این سیگنال‌ها برای کالیبره کردن «مشخصات» (Specification) به کار می‌روند، نه برای قضاوت درباره عملکرد مجری. برای مثال، یک سؤال شفاف‌ساز به این معناست که یک جمله در متن ابهام داشته است؛ بازنویسی پس از پذیرش به این معناست که معیار آمادگی (Readiness Criterion) اشتباه بوده است. اگر این متریک‌ها به عنوان سیگنال‌های عملکردی درباره کارگر خوانده شوند، ثبت صادقانه متوقف شده و رشته گزارش به داستانی تخیلی تبدیل می‌شود که تولید آن خودش زمان‌بر است.
منطق تعمیر و اصلاح
از آنجایی که تخمین و واقعیت از یک واحد یکسان (ساعات مجری) استفاده می‌کنند، آلمازوف می‌تواند تعیین کند که آیا تبادل برای یک نیازمندی، ارزش هزینه را داشته است یا خیر. دو عدد در واحدهای متفاوت — مانند امتیاز در برابر دلار یا پیچیدگی در برابر مدت زمان — را نمی‌توان بدون یک تبدیل (Conversion) که هیچ‌کس بر سر آن توافق ندارد، مقایسه کرد.
علاوه بر این، دسته‌بندی حوادث، نوع تعمیر مورد نیاز را دیکته می‌کند:
- ابهام در مشخصات: با بازنویسی جمله در متن اصلاح می‌شود.
- خطای مجری: با یک بررسی خارجی اصلاح می‌شود، نه با درخواست برای «دقت بیشتر».
- تغییر محدوده: به‌طور صریح و قابل مشاهده در تخمین اصلاح می‌شود.
- غافلگیری فنی: در بخش «حقایق» اصلاح می‌شود تا مجموعه‌های بعدی این دانش را به ارث ببرند.
- مسدودیت خارجی: با تبدیل انتظار به یک وضعیت «مرئی» اصلاح می‌شود، به‌جای اینکه در سکوت منتظر بمانیم.
ضریب و هزینه
یک مجری خودکار، حسابداری را ارزان می‌کند. اعداد را می‌توان استخراج کرد و بدون تایپ دستی در گزارش گنجاند. با این حال، اتوماسیون نمی‌تواند تصمیم بگیرد چه چیزی «حادثه» محسوب می‌شود، تخمین چه باید می‌بود یا یک شکست به کدام دسته تعلق دارد. این‌ها «قضاوت» هستند و ارزش رشته گزارش در همین قضاوت‌ها نهفته است. اندازه‌گیری ارزان، هر کسی را که تعاریف را تعیین کرده تقویت می‌کند، اما خودش تعاریف را ارائه نمی‌دهد.
این سطح از حسابداری رایگان نیست. این سیستم روی هر تسک، حتی اصلاحات کوچک، مالیات می‌گذارد و همین باعث می‌شود اولین چیزی باشد که تیم‌ها در فشار ددلاین‌ها رها می‌کنند. وقتی ددلاین نزدیک است، حسابداری دقیقاً در زمانی حذف می‌شود که داده‌ها بیشترین کاربرد را دارند. بازسازی دیرهنگام، اعدادی غیرقابل اعتماد تولید می‌کند، به همین دلیل است که به عنوان یک «حادثه» طبقه‌بندی می‌شود، نه یک به‌روزرسانی.
آلمازوف اشاره می‌کند که این مقیاس به تیم‌های انسانی قابل انتقال نیست؛ استفاده از «یک امتیاز ≈ یک ساعت اجرای مجری» برای انسان‌ها، همان مشکلاتی را بازتولید می‌کند که Story Pointها برای حل آن‌ها طراحی شده بودند. او همچنین سه سناریو را شناسایی کرده که در آن‌ها این فرآیند باید نادیده گرفته شود:
- تغییرات یک‌باره (One-off): هفت فیلد حسابداری برای یک اصلاح تک‌خطی، صرفاً تشریفات است.
- تسک‌های بدون معیار آمادگی: اگر چیزی برای پذیرش وجود ندارد، رشته گزارش پایانی ندارد و گزارش درباره یک تسک پذیرفته نشده، گزارش درباره «هیچ» است.
- فرآیندهای موجود: جایی که وضعیت (Status) در حال حاضر معنای متفاوتی دارد — مانند یک نقطه عطف قراردادی یا وضعیت صورت‌حساب — بارگذاری بیش از حد آن، سیستم اصلی را می‌شکند.
هشدار صادقانه
این یافته‌ها بر اساس تسک‌های شخصی آلمازوف به عنوان یک متخصص تک‌نفره است و هیچ نمونه آماری از تیم‌های چندنفره پشت این داده‌ها نیست. علاوه بر این، نیازمندی‌ها توسط همان شخصی فرموله می‌شوند که مالک تسک است. این روش در این مقیاس کوچک جواب می‌دهد، اما این یک محدودیت شناخته شده است، نه یک اصل طراحی.
این رویکرد تمرکز را از «آیا همه مشغول بودند» به «این نیازمندی خاص از لحظه بیان تا لحظه پذیرش چقدر هزینه داشت» تغییر می‌دهد.
برای کسانی که عامل‌های AI را در محیط تولید (Production) پیاده‌سازی می‌کنند، گام حیاتی بعدی، حرکت از «مشاهده یک فرآیند» به «گیت کردن» (Gating) آن است — یعنی اطمینان از اینکه یک مرحله تا زمانی که بررسی‌های لازم انجام نشود، قابل عبور نباشد.
گفتگو