از زمانی که من در اوایل دهه ۲۰۰۰ در شرکت Empirix (که توسط اوراکل در سال ۲۰۰۶ خریداری شد) مدیر محصول بخش تست و مانیتورینگ وب بودم، تغییرات زیادی در دنیای توسعه نرمافزار رخ داده است. اما بسیاری از موارد نیز ثابت ماندهاند: فشار برای نوآوری سریعتر و در عین حال کاهش هزینهها همچنان بیوقفه ادامه دارد.
برای توسعهدهندگان، جدیدترین جریانهای کاری عامل هوش مصنوعی (AI agent) فراتر از قابلیتهای دستیاران هوش مصنوعی (AI assistants) در حال پیشرفت هستند تا تعریف نیازمندیها، تولید کد، تست واحد و هر فاز دیگری از چرخه توسعه را متحول کنند. بهکارگیری این ابزارها میتواند کار طاقتفرسا را کاهش دهد و تیمهای توسعه را قادر سازد تا به سطوح جدیدی از سرعت و کیفیت دست یابند. در عین حال، هیچ محصول واحدی برای هر وظیفهای در SDLC (چرخه حیات توسعه نرمافزار) مناسب نیست.
دستیاران کدنویسی مبتنی بر مدلهای زبانی بزرگ (LLM) مانند Copilot در دو سال گذشته سهم عظیمی از توجه و همچنین بخش قابل توجهی از هزینههای فناوری اطلاعات را در میان پذیرندگان اولیه به خود اختصاص دادهاند. با شروع ارزیابی بازده سرمایهگذاریهای LLM توسط رهبران فناوری، بازخوردها متفاوت است. برای برخی از کاربران، افزایش بهرهوری غیرقابل انکاری وجود دارد. اما گزارشهای واقعی از تحول واقعی کمیاب به نظر میرسند و میزان موفقیت در سطوح مختلف ارشدیت متفاوت است، به طوری که بهبودها برای توسعهدهندگان باتجربهتر به طور خاص چشمگیر نیست. این درک فزاینده، بسیاری از شرکتها را به سمت دیدگاهی دقیقتر نسبت به نیازهای ابزار هوش مصنوعی خود سوق میدهد و آنها به طور فزایندهای رویکرد بهترینِ بهترینها را در نظر میگیرند که شامل ابزارهای تخصصی در صورت لزوم میشود. به عاملها خوشآمد بگویید!
با توجه به اینکه گارتنر اعلام کرده است که هوش مصنوعی عاملمحور (Agentic AI) شماره یک در لیست 10 روند برتر فناوری استراتژیک برای سال 2025 است، میتوانید مطمئن باشید که بخشهای بازاریابی در هر شرکت نرمافزاری به شدت در تلاش هستند تا این موج را به دست آورند، حتی اگر تنها چیزی که برای ارائه دارند، تعدادی ماکروی اکسل باشد. اینها عامل هستند، درست است؟ اشتباه است. بیایید شفافسازی کنیم.
دستیاران هوش مصنوعی در مقابل عاملهای هوش مصنوعی
وقتی صحبت از هوش مصنوعی بهکاررفته در نوشتن کد میشود، تمایز اصلی بین دستیاران و عاملها شبیه به تفاوتهای بین همکاری و تفویض اختیار است. در حالی که هر دو حالت عملیاتی میتوانند در صورت بهکارگیری در چالش مناسب، ارزش ایجاد کنند، اما تجربیات کاملاً متفاوتی با الزامات منابع متفاوت هستند. مهمتر از همه، فرصتهای ایجاد ارزش از تفویض کامل بخشهای بزرگی از کار به یک عامل قابل اعتماد، شایسته و خودمختار، چیزی را که همکاری با دستیاران هوش مصنوعی میتواند ارائه دهد، کوچک جلوه میدهد.
دستیاران هوش مصنوعی برای انواع وظایف روزمره کدنویسی مفید هستند و پشتیبانی و اطلاعات را در زمان واقعی ارائه میدهند. این ابزارها برای همکاری با توسعهدهندگان طراحی شدهاند، پیشنهاداتی را در حین کدنویسی ارائه میدهند، به طور یکپارچه در محیطهای توسعه یکپارچه (IDE) محبوب ادغام میشوند و ویژگیهایی را ارائه میدهند که تجربه کدنویسی را بهبود میبخشند. برخی از موارد استفاده کلیدی برای دستیاران هوش مصنوعی در توسعه عبارتند از تکمیل کد، تشخیص خطا، جستجوی مستندات و پیشنهادات بازآفرینی (refactoring).
در همین حال، عاملهای هوش مصنوعی میتوانند در خودکارسازی فرآیندهای پیچیده و تصمیمگیریهای سطح بالا تقریباً به طور کامل بدون نظارت، عالی عمل کنند. نحوه مدیریت و اجرای پروژهها را متحول کنند. عاملهای هوش مصنوعی که برای انجام وظایف پیچیده بدون دخالت انسان طراحی شدهاند، اتوماسیون را یک گام فراتر میبرند و امکان تفویض اختیار کامل را فراهم میکنند.
دستیاران در مقابل عاملها: یک مطالعه موردی
بیایید یک مورد استفاده واقعی را بررسی کنیم تا تفاوتهای بین دستیاران و عاملهای هوش مصنوعی را نشان دهیم و با انجام این کار، نوری روشن بر معنای همکاری در مقابل تفویض اختیار بتابانیم.
تستهای واحد. تستهای واحد که عموماً مورد نفرت توسعهدهندگان هستند، همچنان به عنوان پایه و اساس یک رژیم تضمین کیفیت نرمافزار مؤثر شناخته میشوند. نوشتن آنها اغلب میتواند یک چهارم تا یک سوم چرخههای کدنویسی یک توسعهدهنده را مصرف کند و این تلاش عموماً به عنوان کار طاقتفرسا تلقی میشود. جذابیت کاهش زمان صرف شده برای توسعه تستهای واحد قوی است و بسیاری از توسعهدهندگانی که به دستیاران کدنویسی مبتنی بر LLM دسترسی دارند، به طور قابل درک میخواهند این وظیفه را به آنها برونسپاری کنند. آیا در عمل کار میکند؟
پاسخ این است که گاهی اوقات. اما همچنین میتواند در برخی سناریوها به طرز چشمگیری شکست بخورد.
محققان Diffblue (افشای کامل: من مدیرعامل آنجا هستم) سه پروژه منبع باز را که نماینده برنامههای کاربردی دنیای واقعی هستند، انتخاب کردند و از یک دستیار کدنویسی مبتنی بر LLM (GitHub Copilot) برای تولید تستهای واحد برای آنها استفاده کردند. آنها با سه مشاهده زیر به نتیجه رسیدند:
- از وضعیت موجود بهتر است: قاعده کلی این است که حدود 15 دقیقه توسعه دستی برای ایجاد یک تست واحد محکم طول میکشد. البته، میزان کار شما بسته به مهارت توسعهدهنده و پیچیدگی کد مورد آزمایش متفاوت خواهد بود، اما 15 دقیقه برای هر تست تخمین معقولی است. با همکاری Copilot، محققان هر 26 ثانیه یک تست توسعه دادند. در ظاهر، این یک بهبود بهرهوری قابل توجه است. این را به خاطر بسپارید.
- هنوز کار واقعی است. همکاری با Copilot مستلزم آن بود که توسعهدهنده/محقق ما به طور مداوم در یک فرآیند تکراری، تعاملی و کاملاً متمرکز درگیر بماند. پس از درخواست از ابزار برای تولید تستها در سطح متد یا کلاس، خروجی باید ارزیابی، اجرا، اصلاح، دوباره آزمایش و در نهایت توسط کاربر پذیرفته میشد.
- هنوز هم کار طاقتفرسای زیادی وجود دارد: این مطالعه نشان داد که بسته به پروژه، بین 30 تا 45 درصد از تستهای واحد تولید شده توسط LLM در کامپایل و/یا پاس شدن ناموفق بودند. در نتیجه، کاربر مجبور بود برای رفع دستی آنها مداخله کند، بنابراین به همان کار طاقتفرسایی که در وهله اول سعی در اجتناب از آن داشت، بازگردانده میشد.
هنگامی که به همان چالش اعمال شود، یک عامل موثر می تواند نتایج کاملاً متفاوتی ارائه دهد. به طور خاص، استفاده از عامل نوشتن تست واحد Diffblue در این سه پروژه منبع باز، تجربه و نتیجه کاملاً متفاوتی را ارائه داد.
- اولاً، توسعهدهنده میتوانست واقعاً وظیفه تولید مجموعه کاملی از تستهای واحد را برای هر پروژه تفویض کند. او عامل را به مخازن مربوطه هدایت کرد، گفت "برو" و اجازه داد عامل کار خود را برای چند ساعت انجام دهد. نیازی به تعامل با عامل یا نظارت مداوم بر خروجی آن نبود. در عوض، توسعهدهنده آزاد بود تا روی اولویتهای دیگر کار کند.
- ثانیاً، خروجی حاصل از عامل هم از نظر کمی و هم از نظر کیفی برتر بود. به دلیل فناوری هوش مصنوعی مولد زیربنایی مورد استفاده (یادگیری تقویتی همراه با تحلیل استاتیک و اجرای کد پویا)، هر تست ایجاد شده تضمین شده بود که کامپایل و پاس شود، و نیاز به دستکاری خستهکننده تستها برای کار کردن آنها را که بخش تعیینکنندهای از تجربه Copilot بود، از بین میبرد. تستها کیفیت بهتری نسبت به تستهای Copilot داشتند و میانگین امتیاز تست جهش 68% در مقابل 63% را کسب کردند.
- ثالثاً، کل خطوط کد تحت پوشش تستهای تولید شده توسط عامل، چهار برابر توسعهدهنده با استفاده از Copilot بود، زمانی که به هر دو رویکرد زمان یکسانی داده شد. اما مزیت بهرهوری عامل به مزیت 26 برابری افزایش مییابد، وقتی در نظر بگیرید که در تمام طول شبانهروز هر روز سال کار میکند، در حالی که یک توسعهدهنده فقط میتواند به طور منطقی انتظار داشته باشد که شش ساعت در روز کاری تست بنویسد، به تعطیلات برود و مرخصی استعلاجی بگیرد. این مزیت عظیم بهرهوری حتی این واقعیت را در نظر نمیگیرد که بسیاری از توسعهدهندگان اگر از آنها خواسته شود هر روز کاری جز نوشتن تستهای واحد انجام ندهند، احتمالاً استعفا میدهند.
نتیجهگیری
دستیاران کد مبتنی بر LLM یک نوآوری فوقالعاده با طیف گستردهای از کاربردهای ارزشآفرین هستند. با این حال، آنها همچنین محدودیتهای قابل توجهی در موارد استفاده خاص دارند. عدم دقت LLM ها - و گاهی اوقات نادرستی کامل آنها - را می توان با مشارکت پایدار توسعه دهنده در تجزیه و تحلیل و تنظیم خروجی ها کاهش داد. هنگامی که هدف، اتوماسیون کامل طیف گسترده ای از وظایف باشد، مدل دستیار نمی تواند مقیاس پذیر شود. اینجاست که تفویض اختیار به عامل ها این فرصت را دارد که ارزش تحول آفرینی ارائه دهد، و این ارزش تنها در صورتی به طور کامل محقق می شود که خروجی عامل به طور مداوم قابل اعتماد باشد. قطعیت، شفافیت و دقت به ارز رایج جدید عامل هایی تبدیل می شوند که حق تبدیل شدن به نمایندگان ما را کسب می کنند.