اطمینان شما به چراغ سبز خط لوله CI می‌تواند یک توهم خطرناک باشد. از ۱۶ ژوئیه ۲۰۲۶، تمایزی عمیق میان بدهی فنی سنتی و پدیده‌ای بدخیم‌تر به نام بدهی تفاضلی (Diff Debt) شکل گرفته است؛ وضعیتی که در آن تیم‌ها کدهایی را به ارث می‌برند که حتی اگر امروز بی‌نقص کار کنند، هیچ‌کس نمی‌تواند منطق آن‌ها را توضیح دهد.
همان‌طور که در پوشش پیشین ما از Vibe Coding دیدیم که چگونه کدنویسی بر اساس «حس» می‌تواند نقص‌های فنی عمیق را پنهان کند، این مفهوم جدید نشان می‌دهد که شیوه شکست نرم‌افزارها در حال تغییر است. در یک محیط سنتی، برنامه‌نویس برای رسیدن به مهلت تحویل، آگاهانه یک میان‌بر می‌زند و یک «وام» شناخته‌شده ایجاد می‌کند که قصد بازپرداخت آن را دارد. اما بدهی تفاضلی، وامی است که شما بدون خواندن شرایط قرارداد، امضایش کرده‌اید. این چالش در واقع تکمله بحث‌های ما درباره ریسک انباشته‌شدهٔ کدهای بازبینی‌نشده در عصر هوش مصنوعی است که نشان می‌دهد چگونه سرعت تولید کد بر کیفیت بازبینیe غلبه می‌کند.
ریشه‌های بدهی
بدهی فنی استعاره‌ای است که وارد کانینگهام در اوایل دهه ۹۰ معرفی کرد. ویژگی اصلی این نوع بدهی، «صداقت» است. وقتی چیزی را سریع و شلخته می‌سازید، عمداً یک راهکار موقت و «هک‌شده» را به یک راهکار تمیز ترجیح می‌دهید. در این حالت، شما می‌توانید آن فایل را باز کنید و خط‌به‌خط توضیح دهید چرا کد زشت است و نسخه «درست» آن باید چه شکلی باشد. در واقع شما برای این وام امضا داده‌اید و تقریباً می‌دانید چقدر قرض گرفته‌اید.
بدهی تفاضلی اما اساساً متفاوت است. این یک آشفتگی انتخابی نیست، بلکه رازی است که از مخزن کدهای خودتان به ارث می‌برید. این اتفاق زمانی رخ می‌دهد که یک درخواست ادغام یا PR — برای مثال با ۴۰۰ خط کد — ارسال می‌شود و چون تست‌ها پاس شده‌اند و CI سبز است، شما فقط روی کدها اسکرول می‌کنید و بدون اینکه واقعاً آن‌ها را بخوانید، تاییدش می‌کنید. در اینجا هیچ انسانی هرگز مدل ذهنی آن کد را در سر خود نساخته است.
به نقل از تحلیل‌های منتشر شده در dev.to، بدهی تفاضلی زمانی ایجاد می‌شود که یک Pull Request (PR) بدون اینکه انسانی مدل ذهنی تغییرات را درک کند، تایید شود. این وضعیت معمولاً در سه سناریوی خاص رخ می‌دهد:
- یک PR شامل بیش از ۴۰۰ خط کد است اما در کمتر از دو دقیقه تایید (LGTM یا Looks Good To Me) می‌شود.
- کد توسط یک ابزار هوش مصنوعی زاینده تولید شده و نویسنده (برنامه‌نویس) نمی‌تواند منطق آن را خط‌به‌خط توضیح دهد.
- بلوک‌های بزرگی از کد کپی-پیست یا تولید شده‌اند و وقتی پرسیده می‌شود چه کسی واقعاً این تصمیم طراحی را گرفته است، تیم فقط شانه بالا می‌اندازد.
مقایسه تعهدات
برای درک بهتر این ریسک، مفید است که این دو نوع بدهی را در ابعاد کلیدی با هم مقایسه کنیم:
- نحوه ایجاد: بدهی فنی از انتخاب یک میان‌بر حاصل می‌شود؛ بدهی تفاضلی از نادیده گرفتن مطالعه کد می‌آید.
- درک: در بدهی فنی، شما کد را می‌فهمید؛ در بدهی تفاضلی، نمی‌فهمید.
- قابلیت رؤیت: شما تقریباً می‌دانید تا چه اندازه در بدهی فنی غرق شده‌اید؛ اما در بدهی تفاضلی، تا زمانی که مشکل شما را بگیرد، هیچ ایده‌ای ندارید.
- بازپرداخت: معمولاً می‌توانید برای بازپرداخت بدهی فنی برنامه‌ریزی کنید، در حالی که از وجود بدهی تفاضلی تا زمان وقوع یک حادثه (Incident) بی‌خبرید.
این ریسک به‌دلیل اینکه هوش مصنوعی پیوند تاریخی میان «تولید کد» و «درک کد» را قطع کرده، به صورت تصاعدی رشد کرده است. برای دهه‌ها، نوشتن ۴۰۰ خط کد نیازمند تلاشی بود که به‌طور طبیعی نویسنده را مجبور می‌کرد آن خطوط را بفهمد. در واقع، هزینه ایجاد تفاضل (diff) و هزینه درک آن تقریباً برابر بود. امروز یک مدل زبانی بزرگ (LLM) می‌تواند در چند ثانیه تغییری ۴۰۰ خطی تولید کند که با اطمینان کامل نوشته شده و تست‌شده به نظر می‌رسد، در حالی که فرآیند بررسی انسانی همچنان کند و در معرض خستگی است.
هزینه پنهان سرعت هوش مصنوعی
کدهای تولید شده حتی وقتی در سکوت اشتباه می‌کنند، با اطمینان کامل ظاهر می‌شوند. فشار برای «فقط منتشر کردن» (Just ship it) بسیار زیاد است چون تفاضل کد درست به نظر می‌رسد و خط لوله CI سبز است. با این حال، هر بار که تغییری بدون خوانده شدن واقعی ادغام می‌شود، تیم در حال استقراض زمانی با نرخی است که نمی‌توانند آن را ببینند.
توجه داشته باشید که بدهی تفاضلی درباره کیفیت کد نیست. کدی بسیار زیبا و تمیز هم می‌تواند بدهی تفاضلی خالص باشد. نشانه حیاتی (Tell) این نیست که کد چگونه خوانده می‌شود، بلکه این است که آیا «ذهنی» پشت آن است یا خیر. اگر فایلی دارید که هیچ‌کس نمی‌خواهد به آن دست بزند چون یک‌باره ادغام شده است (به جای اینکه به مرور زمان ساخته شود)، شما با بدهی تفاضلی روبه‌رو هستید.
خطر اینجاست که بدهی تفاضلی کاملاً خارج از ترازنامه مالی نرم‌افزار باقی می‌ماند. در حالی که بدهی فنی آشفتگی‌ای است که انتخاب کرده‌اید و می‌توانید بازسازی (Refactoring) آن را در یک اسپرینت زمان‌بندی کنید، بدهی تفاضلی یک معماست. شما تا زمانی که یک حادثه در محیط عملیاتی (Production) شما را مجبور به مهندسی معکوس تصمیمی کند که هیچ انسانی واقعاً نگرفته است، متوجه حضورش نمی‌شوید.
برای مهندسان مدرن، این یعنی تعریف یک «ادغام موفق» باید تغییر کند. خط لوله سبز دیگر معیاری برای کیفیت نیست؛ بلکه فقط نشان می‌دهد که سیستم «همین حالا» شکست نخورده است. اگر انسانی نتواند توضیح دهد چرا یک تغییر درست است، بهرهٔ آن بدهی تفاضلی از همین لحظه در حال انباشت است.
استراتژی‌های بازپرداخت
بدهی فنی با بازسازی کد درمان می‌شود، اما بدهی تفاضلی نیازمند یک درمان متفاوت است: «درک». ارزان‌ترین زمان برای خرید این درک، پیش از ادغام (Merge) است.
- بازتعریف تایید: تایید PR را به معنای «من این کد را درک کردم» تغییر دهید، نه «چیز ترسناکی ندیدم».
- محدود کردن اندازه تفاضل: اندازه تغییرات را به‌گونه‌ای کوچک نگه دارید که فارغ از اینکه توسط انسان یا مدل تولید شده باشند، خواندن آن‌ها ممکن باشد.
- جلسات مرور اجباری (Walkthroughs): وقتی یک مدل نویسنده کد است، الزامی کنید که یک انسان توضیح دهد چرا این تغییر درست است. اگر کسی نتوانست، چراغ سبز صادر نشود.
مراقب زمان چرخه PRهای خود باشید و برای هرگونه تغییرات تولید شده توسط هوش مصنوعی که از یک حد آستانه کوچک فراتر می‌روند، یک «مرور شفاهی» اجباری پیاده کنید. تفاضلی که نخوانده‌اید، چکی است که هرگز زیر نور گرفتید تا اصل یا جعل بودن آن را بفهمید؛ این چک به‌خوبی پاس داده می‌شود، درست تا همان یک باری که پاس داده نشود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.
گفتگو