هزینهٔ نگهداری کدهای تولیدشده توسط هوش مصنوعی در ماه سوم جهش می‌کند

اگر امروز برای سرعت بخشیدن به توسعهٔ نرم‌افزار روی ابزارهای هوش مصنوعی حساب کرده‌اید، باید بدانید که صورت‌حساب واقعی این سرعت در ماه سوم پروژه ارسال می‌شود. این هشدار که در گزارشی از یک توسعه‌دهنده در ۱۵ سپتامبر ۲۰۲۶ منتشر شد، به یک چرخش اقتصادی خطرناک در مهندسی نرم‌افزار اشاره دارد. نویسنده اشاره می‌کند که در حالی که ابزارهایی مثل گیت‌هاب کوپایلت (GitHub Copilot) یا کِرسور (Cursor) ساختار اولیه کد (scaffolding) را به‌سرعت می‌سازند، اما اغلب سامانه‌هایی خلق می‌کنند که هیچ‌کس در تیم به‌طور کامل آن‌ها را درک نمی‌کند. به نقل از این گزارش، اگرچه این اهرم‌ها اجازه داده‌اند پروژه‌های متن‌باز بیشتری نسبت به سال‌های گذشته در ماه‌های اخیر عرضه شوند، اما این پیروزی اغلب توهمی از بهره‌وری است.

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

تلهٔ اعتماد

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد بیش از حد به خروجی‌های مدل بدون لایه‌های نظارتی، ریسک‌های پنهانی را ایجاد می‌کند. در اینجا نیز با «تلهٔ اعتماد» روبرو هستیم؛ کدهای تولیدشده توسط هوش مصنوعی زاینده (Generative AI) — شبیه به یک نویسنده‌ی چیره‌دست که با اعتمادبه‌نفس کامل جملات غلط می‌نویسد — اغلب قابل‌اعتمادتر از آنچه هستند به نظر می‌رسند. این شکاف روان‌شناختی باعث می‌شود توسعه‌دهندگان تغییراتی را که ظاهر تمیزی دارند، بدون بازجویی سخت‌گیرانه تأیید کنند. نویسنده گزارش توصیف می‌کند که این روند منجر به انباشت کدهایی می‌شود که حرفه‌ای به نظر می‌رسند اما تغییرات بعدی را مجبور می‌کنند تا دورِ نقص‌های پنهان آن‌ها بچرخند.

یک مثال عینی، باگی بود که «آتش‌سوزی» یا بحران فوری نبود، بلکه خطایی کوچک در یک تغییر بسیار تمیز بود. کد به‌خوبی خوانده می‌شد، کامنت‌ها متفکرانه بودند و تست‌ها پاس می‌شدند. اما کد در مواجهه با پاسخ یک API که فیلدی اختیاری در آن غایب بود، دچار خطا می‌شد؛ در واقع کد «مسیر خوش‌بینانه» (happy path) را به‌درستی مدیریت می‌کرد اما غیبت آن فیلد را نادیده می‌گرفت. چون کد قابل‌اعتماد به نظر می‌رسید، کمتر مورد بررسی قرار گرفت و تیم بدون تحلیل عمیق منطق آن، کد را تأیید کرد. این تجربه منجر به انتشار یادداشتی با عنوان «مهندسی با کمک هوش مصنوعی: ساخت سریع‌تر به معنای مالکیت ارزان‌تر نیست» شد.

داده‌های کمی نیز این سرعت فریبنده را تأیید می‌کنند. طبق گزارش مطالعه‌ای در سال ۲۰۲۵ توسط METR، توسعه‌دهندگان باسابقهٔ متن‌باز که از ابزارهای هوش مصنوعی استفاده می‌کردند، با وجود اینکه تصور می‌کردند سریع‌تر شده‌اند، در واقع ۱۹٪ زمان بیشتری را برای تکمیل وظایف صرف کردند. سرعت پیش‌نویس اول، زمانی را که بعداً صرف رفع خطاهای ظریف تولیدشده می‌شود، می‌پوشاند.

هزینه‌های مالکیت در کجا متمرکز می‌شوند؟

این «صورت‌حساب نگهداری» در چهار حوزهٔ نامرئی ظاهر می‌شود که به‌ندرت در داشبوردهای بازگشت سرمایه (ROI) هوش مصنوعی دیده می‌شوند:

• زیرساخت‌های عیب‌یابی: برخی کدهای تولیدشده چنان پیچیده‌اند که برای درک آن‌ها به زیرساخت اختصاصی نیاز است. برای مثال، ابزار CauterRule به این دلیل ساخته شد که شکست‌های مکرر عامل‌ها (agents) مدام تکرار می‌شد. برای عیب‌یابی درست آن، توسعه‌دهنده مجبور شد یک تست میدانی با ۴۷۶۸ مسیر (trajectory) اجرا کند. این کار نیازمند تغییرات سخت‌گیرانه در بخش اجرا (runner hardening) بود — شامل تعیین سقف توکن، قرنطینه و تعیین زمان پایان (timeout) برای هر مسیر — تا از متوقف شدن اجرای سیستم در میانه راه جلوگیری شود.
• هزینه‌های پنهان وظایف: قیمت‌گذاری به‌ازای هر فراخوانی (per-call pricing)، هزینه واقعی شکست را پنهان می‌کند. یک داشبورد ممکن است هزینه یک فراخوانی را ۰.۰۰۱ دلار نشان دهد، اما یک وظیفه کامل که شامل یک شکست، یک تلاش مجدد، شکست دوباره و در نهایت ارجاع به سطح بالاتر (escalation) باشد، ممکن است در واقع ۰.۰۵۳ دلار هزینه داشته باشد. ابزار ai-tierforge برای همین دلیل ساخته شد، زیرا تقریباً هیچ‌کس هزینه به‌ازای هر «وظیفه تکمیل‌شده» را ردیابی نمی‌کرد؛ استفاده از این ابزار نشان داد که می‌توان در دنیای واقعی ۴۴.۸٪ در هزینه‌ها صرفه‌جویی کرد، به‌جای اینکه هر درخواست را به یک مدل واحد ارسال کرد.
• حلقه‌های بی‌نهایت خاموش: عامل‌های هوش مصنوعی (AI Agents) — شبیه به کارمندی که در یک چرخه تکراری گیر کرده و بدون خبر دادن به مدیر، ساعت‌ها کار بی‌هوده می‌کند — می‌توانند بدون داشتن سیستم قطع‌کننده (circuit breaker) وارد حلقه‌های تکرار شوند. چون این شکست‌ها با صدای بلند رخ نمی‌دهند، به‌صورت گران و خاموش اتفاق می‌افتند و برای همیشه به کار ادامه می‌دهند. این موضوع منجر به ساخت LoopGuard شد؛ یک سیستم قطع‌کننده برای حلقه‌های عامل‌ها که به‌دلیل ماهیت شکست‌های حلقوی، به ۳۹۱ تست اختصاصی نیاز داشت.
• برون‌سپاری قضاوت: بزرگ‌ترین هزینه، فرسایش قضاوت معماری است. وقتی یک مدل به کسی کمک می‌کند تا کدی حرفه‌ای را پیش از آنکه عادت به پرسش دربارهٔ موازنه (trade-off)ها پیدا کند عرضه کند، این فقدان قضاوت در جای دیگری ظاهر می‌شود؛ معمولاً به‌صورت مالیاتی بر زمان دیگران در فرآیند بازبینی.

بازطراحی گردش کار انسانی

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

برای مقابله با این وضعیت، تیم‌ها باید:

• اتوماسیون را افزایش دهند: توجه انسان با افزایش حجم کار به‌صورت خطی رشد نمی‌کند، اما گیت‌های قطعی (deterministic gates) خسته نمی‌شوند.
• بازبینی بر اساس استدلال، نه ظاهر: سؤال «آیا این کد تمیز است» را با «آیا می‌فهمیم چرا این کد کار می‌کند، چه فرضاتی دارد و کجا شکست می‌خورد» جایگزین کنند.
• توضیحات را زودتر بخواهند: به‌ویژه برای مهندسان جونیور که ممکن است یادگیری خود را به مدل برون‌سپاری کنند، آموزش قضاوت را هدفمند کنند تا یاد بگیرند چگونه موازنه ها را تحلیل کنند.
• مالکیت را ردیابی کنند، نه فقط خروجی: معیار اصلی را از «سرعت عرضه ویژگی» به «هزینه تغییر بعدی» تغییر دهند.

این تغییر به معنای فاصله گرفتن از اندازه‌گیری سرعت عرضه و حرکت به سمت اندازه‌گیری هزینه بلندمدت مالکیت است. نویسنده اعتراف می‌کند که این موضوع بلافاصله مشخص نشد؛ بلکه تنها زمانی آشکار گشت که حجم بازبینی‌ها به‌شدت زیاد شد و مشخص شد که آن‌ها در حال درمان علائم هستند، نه تغییر گردش کار.

اگرچه آزمایش کنترل‌شده‌ای وجود ندارد که ثابت کند کد با کمک هوش مصنوعی همیشه گران‌تر است، اما نتایج METR نشانهٔ قوی‌ای است. اگر تعریف «سریع‌تر» در لحظه ادغام (merge) کد تمام شود، تیم تنها ارزان‌ترین نیمی از چرخه حیات نرم‌افزار را اندازه‌گیری کرده است. برای کسانی که تیم‌های ادغام‌شده با AI را مدیریت می‌کنند، گام بعدی پیاده‌سازی «معیارهای مالکیت» است که زمان صرف‌شده برای عیب‌یابی بلوک‌های تولیدشده توسط AI را با کدهای دستی مقایسه کند و الگوهای «قطع‌کننده» را برای جلوگیری از شکست‌های خاموش و گران‌قیمت (مانند مورد LoopGuard) اجرا نماید.

گام بعدی شما

• معیارهای «مالکیت» را جایگزین معیارهای «سرعت عرضه» کنید و زمان عیب‌یابی بلوک‌های تولیدشده توسط AI را با کدهای دستی مقایسه کنید.
• الگوهای «قطع‌کننده» (circuit breaker) را برای جلوگیری از شکست‌های خاموش و گران‌قیمت در عامل‌های هوش مصنوعی پیاده‌سازی کنید.
• در جلسات بازبینی کد، تمرکز را از زیبایی ظاهری به تحلیل فرض‌های زیربنایی مدل منتقل کنید.

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