تصور کنید ساعت ۲ صبح است و یک ماژول حیاتی در محیط عملیاتی کرش کرده است؛ فایلی را باز میکنید که ماهها «مالک» آن بودهاید، اما متوجه میشوید برای اولین بار است که کدهای آن را میخوانید. این دقیقترین توصیف از بدهی تفاوت (Diff Debt) است؛ اصطلاحی که ریسک انباشتهشده از ادغام تغییرات تولیدشده توسط هوش مصنوعی را تعریف میکند، تغییراتی که در واقعیت هیچ انسانی آنها را نخوانده است.
این معضل تنها مختص شرکتهای بزرگ نیست و تکبرنامهنویسان را هم در بر میگیرد. نویسنده این گزارش در اعترافی صادقانه، تجربه ساخت یک ربات اتوماسیون دسکتاپ به نام Erci را تعریف میکند. این ربات دارای یک رابط کاربری گرافیکی (GUI)، سیستم بینایی ماشین و یک سیستم لایسنسدهی است. او توضیح میدهد که با وجود اینکه ربات در عمل کار میکرد و افرادی از آن استفاده میکردند، او — که یک توسعهدهنده حرفهای نیست — هرگز اکثر کدهای آن را به طور واقعی نخوانده بود. او صرفاً نیازمندیها را به یک عامل (Agent) — شبیه دستیاری که دستورات را میگیرد و سریع اجرا میکند — دیکته میکرد، کد تولیدشده را اجرا میکرد و به محض اینکه کد کار میکرد، به سراغ مرحله بعد میرفت. در نتیجه، هزاران خط کد به این شکل انباشته شدند و شکاف عمیقی میان آنچه «ادغام» شده بود و آنچه واقعاً «بازبینی» شده بود، ایجاد کردند. این رویکرد در واقع همان نگاهی است که در تحلیل ما درباره جایگاه مدلهای زبانی در سطح تکمیلکننده کد بررسی کردیم، جایی که تکیه بیش از حد به دستیاران هوش مصنوعی بدون نظارت معماری، منجر به کاهش کیفیت ساختاری پروژه میشود.
همانطور که در تحلیل قبلی ما دربارهی حالتهای شکست استارتاپهای هوش مصنوعی اشاره کردیم، این موضوع نشاندهندهی تغییری بنیادین در نحوه نگهداری نرمافزار است. در حالی که بدهی فنی سنتی حاصل تصمیمات آگاهانه برای میانبر زدن است، بدهی تفاوت یک فرسایش نامرئی در درک سیستم است. این اتفاق زمانی میافتد که سرعت تولید کد توسط هوش مصنوعی زاینده (Generative AI) — مثل نویسندهای که در ثانیه هزار صفحه مینویسد — بسیار بیشتر از سرعت تأیید انسانی باشد و در نهایت کدبیس را به مجموعهای از «جعبههای سیاه» تبدیل کند.
برای توسعهدهندگان حرفهای، این تجربه ظریفتر اما ساختاراً یکسان است. یک عامل، یک تغییر (Diff) باورپذیر در ۹۰۰ خط کد ایجاد میکند؛ تستهای خودکار سبز میشوند و فشار تحویل پروژه (Sprint) بسیار بالاست. برنامهنویس نگاهی گذرا میاندازد، کد را تأیید کرده و درخواست ادغام (Pull Request) را که بینقص به نظر میرسید، ادغام میکند. دقیقاً همین «به نظر کامل رسیدن»، ریشه مشکل است.
طبق گزارش یک نظرسنجی در سال ۲۰۲۶ توسط شرکت Sonar که بیش از ۱۱۰۰ توسعهدهنده در آن شرکت کردند، در حال حاضر حدود ۴۲٪ از کدهای ثبتشده (Committed) توسط هوش مصنوعی تولید شدهاند. پیشبینی میشود این رقم تا سال ۲۰۲۷ به ۶۵٪ برسد. دادهها شکاف خطرناکی در اعتماد را نشان میدهند: در حالی که ۹۶٪ برنامهنویسان به صحت کامل کدهای AI اعتماد ندارند، تنها حدود نیمی از آنها واقعاً کد را قبل از ثبت بررسی میکنند. این فاصله بین «بیاعتمادی» و «عدم بازبینی»، همان بدهی تفاوت است که در لحظه انباشته میشود.
مکانیسم بدهی نامرئی
این بدهی به این دلیل افزایش مییابد که «ریاضیات توسعه» به هم ریخته است. مهندسی که ۵۰۰ خط کد را دستی مینویسد، به عنوان اثر جانبیِ کار، یک مدل ذهنی از سیستم میسازد. در مقابل، عاملی که ۵۰۰۰ خط کد را در ۶ دقیقه تولید میکند، هیچ درکی در ذهن اپراتور انسانی ایجاد نمیکند. در واقع، «فهم کردن» حالا به یک شغل جداگانه و بدون دستمزد به نام «بازبینی» تبدیل شده است که اعداد نشان میدهند عملاً انجام نمیشود.
این چرخش، اندازه درخواستهای ادغام (PR) را به شدت تغییر داده است. در بسیاری از سازمانها، میانگین حجم PRها سه برابر شده و از محدوده ۱۰۰ تا ۲۰۰ خط به ۴۰۰ تا ۶۰۰ خط رسیده است. در حالی که یک تغییر ۴۰۰ خطی هنوز قابل خواندن است، یک تغییر ۴۰۰۰ خطی معمولاً فقط «اسکن» میشود و به همین ترتیب بدهی تفاوت به صورت مرکب (Compounding) افزایش مییابد.
اکوسیستم بدهیهای AI
این پدیده بخشی از یک زنجیره گستردهتر از هزینههای مربوط به هوش مصنوعی است. بدهی تفاوت، در واقع واحد کوچکتری از چند مشکل کلانتر است:
- بدهی تأیید (Verification Debt): اصطلاحی که ورنر ووگلس، مدیر فناوری AWS در رویداد re:Invent ۲۰۲۵ به کار برد و توصیفی از هزینه کلانِ بررسی ناکافی خروجیهای AI است.
- بدهی درک (Comprehension Debt): اصطلاحی از ادی عثمانی که به فرسایش مدل ذهنی اشاره دارد؛ مدلی که برنامهنویسان قبلاً با نوشتن دستی کد، رایگان به دست میآوردند. برای مقابله با این چالش، راهبردهای خاصی در صنایع حساس برای مهار بدهی شناختی تدوین شده است تا از فروپاشی مدلهای ذهنی در پروژههای حیاتی جلوگیری شود.
- بدهی فنی (Technical Debt): میانبرهای آگاهانهای که در ساختار کد زده میشوند.
نحوه تعلق بهره
بدهی تفاوت مثل وامهای بانکی بهره میگیرد. کدهایی که خوانده نشدهاند، فونداسیونِ تغییرات بازبینینشده بعدی میشوند. در نهایت، هزینه رفع یک باگ در محیط عملیاتی در ماژولی که «کسی» آن را بازبینی کرده، میتواند از هزینه نوشتن کل آن ویژگی از صفر بیشتر شود. بازسازی کدها (Refactoring) متوقف میشود چون هیچکس نمیتواند پیشبینی کند چه چیزی میشکند و ورود نیروهای جدید به تیم کند میشود؛ چرا که نویسنده کد یک مدل بوده و بازبین، صرفاً یک نگاه گذرا.
تسویه بدهی
برای جلوگیری از فروپاشی کامل دانشِ کدبیس، تیمها باید «قابلیت بازبینی» را به عنوان یک ویژگی اصلی در نظر بگیرند. نویسنده این مطلب که تعریف کامل این مفهوم را در سایت diffdebt.com مستند کرده است، استراتژیهای مشخصی را پیشنهاد میکند:
- لایهبندی ریسک (Risk-Tiering): بازبینیهای انسانی عمیق را برای کدهایی که با احراز هویت، تراکنشهای مالی، مدیریت پول یا حذف دادهها در ارتباط هستند، اولویت دهید. کدهای تکراری (Boilerplate) میتوانند با تکیه بر تستهای سبز پاس شوند.
- سقف اندازه تغییرات (Capping Diff Size): عاملها را مجبور کنید خروجیها را در قطعات کوچک و قابل بازبینی تحویل دهند، به جای اینکه بلوکهای عظیم کد ارائه دهند. اگر عاملی ۴۰۰۰ خط کد داد، تقاضا کنید که آن را خرد کند.
- تستهای مبتنی بر قصد (Intent-Based): تستهایی بخواهید که «هدف» و قصد کد را رمزگذاری کنند، نه تستهایی که خودِ AI برای تعریف کردن و چاپلوسی از پیادهسازیاش نوشته است.
- سنجش درک (Comprehension Metrics): درک سیستم را به عنوان یک معیار (Metric) ردیابی کنید. هر ماژولی که هیچ عضو تیم نتواند آن را توضیح دهد، به عنوان یک «قطعه در انتظار خرابی سیستم» علامت بزند.
برای برنامهنویس مدرن، مزیت رقابتی دیگر در این نیست که چه کسی کد بیشتری تولید میکند، بلکه برنده کسی است که اعتماد بالایی به جزئیاتِ آنچه دقیقاً در محیط عملیاتی اجرا میشود، دارد.
اگر در حال حاضر در حال گسترش تیمی هستید که از هوش مصنوعی کمک میگیرند، گام بعدی شما باید حسابرسی حجم PRها باشد تا ببینید آیا «شکاف تأیید» شما در حال گسترش است یا خیر.
گام بعدی شما
- حجم PRهای تیم خود را بررسی کنید تا ببینید آیا شکاف تأیید شما در حال گسترش است یا خیر.
- برای ماژولهای حساس، قانون «بازبینی اجباری انسانی» را فارغ از نتایج تستهای AI وضع کنید.
- از عاملها بخواهید پیش از تولید کد، ابتدا «نقشه راه» یا Intent کد را بنویسند تا بازبینی راحتتر شود.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو