اگر تصور می‌کنید با ابزارهای هوش مصنوعی، سرعت تحویل ویژگی‌های جدید به دست مشتری دو برابر می‌شود، احتمالاً بخشی از واقعیت را نادیده گرفته‌اید. حقیقت این است که نوشتن کد، به‌ندرت کندترین بخشِ ساخت یک نرم‌افزار است. تحویل واقعی یک قابلیت، بیش از آنکه به سرعت تایپ وابسته باشد، به شبکه‌ای پیچیده از تفاهمات انسانی و سیاست‌های سازمانی گره خورده است؛ مسائلی که هیچ پرامپتی نمی‌تواند آن‌ها را حل کند.
اکثر تیم‌های مهندسی در دنیایی زندگی می‌کنند که مرحله «تایپ کردن» تنها بخش کوچکی از کل چرخه است. صنعت در حال حاضر وسواس شدیدی روی سرعت ابزارها دارد، اما همان‌طور که تحلیل اخیر وب‌سایت dev.to نشان می‌دهد، ما در حال بهینه‌سازی مرحله‌ای هستیم که هرگز گلوگاه اصلی نبوده است.
این وضعیت شبیه کارخانه‌ای است که خط تولیدش با سرعت برق پیش می‌رود، اما قطعات با سه هفته تأخیر می‌رسند و نقشه‌های ساخت هر سه‌شنبه تغییر می‌کنند. در چنین شرایطی، سریع‌تر کردن خط تولید باعث تحویل سریع‌تر محصول به مشتری نمی‌شود، بلکه فقط تپه‌ای از کالاهای نیمه‌تمام ایجاد می‌کند که منتظر دستورالعمل هستند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی بهره‌وری تیم‌های فنی اشاره کردیم، ابزارها بدون اصلاح فرآیند، تنها توهم سرعت ایجاد می‌کنند.
توهم ۲۰ درصدی
مدیران مهندسی گزارش می‌دهند که نوشتن کد جدید معمولاً تنها ۱۰ تا ۲۰ درصد از کل زمان تحویل را می‌گیرد. گاهی این عدد حتی کمتر است. ۸۰ درصد باقی‌مانده توسط فعالیت‌هایی بلعیده می‌شود که هوش مصنوعی زاینده (Generative AI) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — نمی‌تواند آن‌ها را خودکار کند:
- گشودن گره‌های وابستگی‌های بالادستی (Upstream Dependencies) که اغلب برای افرادی که خارج از آن حوزه تخصصی هستند، نامرئی است.
- همراستاسازی با ذینفعانی که از آخرین گفتگو تا امروز نظرشان تغییر کرده است.
- عیب‌یابی سیستم‌های عملیاتی برای باگ‌های زنده با استفاده از لاگ‌های ناقص.
- هماهنگ کردن تاریخ‌های ادغام کد بین سه یا چند تیم که ریتم‌های کاری (Sprint Cadences) متفاوتی دارند.
- پیمایش در پایگاه‌های کد عظیم که توسط توسعه‌دهنده فعلی نوشته نشده‌اند.
پژوهش‌های GitHub در سال ۲۰۲۳ این عدم توازن را تأیید کرد و اشاره داشت که توسعه‌دهندگان به اندازه زمان نوشتن کد جدید، وقت خود را صرف انتظار برای بیلدها و تست‌ها می‌کنند. این زمان حتی شامل جلسات، بازبینی‌های امنیتی و ممیزی‌های دستی کد نمی‌شود.
جایی که دستاوردهای AI محو می‌شوند
گزارشی از DORA (پژوهش و ارزیابی DevOps) در مه ۲۰۲۶، شکاف عمیقی را در بازگشت سرمایه (ROI) ابزارهای هوش مصنوعی نشان می‌دهد. مدل‌های آن‌ها ثابت می‌کند که سود واقعی از «سیستم سازمانی» پیرامون ابزار حاصل می‌شود، نه از خودِ ابزار. در واقع، حذف گلوگاه‌هاست که سرعت را بالا می‌برد، نه سرعت تایپ.
- وظایف ساده: در کارهای مجزا و جدید (Greenfield) با معیارهای موفقیت شفاف، هوش مصنوعی ۳۵ تا ۴۰ درصد بهره‌وری را افزایش می‌دهد.
- کدهای قدیمی و پیچیده (Legacy Code): این دستاوردها به ۱۰ درصد یا کمتر سقوط می‌کنند.
کار واقعی در دل پیچیدگی‌هاست، اما محک‌ها (Benchmarks) معمولاً وظایف ساده‌ای را می‌سنجند که هیچ انسانی در چرخه آن‌ها نیست. تحویل واقعی در دنیای واقعی هرگز یک مسئله تمیز با صورت‌مسئله مشخص نیست. این فرآیند شامل مالکان محصولی است که با تیکت‌های جیرا (Jira) خود در تضاد هستند و تیم‌های سرویس‌های پایین‌دستی که تغییرات مخرب (Breaking Changes) را بدون اطلاع قبلی مستقر می‌کنند. هیچ بنچمارک فعلی این اصطکاک‌ها را ثبت نمی‌کند.
توهم بهره‌وری
به نقل از یک تیم مهندسی، آن‌ها اخیراً ادعا کردند که زمان بیلد را ۵۰ درصد کاهش داده‌اند و آن را یک «پیروزی AI» برای یک سرویس مشترک نامیدند که روزانه توسط بیش از بیست توسعه‌دهنده استفاده می‌شد. اما پیروزی واقعی متعلق به یک مهندس ارشد بود که از هوش مصنوعی برای یافتن یک خطای پیکربندی خاص استفاده کرد.
این مهندس مسیرهای اجرا را در زیرساخت‌های تست کانتینری ردیابی کرد و متوجه شد که کامپایل JIT در PostgreSQL — که برای دیتابیس‌های بزرگ تولیدی مفید است — سربار فاجعه‌باری به دیتابیس کوچک تست‌های JUnit آن‌ها اضافه می‌کرد. با خاموش کردن این گزینه، زمان اجرای SQL از ۶۲ دقیقه به ۶ دقیقه رسید.
هوش مصنوعی کمک کرد تنظیمات سریع‌تر پیدا شوند، اما شهود (Intuition) متعلق به انسان بود. دانستن اینکه چه سوالی پرسیده شود، نیازمند حافظه سازمانی است؛ دانشی که از تجربه «سوختن» در مشکلات مشابه در گذشته به دست می‌آید و داشتن حسی نسبت به اینکه کجا را باید بررسی کرد. این همان کاری است که هیچ بنچمارکی آن را نمی‌سنجد.
نیازمندی‌ها و همراستاسازی: کار واقعی
در بسیاری از پروژه‌ها، اثرگذارترین فعالیت مهندسی، نوشتن یک خط کد نیست، بلکه یک گفتگوی ۴۰ دقیقه‌ای با مالک محصول است. چنین گفتگویی می‌تواند مانع از ساخت چیزی شود که اصلاً مورد نیاز نیست. اگرچه این کار باعث می‌شود سرعت اسپرینت ثابت بماند، اما می‌تواند روزها یا هفته‌ها تلاش بیهوده را نجات دهد.
بخش سخت مهندسی، به توافق رساندن پنج نفر با اولویت‌های متفاوت روی تعریف «پایان کار» (Done) است. این یعنی ارتباط درباره موازنه (Trade-off)؛ توضیح اینکه یک ویژگی سریع ممکن است هزینه‌ای داشته باشد که برای ذینفع بسیار ارزشمندتر است. این فعالیت‌ها تعیین می‌کنند که یک پروژه در شش هفته تحویل داده شود یا شش ماه.
ابزارهای کدنویسی در پاسخ به «چطور X را پیاده کنم؟» فوق‌العاده‌اند، اما نمی‌توانند تشخیص دهند که آیا X اصلاً چیز درستی برای پیاده‌سازی است یا خیر. همان‌طور که اندرو دایموند در کتاب Software Engineering in the Age of AI اشاره می‌کند، هوش مصنوعی نمی‌داند آیا کد تولید شده با الزامات قانونی در تضاد است یا با ویژگی‌هایی که تیم دیگر برای فصل آینده برنامه‌ریزی کرده، برخورد دارد. این دانش در ذهن افراد و حافظه سازمانی زندگی می‌کند؛ زمینه‌ای که هرگز مکتوب نشده و در پنجره پرامپت جا نمی‌شود. این تغییر در ماهیت کار باعث شده تا نقش مهندسان نرم‌افزار از کدنویس صرف به رهبران ارکستر ابزارها تغییر کند تا بتوانند پیچیدگی‌های سیستمی را مدیریت کنند.
شکاف هماهنگی
تحویل نرم‌افزار تابع «تئوری محدودیت‌ها» (Theory of Constraints) است، همان‌طور که توسط الیاهو گلدت تعریف شده است. بهبود فرآیندی که گلوگاه نیست، توان عملیاتی کل سیستم را افزایش نمی‌دهد.
- ریاضیات ساده: اگر کدنویسی ۱۵ درصد از چرخه و هماهنگی بین‌تیمی ۴۰ درصد باشد، دو برابر کردن سرعت کدنویسی تنها ۷.۵ درصد از کل زمان را ذخیره می‌کند. اما بهبود ۲۵ درصدی در هماهنگی، ۱۰ درصد از کل زمان را نجات می‌دهد.
هماهنگی، مسئله‌ای مربوط به مذاکره است، نه ترجمه. هوش مصنوعی می‌تواند یک جلسه را خلاصه کند، اما نمی‌تواند آنچه گفته نشده را استخراج کند یا تضاد سیاسی بین دو تیم را حل کند.
به عنوان مثال، یک تیم پلتفرم ابزاری ساخت تا تداخل تغییرات دو تیم در یک مرز سرویس (Service Boundary) در یک اسپرینت واحد را شناسایی کند. شناسایی درست کار کرد و تداخلات را هفته‌ها زودتر نشان داد. اما پذیرش آن متوقف شد چون تیم‌ها به یک پرچم خودکار اعتماد نکردند تا برنامه‌هایشان را تغییر دهند. حل تضاد همچنان نیازمند انسانی با زمینه (Context) کافی برای ایجاد اجماع بود. مشکل اجتماعی بود، نه فنی.
عیب‌یابی تولید و مسئله زمینه
برای مهندسان ارشد، استرس‌زاترین ساعات، صرف نوشتن ویژگی‌ها نمی‌شود، بلکه صرف این می‌شود که بفهمند چرا چیزی که دیروز کار می‌کرد، امروز خراب شده است. عیب‌یابی در محیط تولید نیازمند درک تعاملات سیستم در مرزهای مختلف سرویس‌ها و خواندن لاگ‌های ناقص است؛ جایی که «ناقص» به این معناست که اطلاعات ضروری از ابتدا ارزشمند تشخیص داده نشده تا لاگ شوند.
عیب‌یابی نیازمند دانش سازمانی است: دانستن اینکه یک سرویس پنج‌شنبه گذشته مستقر شده در حالی که تیم دیگر بی‌سروصدا سیاست تلاش مجدد (Retry Policy) را تغییر داده است بدون اینکه دفترچه راهنمای عملیاتی (Runbook) را به‌روز کند. ابزارهای AI برای بازه‌های محدود — مثل تطبیق الگو در لاگ‌ها یا پیشنهاد فرضیه‌ها — مفیدند، اما نمی‌توانند جایگزین زمینه‌ای شوند که در ساعت ۲ صبح برای ردیابی یک Timeout در چهار سرویس و یک صف پیام (Message Queue) نیاز است تا بفهمیم کدام یک از ۱۷ تغییر روزانه، یک وابستگی ترتیب‌بندی (Ordering Dependency) ظریف ایجاد کرده است. در واقع، تکیه بیش از حد به کدهای تولید شده توسط AI بدون درک عمیق، می‌تواند منجر به افزایش چشمگیر زمان دیباگ و ایجاد تله‌های اعتماد کاذب شود که بهره‌وری را به جای افزایش، کاهش می‌دهد.
گلوگاه جدید: تأیید و بازبینی
با ورود عامل‌های هوش مصنوعی (AI Agents) برای اجرای تست‌ها، ردیابی تست‌های شکست‌خورده و باز کردن PRها به‌صورت خودکار، گلوگاه صرفاً به پایین‌دست منتقل شده است. ما در حال ورود به «بحران بازبینی کد» هستیم.
بازبینی و تأیید اکنون گلوگاه‌های جدید زمان بیلد هستند. مدل‌های بازبینی که برای کد انسانی طراحی شده بودند، زیر حجم عظیم پیشنهادات تولید شده توسط عامل‌ها در حال فروپاشی هستند. DORA این وضعیت را یک «منحنی J» توصیف می‌کند: افت بهره‌وری ناشی از سربار تأیید، نه منحنی یادگیری. خودکارسازی ۱۵ درصد از کدنویسی، فقط حجم بیشتری از کار را در صف بازبینی می‌ریزد.
هزینه پیاده‌سازی «ارزان»
وقتی پیاده‌سازی ارزان می‌شود، وسوسه ساخت چیزهای اشتباه افزایش می‌یابد. زمانی که توسط AI ذخیره می‌شود، به‌ندرت صرف تفکر عمیق‌تر یا بهبود نیازمندی‌ها می‌شود؛ بلکه صرف بازبینی کدهای تولید شده، اصلاح پیشنهاداتی که زمینه بحرانی را نادیده گرفته‌اند و جابجایی بین ابزارهای مختلف می‌شود.
سریع‌تر ساختن ویژگی اشتباه، پروژه را زودتر تمام نمی‌کند، بلکه فقط سرعت اتلاف منابع را بالا می‌برد. نظرسنجی شرکت Harness در آوریل ۲۰۲۶ از ۷۰۰ متخصص و مدیر نشان داد: ۹۴ درصد رهبران مهندسی می‌گویند عوامل کلیدی — از جمله بدهی فنی (Tech Debt)، زمان اعتبارسنجی و فرسودگی توسعه‌دهندگان — به‌طور کامل از معیارهای بهره‌وری آن‌ها حذف شده‌اند. ما در حال اندازه‌گیری چیزهایی هستیم که اندازه‌گیری‌شان آسان است و آن را به عنوان تصویر کامل معرفی می‌کنیم.
پرسش دشوار
اگر استراتژی AI شما صرفاً سریع‌تر کردن کدنویسی توسعه‌دهندگان است، در حال بهینه‌سازی مرحله‌ای هستید که از قبل هم گلوگاه نبود. سرعت تحویل شما توسط هر چیزی «به جز کد» محدود شده است: درک، همراستاسازی، هماهنگی، عیب‌یابی و انتظار.
البته صنعت نسبت به این موضوع کور نیست. تحلیل لاگ با AI، تولید بازیابی‌افزا (RAG) روی مستندات، خلاصه‌های خودکار PR و تبدیل جلسات به متن، محصولات واقعی هستند که مشکلات واقعی را حل می‌کنند. آن‌ها باعث می‌شوند یک فرد سریع‌تر یک خط لاگ را پیدا کند یا از جلسه‌ای که از دست داده مطلع شود. اما آن‌ها همچنان در سطح دسترسی اطلاعاتی یک مهندس واحد عمل می‌کنند و به لایه هماهنگی دست نمی‌زنند.
یک استدلال متقابل وجود دارد که AI برای کدنویسی، پله‌ای به سوی مسائل سخت‌تر است. اما کدنویسی مسئله‌ای از «ترجمه» است — تبدیل قصد به دستورالعمل. هماهنگی مسئله‌ای از «مذاکره» است — آشتی دادن قصد‌های متضاد. این دو نیازمند قابلیت‌های بنیاداً متفاوتی هستند. ریسک این است که سازمان‌ها سال‌ها وقت صرف بهینه‌سازی آن ۱۵ درصد کنند، در حالی که سربار ۴۰ درصدی هماهنگی در حال انباشت است.
برای یافتن گلوگاه واقعی، زمان انتقال کد از PR به Merge را نسنجید؛ بلکه بسنجید چقدر طول می‌کشد تا یک «ایده» به چیزی تبدیل شود که مشتری بتواند از آن استفاده کند. اکثر سازمان‌ها این داده‌ها را در تیکت‌های جیرا، گفتگوهای اسلک و دعوت‌نامه‌های تقویم دارند. وقتی می‌بینید ۶ هفته گذشته اما فقط ۳ روز صرف نوشتن کد شده، گلوگاه آشکار می‌شود. شما به ابزار دیگری برای یافتن آن نیاز ندارید؛ فقط باید به جای یک بخش کوچک، به کل مسیر نگاه کنید.
گام بعدی شما
- به جای اندازه‌گیری سرعت کدنویسی، «زمان چرخه» (Cycle Time) از ایده تا استقرار را در جیرا ردیابی کنید.
- روی ابزارهای AI که به «همراستاسازی» و «مستندسازی دانش سازمانی» کمک می‌کنند تمرکز کنید، نه فقط تولید کد.
- فرآیند بازبینی کد (Code Review) خود را برای حجم بالای کدهای تولید شده توسط AI بازنگری کنید تا دچار بحران تأیید نشوید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو