کدنویسی وایبی تغییری در این ایجاد کرده است که چه کسانی میتوانند یک برنامه کاربردیِ ظاهراً قابلاجرا تولید کنند. یک پرامپت میتواند پیش از آنکه تیم مهندسی سنتی نخستین بازبینی طراحی خود را به پایان برساند، صفحهها را تولید کند، یک API را متصل سازد و یک گردشکار قابلباور سرهم کند.
این سرعت، مشکل تازهای در استخدام و تحویل ایجاد میکند: یک دمو دیگر شواهد محکمی از خوب بودن نرمافزار نیست. کارفرمایان بیشازپیش سؤال دشوارتری خواهند پرسید: آیا این سامانه ساختهشده با هوش مصنوعی میتواند وقتی ورودیها نامرتباند، وابستگیها از کار میافتند، کاربران اقدامات را تکرار میکنند و مدل زیربنایی تغییر میکند، درست رفتار کند؟
پاسخ از معیار کیفیای خواهد آمد که کمتر شبیه پرداخت بصری و بیشتر شبیه راستیآزمایی منضبط نرمافزار است. افرادی که متمایز میشوند صرفاً آنچه را ابزار کدنویسی هوش مصنوعی تولید کرده نشان نخواهند داد. آنها نشان خواهند داد چگونه آن را آزمودهاند، چه کارهایی را نمیتواند با ایمنی انجام دهد و از کجا میدانند تغییری چیز دیگری را خراب نکرده است.
معیارمحک شواهد است، نه امتیاز جدول رتبهبندی
معیارمحکهای متنبازِ عاملهای کدنویسی نقطههای شروع مفیدی ارائه میکنند، اما تواناییهای متفاوتی را میسنجند. SWE-bench از مسئلههای واقعی GitHub و نماهای لحظهای مخزنها استفاده میکند و به همین دلیل برای کار نگهداری مرتبط است. Terminal-Bench تعامل با خط فرمان را میآزماید. معیارمحکهای فهرستشده دیگر، از جمله SlopCodeBench و ProgramBench، جنبههای متفاوتی از کد تولیدشده و رفتار عامل را هدف میگیرند.
این معیارمحکها میتوانند به مقایسه ابزارها یا تعیین یک خط مبنا کمک کنند، اما کارفرمایان باید در نظر گرفتن هر امتیاز منفرد بهعنوان مدرکی برای آمادگی تولید محتاط باشند. مدلی که مسئلههای مخزن را حل میکند ممکن است همچنان منطق ناامنِ مجوزدهی تولید کند. عاملی که وظایف ترمینال را کامل میکند ممکن است نتواند وضعیت را در یک گردشکار طولانی حفظ کند. یک برنامه وب پرداختشده ممکن است در یک دموی مسیر ایدهآل موفق شود، اما در مدیریت تلاشهای مجدد یا پرداختهای تکراری شکست بخورد.
بنابراین، یک نمونهکار معتبر یا بازبینی داخلی باید شامل مجموعه ارزیابیِ ویژه همان کار باشد. این مجموعه میتواند گزارشهای نماینده باگ، مسیرهای معمول کاربر، ورودیهای نادرست، مرزهای مجوز، خرابیهای وابستگی و پسرفتهایی را که قبلاً رفع شدهاند دربر بگیرد. هر مورد باید نتیجه موردانتظار صریحی داشته باشد، نه صرفاً اسکرینشاتی که درست به نظر برسد.
حداقل بسته آزمون برای نرمافزار ساختهشده با هوش مصنوعی
برای یک برنامه کوچک، میتوان بدون آزمایشگاه پژوهشیِ پیچیده، بسته کیفی مفیدی ساخت:
- آزمونهای پذیرش: رفتار قابلمشاهده برای کاربر را در مهمترین گردشهای کاری، شامل نتیجههای موفق و ناموفق، راستیآزمایی کنید.
- آزمونهای واحد و یکپارچهسازی: قواعد کسبوکار را بهصورت مجزا بررسی کنید و مطمئن شوید پایگاههای داده، APIها، صفها و احراز هویت آنگونه که intended است با هم کار میکنند.
- آزمونهای منفی: ورودیهای مفقود، نادرست، بیشازحد بزرگ، تکراری و غیرمجاز ارسال کنید. کد تولیدشده با هوش مصنوعی اغلب در مسیری که در پرامپت نشان داده شده قویترین عملکرد را دارد، بنابراین مسیرهای درخواستنشده اهمیت دارند.
- آزمونهای پسرفت: هر نقص کشفشده را به یک آزمون دائمی تبدیل کنید. سبز شدن دمو پس از یک اصلاح کافی نیست، اگر همان خطا بتواند در تغییر تولیدشده بعدی بازگردد.
- بررسیهای امنیتی: کنترل دسترسی، مدیریت اسرار، دفاع در برابر تزریق، آسیبپذیریهای وابستگی و این موضوع را بیازمایید که آیا محتوای نامعتبر میتواند بر فراخوانی ابزارها یا اقدامات دارای امتیاز اثر بگذارد یا نه.
- بررسیهای عملیاتی: مهلتهای زمانی، تلاشهای مجدد، همریشهبودن، ثبت گزارش، هشدارها و رفتار ایمن هنگام در دسترس نبودن یک وابستگی را راستیآزمایی کنید.
این رویکرد به ذهنیت مهندسی تضمین کیفیتی نزدیک است که در شرح Stack Overflow از چرخه حیات توسعه نرمافزار عاملمحور توصیف شده است. تغییر مهم، فرهنگی است: تضمین کیفیت بازرسی نهایی پس از نوشتن کد توسط هوش مصنوعی نیست. تضمین کیفیت ساختاری است که تولید سریع را بهاندازه کافی ایمن میکند تا بتوان از آن استفاده کرد.
هماهنگسازی را بیازمایید، نه فقط خروجی را
وقتی نرمافزار شامل یک عامل هوش مصنوعی است، آزمونهای معمول برنامه ضروری اما ناکافیاند. سامانه ممکن است به این دلیل شکست بخورد که مدل درخواست را بد فهمیده است، اما ممکن است مشکل از این هم باشد که هماهنگسازی پیرامونی زمینه را از دست داده، ابزاری را دو بار فراخوانی کرده، خروجی ساختاریافته نادرست را پذیرفته یا هرگز متوقف نشده است.
حوزههای پسرفت پیش از استقرار که در این مرور توصیه شدهاند، یک فهرست عملیاند: از دست رفتن زمینه، همریشهبودن ابزار، تزریق پرامپت، خروجی ساختاریافته، پایاننیافتن، اتکایابی بازیابی و بازسازی وضعیت. اینها ویژگیهای مهندسیِ قابلآزمون هستند.
برای مثال، یک آزمون میتواند همان درخواست را دو بار اجرا کند و تأیید کند که تلاش دوم سفارش تکراری ایجاد نمیکند. آزمون دیگری میتواند عاملی را در میانه یک گردشکار متوقف کند، آن را دوباره راهاندازی کند و بررسی کند که از یک وضعیت معتبر ادامه میدهد، نه اینکه اقدامی برگشتناپذیر را تکرار کند. یک آزمون بازیابی میتواند سامانه را ملزم کند فقط اطلاعاتی را از مجموعه منابع تأییدشده نقل یا بازگرداند. یک آزمون خروجی ساختاریافته میتواند پاسخی نامعتبر ارائه دهد و تأیید کند که برنامه آن را بهطور ایمن رد میکند، نه اینکه بیسروصدا با آن مانند داده معتبر رفتار کند.
سامانههای طولانیمدت و چندعاملی به سوابق شکستِ بهویژه روشنی نیاز دارند. پژوهشگران در حال کار روی نسبتدادن خودکار شکست هستند، زیرا شناسایی اینکه کدام عامل باعث شکست شده و در چه نقطهای از یک زنجیره تعامل طولانی این اتفاق افتاده است، میتواند دشوار باشد. از نظر عملی، تیمها باید فراخوانیهای ابزار، ورودیها، خروجیها، نسخههای مدل، زمانمهرها، گذارهای وضعیت و تصمیمهای نهایی را در یک ردپای حسابرسیِ ملاحظهگر حریم خصوصی حفظ کنند. بدون این شواهد، یک آزمون قرمز به شما میگوید چیزی شکست خورده است، اما نه اینکه اصلاح آن را از کجا آغاز کنید.
تکرارپذیری به مزیت شغلی تبدیل خواهد شد
کد تولیدشده با هوش مصنوعی متغیر است. اجرای دوباره میتواند پیادهسازی متفاوتی تولید کند؛ بهروزرسانی مدل میتواند رفتار را تغییر دهد؛ و قطعی ارائهدهنده میتواند مسیریابی یا تأخیر را دگرگون کند. بنابراین کارفرمایان برای نامزدهایی ارزش قائل خواهند شد که بتوانند ارزیابیها را تکرارپذیر کنند.
این یعنی در صورت امکان، نماهای لحظهای مدل را ثابت کنید، پرامپتها و پیکربندی را ثبت کنید، هرگاه پلتفرم اجازه میدهد تصادفیبودن را کنترل کنید و برای وظایفی که نتیجههایشان متغیر است چندین بار آزمایش انجام دهید. این مرور بهطور مشخص به نماهای لحظهای ثابتشده، دمای کم یا صفر هرجا که در دسترس باشد و دروازههای CI/CD با حدود اطمینان بهعنوان حفاظهای مفید اشاره میکند.
یک گزارش عملی باید دستکم میان سه نتیجه تمایز قائل شود:
- نرخ موفقیت: چند مورد با موفقیت انجام شدند.
- سازگاری: یک مورد مشخص در اجراهای تکراری، چند وقت یکبار با موفقیت انجام میشود.
- شدت: آیا شکستها صرفاً ظاهریاند، دردسر ایجاد میکنند، به دادهها آسیب میزنند، از نظر امنیتی مهماند، یا میتوانند باعث انجام اقدامی ناایمن در خارج از سیستم شوند.
سیستمی که ۱۹ مورد از ۲۰ بررسی قالببندی کمخطر را با موفقیت پشت سر میگذارد، لزوماً بهتر از سیستمی نیست که ۱۸ مورد از ۲۰ مورد را با موفقیت انجام میدهد اما هرگز از مرز مجوز عبور نمیکند. معیار کیفیت باید شکستها را بر اساس پیامدشان وزندهی کند.
بازبینی انسانی باید ریسک را هدف بگیرد، نه تکتک خطوط را
هدف خودکارسازی بهتر این نیست که فردی را مجبور کنیم تکتک نشانههای تولیدشده توسط هوش مصنوعی را دوباره بخواند. هدف این است که توجه انسان به تصمیمهایی معطوف شود که آزمونها نمیتوانند بهطور کامل دربارهشان تصمیم بگیرند.
بازبینها باید بر احراز هویت و مجوزدهی، نگهداری دادهها، اقدامات مالی یا قراردادی، حریم خصوصی، مهاجرتها، بازیابی از خطا، مجوزهای اشخاص ثالث و تغییراتی که بر خودِ چارچوب ارزیابی سیستم اثر میگذارند تمرکز کنند. درباره یک عامل، باید بررسی کنند که چه ابزارهایی را میتواند فراخوانی کند، هر ابزار به چه دادههایی دسترسی دارد و آیا پیش از یک اقدام برگشتناپذیر به تأیید نیاز است یا نه.
تفاوتهای قابل مشاهده، فرایندهای تأیید، مکالمات بایگانیشده و گزارشهای ممیزی—ویژگیهایی که در توصیف Slack Code از برنامهنویسی مشارکتی با هوش مصنوعی برجسته شدهاند—به انتظاری گستردهتر اشاره دارند: تاریخچه چگونگی ساختهشدن نرمافزار اهمیت خواهد داشت. بازبین باید بتواند درخواست را درک کند، تغییر تولیدشده را بررسی کند، شواهد آزمون را ببیند و مشخص کند چه کسی استقرار را تأیید کرده است.
این سابقه، بوروکراسی برای خودِ بوروکراسی نیست. این سابقه باعث میشود یک نمایش چشمگیر از تغییری کنترلشده که فرد دیگری بتواند آن را نگهداری کند، قابل تشخیص باشد.
چه چیزهایی را در نمونهکار یا مصاحبه ارائه کنیم
برای داوطلبان، قویترین نمایش، سیستمی کوچک با روایتی عمداً قابل مشاهده از کیفیت است. مخزن، دستورالعملهای راهاندازی، یادداشتهای معماری، فرمانهای آزمون، نمونههای نماینده آزمون، محدودیتهای شناختهشده و گزارشی کوتاه از شکستها را ارائه کنید. یک یا دو باگی را که پیدا شده و به آزمونهای رگرسیون تبدیل شدهاند نشان دهید. توضیح دهید از کدام مدل یا عامل برنامهنویسی استفاده شده است، بدون آنکه ابزار را بهعنوان صاحب تصمیمهای مهندسی معرفی کنید.
اگر برنامه از یک عامل استفاده میکند، مجوزهای ابزار، مدل وضعیت، خطمشی تلاش مجدد، شرط خاتمه و نقاط تأیید انسانی را مستند کنید. اگر از بازیابی استفاده میکند، نشان دهید منابع چگونه انتخاب میشوند و وقتی شواهدی وجود ندارد چه اتفاقی میافتد. اگر سرویسهای خارجی را فراخوانی میکند، رفتار آن در برابر پایان مهلت و درخواستهای تکراری را نمایش دهید.
قابلیت اطمینان را بر اساس یک ضبط موفق ادعا نکنید. یک ادعای قابل بررسی بیشتر شبیه این است: «در ۳۰ اجرای ثبتشده از این ۱۲ سناریو، سیستم در ۲۸ مورد معیارهای پذیرش را برآورده کرد؛ دو شکست مربوط به ورودی تاریخ مبهم بودند و هر دو مستند شدهاند.» خودِ عدد از روش، مرزها و صداقت درباره آنچه هنوز آزموده نشده، اهمیت کمتری دارد.
تعریف جدید سرعت
هوش مصنوعی هزینه تولید نسخه نخست را کاهش میدهد. اما هزینه دانستن اینکه آیا آن نسخه شایسته اعتماد است یا نه را حذف نمیکند. در واقع، تولید سریعتر میتواند ارزیابی را مهمتر کند، زیرا ممکن است بین استقرارها تغییرات بررسینشده بیشتری انباشته شوند.
حرفهایِ دوران پس از برنامهنویسیِ وایبی با این چرخه سنجیده خواهد شد: رفتار را تعریف کند، کد تولید یا اصلاح کند، موارد واقعگرایانه و خصمانه را بیازماید، تصمیمهای پرخطر را بررسی کند، شکستها را ثبت کند و بدون از دست دادن شواهد، سیستم را بهبود دهد. معیارها میتوانند به مقایسه توانایی کمک کنند. این شیوههای تضمین کیفیتاند که تعیین میکنند آیا این توانایی به نرمافزاری قابل اتکا تبدیل میشود یا نه.
بنابراین معیار کیفیت این نیست که «آیا میتوانید با هوش مصنوعی یک برنامه بسازید؟» بلکه این است که «آیا میتوانید ثابت کنید برنامه چه کاری انجام میدهد، تشخیص دهید چه زمانی دیگر آن کار را انجام نمیدهد و محدودیتهایی طراحی کنید که مانع تبدیلشدن یک شکست به یک حادثه شوند؟»
