اگر کدی فقط تا زمانی کار می‌کند که پنجرهٔ چت باز است، شما با یک محصول طرف نیستید، بلکه فقط یک دمو دارید. در ۱۱ اکتبر ۲۰۲۶، راهنمای فنی منتشرشده در dev.to هشدار داد که تسلط در کدنویسی با کمک هوش مصنوعی ارزان شده و این موضوع منجر به یک الگوی شکست جدید در استخدام‌های فنی شده است: کاندیداهایی که کدی تحویل می‌دهند که در یک جلسه (Session) عالی است اما با اولین ری‌استارت فرو می‌پاشد.
این تغییر در حالی رخ می‌دهد که مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — در نوشتن پیاده‌سازی‌های صیقل‌خورده‌ای که مسیرهای ایده‌آل (Happy Path) را شبیه‌سازی می‌کنند، خبره شده‌اند. برای مدیران استخدام، خطر اصلی «اثر تخته‌سیاه» (Scratch Pad Effect) است؛ یعنی مدل قصد پرامپت را بهتر از آنکه برنامه وضعیت خودش را به یاد آورد، به خاطر می‌سپارد. وقتی کاندیدایی برای پیش‌نویس راهکار به مدل تکیه می‌کند، اغلب انسجام گفتاری مدل را با صحت معماری اشتباه می‌گیرد.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، تکیه بر خروجی‌های بدون بازبینی می‌تواند حفره‌های امنیتی و منطقی عمیقی ایجاد کند. در اینجا هم مشکل دقیقاً همین است: جایگزینی تفکر معماری با توهمِ کارکرد.
تلهٔ پایداری
طبق گزارش dev.to، رایج‌ترین شکست در تکالیف خانگیِ AI-assisted، سردرگمی بین حافظه جلسه و پایداری روی دیسک است. کاندیدا ممکن است اسکریپتی تحویل دهد که در دمو زنده، تمام موارد خاص (Edge Cases) را به‌درستی مدیریت کند، اما به محض توقف و شروع مجدد فرآیند، وضعیت (State) به صفر برمی‌گردد.
این اتفاق به این دلیل می‌افتد که مدل‌ها اغلب کدی می‌نویسند که داده‌ها را در متغیرهای سراسری یا دیکشنری‌های درون‌حافظه‌ای ذخیره می‌کند. این روش شاید درخواست فوری پرامپت برای «ردیابی یک شمارنده» را برآورده کند، اما قرارداد بنیادی یک سیستم تولیدی یعنی «دوام» (Durability) را نقض می‌کند. اگر عدد ۲ بعد از یک ری‌بوت دیگر معنای ۲ را ندهد، کاندیدا یک برنامه نساخته، بلکه فقط متن یک گفتگو را پیاده کرده است.
«تور» در برابر «قرارداد»
به بررسی‌کنندگان هشدار داده شده که آن‌ها در حال خرید یک «تور» در مدل‌های رایگان نیستند. آن‌ها برنامه‌ای کوچک می‌خرند که باید بدون لپ‌تاپ نویسنده، بدون متن گفتگوهای او و بدون اعتماد به حرفهای او، قابل بازبینی باشد. تحویلی که تست‌هایش بعد از یک فرآیند جدید همچنان همان معنا را داشته باشند، یک کاندیدای واقعی است؛ اما تحویلی که فقط تا زمان باز بودن چت کار می‌کند، صرفاً یک دمو است.
برای تفکیک این دو، این راهنما پیشنهاد می‌کند پرامپت به‌گونه‌ای نوشته شود که مشخصات فنی (Spec) یک فایل در مخزن (Repo) باشد. باید به کاندیداها گفته شود که مدل می‌تواند پیش‌نویس را بنویسد، اما این پیش‌نویس تا زمانی که تستی (که خودشان ثبت کرده‌اند) به دلیل درست شکست بخورد و سپس به دلیل درست پاس شود، غیرقابل اعتماد است. اگر کاندیدایی نتواند یک خطای قرمز (Red Assertion) را بدون اسکرول کردن در تاریخچهٔ چت توضیح دهد، هنوز مالک اثر نیست.
پیاده‌سازی تست «دروازهٔ تلاش مجدد»
برای مقابله با این وضعیت، راهنمای مذکور یک تمرین کوچک و مشخص را پیشنهاد می‌دهد: ساخت یک دروازهٔ تلاش مجدد (Retry Gate). الزامات این تمرین به‌طور عمدی محدود است تا شکاف بین پیش‌نویس و مشخصات فنی آشکار شود:
- قرارداد: یک نقطه اتصال (Endpoint) مانند
POST /retry?key=...باید حداکثر ۲ بار برای یک کلید خاص موفق شود. - شکست: فراخوانی سوم باید خطای ۴۲۹ برگرداند و نباید شمارنده را افزایش دهد.
- پایداری: وضعیت باید روی دیسک ذخیره شود. متوقف کردن و شروع مجدد فرآیند نباید شمارش را ری‌ست کند.
- اعتبارسنجی: یک فراخوانی
GET /retry?key=...باید تعداد استفاده فعلی را برگرداند.
جزئیات فنی و پیاده‌سازی
برای ارائه یک معیار سنجش عینی، این راهنما یک نمونه پیاده‌سازی پایتون با استفاده از کلاس RetryGate ارائه می‌دهد. این کلاس از pathlib.Path برای مدیریت وضعیت در فایل‌های JSON استفاده می‌کند.
مکانیزم‌های کلیدی:
- پاک‌سازی (Sanitization): یک مکانیزم کلیدی برای امنیت، پاک‌سازی کلید است:
safe = "".join(ch for ch in key if ch.isalnum() or ch in "-_")[:64]. این کار تضمین می‌کند که ورودی‌های کاربر نتوانند مسیرهای فایل را دستکاری کنند. - مدیریت خطا: اگر کلید بعد از پاک‌سازی خالی باشد، سیستم باید یک
ValueErrorصادر کند تا از ایجاد فایل‌های نامعتبر جلوگیری شود. - مدیریت وضعیت: متد
used()فایل JSON مربوطه را می‌خواند و مقدار عدد را برمی‌گرداند؛ اگر مسیر فایل وجود نداشته باشد، مقدار ۰ را برمی‌گرداند. - جریان منطقی: متد
allow()ابتدا بررسی می‌کند که آیا شمارش فعلی مساوی یا بیشتر از حد مجاز (که به‌طور پیش‌فرض ۲ است) می‌باشد یا خیر. تنها در صورتی که حد مجاز پر نشده باشد، مقدار را افزایش داده و مجدداً روی دیسک می‌نویسد.
تست برای ری‌استارت
تأیید نهایی نیازمند تست‌هایی است که به‌طور خاص مرزهای فرآیند را هدف قرار دهند. یک تست نمونه به نام test_third_call_sticks_after_new_object این کار را با ایجاد یک شیء RetryGate و مصرف تمام سهمیه، و سپس ساخت یک شیء دوم که به همان دایرکتوری اشاره می‌کند، انجام می‌دهد. این کار ری‌استارت را بدون نیاز به کلاستر شبیه‌سازی می‌کند و تأیید می‌کند که شیء دوم بلافاصله برای allow("job-9") مقدار False برمی‌گرداند و شمارنده روی عدد ۲ باقی می‌ماند.
اعتبارسنجی موارد خاص
تست دیگر، test_rejected_key_does_not_create_a_file بررسی می‌کند که آیا سیستم کلیدهای نامعتبر را درست مدیریت می‌کند یا خیر. مدلی که فقط دستور «ذخیره شمارنده» را شنیده باشد، ممکن است کلید بد را بپذیرد یا فایلی از ورودی خام کاربر بسازد. هدف این است که سیستم استثنا (Exception) صادر کند و دایرکتوری را خالی نگه دارد. این تست به‌طور خاص بررسی می‌کند که بعد از یک تلاش ناموفق با کلیدی مانند "***" عبارت list(tmp_path.glob("*.json")) == [] برقرار باشد.
بازبینی خودکار
برای جلوگیری از «نمره‌دهی بر اساس حس» (Grading by Vibe)، یک اسکریپت بازبین (review_check.py) پیشنهاد شده است. این اسکریپت بعد از ری‌استارت به فایل کلید اشاره کرده و بررسی می‌کند که آیا مقدار used دقیقاً ۲ است یا خیر.
منطق بازبین:
- کدهای خروج: اسکریپت اگر شمارش دقیقاً ۲ نباشد، با استفاده از
SystemExitشکست می‌خورد. - حضور فایل: اگر فایل گم شده باشد، این یک «صفر هوشمندانه» نیست، بلکه یک شکست است؛ یعنی دروازه داده‌ها را جایی نوشته که بازبین آن را نمی‌بیند.
- اجرا: بازبین می‌تواند دستور
python review_check.py /var/lib/retry-gate/job-9.jsonرا اجرا کند تا یک نتیجه باینری (پاس یا شکست) دریافت کند.
شناسایی عادت‌های «تخته‌سیاه»
نحوه برخورد کاندیدا با README و تست‌ها، سطح مالکیت او را فاش می‌کند. ترتیب اهمیت بیشتری از لحن دارد. با درخواست تست‌ها قبل از پیاده‌سازی و الزام به اینکه README یک مورد را نام ببرد که تست‌ها آن را پوشش نمی‌دهند، می‌توان کسانی را که فقط مدل را هدایت کرده‌اند شناسایی کرد. کسی که مشخصات فنی را نوشته، می‌تواند حفره‌ها را نام ببرد؛ کسی که فقط پرامپت زده، نمی‌تواند.
پرچم‌های قرمز در تحویلی‌های AI-assisted:
- ثبت تاریخچه چت: قرار دادن تاریخچه گفتگو با LLM در مخزن به عنوان «یادداشت‌های طراحی» یا ریختن ترانسکریپت در پوشه
docs/. - شبیه‌سازی (Mocking) منطق: نوشتن تست‌هایی که تابع
allow()را شبیه‌سازی می‌کنند و ورودی/خروجی دیسک را نادیده می‌گیرند؛ این کار فقط ثابت می‌کند که تست‌ران کار می‌کند، اما I/O دیسک را نادیده می‌گیرد. - ورودی‌های بررسی‌نشده: استفاده از ورودی خام کاربر برای ساخت مسیرهای ذخیره‌سازی که منجر به آسیب‌پذیری‌های تزریق شل (Shell Injection) می‌شود و مدل ممکن است از آن غافل شود.
- ادعاهای دروغین درباره دوام: ادعای «ایمنی در برابر کرش» در README (مثلاً استفاده از
os.replaceبرای نوشتن اتمیک) بدون ارائه تستی که عملیات نوشتن را در میانه راه متوقف کند. - وضعیت سراسری (Global State): نگه داشتن شمارنده در یک متغیر سراسری که باعث شکست فوری تست ری‌استارت می‌شود.
- روایت گری گریزپا: استفاده از جملاتی مثل «مدل لبه‌ها را تأیید کرد» به‌جای توضیح توالی قرمز-سبز (Red-Green) به زبان خودشان.
نقش زیرساخت‌های رایگان
برای عادلانه کردن این تست‌ها، نویسنده ابزارهایی مانند MonkeyCode را پیشنهاد می‌کند که دسترسی رایگان به مدل برای پیش‌نویس و سرور رایگان برای تست ری‌استارت فراهم می‌کند. این کار باعث می‌شود ری‌استارت صرفاً یک ادعای «به لپ‌تاپ من اعتماد کنید» نباشد، بلکه یک رویداد قابل تأیید روی یک ماشین میزبانی‌شده باشد و هزینه‌های ابری برای کاندیدا حذف شود.
دستورالعمل‌های زیرساختی:
- اجتناب از هزینه‌ها: کاندیداها نباید مجبور باشند برای نمایش یک ری‌استارت، حساب‌های ابری باز کنند یا منتظر تیکت‌های پرداخت بمانند.
- شفافیت: به بازبین‌ها توصیه می‌شود محدودیت‌های واقعی فعلی را از صفحه ارائه‌دهنده کپی کرده و در پرامپت قرار دهند. اختراع اندازه ماشین برای دقیق به نظر رسیدن، باعث ناعادلانه شدن تکالیف می‌شود.
- ثبات: دسترسی رایگان یک در است، نه یک معیار؛ اگر ماشین کند است، نباید معیار نمره‌دهی پایین بیاید.
تحلیل: تغییر از «سلیقه» به «مالکیت»
این رویکرد معیار مصاحبه فنی را از «آیا این شخص می‌تواند مسئله را حل کند» به «آیا این شخص مالک قرارداد است» تغییر می‌دهد. در عصری که LLMها می‌توانند در چند ثانیه پایتونِ از نظر نحوی بی‌نقص تولید کنند، ارزش یک توسعه‌دهنده دیگر در توانایی نوشتن یک تابع نیست، بلکه در توانایی تعریف و تأیید یک مرز (Boundary) است.
برای خواننده، این بدان معناست که «دمو» اکنون پایین‌ترین سطح شواهد است. سیگنال واقعی در توالی قرمز-سبز یافت می‌شود: توانایی شکست دادن عمدی یک سیستم و اثبات دلیل شکست آن. مالکیت زمانی ثابت می‌شود که توسعه‌دهنده با هوش مصنوعی مانند یک تخته‌سیاه سخنگو — ابزاری برای پیش‌طرح — برخورد کند، نه به عنوان معمار سیستم. کاندیدایی که می‌گوید «من خطای ۴۲۹ را تأیید کردم چون پرامپت بودجه‌ای برای ۲ بار تعریف کرده بود و من فایل را بعد از ساخت یک شیء جدید چک کردم»، در واقع یک مشخصات فنی (Spec) را توصیف کرده است.
چه زمانی از این رویکرد صرف‌نظر کنیم؟
این فیلتر مبتنی بر ری‌استارت جهانی نیست. راهنما پیشنهاد می‌کند در سناریوهای زیر از این تکلیف صرف‌نظر کنید:
- غربالگری‌های الگوریتمی خالص: وقتی هدف مشاهده نحوه استدلال فرد درباره یک گراف است، فایل ری‌استارت فقط نویز اضافی ایجاد می‌کند.
- سیاست‌های سخت‌گیرانه: وقتی سیاست شرکت ارسال متن تمرین به مدل‌های شخص ثالث را ممنوع می‌کند.
- نیازهای زیرساختی خاص: وقتی نقش شغلی نیازمند یک هدف آپ‌تایم مشخص، یک ماشین خاص یا بودجه توکن‌های ثابت است.
در نهایت، این فیلتر همکاری یا عمق طراحی را نمی‌سنجد. یک نفر می‌تواند تست ری‌استارت را پاس کند و همچنان هم‌تیمی ضعیفی باشد. هدف صرفاً این است که ببینیم آیا آن‌ها می‌توانند مشخصات فنی را از روی «تخته‌سیاه» خارج کنند، پیش از آنکه با خودِ انسان مصاحبه کنند.
گام بعدی شما این است که تست‌های فعلی خود را بازبینی کنید تا ببینید آیا با وضعیت درون‌حافظه‌ای (In-memory) قابل پاس شدن هستند یا خیر؛ اگر هستند، شما در حال نمره‌دهی به حافظه یک مدل هستید، نه مهارت یک کاندیدا.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو