اتوماسیون وظایف تکراری در برابر تخصص ضمنی؛ مرز توانمندی عامل‌های کدنویس

اگر تصور می‌کنید نمرات بالای بنچمارک‌ها به معنای پایان عصر مهندسان تازه‌کار است، احتمالاً تفاوت میان «تولید کد» و «مهندسی نرم‌افزار» را نادیده گرفته‌اید. این باور که کدنویسی عامل‌محور به‌زودی مهندسان جونیور را منسوخ می‌کند، بر پایه یک سوءتفاهم بنیادین درباره نحوه واکنش بازارهای کار به نمرات بنچمارک است. واقعیت این است که در حالی که مدل‌های پیشرو در صدر جدول‌های کدنویسی قرار می‌گیرند، مفاهیمی چون زمینه (Context)، قضاوت و تأیید (Verification) همچنان برای هوش مصنوعی دست‌نیافتنی‌اند. اکثر مدل‌های جدید با عددی منتشر می‌شوند که نسبت به نسخه قبلی رشد کرده است و همین باعث می‌شود بسیاری به این نتیجه برسند که دوران جونیورها به پایان رسیده است. اما این استدلال، تمام مراحل میانی بین یک نمره بنچمارک و پیامدهای بازار کار را نادیده می‌گیرد.

این تنش در حالی رخ می‌دهد که صنعت از تکمیل سادهٔ کد به سمت عامل‌های هوش مصنوعی (AI Agents) حرکت می‌کند. همان‌طور که در تحلیل قبلی ما درباره‌ی برتری مدل‌های کوچک در رقابت عامل‌محور اشاره کردیم، اکنون پرسش اصلی این است که آیا این عامل‌ها می‌توانند وظایف بلندمدتی را که معمولاً به توسعه‌دهندگان سطح جونیور سپرده می‌شود، مدیریت کنند. این گذار در واقع تغییر بنیادین نقش توسعه‌دهنده از یک نویسنده کد به مدیر سیستم است که ساختار مهندسی نرم‌افزار را بازتعریف می‌کند. برای پاسخ به این پرسش باید چهار شرط اساسی را بررسی کرد؛ سه شرط که هنوز محقق نشده‌اند و شرط چهارمی که تحققش باید صنعت را نگران کند.

شکاف قابلیت اطمینان

به نقل از پژوهش‌های METR، «افق زمانی» — یعنی مدت‌زمانی که یک مدل می‌تواند در ۵۰٪ موارد در انجام یک وظیفه موفق شود — از سال ۲۰۱۹ تقریباً هر هفت ماه یک‌بار دو برابر شده است. نسخه ۱.۱ این محک (Time Horizon 1.1)، مجموعه وظایف را ۳۴٪ گسترش داد و تعداد وظایفی که ۸ ساعت یا بیشتر زمان می‌برند را دو برابر کرد. داده‌های بازه ۲۰۲۴ تا ۲۰۲۶ نشان می‌دهد این روند شتاب گرفته و افق زمانی مدل‌های پیشرو به چند ساعت رسیده است.

با این حال، نرخ موفقیت ۵۰٪ برای جایگزینی نیروی انسانی معیار کافی نیست. داده‌های Kwa et al واقعیت تلخ‌تری را نشان می‌دهد:

• سیستم‌های پیشرو در وظایفی که کمتر از ۴ دقیقه زمان می‌برند، تقریباً بی‌نقص هستند.
• در وظایفی که بیش از ۴ ساعت تلاش انسانی می‌طلبند، نرخ موفقیت به کمتر از ۱۰٪ می‌رسد.
• افق زمانی برای رسیدن به قابلیت اطمینان ۸۰٪، به‌شدت کوتاه‌تر از رقم ۵۰٪ است.

علاوه بر این، METR اشاره می‌کند که بنچمارک‌های آن از وظایفی مستقل و با تعریف دقیق استفاده می‌کنند. چارچوب آن‌ها این است که یک وظیفه دو ساعته، نشان‌دهنده کاری است که فردی «بدون هیچ پیش‌زمینه‌ای» در دو ساعت انجام می‌دهد، نه کاری که یک مهندس مسلط به کدبیس (Codebase) انجام می‌دهد. این دقیقاً همان جایی است که دنیای واقعی با بنچمارک‌ها تفاوت می‌کند و ساختار این تست‌ها برای مهندسی واقعی نامناسب است.

زمینه در برابر مشخصات

شش ماه اول کاری یک مهندس جونیور تقریباً به‌طور کامل صرف کسب «زمینه» می‌شود. این یعنی یاد بگیرد کدام سرویس مالک یک تابع خاص است، چرا یک انتزاع (Abstraction) خاص ایجاد شده و برای راهنمایی به چه کسی مراجعه کند. بنچمارک‌ها دقیقاً بخشی از شغل را می‌سنجند که سخت‌ترین عنصر آن — یعنی فقدان زمینه قبلی — از آن حذف شده است. در واقع، بنچمارک‌ها توانایی حل مسئله را می‌سنجند، اما مهندسی نرم‌افزار درباره مدیریت پیچیدگی در محیط‌های نامشخص است.

بحران بنچمارک‌ها

در فوریه ۲۰۲۶، شرکت OpenAI گزارش نمرات SWE-bench Verified را متوقف کرد و به دیگران نیز توصیه کرد همین کار را کنند. آن‌ها به نقص‌های جدی در مجموعه داده‌ها اشاره کردند که باعث می‌شد اعداد بهتر از واقعیت به نظر برسند.

• تست‌های معیوب: بررسی یک زیرمجموعه ۲۷.۶ درصدی نشان داد که ۵۹.۴٪ از مسائل دارای تست‌های معیوبی بودند که حتی راهکارهای درست را رد می‌کردند.
• آلودگی داده‌ها: مدل‌های پیشرو می‌توانستند «وصله‌های طلایی» (Gold Patches) و جزئیات دقیق مسائل را به‌صورت کلمه به کلمه بازتولید کنند که نشان‌دهنده نشت داده‌ها در مرحله آموزش است.

در حالی که نمرات مدل‌های پیشرو در ۶ ماه از ۷۴.۹٪ به ۸۰.۹٪ رسیده بود، OpenAI تردید کرد که آیا این پیشرفت مربوط به توانایی مدل است یا ویژگی‌های مجموعه داده. پاسخ این بود که عمدتاً مربوط به داده‌هاست. وقتی مدل‌ها در SWE-bench Pro (که سخت‌تر و پاک‌تر است) آزمایش شدند، عملکردشان به‌شدت سقوط کرد و بسیار پایین‌تر از ارقامی قرار گرفت که در پست‌های معرفی محصول استفاده شده بود. اکنون مجموعه‌های جدیدتری مانند Terminal-Bench و بنچمارک‌های تکامل افق زمانی بلند در حال ساخت هستند تا این شکاف‌ها را پر کنند.

گلوگاه تأیید

یکی از بحرانی‌ترین شکست‌های کدنویسی عامل‌محور، هزینهٔ تأیید است. یک آزمایش کنترل‌شده تصادفی توسط METR با حضور ۱۶ توسعه‌دهنده باسابقه در ۲۴۶ وظیفه واقعی در مخازن (Repositories) خودشان، شکاف عجیبی را در ادراک بهره‌وری نشان داد:

• پیش‌بینی: توسعه‌دهندگان انتظار افزایش ۲۴ درصدی سرعت را داشتند.
• ادراک: پس از اجرا، تخمین زدند که ۲۰٪ سریع‌تر بوده‌اند.
• واقعیت: آن‌ها در حقیقت ۱۹٪ کندتر شده بودند.

این یعنی در حالی که تولید کد ارزان شده، بار شناختی لازم برای تأیید خروجی هوش مصنوعی کاهش نیافته است. ابزارهای مورد استفاده مربوط به اوایل سال ۲۰۲۵ بودند و نمونه‌ها شامل توسعه‌دهندگان با تجربه‌ای بودند که کدبیس‌های بالغ خود را به‌خوبی می‌شناختند. اگرچه این یک تخمین جهانی برای بهره‌وری نیست، اما شکاف ادراکی یک یافته پایدار است: انسان‌ها در مورد جهت تغییر بهره‌وری خود تحت اندازه‌گیری، اشتباه می‌کنند.

معیارهای اعتماد و پایداری

این موضوع در نظرسنجی ۲۰۲۵ Stack Overflow از ۴۹,۰۰۰ توسعه‌دهنده نیز تکرار شد؛ ۸۴٪ از ابزارهای هوش مصنوعی استفاده می‌کنند یا قصد استفاده دارند، اما ۴۶٪ به‌طور فعال به دقت خروجی‌ها بی‌اعتماد هستند، در حالی که تنها ۳۳٪ به آن‌ها اعتماد دارند. تنها ۳٪ گزارش داده‌اند که اعتماد بالایی دارند و در میان توسعه‌دهندگان باسابقه، نرخ بی‌اعتمادی شدید به ۲۰٪ می‌رسد.

به همین ترتیب، پژوهش DORA از گوگل روی حدود ۵,۰۰۰ متخصص نشان داد که اگرچه ۹۰٪ از هوش مصنوعی استفاده می‌کنند و بیش از ۸۰٪ معتقدند بهره‌وری بالا رفته، اما ۳۰٪ هیچ اعتمادی به کدهای تولیدشده ندارند. نتیجهٔ DORA این است که هوش مصنوعی یک «تقویت‌کننده» است؛ یعنی هر چه سازمان هست را بزرگ‌نمایی می‌کند. در حالی که نرخ خروجی (Throughput) نسبت به سال قبل بهبود یافته، اما ناپایداری در تحویل (Delivery Instability) تغییری نکرده است. اکنون ظرفیت بررسی کد — که در واقع زمان مهندسان ارشد است — به گلوگاه اصلی تبدیل شده است.

فروپاشی نظام شاگردی

با وجود این محدودیت‌های فنی، شرکت‌ها از همین حالا الگوهای استخدام خود را تغییر داده‌اند. داده‌های Stanford Digital Economy Lab که داده‌های حقوق و دستمزد ADP (که تقریباً یک نفر از هر شش کارگر آمریکایی را پوشش می‌دهد) رصد می‌کند، انحراف شدیدی را در استخدام افراد ۲۲ تا ۲۵ سال در نقش‌های در معرض هوش مصنوعی (از جمله توسعه نرم‌افزار) نشان می‌دهد:

• جولای ۲۰۲۵: کمبود استخدام برای این گروه سنی ۱۵٪ بود.
• ژوئن ۲۰۲۶: این رقم به ۱۹٪ افزایش یافت.

این تغییر از طریق کاهش استخدام رخ می‌دهد، نه اخراج؛ یعنی درها در حال بسته شدن هستند. تحلیل استنفورد می‌گوید استخدام در مشاغلی که بر «دانش کدگذاری‌شده» (Codified Knowledge) مانند مستندات و رویه‌های استاندارد متکی هستند کاهش یافته، اما در مشاغلی که بر «دانش ضمنی» (Tacit Knowledge) متکی‌اند (که از طریق تمرین و منتورینگ به دست می‌آید)، افزایش یافته است. این روند مستقیماً به تغییر نقش برنامه‌نویسان تازه‌کار از کدنویسی صرف به بازبینی و ارکستراسیون AI منجر شده است.

شکاف دانش ضمنی

این وضعیت یک ریسک سیستمی ایجاد می‌کند: شرکت‌ها دقیقاً همان وظایفی را خودکار می‌کنند که جونیورها برای کسب دانش ضمنی به آن‌ها نیاز دارند تا بتوانند در آینده ارشد شوند. دانش کدگذاری‌شده چیزی است که جونیور با خود می‌آورد؛ دانش ضمنی چیزی است که باید با انجام کارهای ساده و کدگذاری‌شده تحت نظارت به دست آورد تا زمانی که بخش ضمنی در ذهن او نهادینه شود. ما در واقع در حال حذف مرحلهٔ شاگردی هستیم، در حالی که هنوز به خروجی‌های آن مرحله (مهندسان ارشد) نیاز داریم.

تغییر مفروضات میدان

برای جامعه فنی، این بدان معناست که گلوگاه دیگر توانایی تولید کد نیست، بلکه ظرفیت بررسی و قضاوت مهندسان ارشد است. کدنویسی عامل‌محور جایگزین مهندسان جونیور نمی‌شود، بلکه جایگزین وظایفی می‌شود که ما به جونیورها می‌دادیم؛ این دو موضوع متفاوت‌اند و دومی پیامدهای بدتری دارد. شرکت‌هایی که صرفاً بر اساس نمرات بنچمارک، تعداد جونیورها را کم می‌کنند، در حال تخریب خط لوله استعدادهای خود در بلندمدت هستند.

مزیت رقابتی واقعی متعلق به شرکت‌هایی خواهد بود که این آزمایش خسته‌کننده را انجام دهند: استخدام جونیورها را ادامه دهند، از روز اول به آن‌ها عامل‌های هوش مصنوعی بدهند و بسنجند که آیا این افراد سریع‌تر از نسل قبلی به سطح قضاوت ارشد می‌رسند یا خیر. حدس من این است که بله، به‌طور قابل‌توجهی سریع‌تر می‌رسند. اما تعداد کمی از شرکت‌ها این مطالعه را تامین مالی می‌کنند، چون عددی برای گزارش‌های مالی سه ماهه تولید نمی‌کند.

برای تغییر این نتیجه‌گیری، باید شواهد مشخصی را ببینیم:

• افق زمانی قابلیت اطمینان ۸۰٪ که یک روز کاری کامل را در وظایفی «با زمینه قبلی» پوشش دهد، نه وظایفی مستقل.
• نمره بالای ۶۰٪ در یک بنچمارک بلندمدت، خصوصی و بدون آلودگی داده.
• تکرار آزمایش METR به‌گونه‌ای که زمان اندازه‌گیری شده و زمان ادراک‌شده در یک جهت باشند.
• کاهش ناپایداری تحویل در گزارش‌های DORA برای دو سال متوالی در حالی که پذیرش هوش مصنوعی ثابت بماند.
• کاهش شکاف استخدامی ۲۲ تا ۲۵ سالگان استنفورد در حالی که نمرات مواجهه با هوش مصنوعی بالا می‌رود.

گام بعدی شما

• اگر مدیر فنی هستید، به‌جای کاهش استخدام جونیورها، مدل «جونیور + عامل» را پیاده کنید و سرعت رسیدن آن‌ها به سطح ارشد را رصد کنید. برای مدیریت بهینه این فرآیند، می‌توانید از ماتریس قطعیت در برابر پرامپت‌نویسی برای تفویض وظایف به عامل‌ها استفاده کنید.
• اگر توسعه‌دهنده ارشد هستید، روی مهارت‌های «بررسی و تأیید» (Review) تمرکز کنید، زیرا این تنها ارزش افزوده شما در عصر تولید ارزان کد است.
• از ابزارهای جدیدی مانند Terminal-Bench برای سنجش واقعی توانایی عامل‌ها در محیط‌های پیچیده استفاده کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.