در بیشتر تیم‌هایی که کدنویسی عامل‌محور را به کار می‌گیرند، گلوگاه از تولید به بازبینی منتقل می‌شود و اگر این چرخه اصلاح نشود، افزایش خالص سرعت تقریباً صفر خواهد بود.
در محیط‌های CI در مقیاس بزرگ، با میلیون‌ها آزمون شبانه و صدها مهندس، ارزشمندترین وظیفه عامل مسیریابی بر اساس مالکیت و اولویت‌بندی مشکلات است، نه تولید کد.
خروجی مفید عامل از موشکافی سربلند بیرون می‌آید و به‌جای صرفاً تطبیق الگوها، رابطه علت و معلولی را توضیح می‌دهد.
طراحی لایه گردآوری شواهد و سرهم‌بندی زمینه، از لایه تولید مهم‌تر است.
بیشتر بحث‌ها درباره کدنویسی عامل‌محور هنوز با وعده‌ای ساده آغاز می‌شوند: نوشتن کد بیشتر، با سرعت بالاتر.
گاهی این وعده به چشم‌اندازی بلندپروازانه‌تر گسترش می‌یابد که در آن عامل‌ها کار را برنامه‌ریزی می‌کنند، درخواست ادغام باز می‌کنند و تغییرات را با کمترین مداخله انسانی منتشر می‌کنند. اما برای بیشتر تیم‌های مهندسی، روشن‌ترین ارزش کوتاه‌مدت دامنه محدودتری دارد. این ارزش، کاهش هزینه تکرار و اصلاح است.
تحویل نرم‌افزار فقط تولید کد نیست. نوشتن کد تنها یکی از مراحل چرخه‌ای طولانی‌تر است که بازبینی، آزمون، استقرار و بررسی هنگام بروز مشکل را نیز در بر می‌گیرد. بیشتر تیم‌هایی که بدون بازطراحی چرخه بازبینی به کدنویسی عامل‌محور روی می‌آورند، فقط گلوگاه را به مراحل بعدی منتقل می‌کنند.
صرفاً سریع‌تر کردن تولید، خودبه‌خود سرعت تیم را افزایش نمی‌دهد. این کار ممکن است فقط زحمت بیشتری را به بازبینی، راستی‌آزمایی و اعتمادسازی منتقل کند.
در بسیاری از محیط‌های مهندسی، بخش پرهزینه کار تهیه پیش‌نویس اولیه نیست، بلکه رسیدن به اطمینان است.
آیا این تغییر واقعاً مشکل را برطرف یا سیستم را بهتر کرده است؟ آیا در جای دیگری پسرفت ایجاد کرده است؟ آیا خرابی از کد، محیط، آزمون‌ها یا یکی از وابستگی‌ها ناشی می‌شود؟ آیا راه‌حل پیشنهادی علت را برطرف می‌کند یا فقط نشانه آشکار را؟
عامل‌ها می‌توانند در اینجا کمک کنند؛ نه چون جای مهندسان را می‌گیرند، بلکه چون می‌توانند شواهد آشفته را در گام نخست به‌صورت ساختاریافته بررسی کنند: گزارش‌ها را وارسی کنند، تغییرات اخیر را مقایسه کنند، نشانه‌های مرتبط را خلاصه کنند، علت‌های محتمل را ردیابی کنند، کنترل‌ها را اجرا کنند و نتیجه‌ای ارائه دهند که انسان بتواند آن را موشکافانه بررسی کند.
در بسیاری از تیم‌ها، پربازده‌ترین کاربرد عامل تولید کد از صفر نیست. بلکه پیش از آنکه انسان ساعت‌ها صرف بررسی دستی کند، فضای جست‌وجوی پیرامون مشکل را محدود می‌کند.
این موضوع به‌ویژه در گردش‌کارهای اشکال‌زدایی در مقیاس بزرگ آشکار است. تصور کنید CI شبانه میلیون‌ها آزمون را روی پایگاه‌های کدی اجرا کند که صدها مهندس در آن‌ها تغییر ایجاد کرده‌اند؛ واقعیتی که یکی از مشتریان ما با آن روبه‌رو است. هنگام بروز خرابی، ارجاع آن به تیم مسئول دشوار است. مشکل ممکن است در کد برنامه، یکی از وابستگی‌ها، چارچوب آزمون یا بخش دیگری از پشته باشد. حجم گزارش‌ها ممکن است به چندین گیگابایت برسد و نخستین تیمی که مشکل را می‌بیند، همیشه تیم مسئول آن نیست.
چنین گردش‌کاری ذاتاً به یک عامل برای نوشتن راه‌حل نیاز ندارد. این گردش‌کار برای سیستمی ساخته شده است که فضای مسئله را به‌سرعت محدود کند.
یک خط پردازش مفید می‌تواند گزارش‌ها را دریافت کند، شواهد مرتبط را برگزیند، نکات مهم را خلاصه کند، کد را در محیطی ایزوله بررسی کند و تحلیلی ساختاریافته از علت ریشه‌ای ارائه دهد که شامل امتیاز اطمینان، قابلیت ردیابی و پیشنهاد گام‌های بعدی باشد. برای تولید امتیاز اطمینان، یک متخصص موضوعی خروجی اولیه عامل را ارزیابی می‌کند. سپس این ارزیابی به الگوهای زبانی بزرگ (LLM) در نقش داور داده می‌شود تا امتیازدهی‌های بعدی خودکار شوند و در عین حال با قضاوت انسانی هم‌راستا بمانند.
هدف حذف قضاوت مهندسی نیست، بلکه فراهم کردن نقطه شروعی بهتر برای بازبینان است. اولویت‌بندی پسرفت‌ها، بازبینی درخواست‌های ادغام، اصلاح آزمون‌ها، اعتبارسنجی انتشار و بررسی پس از استقرار، همگی ساختاری مشابه دارند. همگی سرشار از شواهد، نیازمند بازبینی گسترده و آکنده از ابهام‌اند. در این موارد از عامل خواسته نمی‌شود جای فرایند مهندسی را بگیرد؛ فقط باید به پیشبرد آن کمک کند.
به همین دلیل، تیم‌ها باید در شیوه ارزیابی این سیستم‌ها دقت کنند.
پرسش نادرست این است که آیا عامل می‌تواند به‌تنهایی چیزی چشمگیر تولید کند یا نه. پرسش بهتر این است که آیا گردش‌کاری واقعی را بدون ایجاد اصطکاک در جایی دیگر بهبود می‌دهد یا نه.
یعنی باید سنجید که آیا خروجی به‌اندازه کافی مشخص و قابل راستی‌آزمایی است، به‌جای صرفاً تطبیق الگوها رابطه علت و معلولی را توضیح می‌دهد و بازبینی را آسان‌تر می‌کند، نه دشوارتر. پاسخی که معقول به نظر می‌رسد، لزوماً مفید نیست. در عمل، تیم‌ها زمانی به خروجی عامل اعتماد می‌کنند که از موشکافی سربلند بیرون بیاید و چیزی عینی برای بررسی در اختیارشان بگذارد.
درس عمیق‌تر این است که سیستم‌های عامل‌محور مفید، به چیزی بیش از تولید وابسته‌اند. کارایی آن‌ها به نحوه گردآوری شواهد، سرهم‌بندی زمینه، بررسی خروجی‌ها و آشکار کردن عدم قطعیت برای بازبین بستگی دارد.
به همین دلیل، آینده کوتاه‌مدت مهندسی عامل‌محور بعید است جهشی بزرگ به‌سوی خودمختاری کامل باشد. احتمالاً این آینده مجموعه‌ای از چرخه‌های دقیقاً طراحی‌شده خواهد بود که در آن‌ها عامل‌ها به تیم‌ها کمک می‌کنند با اتلاف تلاش کمتر میان مراحل، کارشان را بررسی، بازبینی، راستی‌آزمایی و اصلاح کنند.
شاید این رویکرد از روایت گسترده‌تر خودمختاری هیجان کمتری داشته باشد، اما به شیوه‌ای که سیستم‌های مفید واقعاً پذیرفته می‌شوند بسیار نزدیک‌تر است.