چرا سرعتِ تولید کد منجر به بازگشت به تکنولوژی‌های سنتی می‌شود؟

اگر امروز احساس می‌کنید با کمک هوش مصنوعی سریع‌تر کد می‌زنید، احتمالاً در حال قرض گرفتن زمان از آینده هستید. طبق پژوهش‌های GitClear و METR که در سپتامبر ۲۰۲۶ منتشر شد، کاهش ۱۹ درصدی در بهره‌وری کلی، هزینه پنهان انفجار کدنویسی با هوش مصنوعی است. در حالی که توسعه‌دهندگان احساس می‌کنند در نوشتن کدهای تکراری (Boilerplate) سریع‌تر شده‌اند، اما زمان صرف شده برای عیب‌یابی و ایمن‌سازی کدهای تولید شده توسط هوش مصنوعی، منجر به یک ضرر خالص در کارایی شده است.

این اتفاق در حالی رخ می‌دهد که صنعت به دیواری به نام «خستگی از نگهداری» برخورد کرده است. سال‌ها هدف ما رسیدن به سرعت نامحدود از طریق فریم‌ورک‌های جدید، معماری‌های پیچیده و هوش مصنوعی بود. اما اکنون مدیران مهندسی دریافته‌اند سرعتی که در سال ۲۰۲۴ به دست آوردند، در واقع وام‌هایی بود که با وثیقهٔ پایداری سیستم در آینده گرفته شده بود. این نگرانی‌ها با رویکردهای جدیدی در سطح کلان همسو است؛ چنان‌که برخی از آزمایشگاه‌های پیشرو برای نظارت مستقل بر سرعت توسعه پیشنهاداتی را برای تنظیم سرعت پیشروی در این حوزه ارائه داده‌اند. ما سال‌ها در تعقیب تجربه لذت‌بخش و آدرنالین‌زای «چیزهای جدید» بوده‌ایم، اما اکنون منظره از بالای این قله، بحرانی از مشقت‌های عملیاتی است.

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

پارادوکس اعتماد و مالیات «تقریباً درست»

داده‌های Uvik Software در سال ۲۰۲۶ یک تناقض تلخ را نشان می‌دهد. پذیرش هوش مصنوعی میان برنامه‌نویسان به ۸۴٪ رسیده است، اما اعتماد به صحت خروجی‌ها به ۲۹٪ سقوط کرده است؛ این یک کاهش شدید نسبت به نرخ اعتماد ۴۰ درصدی است که در سال ۲۰۲۴ مشاهده می‌شد. حتی Claude Sonnet که با رضایت ۶۷.۵ درصدی محبوب‌ترین مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — است، نتوانسته این شکاف اعتماد را پر کند.

این وضعیت منجر به سرخوردگی از خروجی‌های «تقریباً درست» شده است. کدها منطقی به نظر می‌رسند، به‌طور کامل کامپایل می‌شوند و از فیلترهای Lint عبور می‌کنند، اما حاوی اشتباهات منطقی هستند که عیب‌یابی آن‌ها دو برابر زمان تولیدشان طول می‌کشد. برای ۶۶٪ برنامه‌نویسان، این خروجی‌های «تقریباً درست» دیگر یک میان‌بر نیستند، بلکه یک «مالیات بهره‌وری» هستند. وقتی در این مقیاس در حال «پرت کردن زغال» به درون یک سیستم هستید، مواجهه با هوش مصنوعی اعتماد ایجاد نکرده، بلکه مسئولیت‌های خطرناک و بدهی‌های فنی را آشکار کرده است. این چالش‌های ایمنی و پایداری باعث شده تا چهره‌های شاخص صنعت، از جمله مدیرعامل آنتروپیک، بر لزوم کاهش سرعت توسعه برای تضمین ایمنی سیستم‌ها تأکید کنند.

بازگشت به معماری یکپارچه

پیچیدگی بیش از حد باعث شروع «مهاجرت معکوس» شده است. سازمان‌های بزرگی مثل Amazon Prime Video، Segment و Istio در حال رها کردن میکروسرویس‌های توزیع‌شده و بازگشت به معماری‌های یکپارچه (Monolithic) هستند. این چرخش بر اساس پنج یافته کلیدی است:

• هزینه: معماری‌های توزیع‌شده هزینه‌های عملیاتی و حاشیه‌ای عظیمی را تحمیل می‌کنند.
• پیچیدگی: مدیریت ده‌ها مخزن کد (Repository) و کتابخانه‌های مشترک متضاد، یک کابوس برای نگهداری ایجاد می‌کند.
• مقیاس‌پذیری: سربارهای ارکستراسیون، مانند AWS Step Functions، اغلب همان گلوگاه‌هایی را ایجاد می‌کنند که قرار بود حل کنند.
• عملکرد: سربارهای شبکه و پدیده «مسدود شدن ابتدای صف» (Head-of-line blocking) بین سرویس‌ها، تجربه کاربر را تخریب می‌کند.
• سازمان: وقتی تیم کوچکی مجبور است زیرساخت یک غول را مدیریت کند، «قانون کانوی» (Conway’s Law) به یک نقطه ضعف تبدیل می‌شود.

به نقل از گزارش‌های داخلی، Amazon Prime Video با فاصله گرفتن از میکروسرویس‌های بدون سرور (Serverless)، هزینه‌های زیرساختی خود را ۹۰٪ کاهش داد. به همین ترتیب، Istio برای فرار از مشقت ناشی از گسترش بی‌رویه میکروسرویس‌های خود، صفحه کنترل (Control Plane) خود را در Istiod یکپارچه کرد. این روند به نفع «یکپارچهٔ ماژولار» است که مرزهای منطقی تمیزی دارد اما مالیات سیستم‌های توزیع‌شده یا سربارهای شبکه میکروسرویس‌ها را نمی‌گیرد.

اقتصاد توکن‌های نوآوری

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

مدیریت «حضور اهریمنی»

تکنولوژی‌های جدید ریسک «حضور اهریمنی» یا همان «ناشناخته‌های ناشناخته» را با خود می‌آورند. در مقابل، ابزارهای بالغی مثل Postgres یا MySQL «ناشناخته‌های شناخته‌شده» هستند. مهندسان دقیقاً می‌دانند این ابزارها زیر فشار کجا شکست می‌خورند، چون صنعت ۲۰ سال است که در حال مستند کردن این خرابی‌ها و ویرانه‌هاست.

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

کمی‌سازی بدهی فنی هوش مصنوعی

هوش مصنوعی کدها را بازنویسی (Refactor) نمی‌کند، بلکه آن‌ها را تکثیر می‌کند. برای نخستین بار در تاریخ تحلیل کد در مقیاس بزرگ، حجم کدهای «کپی-پیست» از کدهای «جابه‌جا شده» پیشی گرفته است. این یک «توهم بهره‌وری» ایجاد می‌کند که در آن برنامه‌نویس در کوتاه‌مدت ۲۰٪ سریع‌تر است، اما در مجموع کندتر می‌شود.

• تغییرات کد (Code Churn): درصد کدهایی که ظرف دو هفته بازبینی یا حذف شدند، از ۳.۱٪ در سال ۲۰۲۰ به ۵.۷٪ در سال ۲۰۲۴ رسید.
• بازسازی کد (Refactoring): این تمرین حیاتی ۶۰٪ کاهش یافته است، زیرا هوش مصنوعی ترجیح می‌دهد کد جدید اضافه کند تا منطق موجود را بهبود بخشد.
• امنیت: درخواست‌های ادغام (PR) که با کمک هوش مصنوعی نوشته شده‌اند، ۲.۷۴ برابر بیشتر احتمال دارد آسیب‌پذیری داشته باشند. به‌طور مشخص، ۲۹.۱٪ از کدهای پایتون تولیدشده توسط Copilot دارای نقاط ضعف امنیتی بالقوه هستند.

در عصر «سریع حرکت کن»، ما سریع‌تر نمی‌سازیم؛ بلکه در حال تولید بدهی فنی با سرعتی شتابان هستیم.

معماری به مثابه سندی تغییرناپذیر

برای مقابله با از دست رفتن «دانش ضمنی» — همان سندرم «الکس دیگر اینجا کار نمی‌کند» — استفاده از سند تصمیمات معماری مارک‌داون (MADR) به یک ضرورت برای بقا تبدیل شده است. وقتی دلیل یک مرز سیستمی با خروج یک مهندس ارشد از شرکت ناپدید شود، آن سیستم به یک بدهی خطرناک و پایان‌دهنده تبدیل می‌شود.

یک سند ADR واقعی به سبک نایگارد (Nygard) باید چهار بخش مشخص داشته باشد:

• وضعیت: حالت فعلی تصمیم.
• زمینه: دلیل و چرایی نیاز به این تصمیم.
• تصمیم: مسیر انتخاب شده.
• پیامدها: تبادل‌های صادقانه (Trade-offs).

بسیاری از تیم‌ها در بخش پیامدها شکست می‌خورند چون از صداقت می‌گریزند. یک ADR سطح ارشد باید صراحتاً بگوید: «ما گلوگاه‌های نوشتن را در ازای تضمین‌های ACID می‌پذیریم.» اگر در سند هیچ نکته «بد» یا منفی‌ای ذکر نشده، آن سند یک بروشور تبلیغاتی است، نه یک تصمیم مهندسی.

تا سال ۲۰۲۶، عامل‌های هوش مصنوعی (AI Agents) برای استدلال روی این مجموعه‌اسناد ADR به کار گرفته می‌شوند تا «انحراف معماری» را شناسایی کنند. وقتی کد از قصد و نیت مستند شده فاصله می‌گیرد، هوش مصنوعی این تناقض را علامت‌گذاری می‌کند تا تضمین شود سیستم با طراحی اصلی خود همسو باقی می‌ماند.

این نقطه پایان عصر «پذیرش مهندسی» است. مأموریت جدید مهندسان ارشد، «حکمرانی مهندسی» است: دانستن اینکه چه زمانی به یک فروشنده خارجی «نه» بگویند و چه زمانی یک سرویس را دوباره به یک سیستم یکپارچه تبدیل کنند. هدف دیگر یافتن ابزارهای براق نیست، بلکه تضمین این است که محصول تا سال ۲۰۳۰ زنده بماند، نه اینکه به کارآمدترین تولیدکننده بدهی فنی در ساختمان تبدیل شود.

گام بعدی شما

• بررسی مجدد معماری‌های توزیع‌شده در پروژه‌هایتان و ارزیابی امکان بازگشت به مدل‌های یکپارچه ماژولار برای کاهش هزینه‌ها.
• پیاده‌سازی اجباری اسناد MADR برای هر تصمیم کلیدی معماری، با تأکید ویژه بر بخش «پیامدها و نقاط ضعف».
• بازنگری در استراتژی استفاده از هوش مصنوعی؛ جایگزینی «تولید سریع کد» با «بازبینی سخت‌گیرانه» برای کاهش نرخ Code Churn.

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