تصور کنید در تیمی هستید که هر چه می‌خواهید ساخته می‌شود، اما کسی که دستور می‌دهد و تایید می‌کند، یک انسان نیست. در ۷ اکتبر ۲۰۲۶، توسعه‌دهنده IssueFlow — ابزاری برای سازماندهی گردش‌کار عامل‌های هوش مصنوعی — نشان داد که چگونه می‌توان کل چرخهٔ یک درخواست ویژگی را به زنجیره‌ای از عامل‌های خودمختار سپرد.
بیشتر ابزارهای کدنویسی فعلی شبیه به یک «تکمیل‌کنندهٔ پیشرفته» هستند؛ یعنی کد را می‌نویسند و منتظر می‌مانند تا انسان آن را بررسی کند. اما در این آزمایش، مرز دخالت انسان جابه‌جا شد؛ حالا انسان دیگر کد را بررسی نمی‌کند، بلکه تصمیم می‌گیرد چه کسی «اختیار» تایید نهایی را دارد.
این سیستم در واقع یک تیم نرم‌افزاری کوچک است که در آن کسی برای هماهنگی جلسه نمی‌گذارد، اما همه می‌دانند چه می‌خواهند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، سپردن اختیار به مدل‌ها همیشه ریسک دارد، اما در اینجا هدف، تست کردن مفهوم «تمام شدن» (Done) توسط هوش مصنوعی بود.
داستان از جایی شروع شد که توسعه‌دهنده از ChatGPT برای مدیریت یک کمپین بازاریابی (GTM) استفاده می‌کرد. او می‌خواست در حالی که شغل تمام‌وقت دارد، مشتریان جدید جذب کند. طبق گزارش منتشر شده، عامل بازاریابی متوجه یک نقص شد: کاربران روی تبلیغات کلیک می‌کردند، اما مشخص نبود بعد از آن چه اتفاقی می‌افتد. چون حل این مشکل نیاز به تغییر در کد داشت، عامل بازاریابی خودش شروع به ایجاد «تیکت‌های توسعه» کرد.
به جای اینکه به برنامه‌نویس خبر دهد، عامل بازاریابی مستقیماً در IssueFlow درخواست‌ها را ثبت کرد. سپس زنجیره‌ای از عامل‌های تخصصی فعال شدند:
- عامل‌های تریاژ (Triage Agents): درخواست‌ها را دسته‌بندی و جریان کار را شروع کردند.
- عامل‌های طراحی (Design Agents): پیاده‌سازی فنی را پیشنهاد دادند.
- عامل‌های بازبینی طراحی (Design-Review Agents): معماری پیشنهادی را چک کردند.
- عامل‌های بازطراحی (Design-Rework Agents): درخواست‌های پیچیده را که در مرحله اول شکست خورده بودند، اصلاح کردند.
- عامل‌های بازبین (Review Agents): نقص‌های امنیتی و اعتبارسنجی را بررسی کردند.
نقطه عطف این آزمایش در «دروازه تایید» رخ داد. در حالت عادی، انسان کد را می‌بیند و تایید می‌کند. اما چون عامل بازاریابی خودش درخواست را نوشته بود و می‌دانست دقیقاً چه می‌خواهد، توسعه‌دهنده به او اختیار داد تا طرح‌ها را تایید یا رد کند. این یک حلقه بسته ایجاد کرد: یک عامل درخواست می‌دهد، بقیه می‌سازند و همان عامل اول بررسی می‌کند که آیا مشکل حل شده یا نه. این رویکرد خودکارسازی در شناسایی و ثبت خطاها، یادآور سیستم عامل‌های AIPass است که با ارسال ایمیل برای یکدیگر گزارش باگ ثبت می‌کنند و تلاش می‌کنند بدون دخالت مستقیم انسان، نقص‌ها را مستند کنند.
این عامل‌ها با خطاهایی مواجه شدند که کامپایلرهای سنتی هرگز نمی‌فهمند؛ خطاهایی که مربوط به «معنا» بود نه «سینتکس». برای مثال، طرحی برای ردیابی ثبت‌نام از نظر فنی درست بود، اما وقتی عامل بازاریابی آن را با نیازهای واقعی مقایسه کرد، متوجه شد که هدف را برآورده نمی‌کند.
بر اساس مستندات این آزمایش، عامل بازاریابی چندین نقص فنی را در طرح اول شناسایی کرد:
- انتقال هویت: نحوه انتقال اطلاعات کاربر از وب‌سایت به پورتال.
- نتایج نامشخص: مدیریت اتفاقاتی که نتیجه ارسال رویداد در آن‌ها مبهم است.
- نسبت‌دهی (Attribution): حفظ داده‌های منبع برای تبدیل‌های بعدی.
- قوانین زمان‌بندی: مدل داده‌ها را به لحظه تحویل گره زده بود، نه به جلسه کاربر (Session). عامل اشاره کرد اگر کاربر تب مرورگر را باز بگذارد و بعداً برگردد، این منطق شکست می‌خورد.
توسعه‌دهنده اعتراف کرد که خودش در مورد این جزئیات پلتفرم‌های بازاریابی اطلاعی نداشت و دانش تخصصی عامل در اینجا حیاتی بود.
در مراحل فعال‌سازی و پرداخت هم تضادهای مشابهی پیش آمد. مثلاً یک طرح پیشنهاد داد که «خرد کردن یک درخواست به تکالیف کوچک‌تر» را به عنوان «پیشرفت معنادار» بشماریم. عامل بازاریابی با این ایده مخالفت کرد و گفت ایجاد کار بیشتر، به معنای تکمیل کار مفید نیست.
در بحث پرداخت‌ها هم، سیستم نمی‌توانست با اطمینان بگوید یک پرداخت «اولین پرداخت» است یا نه، مگر اینکه تاریخچه قبلی را کامل چک کند. عامل‌ها طرح را اصلاح کردند تا عدد نهایی با اطمینان کامل ارائه شود، نه بر اساس حدس.
حتی بعد از توافق عامل‌ها، IssueFlow کدها را از یک مسیر سخت‌گیرانه عبور داد: اعتبارسنجی، چک‌های امنیتی و بازبینی کد. در این مرحله نقص‌های اجرایی پیدا شد و ثابت شد که تایید طرح لزوماً به معنای کد بدون باگ نیست، بلکه فقط مسیر را درست می‌کند.
در نهایت هر سه ویژگی به محیط عملیاتی منتقل شدند. با این حال، توسعه‌دهنده اشاره کرد که «ارسال کد» با «تایید سفر مشتری» دو نقطه متفاوت هستند و هنوز بررسی رویدادهای واقعی نیاز به کار دارد.
این تجربه نشان می‌دهد مرز بعدی بهره‌وری، نه مهندسی پرامپت — یعنی هنر سؤال درست پرسیدن برای گرفتن بهترین جواب — بلکه «تفویض اختیار» است. توسعه‌دهنده دیگر هر پاسخ را تایپ نمی‌کند، بلکه فقط تصمیم می‌گیرد چه کسی اختیار تصمیم‌گیری دارد.
گام بعدی شما
- اگر از عامل‌های کدنویسی استفاده می‌کنید، به جای بررسی خط به خط کد، سعی کنید یک عامل «بازبین» تعریف کنید که فقط بر اساس نیازمندی‌های بیزنس (Business Requirements) قضاوت کند.
- روی ساختارهای «حکمرانی عامل‌ها» (Agent Governance) تمرکز کنید تا بدانید کجا باید تایید انسانی را اجباری کنید و کجا اجازه دهید عامل‌ها حلقه را ببندند.
- بررسی کنید آیا ابزارهای فعلی شما می‌توانند بین «صحت فنی» و «ارزش کاربردی» تفاوت قائل شوند یا خیر.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو