آرش یزدانی، کارشناش ارشد نرمافزار شرکت آراد / این روزها اگر از یک برنامهنویس بپرسید تجربهاش از کار با هوش مصنوعی چیست، احتمالاً یکی از دو پاسخ را میشنوید: یا از خروجیهای AI و سرعتی که به فرایند توسعه نرمافزار داده تعریف میکند، یا از کدهای بیکیفیت، تصمیمهای معماری اشتباه و باگهایی که بعد از استفاده از آن پیدا کرده است.
هر دو تجربه واقعیاند. یک گروه معتقدند هوش مصنوعی هنوز آنقدر قابل اعتماد نیست که بتوان کدنویسی را به آن سپرد. از نگاه آنها، مدلها گاهی پاسخهایی تولید میکنند که در نگاه اول درست به نظر میرسند، اما در عمل پر از خطا هستند.
گروه دیگری اما تجربه متفاوتی دارند و معتقدند با استفاده درست از AI میتوان بخش قابلتوجهی از فرایند توسعه نرمافزار را سریعتر کرد؛ از نوشتن کد و تست گرفته تا Refactoring، مستندسازی و حتی بررسی تصمیمهای معماری.
کدام گروه درست میگویند؟ به نظرم هر دو.
مسئله اینجاست که کیفیت خروجی هوش مصنوعی فقط به توانایی مدل وابسته نیست؛ به کیفیت مسئلهای که برایش تعریف میکنیم، Context ای که در اختیارش میگذاریم و نحوه تعامل ما با آن هم بستگی دارد.
به همین دلیل، کار کردن با AI به این معنا نیست که یک سؤال بنویسیم و منتظر پاسخ بمانیم. برای گرفتن خروجی قابلاتکا، باید بلد باشیم مسئله را درست تعریف کنیم، Context مناسب بدهیم، درخواست را به بخشهای کوچکتر تقسیم کنیم و مهمتر از همه، خروجی را اعتبارسنجی کنیم.
به بیان سادهتر، شاید مشکل همیشه از اسب نباشد؛ گاهی مشکل از سوارکار است.
سه قانون سوارکاری با AI
بر اساس تجربهای که در پروژههای واقعی توسعه نرمافزار داشتهام، استفاده مؤثر از هوش مصنوعی را میتوان در سه اصل خلاصه کرد؛ سه قانونی که من اسمشان را گذاشتهام «سه قانون سوارکاری با AI».
قانون اول: قبل از کدنویسی، Context بدهید.
سوارکار قبل از شروع کار، مسیر را میشناسد؛ پیچها، موانع و شرایط مسیر را در نظر میگیرد. در کار با AI هم باید پیش از آنکه از مدل بخواهیم کد تولید یا اصلاح کند، محیطی را که مسئله در آن قرار دارد برایش روشن کنیم.
یکی از رایجترین اشتباهات برنامهنویسان این است که یک تکه کد را جدا از بقیه پروژه در اختیار AI میگذارند و از آن میخواهند کد را اصلاح یا بازنویسی کند. طبیعی است که مدل هم این کار را انجام دهد. اما مدل از کجا باید بداند این کد قرار است در چه معماریای استفاده شود؟ قوانین پروژه چیست؟ چه محدودیتهایی وجود دارد؟ هدف بیزینسی این سرویس چیست؟ چه وابستگیهایی در بخشهای دیگر سیستم وجود دارد؟
ممکن است کدی که AI در پاسخ تولید میکند، همان لحظه کاملاً منطقی به نظر برسد؛ اما چند قدم جلوتر، وابستگیهای نامناسب، Technical Debt یا حتی باگهایی ایجاد کند که پیدا کردنشان بسیار دشوارتر است.
در یکی از پروژههای اخیر، برای بازطراحی یکی از سرویسهای یک پروژه .NET از AI کمک گرفتم. در ابتدا فقط کلاس مربوطه را در اختیار مدل گذاشتم. خروجی در نگاه اول خوب بود، اما چند اصل معماری پروژه را نقض میکرد. بعد معماری پروژه، قوانین کدنویسی، محدودیتها و هدف سرویس را برای مدل توضیح دادم. نتیجه کاملاً متفاوت شد.
مدل همان مدل بود؛ چیزی که تغییر کرده بود Context بود.
بنابراین قبل از اینکه از AI بخواهید کد بنویسد، حداقل این موارد را برایش مشخص کنید:
- نقش و سطح تخصص خودتان
- پروژه و Tech Stack
- معماری سیستم
- قوانین و استانداردهای کدنویسی
- محدودیتهای فنی
- هدف بیزینسی
- و در صورت نیاز، مستندات و کدهای مرتبط
قانون دوم: از AI نخواهید همیشه با شما موافق باشد.
یکی از تلههای رایج در کار با مدلهای زبانی این است که مدل تمایل دارد پاسخ را در جهتی ببرد که برای کاربر قابل قبول باشد. اگر بدون تعیین چارچوب از آن سؤال کنید، ممکن است بهجای اینکه تصمیم شما را به چالش بکشد، بیشتر تلاش کند آن را تأیید و تکمیل کند.
اما در توسعه نرمافزار، همیشه به یک دستیار موافق نیاز نداریم؛ گاهی به یک منتقد فنی سختگیر نیاز داریم. به همین دلیل بهتر است صریحاً از مدل بخواهیم تصمیمهای ما را به چالش بکشد.
مثلاً میتوان گفت:
Act as a Senior .NET Architect. Don’t agree with me by default. Challenge my design decisions. Point out violations of SOLID, Clean Architecture and performance issues.
یا حتی سادهتر، از آن بخواهید: «هرجا منطق یا طراحی من با اصول SOLID یا Clean Code مغایرت دارد، آن را صریحاً به من بگو و صرفاً برای تأیید من پاسخ نده»
نکته مهم اینجاست که Role Prompting بهتنهایی معجزه نمیکند. اینکه فقط بنویسیم «مثل یک Senior Developer رفتار کن» کافی نیست. باید دقیقاً مشخص کنیم از این نقش چه انتظاری داریم، چه چیزهایی را بررسی کند و چه چیزهایی برای ما اهمیت دارد.
گاهی یک پرامپت خوب، بهجای اینکه جواب بهتری تولید کند، سؤال بهتری از شما میسازد؛ و همین موضوع میتواند ارزشمندتر باشد.
قانون سوم: Context را مدیریت کنید.
در سوارکاری، آمادهسازی و تمرین تدریجی باعث میشود اسب بتواند بدون خستگی و فشار بیش از حد، عملکرد خود را حفظ کند. در کار با AI هم مسئله مشابهی وجود دارد: Context باید مدیریت شود، نه اینکه بینهایت انباشته شود.
یکی دیگر از گلایههای رایج این است که مدل بعد از چندین رفتوبرگشت، دیگر مثل ابتدای گفتگو پاسخ نمیدهد یا در یک مکالمه طولانی شروع به از دست دادن بخشی از اطلاعات مهم میکند. این موضوع را نباید صرفاً به «باهوش نبودن» مدل نسبت داد.
مدلهای زبانی Context Window محدودی دارند. هرچه حجم گفتگو، فایلها، کدها و دستورهای قبلی بیشتر شود، مدیریت این Context اهمیت بیشتری پیدا میکند.
به همین دلیل، یکی از عادتهای مفید این است که برای تسکهای مستقل، Context را از نو و به شکل فشرده تعریف کنید؛ بهجای اینکه یک گفتوگوی بسیار طولانی را برای همه کارها ادامه دهید.
البته این به معنی آن نیست که برای هر سؤال حتماً Session Chat جدید باز کنیم. اگر در حال ادامه یک مسئله مشخص هستیم و اطلاعات قبلی برای حل آن ضروری است، حفظ Context میتواند نتیجه بهتری داشته باشد.
نکته اصلی این است: Context باید مدیریت شود، نه اینکه صرفاً انباشته شود.
گاهی یک خلاصه دقیق از معماری، تصمیمهای قبلی و محدودیتهای پروژه، از صدها پیام تاریخچه ارزشمندتر است.
مسئله فقط Prompt نیست
وقتی از Prompt Engineering صحبت میکنیم، گاهی تصور میشود که برای استفاده حرفهای از AI باید مجموعهای از جملههای جادویی بلد باشیم. در عمل، ماجرا کمی متفاوت است.
Prompt خوب مهم است، اما مهارت اصلی در سطح بالاتری قرار دارد: توانایی تعریف درست مسئله.
اگر ندانیم چه میخواهیم، چه محدودیتهایی داریم و خروجی درست چه ویژگیهایی دارد، حتی بهترین مدل هم نمیتواند همیشه نتیجه قابلاتکایی تولید کند.
به همین دلیل، استفاده حرفهای از AI بیشتر از اینکه یک مهارت تایپ کردن پرامپت باشد، ترکیبی از Prompt Engineering، Context Management، Problem Solving و Validation است.
و بخش آخر، یعنی Validation، شاید از همه مهمتر باشد.
هوش مصنوعی میتواند کدی تولید کند که بسیار تمیز، منطقی و حتی متقاعدکننده به نظر برسد؛ اما این ظاهر حرفهای، تضمینکننده درست بودن آن نیست.
کدی که AI نوشته است باید مثل کدی که یک برنامهنویس دیگر نوشته بررسی، تست و در صورت نیاز اصلاح شود.
سوارکار مهمتر از اسب است
هوش مصنوعی قرار نیست برنامهنویس را حذف کند؛ اما احتمالاً فاصله بین برنامهنویسی که بلد است از AI استفاده کند و برنامهنویسی که از آن استفاده نمیکند، روزبهروز بیشتر خواهد شد.
AI یک ماشین Copy/Paste پیشرفته نیست. اگر درست از آن استفاده کنیم، میتواند چیزی شبیه یک Co-Pilot فنی باشد؛ ابزاری که در کنار ما کد مینویسد، ایدههایمان را بررسی میکند، خطاها را پیدا میکند و حتی گاهی تصمیمهای ما را به چالش میکشد.
اما Co-Pilot هم قرار نیست جای خلبان را بگیرد. در نهایت، مسئولیت تصمیم فنی، معماری و صحت کدی که وارد پروژه میشود با انسان است.
پس شاید سؤال اصلی این نباشد که «هوش مصنوعی چقدر باهوش است؟» سؤال مهمتر این است: ما چقدر بلدیم از هوش مصنوعی استفاده کنیم؟
اسب قدرتمند است. سرعتش هم روزبهروز بیشتر میشود. اما اینکه به مقصد برسیم یا در مسیر گم شویم، هنوز تا حد زیادی به کسی بستگی دارد که افسار را در دست گرفته است.
تجربه شما چیست؟
آیا AI تا به حال پروژهتان را به هم ریخته یا به یکی از کاربردیترین ابزارهای روزمرهتان تبدیل شده است؟ بزرگترین درسی که کار با AI به شما داده چیست؟
