تصور کنید ساعت‌ها با یک ابزار هوشمند کار کرده‌اید و با اینکه کد زیادی تولید شده، اما در پایان روز حتی توان تصمیم‌گیری برای انتخاب یک غذای ساده را ندارید. این وضعیت، برخلاف خستگی معمول برنامه‌نویسی، یک فروپاشی کامل در قدرت قضاوت است.
به گزارش dev.to در ۲۲ سپتامبر ۲۰۲۶، الگوی جدیدی از فرسودگی شناختی در میان توسعه‌دهندگانی که از عامل‌های هوش مصنوعی (AI Agents) — ابزارهایی که مثل دستیارهای خودگردان، تکالیف پیچیده را بدون نظارت لحظه‌ای انجام می‌دهند — استفاده می‌کنند، شناسایی شده است. این حالت که «خمارگی هوش مصنوعی» نامیده می‌شود، ناشی از تغییر بنیادین ماهیت کار است: برنامه‌نویسان دیگر نویسنده نیستند، بلکه به بازبین‌های تمام‌وقت تبدیل شده‌اند. این تغییر در نقش توسعه‌دهنده، در حالی رخ می‌دهد که پتانسیل این ابزارها در مقیاس سازمانی بسیار بالاست؛ برای مثال، برخی از مؤسسان تک‌نفره توانسته‌اند با بهره‌گیری از معماری عامل‌محور، کل تیم عملیات خود را به صورت ۲۴ ساعته خودکار کنند.
برای سال‌ها، صنعت نرم‌افزار به هوش مصنوعی به چشم ابزاری برای کاهش حجم کاری نگاه می‌کرد. اما اکنون مشخص شده که ماهیت کار به طور اساسی تغییر کرده است. این انتقال، یک «مالیات روان‌شناختی» ایجاد می‌کند که با قهوه یا پیاده‌روی‌های کوتاه برطرف نمی‌شود. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اتکای بیش از حد به خروجی‌های خودکار، هزینه‌های پنهانی دارد.
طبق تحلیل dev.to، این خستگی با حجم کد تولیدشده رابطه مستقیم ندارد. یک توسعه‌دهنده ممکن است یک ویژگی عظیم را با سرعت بالا تحویل دهد و احساس خوبی داشته باشد، اما ساعت‌ها کلنجار رفتن با یک ماژول لجباز، او را در پایان روز به وضعیتی می‌رساند که قادر به برقراری ارتباط منسجم با دیگران در هنگام شام نباشد. این موضوع ثابت می‌کند که حجم خروجی، محرک اصلی این فرسودگی نیست.
تفاوت تخلیه انرژی و اضافه‌بار شناختی
خستگی معمولی برنامه‌نویسی شبیه به تخلیه تدریجی یک باتری است؛ مثل دویدن در یک مسابقه که کم‌کم سرعتتان کم می‌شود و معمولاً از یک ساعت قبل متوجه می‌شوید که خسته شده‌اید. این یک وضعیت «تخلیه» (Depletion) است.
اما خمارگی هوش مصنوعی یک وضعیت «اضافه‌بار» (Overload) است که ناگهانی و دیر رخ می‌دهد. در این حالت، فرد هنوز می‌تواند صحبت کند یا اشیاء فیزیکی را بلند کند، اما توانایی تصمیم‌گیری درباره هر چیزی را از دست می‌دهد. این نقص خاص در قدرت قضاوت، همان «نشانه»ای است که به علت اصلی مشکل اشاره دارد.
مکانیسم ایجاد اضافه‌بار
برنامه‌نویسی سنتی دارای چرخه‌ای از تولید و توقف (Punctuation) است. تایپ کردن کند است و به ذهن اجازه می‌دهد در حالی که دست‌ها حرکت می‌کنند، قطعه بعدی کد را آماده کند. این بازه‌های زمانی اجرا در واقع دوره‌های بازیابی بین تصمیمات حیاتی هستند.
اما هنگام هدایت یک عامل، این دقایق بازیابی حذف می‌شوند. عامل تولید را بر عهده می‌گیرد و برنامه‌نویس را در جریانی مداوم از تکالیف شناختی گران‌قیمت قرار می‌دهد:
- ساخت مدل ذهنی: خواندن کدی که خودتان ننوشته‌اید، نیازمند تلاشی آگاهانه برای ترسیم نقشه ذهنی است. در حالی که هنگام نوشتن یک تابع، مدل ذهنی به‌طور رایگان و به عنوان محصول جانبی در ذهن شکل می‌گیرد. ساختن این مدل، خودش یک «کار» است.
- تأیید مستمر: چون عامل‌ها «به اندازه کافی خوب» هستند که خطاهای باورپذیر (و نه بدیهی) ایجاد کنند، برنامه‌نویس باید هوشیاری شدیدی داشته باشد. یک کد کاملاً خراب خودش را لو می‌دهد، اما یک کد «تقریباً درست» یا به طور ظریفی غلط، اعلام حضور نمی‌کند.
- قضاوت سریع: هر خروجی نیازمند تصمیمی است: آیا کد درست است؟ آیا با ساختار پروژه سازگار است؟ یا آیا روش جایگزین عامل بهتر از چیزی است که در ابتدا درخواست شده بود؟
این چرخه، بخش‌های «ارزان» برنامه‌نویسی (تایپ و اجرا) را حذف کرده و فقط بخش «گران» یعنی قضاوت را باقی گذاشته است. برنامه‌نویس حالا نویسنده نیست، بلکه بازبینی‌کننده‌ای است که باید با سرعتی بالا عمل کند تا خودش تبدیل به گلوگاه (Bottleneck) پروژه نشود.
هزینه بازبینی
از نظر تاریخی، بازبینی یک Pull Request بزرگ بسیار خسته‌کننده‌تر از نوشتن همان کد است. هر برنامه‌نویسی که این تجربه را داشته می‌داند که ۴۰ دقیقه بازبینی، فشار بیشتری نسبت به ۴۰ دقیقه کدنویسی وارد می‌کند. خمارگی هوش مصنوعی نتیجه انجام این بازبینی با سرعت بالا برای ۶ ساعت متوالی است.
این وضعیت توسط دو عامل پیش می‌راند:
۱. مدل‌سازی آگاهانه: نیاز به ساخت دستی مدل ذهنی برای کدی که توسعه‌دهنده نویسنده آن نبوده است.
۲. هوشیاری پایدار: عدم امکان اعتماد کامل به خروجی، که نیازمند سطح ثابتی از توجه شدید از اولین پرامپت تا آخرین خط کد است.
توجه مستمر بدون وقفه‌های طبیعی، روشی شناخته شده برای فرسودگی کامل یک انسان است. این یعنی اگرچه عامل‌ها خروجی را افزایش می‌دهند — و کاری که دو هفته زمان می‌برد را به یک بعدازظهر تبدیل می‌کنند — اما هم‌زمان ممکن است مدت‌زمان عملکرد اوج شناختی برنامه‌نویس را کاهش دهند.
گلوگاه از کیبورد به قشر پیش‌پیشانی (Prefrontal Cortex) مغز منتقل شده است. برای مدیریت این وضعیت، توسعه‌دهندگان باید بپذیرند که شغلشان بدون اینکه متوجه شوند تغییر کرده است. برخورد با این وضعیت به عنوان «خستگی ناشی از حجم کار» منجر به مدیریت نادرست می‌شود؛ این در واقع شکست در ظرفیت تصمیم‌گیری است. در این حالت، تنها خواب عمیق (و نه یک چرت کوتاه) می‌تواند وضعیت را حل کند.
باید منتظر تحقیقات نوظهور درباره «بار شناختی» در جریان‌های کاری عامل‌محور (Agentic Workflows) بود، زیرا صنعت ممکن است نیاز داشته باشد تعریف «ساعات بهره‌ور» را برای محاسبه هزینه بالاتر بازبینی‌های کمک‌گرفته از هوش مصنوعی، بازتعریف کند.
گام بعدی شما
- زمان‌های بازبینی کد را به بلوک‌های کوتاه (حداکثر ۹۰ دقیقه) تقسیم کنید و بین آن‌ها وقفه‌هایی بدون صفحه نمایش قرار دهید.
- برای کاهش بار مدل‌سازی ذهنی، از عامل بخواهید قبل از تولید کد، استراتژی و منطق خود را به صورت متنی توضیح دهد.
- علائم «از دست دادن توان تصمیم‌گیری» را شناسایی کنید و در آن لحظه هرگونه بازبینی کد را متوقف کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو