اگر امروز یک مخزن گیت‌هاب بی‌نقص را به عنوان رزومه ارائه می‌دهید، احتمالاً دیگر نمی‌توانید ثابت کنید که واقعاً کدنویسی بلدید. طبق گزارشی که در ۲۸ اوت ۲۰۲۶ در وب‌سایت dev.to منتشر شد، هوش مصنوعی با فشرده کردن نمرات تقریباً تمام متقاضیان در یک بازه عالی، آزمون‌های کدنویسی خانگی (Take-home tests) را عملاً بی‌اثر کرده است.
سال‌ها بود که این آزمون‌ها معیاری برای سنجش تلاش و مهارت بودند. متقاضی‌ای که ۶ ساعت وقت می‌گذاشت تا یک نقطه اتصال REST تمیز با مستندات دقیق و کلاس‌های خطای سفارشی بسازد، گزینه‌ای مطمئن برای استخدام بود. این همبستگی وجود داشت چون ظرافت‌های ساختاری — مثل تست‌ها، تزریق وابستگی (Dependency Injection) و مستندات — نیازمند تلاش واقعی بود. در واقع این راهی بود برای یافتن کسی که بدون دستور، دقیق و ساختاریافته کار کند.
اما هوش مصنوعی زاینده (Generative AI) — مثل دستیاری که تمام الگوهای کدنویسی دنیا را حفظ است و می‌تواند در ثانیه‌ای یک قالب استاندارد بسازد — این همبستگی را از بین برد. امروز، تمام آن نشانه‌های باکیفیت، ارزان‌ترین بخش پروژه هستند. ساختار، تست‌ها، فایل README، مدیریت خطاها و بخش‌های تحلیل سبک‌های مختلف طراحی (Trade-offs) اکنون به‌صورت پیش‌فرض توسط مدل‌های زبانی بزرگ (LLM) — شبیه کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — تولید می‌شوند.
نتیجه این است که ۹۰٪ تسلیم‌ها در بالاترین سطح ارزیابی قرار می‌گیرند. وقتی همه نمره ۹۵ می‌گیرند، آزمون دیگر نمی‌تواند رتبه‌بندی کند. این یک شکست آماری است؛ پراکندگی نمرات از بین رفته است. وقتی دو-سوم متقاضیان برتر تنها بر اساس «سلیقه» و نه «توانایی» از هم متمایز می‌شوند، مدیران استخدام مجبور می‌شوند به معیارهای بدتری مثل نام دانشگاه، لوگوی شرکت‌های قبلی یا حتی لحن خاص نوشته شده در README متوسل شوند.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی تغییر ماهیت خروجی‌های هوش مصنوعی اشاره کردیم، وقتی هزینه تولید پیش‌نویس به صفر می‌رسد، ارزش ابزار تغییر می‌کند.
هزینه پنهانِ «بالا بردن استاندارد»
با یکسان شدن کیفیت تسلیم‌ها، شرکت‌ها واکنش نشان دادند و سطح دشواری را بالا بردند. آن‌ها ویژگی‌های بیشتر، موارد خاص (Edge cases) پیچیده‌تر و پرداخت (Polish) بیشتری را خواستند. این اتفاق یک موازنه سمی ایجاد کرد: هزینه برای متقاضی بالا رفت، اما اطلاعات به‌دست‌آمده برای شرکت کاهش یافت. این فشار بیشتر روی متقاضیانی است که فرزند دارند، شغل دوم دارند یا در حال حاضر در شرکتی مشغول‌اند که نمی‌توانند روزها وقت خود را صرف یک تمرین مصنوعی کنند.
شکست سیستم‌های شناسایی
بسیاری از تیم‌ها سعی کردند با ممنوعیت AI یا پیاده‌سازی خط لوله‌های شناسایی با این وضعیت بجنگند. طبق گزارش dev.to، این تلاش‌ها به دو دلیل شکست خورد:
- شکاف سیستم اعتمادی: درخواست از متقاضی برای عدم استفاده از AI در تکلیفی که نظارت نمی‌شود، شرط‌بندی روی باخت است. این یک سیستم اعتمادی روی کاری است که هیچ‌کس آن را نمی‌بیند، در حالی که ابزاری در تب соседین باز است و واقعاً کاربردی است. در واقع از متقاضی خواسته می‌شود داوطلبانه ضعیف‌تر از رقبایش عمل کند تا فقط شانس یک تماس در دور دوم مصاحبه را داشته باشد.
- سیکل اتهامات: تیم‌ها انرژی بیشتری صرف تحلیل زمان کامیت‌ها (Commit-timeline forensics)، سبک‌سنجی (Stylometry) و نظارت‌های تهاجمی کردند تا یافتن سیگنال‌های مهارت. حتی وقتی شناسایی «محتمل» بود، این عدم قطعیت چیزی نبود که یک مدیر بتواند بدون مسموم کردن فضای استخدامی، در تصمیم نهایی از آن استفاده کند.
چرخش به سمت «مالکیت کد»
صنعت اکنون طبق تحلیل dev.to از اندازه‌گیری «خروجی» به سمت اندازه‌گیری «مالکیت» حرکت می‌کند. بازنگری مفید این است که نپرسیم «آیا AI کد را نوشته است؟» بلکه بپرسیم «آیا این موضوع اهمیتی دارد؟». در یک تیم واقعی، مهندسی که از AI برای تولید یک سرویس فعال استفاده می‌کند، مشکلی نیست. اما مهندسی که نمی‌تواند آنچه را تحویل داده است توضیح دهد، گسترش دهد یا عیب‌یابی کند، یک مشکل بسیار هزینه‌بر است. این ویژگی دوم قابل اندازه‌گیری است. در واقع، همان‌طور که در بررسی روش‌های شناسایی نفوذ در محیط‌های ایزوله دیدیم، سنجش واقعی مهارت یا امنیت، در توانایی تحلیل رفتارهای غیرمنتظره و عمیق نهفته است.
چهار فرمت مصاحبه به عنوان استاندارد جدید برای یافتن سیگنال ظهور کرده‌اند که بر اساس میزان سیگنال به‌دست‌آمده در هر دقیقه رتبه‌بندی شده‌اند:
۱. دوره‌ی گسترش (Extension Round)
در این مدل، آزمون خانگی حفظ می‌شود اما زمان آن به ۹۰ دقیقه کاهش یافته و استفاده از AI صراحتاً مجاز است. سپس در یک تماس زنده، مصاحبه‌کننده یک نیاز جدید را در برابر کد تحویل داده شده قرار می‌دهد. مثال‌هایی از این نیازها عبارتند از:
- تغییر یک محدودکننده نرخ (Rate limiter) از حالت هر-پردازش (per-process) به حالتی که در سه نمونه (Instance) مختلف کار کند.
- اضافه کردن صفحه‌بندی (Pagination) به یک نقطه اتصال بدون شکستن تست‌های موجود.
۲۰ دقیقه از این گفتگو، ارزشمندتر از ۶ ساعت بررسی کد است. اینجا مشخص می‌شود متقاضی مثل کسی است که در آشپزخانه خودش است یا اولین بار است فایل‌ها را می‌بیند. کسی که مالک کد نیست، فایل‌ها را با جست‌وجو باز می‌کند و برای یافتن تنظیمات (Config) دچار مشکل می‌شود، در حالی که یک مالک، غریزی در کد ناوبری می‌کند.
۲. بررسی PRهای بد (Bad-PR Review)
متقاضی ۲۰ دقیقه قبل از تماس، یک Pull Request ۲۰۰ خطی دریافت می‌کند که شامل سه مورد هدفمند است:
- یک باگ واقعی: مثل خطای مرزی (off-by-one)، استثنائی که بلعیده شده (swallowed exception) یا یک Race condition روی وضعیت‌های مشترک.
- یک بوی بد طراحی (Design Smell): چیزی که باگ نیست اما معماری ضعیفی دارد.
- یک انحراف (Red Herring): چیزی که غلط به نظر می‌رسد اما در واقع عمدی و درست است.
این آزمون توانایی اولویت‌بندی شکست‌های بحرانی را در برابر ایرادات ظاهری (Style nits) می‌سنجد. همچنین متقاضی‌ای را شناسایی می‌کند که ۹ مورد فرمت‌بندی را گزارش می‌کند اما Race condition را نمی‌بیند. لحن بازخوردهای آن‌ها — مثلاً «این غلط است» در مقابل «چه اتفاقی می‌افتد اگر دو درخواست همزمان به اینجا برسند؟» — دقیقاً نشان می‌دهد همکاری با آن‌ها در یک پنجشنبه شلوغ و بد چگونه خواهد بود.
۳. دوره‌ی عیب‌یابی (Debug Round)
به متقاضی مخزنی با یک تست شکست‌خورده یا خروجی اشتباه داده می‌شود و ۳۰ دقیقه فرصت دارد آن را درست کند. استفاده از هر ابزاری، از جمله AI، مجاز است. سیگنال اصلی، «راهبرد جست‌وجو» است. مهندسان عالی یک فرضیه می‌سازند و سوالات محدود و قابل‌بررسی از مدل می‌پرسند. دیگران صرفاً کل Stack trace را کپی می‌کنند و منتظر معجزه می‌مانند. AI این دور را متمایزتر کرده است چون تفاوت در نحوه هدایت مدل توسط مهندس برای حل یک باگ ناشناخته را برجسته می‌کند.
۴. تحلیل کد تحویل‌شده (Shipped-Code Walkthrough)
متقاضی پروژه‌ای را که واقعاً در محیط عملیاتی منتشر کرده، با استفاده از صفحه نمایش و مخزن خودش ارائه می‌دهد. مصاحبه‌کننده می‌پرسد چرا سه تصمیم خاص گرفته شد، اگر دوباره انجام می‌داد چه چیزی را تغییر می‌داد و چه چیزی در محیط عملیاتی شکست خورد. چون بستر واقعی عمق بی‌نهایاتی دارد، این بخش غیرقابل جعل است. تنها نقطه ضعف آن دسترسی است، زیرا برخی نمی‌توانند کد اختصاصی شرکت را نشان دهند و فارغ‌التحصیلان جدید موارد کمتری برای ارائه دارند.
استاندارد جدید برای متقاضیان
برای توسعه‌دهندگان، استاندارد از «تولید یک تسلیم صیقل‌خورده» به «دفاع از یک تسلیم کاربردی» تغییر کرده است. یک تسلیم خام که متقاضی بتواند خط به خط آن را توجیه کند، اکنون بر یک تسلیم بی‌نقص که نتواند توضیح دهد، برتری دارد. کدی که قابل دفاع نباشد، اکنون یک نقطه ضعف است، نه یک امتیاز اضافی.
برای موفقیت در این محیط، متقاضیان باید این استراتژی‌ها را به کار بگیرند:
- بازبینی و هرس: از AI استفاده کنید، اما سپس کد را خط به خط بررسی کنید. اگر تکه‌ای از کد فقط به این دلیل آنجاست که AI آن را تولید کرده و شما آن را نمی‌فهمید، آن را حذف کنید.
- کاهش عمدی دامنه: به جای ۹ ویژگی لرزان، ۴ ویژگی مستحکم ارائه دهید. صراحتاً بنویسید چه چیزهایی حذف شده و چرا. گفتن جمله‌ای مثل «من کشینگ را اضافه نکردم چون در این مقیاس، این کار یک بهینه‌سازی زودرس (Premature) بود»، یک سیگنال در سطح مهندسان ارشد است.
- تمرین گسترش: قبل از ارسال، یک شاخه (Branch) پیش‌نویس بسازید و سعی کنید یک ویژگی جدید اضافه کنید. این کار کمک می‌کند تا درزهای طراحی را قبل از مصاحبه پیدا کنید.
- تسلط کامل بر مخزن: آماده باشید تا فوراً فایل تنظیمات را پیدا کنید یا دستور اجرای تست را بزنید. دست‌وپا زدن در فایل‌های خودتان، بدتر از نبود یک ویژگی به نظر می‌رسد.
- شفافیت در ابزار: اعتراف کنید که برای اسکلت‌بندی (Scaffolding) از AI استفاده کردید، اما توضیح دهید چرا منطق خاصی را بازنویسی کردید (مثلاً: «من منطق تلاش مجدد را بازنویسی کردم چون نسخه اول روی خطاهای 4xx هم تلاش مجدد می‌کرد»). این کار هم تسلط بر ابزار و هم قدرت قضاوت شما را نشان می‌دهد.
این تغییر نشان‌دهنده دگرگونی بنیادین در بازار کار مهندسی است؛ آزمون‌های خانگی ۸ ساعته، بدون پرداخت و با ممنوعیت AI مرده‌اند، زیرا آن‌ها «تلاش» را در زمانی می‌سنجیدند که تلاش دیگر پیش‌بینی‌کننده مهارت نبود. وقتی هزینه پیش‌نویس اول به نزدیک صفر می‌رسد، ارزش مهندس کاملاً به بازبینی، معماری و نگهداری منتقل می‌شود. اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو