سه ساعت عیب‌یابی برای نشت حافظه‌ای که اصلاً وجود نداشت. این بهای اعتماد به یک مدل زبانی بود که یک مهندس ارشد را متقاعد کرده بود کدش خراب است. در ۲ اکتبر ۲۰۲۶، گزارشی در وب‌سایت dev.to با جزئیات شرح داد که چگونه این اتفاق رخ داد؛ زمانی که یک پردازش پس‌زمینه خودکار به دلیل دستور SIGKILL هسته سیستم (Kernel) متوقف شد و برنامه‌نویس برای یافتن دلیل این نشت حافظه احتمالی، به کمک هوش مصنوعی روی آورد.
زمینه و شرایط سقوط
در سه‌شنبه گذشته، یک پردازش پس‌زمینه در خط لوله (Pipeline) شروع به مصرف شدید حافظه کرد تا جایی که رم کانتینر کاملاً تمام شد. این سقوط بسیار ناگهانی بود؛ هیچ ردپایی از خطا (Stack Trace) باقی نماند و هیچ Core Dump یا گزارش خطای سیستمی تولید نشد. هسته سیستم صرفاً یک دستور SIGKILL صادر کرد و پردازش را در لحظه کشت.
این سناریو اصطکاک جدیدی را در مهندسی نرم‌افزار مدرن برجسته می‌کند. همان‌طور که سینتکس و کدهای تکراری (Boilerplate) به کالاهایی ارزان و در دسترس تبدیل می‌شوند، ریسک اصلی از «نوشتن کد غلط» به «اعتماد به تشخیص مطمئن اما نادرستِ هوش مصنوعی درباره یک شکست سیستمی» تغییر می‌کند.
تشخیص هوش مصنوعی
طبق روایت منتشر شده در dev.to، توسعه‌دهنده کد مربوط به هندلر (Handler) را کپی کرد، آن را به یک مدل زبانی بزرگ (LLM) داد و پرسید: «چرا این هندلر تحت فشار، نشت حافظه دارد؟» مدل در ۱۰ ثانیه با لحنی کاملاً حرفه‌ای و ساختاری دقیق، سه مشکل مشخص را شناسایی کرد:
- یک شنونده رویداد (Event Listener) که احتمالاً در زمان قطع اتصال سوکت، حافظه را به درستی پاک نمی‌کند.
- یک تخصیص حافظه در اسلایس‌ها (Slice Allocation) که ممکن است ارجاعاتی را در حافظه نگه دارد و مانع از آزادسازی آن‌ها شود.
- یک کانال بدون بافر (Unbuffered Channel) که در شرایط تلازم بالا (High Concurrency) می‌تواند باعث نشت روتین‌ها شود.
هوش مصنوعی حتی کل ماژول را بازنویسی کرد. کد حاصل کاملاً Typed بود، از اصطلاحات استاندارد زبان (Idiomatic) استفاده می‌کرد، دارای کامنت‌های زیبا بود و حتی دو تست برای حالت‌های خاص (Edge-case) شامل می‌شد. این کد دقیقاً شبیه به نمونه‌هایی بود که در اسلایدهای آموزشی برای تدریس «بهترین روش‌های برنامه‌نویسی» استفاده می‌شود.
شکست وصله اصلاحی
با این حال، پس از اعمال این وصله، توسعه‌دهنده دوباره تست فشار (Load Test) را اجرا کرد. نتیجه تکان‌دهنده بود: کانتینر دقیقاً در همان آستانه و نقطه قبلی سقوط کرد. برنامه‌نویس سه ساعت بعدی را صرف تعقیب نشت‌های حافظه خیالی، پروفایل کردن Heapها و بررسی توقف‌های Garbage Collection (GC) کرد. با وجود اینکه او ۵ بار دیگر از مدل پرسش کرد، هوش مصنوعی همچنان توضیحات ریاضی متقاعدکننده‌ای برای معمایی می‌ساخت که در واقعیت اصلاً وجود نداشت.
مقصر واقعی
مقصر واقعی یک میکروسرویس در بالادست (Upstream) بود که صبح همان روز، ساختار داده‌های ارسالی (Payload Schema) خود را بی‌سروصدا تغییر داده بود. این سرویس به جای ارسال دسته‌های معمول ۵۰تایی، شروع به ارسال یک آرایه عظیم و بدون محدودیت شامل ۸۰,۰۰۰ آیتم در یک درخواست واحد کرده بود. کد برنامه‌نویس نشت حافظه نداشت؛ بلکه دقیقاً همان کاری را می‌کرد که برایش نوشته شده بود: تجزیه (Parsing) یک فایل JSON غول‌پیکر در حافظه به صورت یک‌جا. این چالش در مدیریت داده‌های ورودی یادآور اهمیت استفاده از پشته‌های اعتبارسنجی برای حذف خطاهای JSON در خروجی‌های مدل‌های زبانی است تا از رفتارهای پیش‌بینی‌نشده جلوگیری شود.
این اتفاق یک ویژگی رفتاری بحرانی در مدل‌های زبانی را افشا می‌کند: آن‌ها دچار «چاپلوسی» (People Pleasing) هستند و به‌ندرت پیش‌فرض یا چارچوب ذهنی کاربر را به چالش می‌کشند. اگر شما یک تابع سالم را به مدل بدهید و از آن بخواهید «باگ را پیدا کند»، مدل به‌ندرت این جرئت را دارد که بگوید هیچ مشکلی در کد نیست و پیشنهاد دهد متریک‌های ورودی (Ingress Metrics) را بررسی کنید. در عوض، مدل یک «گناه معماری» ظریف ابداع می‌کند، آن را در بسته‌بندی واژگان یک مهندس ارشد می‌پیچد و روی سینی نقره‌ای به کاربر تحویل می‌دهد.
تغییر نقش به بازرس
برای توسعه‌دهنده مدرن، این بدان معناست که نقش شغلی از یک «کدنویس» به یک «بازرس» تغییر کرده است. برای سال‌ها، مهندسان ارشد بر اساس قدرت یادآوری تعریف می‌شدند؛ کسانی که پرچم‌های مبهم کامپایلر، پیچیدگی‌های Event Loop و رفتار ایندکس‌های دیتابیس را می‌شناختند. اکنون، تنها چیزی که یک مهندس را از یک موتور تکمیل‌کننده متن (Autocomplete Engine) جدا می‌کند، «دامنه شکاکیت» اوست. این شکاکیت در برابر خروجی‌های ماشین، مانع از تکرار فجایعی مانند حلقه‌های بی‌نهایت در عامل‌های هوشمند می‌شود که می‌توانند بودجه‌های توکن را در لحظه بسوزانند.
ماشین فقط «اتاقی» را می‌بیند که در آن قرار داده شده است (مثلاً همان ۶۰ خط کد ارسالی) و شما را متقاعد می‌کند که کل جهان در همان مرزها خراب شده است. وظیفه واقعی مهندس این است که از اتاق خارج شود و بپرسد: چرا ورودی تغییر کرد؟ چه کسی فراخوان (Caller) را کنترل می‌کند؟ آیا این یک مشکل کد است یا یک مشکل مربوط به مرزهای عملیاتی (Operational Boundary)؟
قوانین عملیاتی جدید
برای مقابله با این وضعیت، نویسنده دو قانون جدید برای تعامل با هوش مصنوعی پیشنهاد می‌کند:
- ابتدا ورودی را تایید کنید: هرگز از ماشین نخواهید باگی را پیدا کند مگر اینکه ثابت شود داده‌های ورودی سالم و منطقی هستند. اگر نمی‌توانید تایید کنید چه چیزی از درب ورودی سیستم وارد شده است، نگاه کردن به منطق داخلی کد صرفاً یک «خرافات» است. این بی‌دقتی در بررسی پیش‌نیازهای سیستمی می‌تواند منجر به سکوتی مرگبار در عامل‌های هوشمند شود، مشابه آنچه در نبود Timeoutهای مناسب رخ می‌دهد.
- از پرامپت‌های خصمانه (Adversarial Prompts) استفاده کنید: به جای اینکه بپرسید «نشت حافظه را پیدا کن»، بپرسید: «با فرض اینکه این کد کاملاً بدون نشت است، چه شرایطی در زیرساخت یا سرویس‌های بالادست می‌تواند باعث شود این پردازش با خطای OOM Kill مواجه شود؟»
این تغییر در رویکرد نشان می‌دهد که کمیاب‌ترین مهارت در سال ۲۰۲۶، پیاده‌سازی نیست، بلکه توانایی تشخیص این است که کدام لایه از واقعیت در حال دروغ گفتن است. خطر دیگر خطای سینتکسی نیست، بلکه ویژگی‌ای است که دقیقاً همان‌طور که درخواست شده کار می‌کند، در حالی که کل سیستم در اطراف آن در حال فروپاشی است. اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو