تصور کنید یک فایل زیپ حاوی کدی را دریافت میکنید که تمام تستهای آن با موفقیت پاس شدهاند؛ در عصر پیش از هوش مصنوعی، این یک نشانهٔ طلایی از مهارت و صلاحیت فنی در استخدامهای حوزه مهندسی بود، اما امروز یک سیگنال توخالی است. وقتی کاندیدایی تکلیفی را تحویل میدهد که در آن هر چیزی بینقص است و هر تست با رنگ سبز پاس شده، احتمالاً فقط از یک مدل کدنویسی استفاده کرده تا دشواریهای عیبیابی و کلنجار رفتن با باگها را دور بزند.
مصاحبهٔ واقعی اکنون در سکوتِ لاگها اتفاق میافتد؛ به طور مشخص، این است که آیا کاندیدا میتواند ثابت کند ابتدا شاهد وقوع خطا بوده و سپس برای اصلاح آن از هوش مصنوعی کمک گرفته است. بدون یک لاگِ شکست (Failing Log)، یک برچند زمانی دقیق یا مدرکی از تلاش برای حل مشکل، این سکوت به معنای عدم مهارت است و در واقع مصاحبه در همین نقطه به پایان میرسد.
همانطور که در تحلیلهای قبلی ما دربارهی فرسایش تستهای تکلیفی (Take-home tests) توسط کدهای تولید شده توسط AI اشاره کردیم، صنعت اکنون با بحران «درختهای مرتب» (Tidy Trees) روبروست. مدلهای زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — کدهای مرتبی مینویسند. تولید یک فایل «سبز» ارزان شده است، اما اجرای یک کد «قرمز» روی یک ماشین واقعی، ارزان نیست.
در هفته گذشته در پلتفرم DEV، بحثهای شدیدی در جریان بود درباره اینکه آیا هوش مصنوعی در حال حاضر بهتر از اکثر ما کد میزند یا اینکه اکثر «عاملها» (Agents) صرفاً مجموعهای از دستورات if-statement هستند که در پوششی زیبا ارائه شدهاند. این موضوع با یافتههای پژوهش برکلی همسو است که نشان میدهد نرخ موفقیت عاملهای هوش مصنوعی در وظایف تخصصی زیر ۲۵٪ است. اینها بحثهای جالبی هستند، اما به شما در استخدام کمک نمیکنند. برای مدیران استخدام، هدف دیگر این نیست که ارزیابی کنند آیا یک مدل میتواند یک تابع تولید کند یا خیر، بلکه هدف این است که بسنجند آیا یک انسان میتواند تا زمانی که یک تست واقعاً «قرمز» شود، از پرسیدن از مدل خودداری کند یا خیر.
مکانیزم Red Log
برای مقابله با تقلبهای مبتنی بر هوش مصنوعی، پروتکلی جدید پیشنهاد شده که بر محوریت فایلی به نام red.log میچرخد. در این چارچوب، به کاندیدا یک کد معیوب برای محاسبه صورتحسابها (یک فایل invoices.py) داده میشود که وظیفه دارد مجموع هزینهها را از یک فایل CSV بخواند. در این سیستم، مبالغ برگشتی (Refunds) به صورت اعداد منفی ذخیره شدهاند. با این حال، کد فعلی هر ردیف را در تابع abs() (قدر مطلق) قرار میدهد؛ در نتیجه مبالغ برگشتی بهجای کم شدن از کل، باعث افزایش مجموع میشوند.
بهجای ارسال یک فایل زیپ استاندارد، کاندیدا باید در یک جلسهٔ راه دور فعالیت کند که توسط اسکریپتی به نام gate.py مدیریت میشود. این گیت یک توالی خطی از عملیات را تحمیل میکند. به کاندیدا گفته میشود که میتواند از مدلهای کدنویسی استفاده کند، اما حق ندارد یک «درخت کد» کامل را که پیشتر روی لپتاپش سبز شده، در محیط جایگذاری کند. در اینجا امتیازدهی بر اساس «ترتیب اقدامات» است، نه کیفیت نثر یا استایل کد.
الزامات دقیق پروتکل
برای اجرای این متد، رعایت موارد زیر الزامی است:
- ثبت شکست (Capture the Failure): کاندیدا باید ابتدا تستها را اجرا کرده و خطا را در
artifacts/red.logذخیره کند، پیش از آنکه حتی یک کلمه به مدل هوش مصنوعی بزند. او نباید اجرای قرمز را به صورت بیصدا نادیده بگیرد. - تست صریح (Explicit Testing): آنها باید یک تست بنویسند یا تستی موجود را گسترش دهند که مورد «مبالغ برگشتی» را به زبان ساده نام ببرد. این کار تضمین میکند که کاندیدا واقعاً فایل CSV را باز کرده و دادهها را درک کرده است.
- مستندسازی پرامپت (Documented Prompting): تنها پس از ثبت وضعیت «قرمز»، اجازهٔ پرسش از مدل داده میشود. پرامپت دقیق باید در
artifacts/prompt.txtو پاسخ خام مدل درartifacts/model.mdذخیره شود. - سند رد کردن (The Refusal): کاندیدا باید فایلی به نام
artifacts/refuse.mdایجاد کند. در این فایل باید یک اصلاحیهٔ ناامن که مدل پیشنهاد داده (یا میتوانست پیشنهاد دهد) را مستند کرده و توضیح دهد که چرا آن را اعمال نکرده است. - اعتبارسنجی نهایی (Final Validation): پس از اعمال اصلاحیهای که درک کرده است، تستها دوباره اجرا شده و در
artifacts/green.logذخیره میشوند. اگر مدل در پاسخگویی کند بود، کاندیدا باید این موضوع را درartifacts/notes.mdذکر کند.
مهندسی تله
اثربخشی این روش به جای یک معمای سخت، بر یک «تله» استوار است. اگر کد ارائه شده شبیه به یک محصول واقعی و پیچیده باشد، مدل هوش مصنوعی یک محصول کامل تولید میکند و مصاحبهکننده هیچ چیز درباره مهارت کاندیدا نمیآموزد. بنابراین، کد ارائه شده یک «درخت کوچک» است. مجموعه تستها عمداً اشتباه طراحی شدهاند تا خودشان باگ را کدگذاری کنند.
برای مثال، در فایل sample.csv مقادیر ۱۰۰۰، ۵۰۰ و ۲۰۰- وجود دارد. تست فعلی test_charges_only ادعا میکند که مجموع باید ۱۵۰۰ باشد (چون ۲۰۰- را به صورت مثبت حساب کرده است).
کاندیدایی که صرفاً از هوش مصنوعی میخواهد «تستها را پاس کند»، احتمالاً پس از یک کامنت از سوی مدل، انتظار تست را به ۱۵۰۰ تغییر میدهد تا با کد معیوب سازگار شود. این منجر به یک تست «سبز» اما یک مصاحبهٔ «شکستخورده» میشود. هدف این است که ببینیم آیا کاندیدا تست را بازنویسی میکند تا مجموع ۱۳۰۰ (۱۰۰۰ + ۵۰۰ + (-۲۰۰)) را انتظار داشته باشد و تابع abs() را از مسیر تولید حذف کند یا خیر.
معیار ارزیابی
ارزیابی بر اساس چهار سیگنال مشخص است، نه یک نمره کلی برای «مهارت در AI». اگر سیگنال پنجمی اضافه کنید، در جلسه بررسی نهایی بهجای استخدام، بر سر آن بحث خواهید کرد. «ترتیب عملیات» ماهیچه متفاوتی از «سلیقه فنی» است و ترکیب این دو باعث میشود دوباره «فایلهای زیپ سبز» برنده شوند.
- صحت Red Log: پذیرفته است اگر عبارت
FAILEDدرred.logباشد و زمان تغییر فایل (mtime) پیش از برچسب زمانی مدل باشد. رد میشود اگر فایل گم شده، خالی یا از ابتدا سبز باشد. - نامگذاری تست: پذیرفته است اگر در ادعا (assertion) یا نام تست به «سنتهای منفی» اشاره شده باشد. رد میشود اگر فقط نام متغیرها را تغییر داده باشند.
- صبر برای مدل: پذیرفته است اگر برچسب زمانی
model_allowed.atبعد از لاگ قرمز ایجاد شده باشد. رد میشود اگر پچی را بدون برچسب زمانی جایگذاری کرده باشند. - دقت در رد کردن: پذیرفته است اگر یک جایگزین مضر را به طور مشخص نام برده باشد. رد میشود اگر از عبارات مبهمی مثل «من محتاط میبودم» بدون ارائه مثال استفاده کرده باشد.
پیادهسازی و ابزارها
برای جلوگیری از جعل لاگها در محیط محلی، این فرآیند به یک محیط راه دور نیاز دارد. طبق مستندات، نباید از کاندیدا خواسته شود برای یک تمرین ۹۰ دقیقهای کلید API بخرد، زیرا این کار باعث میشود شما «کارت اعتباری» را فیلتر کنید، نه «قضاوت فنی» را. شما به سروری نیاز دارید که بتواند pytest را اجرا کند و کلاینت مدلی داشته باشد که ساعت آن با لپتاپ کاربر یکی نباشد.
سرویس MonkeyCode دسترسی رایگان به مدل و سرور برای میزبانی این جلسات را فراهم میکند. این امر تضمین میکند که برچسب زمانی model_allowed.at در سمت سرور باشد و تغییرناپذیر بماند. این رویکرد در واقع بخشی از استراتژی گستردهتر MonkeyCode است که از لایههای اعتبارسنجی برای تبدیل مدلهای رایگان به ابزارهای اصلاح کد استفاده میکند. اسکریپت gate.py نقش اجراکننده را دارد؛ اگر کاندیدا پیش از ثبت وضعیت قرمز، بخواهد دستور python gate.py model را اجرا کند، سیستم هشدار میدهد. این هشدار، در واقع همان مصاحبه است.
سناریوهای شکست کاندیداها
کاندیداها معمولاً به چهار روش در این فرآیند شکست میخورند:
۱. پرش مطمئن (The Confident Skip): تست را محلی اجرا میکنند، از مدل در لپتاپ خود میپرسند، کد سبز را آپلود میکنند و سپس سعی میکنند red.log را دستی جعل کنند. این جعلها معمولاً بیش از حد تمیز هستند؛ لاگهای واقعی pytest دارای هدرهای جلسه و پیامهای خطای خاصی هستند که در انتهای آن عبارت '1 failed' میآید، در حالی که یک لاگ دستنویس شبیه به یک شعر کوتاه (هایکو) است.
۲. بیشبرازش تست (The Overfit Test): مجموع مورد انتظار را به ۱۵۰۰ تغییر میدهند و abs() را باقی میگذارند. تستها سبز میشوند اما منطق کد همچنان خراب است. گیت این مورد را نمیگیرد، اما یک انسان در ۵ ثانیه متوجه میشود چون میتواند جمع بزند.
۳. مقاله نویسی (The Essay): چهار پاراگراف دربارهٔ حلقههای عاملهای هوش مصنوعی مینویسند اما هرگز فایل CSV را باز نمیکنند. در حالی که شما لاگ قرمز خواستهاید، آنها یک فایل Keynote میفرستند.
۴. اعمال ناامن (The Unsafe Apply): مدل پیشنهاد میدهد از eval() روی ردیفها استفاده کند یا فایلی را از /etc بخواند. کاندیدا چون تستها پاس میشوند، آن را اعمال میکند و فایل refuse.md را خالی میگذارد. این یک شکست خودکار است، حتی اگر مجموع درست باشد.
تغییر در پارادایم ارزیابی
این رویکرد با مدل هوش مصنوعی مانند «پیمانکاری که در راهرو ایستاده» برخورد میکند. شما کلیدهای کدبیس را به پیمانکار نمیدهید مگر اینکه ابتدا زنگ خطر به صدا درآمده باشد. ارزش کار از «تغییرات نهایی کد» (Diff) — که شاید فقط سه خط باشد — به «یادداشت رد کردن» منتقل شده است.
یک یادداشت باکیفیت، پیشنهادی از مدل برای حذف ردیفهای برگشتی یا تبدیل هلپر به یک DataFrame را شناسایی میکند. کاندیدایی که مینویسد «حذف ردیفها درآمد را تغییر میدهد و مجموع را اصلاح نمیکند»، قضاوت یک متخصص را نشان میدهد. شما این جمله را بیشتر از خودِ پچ امتیاز میدهید.
برای مدیر استخدام، این یعنی دور ریختن تسلیمهای «بینقص». کاندیدایی که در پچ نهایی شکست میخورد اما یک یادداشت رد کردن تیز و یک اجرای قرمز تمیز ارائه میدهد، ارزشمندتر از کسی است که یک Diff بینقص دارد اما هیچ مدرکی از مواجهه با شکست ندارد. اولی ماشین را میشناسد؛ دومی چتبات را.
محدوده و محدودیتها
این پروتکل برای تکالیف غیرهمزمان (Asynchronous) طراحی شده است که در آن مصاحبهکننده فقط فایل زیپ نهایی را میبیند. برای نقشهایی که نیاز به مهارت تست ندارند، این روش مناسب نیست، زیرا در این صورت افرادی را برای مهارتی جریمه میکنید که بابت آن به آنها حقوق نمیدهید. اگر تیم حقوقی شما استفاده از مدلهای خارجی را منع میکند، باید مدل را روی سرور خودتان ارائه دهید یا تمرین را به صورت یک پچ کاغذی با همان قانون «قرمز پیش از تغییر» بازنویسی کنید.
اگر به دنبال یک پروژه دو روزه هستید، این بسته شاید کوچک به نظر برسد؛ اما اسباببازی کوچکی است که به شما میگوید آیا کسی میتواند «صبر» کند یا خیر. برای تازهکارانی که با pytest آشنا نیستند، میتوانید یک خط به پرامپت اضافه کنید: «قرمز یعنی اجراکننده عبارت FAILED را چاپ کرد». این مورد را برای جلسات Pair Programming زنده که میتوانید فیزیکی ببینید کاندیدا چه زمانی به سراغ AI میرود، حذف کنید.
پس از جمعآوری فایلها، ابتدا red.log را باز کنید، سپس برچسب زمانی و بعد یادداشت رد کردن را. اگر هنوز علاقهمند بودید، به کد نهایی نگاه کنید. برچسبهای زمانی را چک کنید. یک green.log که تاریخش پیش از red.log است، معمایی نیست؛ بلکه کاندیدایی است که از جواب نهایی به سمت شروع حرکت کرده است. در عصر مدلهای زبانی، «ترتیب عملیات» تنها جایگزین باقیمانده برای سنجش قضاوت واقعی مهندسی است.
گام بعدی شما
- اگر مدیر استخدام هستید، در تستهای بعدی بهجای درخواست کد نهایی، درخواست «تاریخچه خطاهای ثبتشده» را بدهید.
- برای کاندیداها: تمرین کنید که ابتدا تستهای شکستخورده را بنویسید و سپس از AI برای حل آنها استفاده کنید.
- ابزارهای محیط راه دور مانند MonkeyCode را برای حذف امکان جعل لاگها بررسی کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو