گزارش جدید: عامل‌های کدنویس هزینه‌ی توکن و بدهی فنی را افزایش دادند

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

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

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

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، حذف لایه‌های نظارتی انسانی در برابر سرعت، همواره ریسک‌های ساختاری را افزایش می‌دهد.

شواهد زوال ساختاری

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

به گزارش GitClear، تحلیل ۶۲۳ میلیون تغییر کد بین سال‌های ۲۰۲۳ تا ۲۰۲۶ نشان می‌دهد که بلوک‌های کد تکراری ۸۱٪ افزایش یافته‌اند. به‌طور هم‌زمان، کدهایی که از نوع بازسازی (Refactoring) بوده‌اند و جابه‌جا شده‌اند، به تنها ۳.۸٪ از خطوط تغییر یافته کاهش یافته‌اند. همچنین کدهای جدید ۳۵٪ کمتر از سال ۲۰۲۳ به توابع موجود متصل می‌شوند. GitClear تأکید می‌کند که این‌ها همبستگی‌هایی در دوره رشد استفاده از AI هستند و نه لزوماً اثبات قطعی علت و معلول.

یک مطالعه‌ی داوری‌شده از دانشگاه کارنگی ملون (MSR ۲۰۲۶) صریح‌تر است. پژوهشگران دریافتند پروژه‌های متن‌بازی که از Cursor استفاده کرده‌اند، افزایش موقتی در سرعت توسعه داشتند، اما این رشد با افزایش شدید و پایدار هشدارهای تحلیل استاتیک و پیچیدگی کلی کد همراه بود.

مالیات توکن بر بدهی فنی

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

مستندات صورت‌حساب فروشندگان این فشار کاری را آشکار می‌کند:

• مستندات Claude Code شرکت Anthropic صراحتاً «اندازه کدبیس» را عاملی می‌داند که باعث نوسان شدید هزینه‌ها می‌شود و اشاره می‌کند که «هزینه‌های توکن با اندازه زمینه مقیاس می‌پذیرند».
• مستندات GitHub Copilot اشاره دارند که یک جلسه عامل‌محور پیچیده که در یک کدبیس بزرگ فعالیت می‌کند، به‌طور قابل‌توجهی بیشتر از یک پرسش سریع در چت، مصرف توکن دارد.
• OpenAI بیان می‌کند که استفاده از Codex به‌شدت به «اندازه و پیچیدگی تکالیف» و همچنین زمینه، استدلال و استفاده از ابزار وابسته است.

در یک پیش‌چاپ (Preprint) در مه ۲۰۲۶، پژوهشگران SonarSource این اثر را ایزوله کردند. آن‌ها Claude Code را روی نسخه‌های تمیز و نامرتب از یک کد مشابه آزمایش کردند. در حالی که عامل در هر دو سناریو تکالیف را با نرخ یکسانی پاس کرد، در نسخه تمیز ۷ تا ۸٪ توکن کمتر مصرف کرد و ۳۴٪ کمتر به فایل‌ها مراجعه کرد.

شکست حلقه بازخورد

طبق گزارش Google DORA در سال ۲۰۲۵، پذیرش هوش مصنوعی در حال حاضر با توان عملیاتی بالاتر اما پایداری کمتر مرتبط است. این گزارش تأکید می‌کند تیم‌هایی با معماری‌های با جفت‌شدگی کم (Loosely Coupled) و حلقه‌های بازخورد سریع، بیشترین سود را می‌برند، در حالی که سیستم‌های با جفت‌شدگی زیاد، «سود اندک یا هیچ سودی» نمی‌بینند. دیدگاه DORA این است که هوش مصنوعی صرفاً آنچه از قبل وجود دارد را تقویت می‌کند.

مشکل اصلی این است که تست‌ها رفتار را تأیید می‌کنند، نه ساختار را. بازبینی کد (Code Review) که حفاظ سنتی بود، اکنون به یک گلوگاه تبدیل شده است. DORA اشاره می‌کند زمانی که در نوشتن کد ذخیره شده، اغلب صرف «حسابرسی و تأیید» می‌شود. آنچه کم است، یک سیگنال ساختاری ارزان و مستقل است که بتواند قبل از تغییر بررسی شود، نه بعد از آنکه بازبین خسته شده است.

معرفی CXCAP

برای حل این مشکل، توسعه‌دهنده‌ای به نام Moonlett ابزار CXCAP را ساخت؛ یک ابزار CLI محلی و قطعی که برای ارائه حلقه بازخورد ساختاری طراحی شده است. CXCAP که پس از مشاهده موفقیت تکالیف فردی در کنار سخت‌تر شدن کلی کدبیس ساخته شده، فقط خواندنی است و داده‌ای را آپلود نمی‌کند. این ابزار از tree-sitter برای تحلیل پایتون، جاوااسکریپت/تایپ‌اسکریپت و راست استفاده می‌کند.

CXCAP چندین ریسک ساختاری حیاتی را شناسایی می‌کند:

• نقاط داغ (Hotspots): مناطقی که اندازه، شاخه‌بندی و جفت‌شدگی در آن‌ها متمرکز است.
• وابستگان (Dependents): دسترسی‌های متعددی که یک فایل یا پوشه خاص دارد (از طریق پرچم --focus <path>).
• چرخه‌های Import: تشخیص تفاوت بین چرخه‌های زمان بارگذاری (load-time) و چرخه‌های تنبل (lazy).
• بسترهای محدود (Bounded Contexts): استفاده از پرچم --intent برای نقشه‌برداری از نقاط تماس احتمالی، یال‌های متقاطع مرزی و چرخه‌ها برای یک تغییر خاص که به زبان ساده توصیف شده است.
• عدم قطعیت: علامت‌گذاری Importهای پویا، توزیع‌های getattr یا Registryهایی که تصویر استاتیک در آن‌ها ناقص است.

در یک اجرای آزمایشی روی یک سیستم پرداخت Django، درخواست برای «افزودن انقضای جلسه به درخواست‌های احراز هویت شده» نشان داد تغییری که به‌نظر محلی بود، در واقع در سطحی از ۲۲ فایل تولیدی در دو کامپوننت قرار داشت، شامل ۱۶ یال متقاطع و چهار چرخه Import (یک مورد در زمان بارگذاری و سه مورد در سطح تابع). همچنین در ۱۰ نقطه عدم قطعیت تحلیل پویا را شناسایی کرد. این تحلیل در کمتر از یک ثانیه انجام شد.

آزمایش و ابطال

برای اطمینان از کاربردی بودن، این ابزار تحت تلاش‌های سخت‌گیرانه برای شکستن قرار گرفت:

• حسابرسی داخلی: وقتی CXCAP روی سورس خودش اجرا شد، حکم خودش را SEVERE (شدید) اعلام کرد، با ۱۵ هشدار بالا و یک کپی ۲۲-بلوکی بین دو پارسر خودش.
• قصد‌های تاریخی: در ۳۱ تغییر واقعی در ۷ مخزن، ۱۰ کاندیدای برتر ابزار توانست حدود ۷۰٪ از فایل‌هایی که واقعاً تغییر کرده بودند را بازیابی کند (Recall@10 0.70 و MRR 0.47).
• شکار باگ: تست روی مخازن عمومی منجر به اصلاحاتی در نسخه ۱.۰.۴ شد، از جمله اصلاح نحوه برخورد با گارد‌های typing.TYPE_CHECKING و اطمینان از اینکه from pkg import submodule به‌عنوان یک وابستگی شمرده شود.

محدودیت‌های صادقانه

CXCAP دانای کل نیست. این ابزار فقط استاتیک است، به این معنی که سیستم‌های پلاگین، Reflection و Dependency Injection می‌توانند نامرئی باشند (هرچند هر آنچه قابل تشخیص باشد را علامت‌گذاری می‌کند). همچنین فقط پایتون، JS/TS و راست را امتیازدهی می‌کند و سایر زبان‌ها به‌عنوان «بدون امتیاز» لیست شده‌اند. این ابزار تلاش را پیش‌بینی نمی‌کند یا کیفیت کد را نمره نمی‌دهد؛ حکم HIGH یا SEVERE اغلب فقط به این معناست که سیستم بزرگ و بالغ است. در نهایت، ویژگی --intent از بازیابی لغوی و گسترش گراف استفاده می‌کند، بنابراین واژگان تخصصی ناشناخته در دامنه پروژه، نرخ بازیابی را کاهش می‌دهد.

تحلیل: تغییر در معیارهای مهندسی

این توسعه، مفروضات بنیادی توسعه با کمک هوش مصنوعی را تغییر می‌دهد. ما در حال حرکت از فاز «آیا هوش مصنوعی می‌تواند این تابع را بنویسد؟» به سمت «آیا هوش مصنوعی می‌تواند این معماری را حفظ کند؟» هستیم. پارادایم فعلی برای تکالیف فوری بهینه شده است، اما خروجی عامل امروز، تبدیل به زمینهٔ عامل فردا می‌شود.

اگر عامل‌ها بدون سیگنال‌های ساختاری به فعالیت خود ادامه دهند، ریسک ایجاد «کدهای میراثی بومیِ هوش مصنوعی» (AI-native legacy code) را می‌پذیریم؛ سیستم‌هایی که از نظر عملکردی درست هستند اما از نظر ساختاری برای انسان‌ها و مدل‌ها غیرقابل‌فهم‌اند. اثر مرتبه دوم این موضوع، اقتصادی است: هرچه مخزن پیچیده‌تر شود، هر تغییر بعدی که توسط هوش مصنوعی هدایت شود، گران‌تر خواهد شد.

گام بعدی شما

• مخازن کد خود را که به‌شدت با AI توسعه یافته‌اند، با ابزارهای تحلیل ساختاری مانند CXCAP بررسی کنید تا ببینید آیا هزینه‌های توکن شما ناشی از پیچیدگی‌های قابل اجتناب است یا خیر.
• در تغییر بعدی خود، دستورات زیر را اجرا کنید:

curl -fsSL https://github.com/moonlettai/cxcap/releases/latest/download/install.sh -o install.sh
sh install.sh
cxcap audit . --intent "<تغییر مورد نظر>"

• منتظر ادغام مهارت‌های «لینتر ساختاری» (Structural Linter) در چارچوب‌های عامل‌محور باشید تا این زوال در لحظه متوقف شود.

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