نکات کلیدی
- عاملهای کدنویسی یک مُد گذرا نیستند؛ آنها بخش در حال تکاملِ چشمانداز توسعه هستند و برای توسعهدهندگان ضروری میشود که استفادهٔ مؤثر از آنها را یاد بگیرند تا هم بهرهوری و هم کیفیت را بالا ببرند.
- مدلهای زبانی بزرگ را نباید «کالای یکسان» در نظر گرفت. انتخاب مدل میتواند بهشدت روی کیفیت کاری که عاملها انجام میدهند اثر بگذارد.
- با اینکه عاملها اتوماسیون و کارایی میآورند، مهم است که بیش از حد کار را به آنها واگذار نکنیم. توسعهدهندگان باید فعالانه درگیر بمانند و کنترل فرایند توسعه را دست خودشان نگه دارند، چون در نهایت مسئول نتیجهاند.
- تجربه همچنان دارایی حیاتیِ توسعهدهندگان است؛ چون کمک میکند راهحلهای مؤثر طراحی کنند، پیادهسازی را برنامهریزی کنند، و خروجی تولیدشده توسط عاملهای کدنویسی را نقادانه ارزیابی کنند.
یک گردشکار جدید برای توسعهدهندگان
از زمانی که «گیتهاب کوپایلوت» در تابستان ۲۰۲۱ بهصورت پیشنمایش عرضه شد، شاهد انفجار محصولات دستیار کدنویسی بودهایم. در ابتدا این ابزارها مثل «تکمیل کدِ تقویتشده» استفاده میشدند، اما بعضی محصولات این حوزه (مثل «کِرسِر» و «ویندسرف») خیلی سریع به سمت تعاملهای عاملمحور حرکت کردند؛ جایی که دستیار با فرمانهای متنی فعال میشود و بهطور خودکار کارهایی مثل تغییر فایلهای کد و اجرای دستورهای ترمینال را انجام میدهد.
اخیراً «گیتهاب کوپایلوت» قابلیت «حالت عامل» را هم به چت یکپارچهٔ خودش اضافه کرده است؛ حالتی که با آن میشود از یک عامل خواست کارهای مختلفی را از طرف شما انجام بدهد. «حالت عامل» در «گیتهاب کوپایلوت» نمونهٔ دیگری از تکامل پرشتاب فضای عاملمحور است. این «حالت عامل» را نباید با «عامل کدنویسی گیتهاب کوپایلوت» اشتباه گرفت؛ همان عاملی که میشود از رابطهای «گیتهاب» مثل وبسایت یا خط فرمان گیتهاب فراخوانیاش کرد تا روی ایشوهای گیتهاب بهصورت خودکار کار کند.
در این مقاله میخواهیم ببینیم استفاده از عاملها در توسعهٔ نرمافزار دقیقاً یعنی چه و چه تغییرهایی در گردشکار توسعهدهنده ایجاد میکند. برای اینکه حس ملموستری از این گردشکار جدید بگیریم، از «حالت عاملِ گیتهاب کوپایلوت» استفاده میکنیم تا یک برنامهٔ سادهٔ «انگولار» بسازیم که مقالههای «ویکیپدیا» را جستوجو میکند و نتیجه را به شکل یک فهرست نشان میدهد (راهنمای دسترسی به عامل گیتهاب کوپایلوت در «ویاسکد»). اسمش را میگذاریم «اپ جستوجوی ویکی».
اول تلاش میکنیم برنامه را یکباره بسازیم، یعنی فقط یک پیام به عامل بدهیم. بعد همان کار را با یک رویکرد هدایتشدهتر انجام میدهیم.
ساخت برنامه در یک مرحله
«اپ جستوجوی ویکی» خیلی ساده است. اینکه چیست و چه کار میکند را میشود با یک پیام نسبتاً کوتاه توضیح داد، مثل نمونهٔ زیر. توجه کنید جزئیات فنیِ مربوط به انگولار برای نشان دادن اثر عاملها روی گردشکار توسعهدهنده ضروری نیست، اما یادآوری میکند که حتی هنگام کار با عاملها هم توسعهدهنده باید حواسش به جزئیات فنی مهم باشد و هنگام نوشتن پیام، آنها را در اختیار عامل بگذارد تا کار درست انجام شود.
پیام ما برای اینکه از «عاملِ گیتهاب کوپایلوت» بخواهیم کل برنامه را بسازد
یک برنامهٔ انگولار تولید کن که از رابط برنامهنویسی کاربردیِ ویکیپدیا برای دریافت مقالههایی که با یک عبارت جستوجو تطابق دارند استفاده کند و نتایج را در قالب یک فهرست نمایش بدهد.
برنامه باید یک نوار جستوجو داشته باشد که کاربران بتوانند عبارت جستوجو را وارد کنند و وقتی روی دکمهٔ جستوجو کلیک میکنند، برنامه رابط برنامهنویسی کاربردیِ ویکیپدیا را فراخوانی کند و نتایج را به شکل فهرست نشان بدهد. هر آیتم فهرست باید شامل عنوان مقاله و یک توضیح کوتاه باشد.
برنامه باید خطاها را با آرامش مدیریت کند و اگر نتیجهای پیدا نشد یا در فراخوانی رابط برنامهنویسی کاربردی خطایی رخ داد، پیام مناسبی نمایش دهد.
برای اجزای رابط کاربری از «انگولار متریال» استفاده کن و مطمئن شو برنامه واکنشگراست و هم روی دسکتاپ و هم روی موبایل خوب کار میکند. برنامه باید ساختاری ماژولار داشته باشد، با کامپوننتهای جداگانه برای نوار جستوجو و فهرست نتایج. از بهترینروشهای توسعهٔ انگولار استفاده کن، از جمله سرویسها برای فراخوانی رابط برنامهنویسی کاربردی و «آبزروبل»ها برای مدیریت دادههای ناهمگام.
موتور مدل مهم است
«حالت عاملِ گیتهاب کوپایلوت» اجازه میدهد مدل زبانی مورد استفاده را انتخاب کنیم. آزمایشهایی که انجام دادیم نشان داد انتخاب موتور مدل، کلیدی است. باید روی این نکته تأکید کنیم تا گرفتار این تصور نشویم که مدلهای زبانی بزرگ کالاهای مشابهی هستند و تفاوتهایشان فقط در بحثهای خیلی تخصصی اهمیت دارد. این باور حتی ممکن است با این واقعیت تقویت شود که گیتهاب کوپایلوت اجازه میدهد توسعهدهندگان مدل را از یک فهرست کشویی ساده انتخاب کنند. مدلها تواناییهای متفاوت (و دائماً در حال تکامل) دارند و این تفاوتها خودش را در هزینه و نتیجه نشان میدهد.
برای اثبات این موضوع، همان پیام را با دو مدل متفاوت امتحان کردیم: «کلود سونِت ۴» از «آنتروپیک» و «او۴-مینی (پیشنمایش)» از «اوپنایآی». هر دو بهدرستی مدلهای قدرتمندی حساب میشوند، اما ماهیت و تواناییهایشان کاملاً متفاوت است. «کلود سونِت ۴» یک مدل بسیار بزرگ است با بیش از ۱۵۰ میلیارد پارامتر که بهطور ویژه برای کدنویسی تنظیم دقیق شده، در حالی که «او۴-مینی (پیشنمایش)» مدل بسیار کوچکتری است با ۸ میلیارد پارامتر که برای استفادهٔ عمومیتر تنظیم شده است. بنابراین عجیب نیست که نتایج خیلی متفاوت بودند، اما این تنوع جزو ذات چشمانداز فعلی مدلهاست و بهتر است آن را جدی بگیریم.
کار کردن با «او۴-مینی (پیشنمایش)»
با استفاده از «او۴-مینی (پیشنمایش)»، عامل گیتهاب کوپایلوت نتوانست یک قابلیتِ کارکردی بسازد. در واقع نسخهٔ اول چند خطا داشت که مانع کامپایل میشد. بعد از آن، گفتوگویی را با عامل شروع کردیم و خواستیم خطاها را اصلاح کند. بعد از چند دور رفتوبرگشت، متوقف شدیم چون خطاها همچنان ظاهر میشدند و مهمتر از آن، بهسختی میشد فهمید راهحل چطور طراحی شده و کد هم سختخوان بود، حتی با اینکه تا حدی با انگولار آشنا هستیم. (برای افراد کنجکاو: میتوانند کدی که در این آزمایش تولید شده را ببینند.)
کار کردن با کلود سونِت ۴ (Claude Sonnet 4)
«کلود سونِت ۴» نتیجهای کاملاً متفاوت داد. کدی که در اولین تلاش تولید شد همانطور که انتظار میرفت کار کرد و هیچ نیازی به تکرار یا دخالت دستی نداشت. طراحی راهحل تمیز بود، ماژولار شده بود و ساختار پوشههای پروژه هم شفاف و مرتب بود.
حتی از عامل خواستیم یک نمودار معماری هم تولید کند و عامل، نمودارهای «مرمید» خوبی همراه با توضیحهای دقیق دربارهٔ عناصر کلیدی طراحی ارائه داد.
حس «واقعاً کنترل دست من نیست»
حتی با اینکه عاملِ مبتنی بر «کلود سونِت ۴» یک راهحلِ کارکردی و مستندات خوب تولید کرد، باز هم حس من این بود که «کنترل دست من نیست». مثلاً برای اینکه مطمئن شوم نمودارهای تولیدشده دقیقاند، مجبور بودم کد را با دقت دنبال کنم و همزمان آن را با نمودارها و مستندات تولیدشده تطبیق بدهم. یعنی برای اینکه واقعاً بفهمیم عامل چه کرده، عملاً باید کد را مهندسی معکوس کنیم و مستندات تولیدشده را هم اعتبارسنجی کنیم.
اما این کار را نباید «اختیاری» دید. در واقع ضروری است، چون کمک میکند بهتر بفهمیم عامل چه کرده، مخصوصاً اینکه در نهایت مسئول کد ما هستیم، حتی اگر توسط هوش مصنوعی نوشته شده باشد.
میشود گفت این وضعیت خیلی هم با شرایطی که یک همکار برایمان نمودار میکشد یا چیزی را مستندسازی میکند فرق ندارد. اصل ماجرا «اعتماد» است. در تیمها معمولاً با بعضی همکارها اعتماد ساخته میشود و خروجی همکار مورد اعتماد را معمولاً «خوب» فرض میکنیم. اما با عاملها و مدلها، اعتماد کردن خطرناک است، چون مشکل «توهمزایی» حتی در مدلهای پیشرفته هم هنوز وجود دارد. بنابراین باید همهٔ چیزهایی را که هوش مصنوعی تولید میکند بررسی کنیم.
یک رویکرد هدایتشده
معمار باشید
برای اینکه پشت فرمان بمانیم، یک رویکرد متفاوت را امتحان میکنیم: اول ساختار راهحلی که میخواهیم بسازیم را طراحی میکنیم، بعد یک برنامهٔ پیادهسازی میکشیم و کار را به گامهای کوچک تقسیم میکنیم. به زبان ساده، همان کاری را انجام میدهیم که یک معمار اپلیکیشنِ کلاسیک انجام میدهد. فقط وقتی برنامهٔ پیادهسازی آماده شد، از عامل میخواهیم هر گام را انجام بدهد تا کمکم برنامه ساخته شود.
تعریف بهترینروشها برای پیروی عامل
چون میخواهیم معمارهای خوبی باشیم، باید بهترینروشهایی را که میخواهیم عامل رعایت کند تعریف کنیم. بهترینروشها میتوانند شامل قراردادهای نامگذاری، سبک کدنویسی، الگوها و ابزارهای مورد استفاده باشند.
گیتهاب کوپایلوت یک روش راحت برای تعریف این بهترینروشها دارد: «فایلهای دستورالعمل» که بعد بهطور خودکار در هر پیامی که به عامل ارسال میشود قرار میگیرند. حتی میتوانیم با استفاده از هوش مصنوعی مولد، از طریق یک چتبات معمولی مثل «چتجیپیتی»، کمک بگیریم تا یک فهرست خوب از بهترینروشها بنویسیم.
در این مثال، به عامل گفتیم تستهای جامع بنویسد، دسترسپذیری را در همهٔ نماها پیادهسازی کند، و روی پیچیدهترین بخشهای کد با استاندارد «جیاسداک» توضیحهای روشن بنویسد. نتیجهٔ این دستورالعملها خیلی خوب بود.
اشتراکگذاری و اعمال بهترینروشها در سطح تیم
یک اثر جانبی جالبِ تعریف بهترینروشها در فایلهای دستورالعمل این است که بعد میشود آنها را بخشی از خروجیهای پروژه در نظر گرفت. بنابراین این بهترینروشهای تعریفشده میتوانند در مخزن پروژه نسخهبندی شوند و بین همهٔ توسعهدهندگان به اشتراک گذاشته شوند. این سازوکار کمک میکند بهترینروشهای تعریفشده بهصورت مرکزی، بین همهٔ مشارکتکنندگان پروژه اعمال شود، به شرطی که آنها برای انجام کار از عاملها استفاده کنند.
ساخت برنامه
حالا که برنامهٔ پیادهسازی و بهترینروشها را تعریف کردهایم، وقت ساختن برنامه است. روند کار این است:
- هر گام از برنامهٔ پیادهسازی به یک پیام برای عامل تبدیل میشود.
- بعد از اجرای هر پیام، بررسی میکنیم عامل چه کرده است. اگر گامها را کوچک و ساده نگه داریم، کدی که عامل در هر گام تولید میکند سخت نیست که فهمیده و بررسی شود.
- ممکن است بخواهیم با عامل گفتوگو کنیم و دربارهٔ همان گام، توضیح یا تغییر بخواهیم.
- وقتی از نتیجهٔ گام راضی شدیم، تغییرات را ثبت میکنیم تا یک نقطهٔ سازگاری داشته باشیم و بعد به گام بعدی برویم.
- برنامه را گامبهگام میسازیم و همیشه کنترل را دست خودمان نگه میداریم.
این رویکرد باعث میشود بتوانیم یک برنامهٔ باکیفیت بسازیم، چون عامل با «فایل دستورالعمل» معمولاً بسیاری از بهترینروشها را رعایت میکند. در تجربهٔ ما:
- عامل یک مجموعه تست جامع نوشته و طیف بزرگی از حالتهای لبهای را پوشش داده است.
- عامل در هر قالب اچتیامال دسترسپذیری را رعایت کرده، کاری که معمولاً زمان قابل توجهی از ما میگیرد.
- عامل روی بخشهای حساستر کد با استاندارد جیاسداک توضیحهای روشن اضافه کرده است.
در مجموع، ما با چهار گام و با چهار پیام، یک برنامهٔ کارکردی ساختیم و هر چهار پیام در اولین تلاش با استفاده از «کلود سونِت ۴» بهعنوان موتور مدل، نتیجهٔ مورد انتظار را دادند.
مدل درست را انتخاب کنید
همانطور که گفتیم، انتخاب مدل میتواند تفاوتساز باشد. ما همین رویکرد هدایتشده را با چند مدل دیگر و با همین توالی پیامها امتحان کردیم. با «جیپیتی-۴.۱»، عامل یک برنامهٔ کارکردی تولید کرد و تقریباً نیازی به اصلاح نداشت (تنها خطاها مسیرهای نادرستِ ایمپورت بود)، اما کیفیت پایینتر بود. مثلاً برنامه مطابق طراحی متریال نبود (در حالی که طبق دستورالعمل باید میبود) و رویداد «کلید اینتر» را هم مدیریت نکرده بود. همچنین دسترسپذیری در همان تلاش اول پیادهسازی نشده بود.
سرعت مهم است، اما همهچیز نیست
با این رویکرد هدایتشده، یک برنامهٔ کاملاً کارکردی با تستهای جامع و ویژگیهای کیفیِ بیشتر را با فقط چهار پیام ساختیم. این کار نهایتاً چند ساعت زمان برد، و احتمالاً کمتر. این سرعت در مقایسه با رویکرد سنتی واقعاً چشمگیر است؛ جایی که توسعهدهنده قبل از نوشتن کد باید کلی جزئیات فنی را بررسی کند، مثل مستندات رابط برنامهنویسی کاربردی ویکیپدیا یا تازهترین راهنماهای بهترینروشهای انگولار.
در عین حال، میشود گفت حتی میتوانستیم سریعتر باشیم، اگر از عامل میخواستیم کل برنامه را با یک پیام بسازد. نکته اینجاست که احتمالاً مقداری سرعت را فدای ساختن «راهحلی که میخواهیم» کردیم. یعنی گرچه ممکن است درخواست ساخت یک برنامهٔ کامل با یک پیام سریعتر باشد (و عامل هم آنقدر قدرتمند باشد که انجامش بدهد)، ما فقط نمیخواهیم «یک برنامه» بسازیم؛ ما میخواهیم «برنامهٔ خودمان» را بسازیم، برنامهای که آن را میفهمیم و از طراحیای که میخواهیم پیروی میکند، چون در نهایت باید آن را نگهداری و تکامل بدهیم. طراحی ساختار برنامه و کشیدن برنامهٔ پیادهسازی زمان میبرد، اما تضمین میکند نتیجه چیزی است که تحت کنترل ماست، قابل مدیریت است و قابل نگهداری. و همهٔ اینها با سرعتی بسیار بالاتر از کدنویسی کاملاً دستی به دست میآید.
نتیجهگیری
عاملها میتوانند ابزار بسیار قدرتمندی در دست توسعهدهندگان باشند، مخصوصاً وقتی با مدلهای مؤثر تغذیه شوند. آنها میتوانند توسعه را سریعتر کنند، کارهایی را که گاهی عقب میاندازیم (مثل تستها) انجام دهند و همهٔ این کارها را طبق دستورالعملها و بهترینروشهایی که برایشان تعریف کردهایم پیش ببرند. اما این قدرت با خطر از دست دادن کنترل همراه است. ممکن است به راهحلهای کارکردی برسیم که فهمیدنشان زمان میبرد و وسوسه شویم بدون حفظ کنترل لازم به آنها اعتماد کنیم. گاهی هوش مصنوعی مولد دچار توهمزایی میشود و این ریسک بزرگی است. حتی اگر فرض کنیم هوش مصنوعی هرگز توهمزایی نمیکند، تکیه کردن به راهحلی که آن را نمیفهمیم خطرناک است.
برای حفظ کنترل بر آنچه ساخته میشود و همزمان بهرهبردن از قدرت عاملها، میتوانیم گردشکاری را اتخاذ کنیم که دانش معماری انسانی را با کارآمدی عامل ترکیب میکند. در این گردشکار، مرحلهٔ طراحی و برنامهریزی دست معمارهای انسانیِ باتجربه میماند؛ کسانی که راهحل و گامهای رسیدن به آن را تعریف میکنند. کدنویسی به عامل واگذار میشود؛ عاملی که سریع کار میکند و کیفیت خوبی دارد.
ما معتقدیم آزمایش ما بهشدت ساده است. همچنین معتقدیم ساختن یک برنامهٔ جدید از صفر با کار کردن روی یک کدبیس موجود و پیچیده (و اغلب گیجکننده) خیلی فرق دارد. با این حال، نتایج چشمگیر است و واضح نشان میدهد که داریم راه همکاری بهتر با عاملها را پیدا میکنیم. این رویکرد برای ما هم کارایی میآورد و هم کیفیت.
تجربه کلیدی است
اگر میخواهیم کنترل کنیم عاملها برای ما چه میکنند، تجربه کلیدی است. تجربه کمک میکند یک راهحل خوب طراحی کنیم، یک برنامهٔ پیادهسازی مؤثر بچینیم، و قضاوت لازم را داشته باشیم تا خروجی هوش مصنوعی را بررسی کنیم. اینکه در جهانی که عاملها بخش سنگین کدنویسی را انجام میدهند چطور این تجربه را به دست میآوریم؟ این خودش یک سؤال دیگر است؛ سؤالی که برای بسیاری از فعالیتهای فکری انسان در جهانی که به ابزارهای هوش مصنوعی مولد دسترسی دارد مطرح میشود.
