تصور کنید برنامه‌نویسی به قدری ارزان شود که دیگر نیازی به فکر کردن به مسئله نباشد؛ نتیجه این وضعیت، بهره‌وری نیست، بلکه انباشت انبوهی از زباله‌های دیجیتال است. ما در آغاز عصر «خزش زباله» (Slop-creep) هستیم؛ جریانی خاموش که زیرساخت‌های شرکتی را با سیستم‌هایی پر می‌کند که هیچ‌کس آن‌ها را نمی‌فهمد و هیچ‌کس واقعاً به آن‌ها نیاز ندارد.
این تغییر زمانی رخ داد که عامل‌های هوش مصنوعی (AI Agents) — مانند مدل کلود (Claude) که پیاده‌سازی ایده‌ها را تقریباً بدون اصطکاک می‌کنند — وارد میدان شدند. این روند با سقوط شتابان هزینه‌های تولید هوش مصنوعی که ماهیت پروژه‌های نرم‌افزاری را تغییر داده است، شتاب بیشتری گرفته است. در گذشته، هزینه بالای مهندسی مانند یک فیلتر طبیعی عمل می‌کرد؛ ایده‌های بد چون ساختشان زمان‌بر و هزینه‌بر بود، پیش از آنکه به مرحله اجرا برسند، می‌مردند. اما امروز این اصطکاک از بین رفته و مهندسان سریع‌تر از آنکه بتوانند مشکلات واقعی را شناسایی کنند، راهکار تولید می‌کنند. ما بخش بزرگی از تفکر خود را به ماشین‌ها سپرده‌ایم و با آن‌ها مانند «ماشین‌های پیش‌گویی روی میز» برخورد می‌کنیم؛ یعنی اولین راهکاری که ارائه می‌دهند را بدون هیچ‌گونه آزمایش یا تفکر انتقادی، به عنوان حقیقت مطلق می‌پذیریم.
مکانیسم‌های خزش زباله (Slop-Creep)
خزش زباله در واقع انباشت تدریجی ویژگی‌ها، انتزاع‌ها و زیرساخت‌هایی است که صرفاً چون عامل‌های AI تولید آن‌ها را ارزان کردند، ساخته می‌شوند. این‌ها سیستم‌هایی هستند که هرگز نیازی به وجود داشتن نداشتند، اما چون ماشین‌ها می‌توانستند آن‌ها را پیش از آنکه کسی بپرسد «چرا؟» بسازند، به محیط عملیاتی وارد شدند. این فرآیند با ظهور نقش جدیدی در شرکت‌ها به نام «پراکسی انسانی» (Meat Proxy) شتاب گرفته است.
نیکلاس گرون (Niklas Gruhn)، مهندس نرم‌افزار، اصطلاح پراکسی انسانی را برای توصیف افرادی به کار می‌برد که کد یا متن تولید شده توسط AI را بدون خواندن، بررسی یا درک آن، صرفاً کپی و ارسال می‌کنند. در این گردشِ کار، عامل هوش مصنوعی مانند یک جعبه سیاه است که راهکارها را بیرون می‌ریزد و انسان تنها یک رابط (Interface) ساده میان AI و سایر همکاران شرکت است.
این اتکا به اتوماسیون هزینه‌های شناختی قابل‌اندازه‌گیری دارد. بر اساس مطالعه‌ای از مایکروسافت ریسرچ (Microsoft Research) و دانشگاه کارنگی ملون (Carnegie Mellon) روی ۳۱۹ کارکن دانش‌بنیان و ۹۳۶ مورد استفاده واقعی از AI، مشخص شد که اعتماد بیشتر به هوش مصنوعی مستقیماً با کاهش تلاش برای تفکر انتقادی مرتبط است. این یافته‌ها نشان می‌دهد که هرچه بیشتر به این ماشین‌ها اعتماد می‌کنیم، کمتر فکر می‌کنیم.
فرسایش اصطکاک در پیاده‌سازی
از نظر تاریخی، هزینه اشتباهات در مهندسی نرم‌افزار بسیار سنگین بود. مهندسان مجبور بودند بنشینند و عمیقاً روی مسائل واقعی فکر کنند تا راهکارهایی کاربردی و پایدار بسازند. اکنون چون تولید نرم‌افزار به‌طور مضحکی ارزان شده، انگیزه برای کوچک‌تر کردن سیستم‌ها و افزایش قابلیت نگهداری آن‌ها از بین رفته است.
برخی استدلال می‌کنند که چون ارتشی از عامل‌های AI می‌توانند کدهای بد را اصلاح کنند، استانداردهای پذیرش کد پایین آمده است؛ اما واقعیت این است که ما در حال پیشروی بدون نقشه هستیم. این کاهش هزینه‌ها تا حد زیادی مدیون ظهور مدل‌های کوچک و وزن‌باز است که استنتاج عامل‌ها را به شدت ارزان‌تر کرده‌اند. عامل‌ها هنوز آن‌قدر هوشمند نیستند که در سطوح مختلف انتزاع به مهندس بگویند: «نه، این را نساز». چه وظایفی را به یک ناوگان از عامل‌ها بسپارید و چه بدون فکر دکمه Enter را در ترمینال بزنید، در هر صورت به موج خزش زباله کمک می‌کنید.
از استارتاپ‌ها تا بدهی‌های شرکتی
برای استارتاپ‌ها، این هزینه پایینِ شکست یک مزیت است. یک کارآفرین می‌تواند یک CRM مبتنی بر AI برای بازاری بسیار خاص — مثلاً پرورش‌دهندگان آلپاکا — بسازد و وقتی فهمید هیچ تناسبی بین محصول و بازار (Product-Market Fit) وجود ندارد، سریعاً آن را حذف کند. توانایی شکست ارزان، یکی از بهترین هدایای عامل‌های AI است.
برای توصیف این موضوع، نویسنده به تجربه شرکت خود، وادل (Waddle)، اشاره می‌کند. آن‌ها یک CRM مخصوص تاتوکارها ساختند. مهندسی آن حتی پیش از عصر AI کامل و بی‌نقص بود، اما پروژه شکست خورد چون تاتوکارها اصلاً به CRM نیاز نداشتند؛ آن‌ها ترجیح می‌دادند از اینستاگرام برای جذب مشتری، گوگل کلندر برای زمان‌بندی و انتقال وجه مستقیم یا نقدی برای پرداخت استفاده کنند. آن‌ها حتی نمی‌خواستند کارت اعتباری بپذیرند، که این موضوع باعث شد تمام اتصالات مربوط به درگاه‌های پرداخت کارت اعتباری بی‌فایده شود.
در گذشته، محدودیت‌های طبیعی وجود داشت چون ساخت چنین محصولی ماه‌ها تلاش می‌طلبید. اکنون فرآیند معکوس شده است: ابتدا CRM را می‌سازید، سپس صنعتی را انتخاب می‌کنید و بعد به دنبال مشکلی می‌گردید که این ابزار ظاهراً آن را حل می‌کند. در حالی که این رویکرد برای پروژه‌های تفننی آخر هفته که می‌توان آن‌ها را پاک کرد مناسب است، اما خطر آن در سازمان‌های بزرگ به شدت افزایش می‌یابد.
خطر زباله‌های «چسبناک» شرکتی
برخلاف یک پروژه آخر هفته، نرم‌افزارهای شرکتی «چسبناک» هستند. وقتی یک همکار به ابزاری تکیه می‌کند، سازنده آن مجبور است تا ابد آن را نگهداری کند. وقتی کارکنان در یک شرکت بزرگ مانند استارتاپ‌های بی‌دقت رفتار می‌کنند، پیچیدگی‌های غیرضروری ایجاد می‌کنند که مدت‌ها پس از ناپدید شدن نیاز اولیه، باقی می‌ماند.
این وضعیت چرخه خطرناکی از مالکیت تکه‌تکه شده و بدهی فنی ایجاد می‌کند:
- انتزاع‌های غیرضروری: کارمندی یک سرویس داخلی، یک پایگاه‌داده جدید یا یک فریم‌ورک جدید اضافه می‌کند، صرفاً چون کلود آن را به عنوان «معماری تمیز» (Clean Architecture) پیشنهاد داده است.
- تصمیم‌گیری ارزان: هر تصمیم در حالت ایزوله آن‌قدر ارزان است که کسی انگیزه ندارد «نه» بگوید؛ در نتیجه مهاجرت‌های سیستمی رخ می‌دهد چون سیستم موجود با معماری پیشنهادی AI سازگار نیست.
- راهکارهای بیش از حد خاص: افراد به‌جای هماهنگی با تیم‌های متمرکز داده، اسکریپت‌های شخصی برای حل مشکلات بسیار کوچک می‌سازند.
- شکاف‌های دانشی: این ابزارها اغلب خارج از Git زندگی می‌کنند و به منطقی گره خورده‌اند که حتی سازنده‌اش هم به‌سختی آن را می‌فهمد.
- هرج‌ومرج موروثی: وقتی کارمندی سازمان را ترک می‌کند، جایگزین او مجموعه‌ای از اسکریپت‌های تولید شده توسط AI را به ارث می‌برد، بدون اینکه هیچ زمینه‌ای از منطق دامنه (Domain Context) پشت آن داشته باشد.
مطالعه موردی: زباله‌های بهره‌وری
یک تیم مالی را در نظر بگیرید که در حال تهیه گزارش فصلی است. پیش از این، آن‌ها با مهندسان داده هماهنگ می‌کردند تا خط لوله‌های داده‌ای (Pipelines) بسازند و از یک پلتفرم متمرکز برای اعتبارسنجی داده‌ها در سه سند مختلف استفاده می‌کردند. این فرآیند کند بود اما ساختاریافته بود.
با ورود AI، فرآیند تغییر می‌کند. کاربران غیرفنی از عامل‌ها برای ساخت اسکریپت‌هایی استفاده می‌کنند که تایید دستی داده‌ها را سرعت می‌بخشد. بهره‌وری به‌شدت بالا می‌رود. سپس، به‌جای همکاری با تیم داده برای یک گردش کار جدید، تیم مالی خودش آن را با AI می‌سازد. حالا یک خط لوله که سه گزارش جدید را تایید می‌کند، در سیستمی خارج از Git زندگی می‌کند که به دانشی گره خورده که مالک آن به‌سختی درکش می‌کند. ماشین مالک پیاده‌سازی است و انسان به‌صورت سطحی آن را نگهداری می‌کند.
وقتی آن کارمند می‌رود، جایگزین او گزارش‌ها و اسکریپت‌ها را می‌گیرد اما «درک» پشت آن‌ها را نه. با تغییر نیازهای کسب‌وکار، او از AI می‌خواهد سیستم را به‌روز کند و این باعث می‌شود سیستم بیشتر از «مسیر طلایی» (Golden Path) فاصله بگیرد. در اینجا نقش فرد از متخصص مالی به «مهندس اتفاقی» تغییر می‌کند.
تله تکنولوژی‌های قدیمی (Legacy Tech)
شرکت‌ها با دور زدن فرآیندهای «کندِ» بررسی معماری، در واقع روند منسوخ شدن خود را تسریع می‌کنند. آن‌ها در حال ساخت معادل‌های مدرنی از غول‌های تکنولوژی قدیمی هستند؛ شبکه‌های درهم‌تنیده‌ای از سرویس‌ها که پیاده‌سازی‌شان در اختیار ماشین است و نگهداری‌شان تبدیل به یک بازی حدس‌زدن شده است. ما کسب‌وکارهای جوان را به غول‌های قدیمی تبدیل می‌کنیم که دانش حیاتی آن‌ها در لحظه خروج یک نفر، ناپدید می‌شود.
امروز پیاده‌سازی بخش آسان کار است. بخش سخت، پرسیدن سوالات دشوار، اجرای آزمایش‌هایی که فرضیات را به چالش می‌کشد و حفظ چشم‌انداز کلی است. تفکر در سطح کلان هنوز نیازمند تلاش انسانی است.
شکستن این چرخه
رهبران سازمان‌ها باید دست از پاداش دادن به «تحویل سریع» (Delivery for the sake of delivery) بردارند. هدف باید از «سرعت عرضه ویژگی» به «قابلیت نگهداری آن ویژگی در سه سال آینده» تغییر کند. ما باید پاداش دادن به عملِ سرهم کردن پروژه‌های بزرگ با استفاده از مستندات تولید شده توسط AI و معیارهای موفقیت ساختگی AI را متوقف کنیم.
برای مبارزه با خزش زباله، مهندسان باید به مستندات طراحی دستی و حلقه‌های بازخورد انسانی بازگردند. فرآیند درست باید این باشد:
۱. تمام عامل‌های AI را ببندید و زمان بگذارید برای فکر کردن.
۲. مستند طراحی (Design Doc) را خودتان بنویسید.
۳. راهکارها را به‌طور مستقل توسعه دهید.
۴. بازخورد انسان‌های دیگر را بگیرید (و مطمئن شوید آن‌ها پراکسی انسانی نیستند).
۵. از عامل‌ها فقط برای تنظیم نهایی نتیجه استفاده کنید.
همان‌طور که نویسنده در یادداشتی در ۶ سپتامبر ۲۰۲۶ در اویتینگ اینپوت (Awaiting Input) اشاره کرد، انسان‌ها هنوز برای «فکر کردن» حقوق می‌گیرند و این تنها کاری است که عامل‌ها هنوز نمی‌توانند جایگزین کنند. پس فکر کنید.
گام بعدی شما
- در پروژه بعدی خود، پیش از باز کردن Claude یا ChatGPT، یک صفحه کاغذ بردارید و معماری سیستم را به‌صورت دستی رسم کنید.
- در جلسات بررسی کد (Code Review)، از نویسنده بخواهید هر بخش از کد تولید شده توسط AI را به‌طور شفاهی توضیح دهد تا مطمئن شوید «پراکسی انسانی» نیست.
- فهرستی از اسکریپت‌های «سریع و ارزان» که در سازمانتان ساخته شده و مستند نیستند تهیه کنید و برای حذف یا یکپارچه‌سازی آن‌ها برنامه‌ریزی کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو