تصور کنید برنامهنویسی در شرکتی هستید که دیگر کسی نمیداند مسئولیت نهاییِ یک خط کد با کیست. اگر امروز یک مهندس نرمافزار هستید، احتمالاً متوجه شدهاید که زمان بیشتری را صرف خواندن کدهای تولید شده توسط ماشین میکنید تا تایپ کردن آنها.
طبق گزارش Digital Applied در نظرسنجی سه ماهه اول سال ۲۰۲۶ از ۲٬۸۴۷ توسعهدهنده، مهندسان اکنون ساعات بیشتری را به بازبینی کدها اختصاص میدهند تا نوشتن خطوط جدید. این یک چرخش کامل نسبت به سال ۲۰۲۴ است؛ زمانی که نوشتن کد، چهار ساعت پیشتازِ بازبینی بود. این دادهها نشان میدهند که بازبینی حالا به بزرگترین «بلعنده زمان» در جریانهای کاری کمکگرفته از هوش مصنوعی تبدیل شده است.
در دنیای قدیمی، مرز بین «کسی که کد میزند» و «کسی که مدیریت میکند» کاملاً شفاف بود. در آن دوران، مهندسان مالکیت کیفیت اجرا را بر عهده داشتند و مدیران مالکیت اولویتها، تخصیص منابع و مدیریت افراد را بر عهده میگرفتند. اما امروز عاملهای هوش مصنوعی (AI Agents) — شبیه دستیاران هوشمندی که میتوانند تکالیف پیچیده را به طور مستقل پیش ببرند — این مرز را از بین میبرند. این تحول با ظهور عاملهای کدنویسی جدیدی که مستقیماً کد تولیدی ارسال میکنند شتاب گرفته است. همانطور که در تحلیلهای پیشین ما دربارهی امنیت مدلهای بازمتن دیدیم، سرعت رشد ابزارها همیشه سریعتر از تغییر ساختارهای سازمانی است. این موضوع اکنون یک خلاء در مالکیت ایجاد کرده که اغلب مستقیماً به شکستهای عملیاتی در محیط تولید منجر میشود.
همگرایی نقشها
بر اساس بررسیهای The Pragmatic Engineer روی ۹۰۰ مدیر در سال ۲۰۲۶، روتین روزانه یک مهندس ارشد اکنون بیشتر شبیه به «هماهنگکننده» است تا کدنویس و شامل جابجاییهای مداوم زمینه (Context-switching) است. این تغییر رویکرد را میتوان نتیجهی تغییر پارادایم برنامهنویسی ارشد از تولید خط به خط به ارکستراسیون دانست. یک روز کاری معمولی، برای مثال یک سهشنبه، ممکن است اینگونه باشد:
- اجرای دو فرآیند عاملمحور (Agentic) پیش از جلسه صبحانه یا استندآپ.
- بازبینی انبوهی از درخواستهای ادغام (Pull Requests) تولید شده توسط مدل در اواسط صبح.
- اصلاح تنظیمات یک پرامپت که باعث تولید تستهای ناپایدار و متناقض (Flaky tests) شده است.
- جابجایی سریع بین سه ابزار مختلف پیش از ناهار.
همزمان، مدیران مهندسی (EMs) دوباره به فضای کد بازگشتهاند. چون هوش مصنوعی عاملمحور مانع ورود به کد را پایین آورده، مدیران اکنون بین جلسات یکبهیک (One-on-ones)، نمونههای اولیه و اصلاحات را مستقیماً ارسال میکنند. این روند باعث میشود فاصله فنی مدیران از کد (که معمولاً بعد از دو سال مدیریت ایجاد میشود) و زوال مهارتهای عملی آنها متوقف شود. در واقع مهندسان از یک سو و مدیران از سوی دیگر به هم نزدیک میشوند و نقشها بهشدت مشابه میشوند.
این وضعیت یک «شکاف مالکیت» خطرناک ایجاد میکند. وقتی عاملها بخش بزرگی از کد یک ویژگی را میزنند، کسی که عامل را هدایت میکند، در واقع دارد تصمیمات تخصیصی میگیرد — یعنی تصمیم میگیرد چه تکالیفی به ماشین سپرده شود، چه بخشهایی انسانی بماند و هر خروجی چقدر نیاز به بررسی دقیق داشته باشد. این وظیفه قبلاً کاملاً در حیطه مدیریت بود. در مقابل، وقتی یک مدیر یک اصلاحیه AI-assisted را ادغام میکند، دوباره وارد محیط تولیدی میشود که طبق ساختار سازمانی، قرار بود از دور و با فاصله نظارت کند.
هزینه تاریِ نقشها
تأثیر این ابهام در نقشها، قابل اندازهگیری و اغلب منفی است:
- کیفیت برنامه: در نظرسنجی مارس ۲۰۲۶ شرکت SmartBear از ۲۷۳ رهبر نرمافزاری، ۷۰٪ گزارش دادند که با تسریع توسعه توسط AI، کیفیت برنامهها پیش از این کاهش یافته است.
- استیصال توسعهدهندگان: نظرسنجی سال ۲۰۲۵ Stack Overflow نشان داد ۴۵٪ توسعهدهندگان، عیبیابی زمانبرِ کدهای تولید شده توسط AI را به عنوان یکی از اصلیترین عوامل سرخوردگی و استیصال میدانند.
- تغییر خروجی: مطالعه دانشگاه Tilburg روی پذیرش Copilot در پروژههای متنباز نشان داد توسعهدهندگان اصلی ۶.۵٪ بیشتر بازبینی کردهاند، در حالی که خروجی اصلی (کدنویسی) آنها ۱۹٪ کاهش یافته است.
یک مثال واقعی، تیمی است که سه گروه مختلف همزمان در حال بهبود یک جریان کاری AI بودند. تیم مهندسی مدل را برای کاهش تأخیر (Latency) ارتقا داد، تیم AI پرامپتها و تنظیمات تولید بازیابیافزا (RAG) — شبیه دانشآموزی که قبل از جواب دادن، اول کتاب را باز میکند تا دقیق باشد — را برای کیفیت پاسخ بهبود داد و تیم عملیات قوانین تجاری را بهروز کرد که عامل باید از آنها پیروی میکرد. هر سه تیم تغییرات خوبی ارسال کردند و اهداف محلی خود را زدند، اما یک ماه بعد، دقت کلی سیستم افت کرد. هیچ تغییری به تنهایی مقصر نبود؛ بلکه تعامل میان این سه تغییر مشکلساز شد. چون همه بخش خود را بهینه کردند، هیچکس «مالک کل سیستم» نبود.
این نبودِ مالکیت، در جلسات کالبدشکافی (Post-mortem) بحران ایجاد میکند. وقتی یک مدیر کدی را ادغام میکند و دو هفته بعد یک حادثه در محیط تولید (Production Incident) رخ میدهد، مشخص نیست مقصر کیست: مهندسی که PR را تایید کرد، تیمی که پرامپت را تنظیم کرد، تیم پلتفرمی که مدل را انتخاب کرد، یا مدیر محصولی که جریان کار را تعریف کرد. در واقع تیمها هزینه AI را دوبار پرداخت میکنند: یک بار برای هزینه توکنها و بار دوم برای هزینههای هماهنگی و سربار مدیریتی جهت یافتن اینکه چه کسی مسئول خروجی است.
بازطراحی برای عصر عاملمحور
نیک تالوار (Nick Talwar)، مدیر فناوری و مهندس سابق مایکروسافت، برای رفع این سردرگمی و پوشش دادن این تداخلات، بازطراحی چهارجانبه سازمان را پیشنهاد میکند:
- مسئولیت واحد: برای هر سطح از کد، یک بازبین مسئول تعیین شود. تمام PRهای تولید شده توسط عامل باید یک مالک انسانی داشته باشند که نامش به تفکیک ناحیه کد در فایل
CODEOWNERS.mdنوشته شده باشد. چه مهندس باشد و چه مدیر، یک نام باید برای تضمین کیفیت در برابر افزایش حجم کدها مسئول باشد. - مرزهای مدیریتی: قوانین صریحی برای مشارکت مدیران در کد وضع شود. اگر مدیر کدی میزند، باید همان مسیر بازبینی عادی را طی کند که همه طی میکنند و محدوده کاری او باید محدود بماند. تولید نمونههای اولیه، ابزارهای داخلی و Spikeها مناسب هستند، اما ویژگیهای مسیر حیاتی (Critical-path) نباید توسط مدیر ارسال شوند. مدیری که مالک کدهای تولیدی میشود، در واقع مهندسی است که مشکل گزارشدهی و سلسلهمراتب دارد.
- بهروزرسانی شرح شغل: «هماهنگسازی» (Orchestration) باید وارد شرح شغل مهندس شود. ساعتهایی که صرف هدایت عاملها، نوشتن ارزیابیها (Evals) و نگهداری تنظیمات پرامپتها میشود، باید در ارزیابی عملکرد به عنوان کار مهندسی پذیرفته شود. اگر معیارهای ارتقاء شغلی هنوز بر اساس خطوط کدنویسی دستی باشد، مهندسان برای شغل قدیمی بهینه میکنند در حالی که کار واقعی اندازه گرفته نمیشود.
- بازسازی مدیریت: نقش مدیر مهندسی باید حول محور چیزهایی بازسازی شود که AI به جا گذاشته است. این شامل مذاکره با ذینفعان، تصمیمات میانتیمی، توسعه مسیر شغلی کارکنان و قضاوتهایی است که عاملها به طور مداوم در آنها شکست میخورند. ارزش این مسئولیتها هرچه بیشتر شود، چون هر چیزی در اطراف آنها خودکار میشود.
از آنجا که ابزارهای AI سریع تغییر میکنند، این تعریفهای نقش باید هر سه ماه یک بار بازبینی شوند. یک چارت سازمانی در واقع ادعایی است درباره نحوه انجام کار؛ اگر ابزارها تغییر کنند و چارت ثابت بماند، سازمان بر اساس یک دروغ عمل میکند. تیمهای موفق یک عادت دارند: هر تغییر در نقشها را مکتوب میکنند. با نامگذاری دقیق نقشهای مهندسانی که عاملها را مدیریت میکنند و مدیرانی که با کد درگیر هستند، رهبران میتوانند همگرایی نقشها را به عنوان یک «مشکل طراحی» حل کنند.
گام بعدی شما
- اگر مدیر هستید، مرز کدنویسی خود را تعریف کنید تا از تداخل مالکیت جلوگیری شود.
- اگر مهندس هستید، زمان صرف شده برای بازبینی و تنظیم پرامپتها را به عنوان «کار فنی» مستند کنید.
- فایل
CODEOWNERS.mdپروژه خود را برای پذیرش کدهای تولیدی AI بازنگری کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو