بر اساس نظرسنجی سال ۲۰۲۶ از ۲۹۰۰ مهندس، توسعه‌دهندگان اکنون ۱۱.۴ ساعت در هفته را صرف بازبینی کدهای تولیدشده توسط هوش مصنوعی می‌کنند، که از ۹.۸ ساعتی که خودشان صرف نوشتن کد می‌کنند پیشی گرفته است. گلوگاه اصلی از «آیا هوش مصنوعی می‌تواند کد تولید کند؟» به «آیا می‌توانیم به کدی که تولید می‌کند اعتماد کنیم؟» تغییر یافته است و تیم‌ها به سمت جریان‌های کاری چندعاملی (multi-agent AI workflows) حرکت می‌کنند که وعده مسیرهای تصمیم‌گیری شفاف‌تر و اعتماد بالاتر را می‌دهند.
نظرسنجی که بحث را برانگیخت
پرسشنامه‌ای که اوایل امسال اجرا شد، از توسعه‌دهندگان پرسید که چگونه زمان خود را بین نوشتن کدهای جدید و بررسی کدهای تولیدشده توسط هوش مصنوعی تقسیم می‌کنند. پاسخ‌دهندگان گفتند که بازبینی اکنون بیشتر از مرحله ایجاد اولیه زمان می‌برد. آن‌ها همچنین گزارش دادند که در یک پروژه واحد، با دو تا چهار دستیار هوش مصنوعی مختلف دست‌وپنجه نرم می‌کنند و ۷۰٪ گفتند که این کار به یک روال عادی تبدیل شده است.
این اعداد بازتاب‌دهنده یک ناامیدی رو به رشد است: یک مدل واحد و همه‌منظوره می‌تواند در عرض چند ثانیه یک تابع بنویسد، اما همزمان بدون ثبت هیچ سندی، تصمیمات پنهانی درباره ساختارهای داده، مدیریت خطا و بهینه‌سازی‌های عملکردی می‌گیرد. توسعه‌دهندگان در نهایت مجبور می‌شوند آن تصمیمات را مهندسی معکوس کنند؛ فرآیندی که می‌تواند یک روز کاری کامل را مصرف کند.
چرا یک مدل واحد دیگر کافی نیست
سال‌ها جریان کاری معمول به این صورت بود: توسعه‌دهنده یک پرامپت (prompt) تایپ می‌کرد، مدل یک فایل تولید می‌کرد و توسعه‌دهنده آن را در پایگاه کد (codebase) کپی می‌کرد. این ترفند برای دموهای سریع جواب می‌دهد، اما نرم‌افزارهای عملیاتی (production) به چیزی فراتر از یک خروجی تک‌مرحله‌ای نیاز دارند. برای مثال، وقتی مدل تصمیم می‌گیرد به جای یک آرایه (array) از یک لیست پیوندی (linked list) استفاده کند یا استثناها (exceptions) را بی‌صدا نادیده بگیرد، این انتخاب‌ها در کد جاسازی شده و از دید بازبین محو می‌شوند.
از آنجایی که استدلال داخلی مدل ثبت (log) نمی‌شود، تیم‌ها پس از انجام کار می‌پرسند: «چرا هوش مصنوعی این الگو را انتخاب کرد؟». پاسخ اغلب مستلزم جستجو در کامنت‌های تولیدشده، اجرای مجدد پرامپت با تنظیمات دمای (temperature) متفاوت یا حتی بازسازی کل مرحله تولید است. این عدم قطعیت اکنون خود را به صورت ساعات اضافی بازبینی در نظرسنجی نشان می‌دهد.
تقسیم کار: سیستم‌های چندعاملی چگونه کمک می‌کنند
راه‌کارهای چندعاملی (Multi-agent setups) از یک تیم توسعه کوچک تقلید می‌کنند. به جای اینکه یک مدل همه کارها را انجام دهد، عامل‌های (agents) مجزا مسئولیت‌های متمایزی را بر عهده می‌گیرند:
- عامل معمار (Architect agent): یک سند طراحی سطح بالا تولید می‌کند و مدل‌های داده، قراردادهای API و استراتژی‌های مدیریت خطا را ترسیم می‌کند.
- عامل پیاده‌ساز (Implementation agent): کدی می‌نویسد که دقیقاً از معماری پیروی می‌کند و از مشخصات به عنوان یک چک‌لیست استفاده می‌کند.
- عامل تأییدکننده (Verification agent): تست‌های واحد (unit tests) تولید می‌کند، تحلیل ایستا (static analysis) انجام می‌دهد یا خط‌لوله‌های CI/CD را آماده می‌کند و صرفاً بر تضمین کیفیت تمرکز دارد.
خروجی هر عامل یک مصنوع (artifact) مجزا است، بنابراین استدلال پشت یک تصمیم در خود آن مصنوع باقی می‌ماند. بازبینی معماری قبل از نوشتن حتی یک خط کد، بسیار کم‌هزینه‌تر از رفع باگی است که از یک انتخاب طراحی اشتباه ناشی شده باشد. همچنین قابلیت ردیابی (traceability) نیاز تیم‌های انطباق (compliance) را برآورده می‌کند که باید بدانند چه کسی (یا چه چیزی) در مورد یک جزئیات پیاده‌سازی خاص تصمیم گرفته است.
ابزارهایی که جریان‌های کاری چندعاملی را کاربردی می‌کنند
توسعه‌دهندگان در حال حاضر با ترکیبی از ابزارها در حال سرهم کردن این خط‌لوله‌ها هستند:
- ادغام‌های IDE: به عامل‌ها اجازه می‌دهند به صورت پنل‌های کناری ظاهر شوند و سند معماری را تنها با یک کلیک به دستیار تولید کد منتقل کنند.
- ابزارهای CLI: امکان اجرای توالی‌های اسکریپت‌نویسی شده را فراهم می‌کنند: اجرای معمار، انتقال خروجی آن به کدنویس و سپس تحویل نتیجه به تست‌کننده.
- فریم‌ورک‌ها (Frameworks): کتابخانه‌هایی برای ساخت عامل‌های سفارشی فراهم می‌کنند که بسته به نیاز پروژه می‌توان آن‌ها را جایگزین یا حذف کرد.
- پلتفرم‌های مبتنی بر مشخصات (Specification-first platforms): قبل از شروع هرگونه تولید، یک فایل الزامات رسمی را می‌طلبند تا اطمینان حاصل شود که مرحله طراحی قابل چشم‌پوشی نیست.
آمار ۷۰ درصدی نظرسنجی نشان می‌دهد که اکثر تیم‌ها قبلاً نسخه‌های موردی (ad-hoc) این خط‌لوله‌ها را ساخته‌اند. پلتفرم‌های جدید صرفاً آنچه را که مهندسان به صورت دستی انجام می‌دادند، رسمی می‌کنند.
چه کسانی سود می‌برند — و چه کسانی ممکن است عقب بمانند
سازمان‌هایی که باید الزامات سخت‌گیرانه حسابرسی را رعایت کنند، مانند شرکت‌های حوزه مالی یا مراقبت‌های بهداشتی، بلافاصله از این مزایا بهره‌مند می‌شوند. یک زنجیره مستند از طراحی تا کد، خطر نفوذ آسیب‌پذیری‌های پنهان به محیط عملیاتی را کاهش می‌دهد. استارتاپ‌های کوچک‌تر ممکن است بار اضافیِ نگهداری چندین عامل را غیرضروری بدانند، اگر با سرعت کافی حرکت کنند، به طوری که سرعت یک مدل واحد بر هزینه بازسازی‌های گاه‌به‌گاه غلبه کند.
یک استدلال مخالف اشاره می‌کند که سیستم‌های چندعاملی (multi-agent systems) پیچیدگی را افزایش می‌دهند. هماهنگ‌سازی سه یا چند مدل می‌تواند باعث بروز باگ‌های یکپارچه‌سازی، افزایش تأخیر (latency) و نیاز به نظارت پیشرفته‌تر شود. تیم‌هایی که فاقد تخصص لازم برای ساخت یا مدیریت عامل‌های سفارشی هستند، ممکن است زمان بیشتری را صرف مدیریت هماهنگی (orchestration) کنند تا توسعه واقعی. برای این گروه‌ها، یک مدل واحدِ به‌خوبی تنظیم‌شده — به‌ویژه مدلی که قابلیت توضیح‌پذیری (explainability) داخلی ارائه می‌دهد — می‌تواند همچنان انتخابی عمل‌گرایانه باقی بماند.
آنچه در ماه‌های آینده باید زیر نظر داشت
- فرمت‌های استاندارد ثبت وقایع (logging) برای مصنوعات تولیدشده توسط هوش مصنوعی می‌تواند مقایسه خروجی‌ها در میان عامل‌های مختلف را آسان‌تر کند.
- پیشنهادهای بازار (Marketplace) که عامل‌های معماری، کدنویسی و تست را در قالب یک اشتراک واحد ارائه می‌دهند، ممکن است موانع را برای تیم‌های فاقد تخصص داخلی در زمینه هوش مصنوعی کاهش دهند.
- رهنمودهای نظارتی در مورد کدهای تولیدشده با کمک هوش مصنوعی می‌تواند سازمان‌های بیشتری را به سمت خط‌لوله‌های (pipelines) چندمرحله‌ای و قابل حسابرسی سوق دهد.
- معیارهای سنجش عملکرد (benchmarks) که زمان کل توسعه — و نه فقط سرعت تولید — را اندازه‌گیری می‌کنند، به تیم‌ها کمک می‌کند تا تصمیم بگیرند آیا هزینه‌ی اضافیِ هماهنگی صرفه اقتصادی دارد یا خیر.
ارقام اصلی این نظرسنجی داستان روشنی را روایت می‌کنند: توسعه‌دهندگان بیشتر از آنکه وقت خود را صرف نوشتن کدهای جدید کنند، هفته خود را صرف بازبینی خروجی‌های هوش مصنوعی می‌کنند. جریان‌های کاری چندعاملی (multi-agent workflows) به عنوان پاسخی مستقیم ظهور کرده‌اند و قابلیت ردیابی (traceability) را ارائه می‌دهند که تولیدات «جعبه سیاه» (black-box) را به فرآیندی مستند و قابل بازبینی تبدیل می‌کند. اینکه آیا پیچیدگیِ اضافه شده در مدیریت هماهنگی برای هر تیمی توجیه‌پذیر است یا خیر، باید منتظر ماند و دید، اما روند تقسیم مسئولیت‌های هوش مصنوعی از همین حالا در حال بازتعریف نحوه ساخت نرم‌افزار است.