استفاده از VM یک‌بارمصرف برای عامل‌های کدنویسی AI

چرا یک VM یک‌بارمصرف از لپ‌تاپ شما بهتر است

اگر به یک عامل کدنویسی (coding agent) یک VM یک‌بارمصرف بدهید، بدترین اتفاقی که ممکن است رخ دهد، نابودی ماشینی است که می‌توانید در عرض 10 دقیقه دوباره آن را بسازید. این عامل همچنان دسترسی root دارد، بسته‌ها را نصب می‌کند و بدون نیاز به اجازه برای هر مرحله، مجموعه تست‌ها را اجرا می‌کند. تفاوت در این است که آسیب به کجا وارد می‌شود. روی لپ‌تاپ، عامل با دایرکتوری home شما که شامل کلیدهای SSH، پروفایل مرورگر، فایل‌های .env و تمام مخازنی است که تا به حال clone کرده‌اید، مشترک است. روی یک سرور یک‌بارمصرف، عامل فقط یک shell و یک checkout دارد و هیچ چیز دیگری که ارزش سرقت داشته باشد وجود ندارد.

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

پیش از بحث درباره شعاع انفجار، آن را تعریف کنید

شعاع انفجار به مجموعه‌ای از منابع گفته می‌شود که یک پردازش به آن‌ها دسترسی دارد. برای عاملی (agent) که با کاربر عادی شما روی سیستم معمولی‌تان اجرا می‌شود، این مجموعه بسیار گسترده‌تر از آن چیزی است که اکثر افراد تصور می‌کنند.

این مجموعه شامل ~/.ssh/id_ed25519 است که معمولاً رمزنگاری‌نشده باقی می‌ماند، چون از تایپ مداوم عبارت عبور خسته شده‌اید. این مجموعه شامل ~/.aws/credentials و ~/.config/gh/hosts.yml است که ذاتاً به صورت متن ساده (plain text) هستند. همچنین شامل تمام مخازن (repository) هم‌سطح در مسیر ~/code می‌شود، از جمله آن‌هایی که حاوی رشته‌های اتصال به محیط عملیاتی (production) در یک فایل env محلی هستند. تاریخچه shell شما نیز بخشی از این مجموعه است که توکن‌هایی را که یک‌بار در آن کپی کرده‌اید، در خود نگه می‌دارد. علاوه بر این، شبکه محلی که لپ‌تاپ شما به آن متصل است نیز در این محدوده قرار می‌گیرد؛ شبکه‌ای که اغلب در خانه یا دفتر کار است و سرویس‌های بدون احراز هویت روی آن وجود دارند.

هیچ‌کدام از این موارد نیازی به یک عامل مخرب ندارند. تنها یک دستور که با اطمینان اما به اشتباه اجرا شود، کافی است. یک rm -rf با متغیری که مقداردهی نشده و به / بسط می‌یابد، یک git clean -xfd در دایرکتوری اشتباه، یک docker system prune -af --volumes که دیتابیس محلی شما را نیز پاک می‌کند، یا یک chmod -R 777 مفید روی دایرکتوری خانگی. عامل‌ها بر اساس همان اینترنتی آموزش دیده‌اند که این دستورات را به دیگران آموخته است.

مکانیزمی که شما را نجات می‌دهد، قضاوت آن عامل نیست. بلکه این واقعیت است که ماشینی که آسیب را متحمل می‌شود، همان ماشینی است که از قبل آمادگی از دست دادن آن را داشته‌اید.

محاسبات هزینه خسته‌کننده است، و دقیقاً همین نکته اصلی است

یک VPS کوچک ماهانه چند دلار هزینه دارد. بازیابی لپ‌تاپ یک توسعه‌دهنده یک روز کامل زمان می‌برد، و این در بهترین حالت است؛ یعنی زمانی که بلافاصله متوجه مشکل می‌شوید و نسخه پشتیبان هم دارید.

این محاسبات را با اعداد خودتان انجام دهید. نرخ ساعتی خود را در تعداد ساعاتی که برای نصب مجدد سیستم‌عامل، بازیابی دایرکتوری home، تغییر کلید SSH، تغییر توکن دسترسی شخصی و کلون کردن مجدد 20 مخزن کد نیاز دارید، ضرب کنید. این عدد را با هزینه 12 ماه استفاده از کوچک‌ترین سروری که ارائه‌دهنده شما می‌فروشد مقایسه کنید. نقطه سر‌به‌سر هزینه، کمتر از یک حادثه در هر چند سال است و برای رسیدن به این حد نصاب، لازم نیست حادثه فاجعه‌بار باشد. تنها یک بعدازظهر که به دلیل خرابی محیط محلی از دست می‌رود، هزینه یک سال سرور را پوشش می‌دهد.

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

چشم‌انداز تا ژوئیه 2026

سه پاسخ صادقانه برای پرسش «عامل (agent) کجا باید اجرا شود» وجود دارد که همگی میان دو فاکتور مبادله (trade-off) ایجاد می‌کنند: قدرت مرز امنیتی و میزان تنظیمات مورد نیاز.

یک میکرو ماشین مجازی محلی (Local micro VM). ابزارهای این دسته، یک ماشین مجازی واقعی را روی سخت‌افزار شما بوت می‌کنند، مخزن (repository) شما را درون آن mount می‌کنند و به عامل اجازه می‌دهند دسترسی root در آن داشته باشد. clawk نمونه فعلی است و ایده اصلی آن دقیقاً همان تز این مقاله است: به عامل‌های برنامه‌نویسی یک ماشین مجازی لینوکس یک‌بارمصرف بدهید، نه لپ‌تاپ خودتان. تا ژوئیه 2026، این ابزار macOS 14 و نسخه‌های بعد از آن را روی Apple silicon هدف قرار می‌دهد و پشتیبانی آزمایشی از لینوکس را از طریق Firecracker ارائه می‌کند؛ نصب آن نیز با brew install clawkwork/tap/clawk انجام می‌شود. شما clawk را درون یک مخزن اجرا می‌کنید تا sandbox بوت شود و عامل به آن متصل گردد، clawk down برای متوقف کردن و clawk destroy برای حذف آن است. مرز امنیتی در اینجا یک hypervisor است که بسیار قدرتمند است. محدودیت این است که ماشین مجازی روی دستگاهی که با خود حمل می‌کنید اجرا می‌شود، بنابراین با حافظه سیستم شما رقابت می‌کند و با بستن درب لپ‌تاپ، متوقف می‌شود.

یک کانتینر. Docker پاسخی است که اکثر افراد از قبل نصب کرده‌اند و حقیقتاً مفید است.

docker run --rm -it -v "$PWD:/work" -w /work --network none ubuntu:24.04 bash

--rm کانتینر را پس از خروج حذف می‌کند و --network none هیچ دسترسی شبکه‌ای به آن نمی‌دهد که برای اجرای build یا تست، تنظیم پیش‌فرض مناسبی است. دقت کنید که این روش چه کاری انجام نمی‌دهد: کانتینر از هسته (kernel) میزبان استفاده می‌کند، بنابراین یک باگ در هسته راهی برای خروج از آن است؛ همچنین به محض اینکه --privileged را اضافه کنید یا /var/run/docker.sock را mount کنید تا عامل بتواند «از Docker استفاده کند»، مرز امنیتی از بین می‌رود. mount کردن Docker socket درون یک کانتینر، معادل دادن دسترسی root میزبان به آن کانتینر است.

یک VPS ساده که قابلیت بازسازی دارد. بدون نیاز به ابزار جدید، با مرز امنیتی واقعی هسته، قابلیت snapshot گرفتن توسط ارائه‌دهنده، و این مزیت که وقتی لپ‌تاپ خود را خاموش می‌کنید، همچنان به کار خود ادامه می‌دهد. این همان الگویی است که در ادامه این راهنما شرح داده شده و برای اجرای طولانی‌مدت عامل‌ها مناسب است، زیرا کاری که چهار ساعت زمان می‌برد، اهمیتی نمی‌دهد که شما به خانه رفته‌اید.

الگوی VPS: اختصاص یک کاربر مجزا به agent

با یک سرور امن‌شده شروع کنید. راهنمای ده دقیقه اول روی یک VPS جدید بخش‌هایی را پوشش می‌دهد که مختص agent نیستند: به‌روزرسانی‌ها، ورود غیر-root، استفاده از SSH key و فایروال.

سپس حسابی ایجاد کنید که فقط برای agent وجود داشته باشد تا یک اشتباه در آن، سایر بخش‌های سرور را تحت تأثیر قرار ندهد.

sudo adduser --disabled-password --gecos "" agent
sudo install -d -m 700 -o agent -g agent /home/agent/work
sudo -u agent -H bash -lc 'id; ls -la ~'

--disabled-password به این معنی است که هیچ رمز عبوری برای حدس زدن وجود ندارد و شما با استفاده از sudo -u agent یا یک SSH key به این حساب دسترسی پیدا می‌کنید. توجه داشته باشید که agent عمداً در گروه sudo قرار ندارد. یک agent با sudo دسترسی root دارد و root می‌تواند فایل‌های هر کاربر دیگری را بخواند؛ بنابراین جداسازی که ایجاد کردید صرفاً ظاهری خواهد بود. اگر agent واقعاً نیاز به نصب پکیج دارد، این دلیلی برای اختصاص یک سرور کامل به آن است، نه دادن دسترسی sudo روی یک سرور اشتراکی. قوانین کلی در اصل حداقل امتیاز برای کاربران لینوکس در VPS آمده است.

پیش از اعتماد به مرز امنیتی، آن را بررسی کنید. به عنوان کاربر agent، سعی کنید فایلی متعلق به حساب کاربری خودتان را بخوانید:

sudo -u agent cat /home/you/.ssh/id_ed25519

شما باید cat: /home/you/.ssh/id_ed25519: Permission denied را مشاهده کنید. اگر به جای آن محتوای کلید را می‌بینید، دایرکتوری home شما دارای مجوز 755 است و جداسازی هنوز واقعی نیست. آن را با sudo chmod 700 /home/you اصلاح کنید.

اعتبارنامه‌ها را به‌طور کامل از روی ماشین دور نگه دارید

اگر اسرار تولید (production secrets) خود را روی یک ماشین یک‌بارمصرف کپی کنید، هدف از استفاده از چنین ماشینی از بین می‌رود. قاعده ساده است: هیچ‌چیز روی آن ماشین نباید اعتبارنامه‌ای باشد که نگران تغییر فوری آن در همین بعدازظهر باشید.

برای git، به‌جای کپی کردن کلید، SSH agent خود را forward کنید. کلید خصوصی روی لپ‌تاپ شما باقی می‌ماند و تنها درخواست‌های امضا از طریق اتصال منتقل می‌شوند.

ssh -A agent@203.0.113.10
ssh -T git@github.com

دستور دوم باید پاسخ Hi yourname! You've successfully authenticated, but GitHub does not provide shell access. را بدهد. این ثابت می‌کند که git push بدون وجود فایل کلید روی سرور کار خواهد کرد. پس از آن ls -la ~/.ssh را روی ماشین اجرا کنید و تأیید کنید که هیچ کلید خصوصی در آن وجود ندارد.

Forward کردن agent یک هشدار جدی دارد که باید صریح بیان شود: تا زمانی که متصل هستید، هر کسی که دسترسی root روی آن سرور داشته باشد، می‌تواند از سوکت forward شده برای احراز هویت به جای شما استفاده کند. روی سروری که تنها کاربر دیگر آن خود شما هستید، این یک معامله قابل‌قبول است. روی یک ماشین اشتراکی این‌طور نیست و یک deploy key که محدود به یک مخزن (repository) خاص باشد، پاسخ بهتری است. گزینه‌ها در اصول مدیریت کلید SSH پوشش داده شده‌اند.

برای کلیدهای API، به agent کلید مخصوص خودش را با محدودیت هزینه مشخص بدهید که در فایلی با مالکیت کاربر agent و با مجوز 600 ذخیره شده باشد. وقتی ماشین از بین می‌رود، آن کلید را ابطال کنید تا نگران نشت احتمالی آن نباشید. قابل‌مشاهده نگه داشتن هزینه‌های مدل به تفکیک هر کلید، همان روشی است که باعث می‌شود اعداد در کنترل هزینه عامل هوش مصنوعی روی VPS قابل پیش‌بینی باقی بمانند.

محدود کردن دسترسی عامل به شبکه

ایزوله‌سازی سیستم‌فایل نیمی از مرزبندی است. نیمه دیگر، خروجی شبکه (egress) است: یعنی فرآیند مجاز است با چه چیزی ارتباط برقرار کند. لینوکس می‌تواند ترافیک خروجی را بر اساس کاربری که آن را ایجاد کرده است فیلتر کند، که دقیقاً با این الگو مطابقت دارد.

sudo iptables -A OUTPUT -m owner --uid-owner agent -o lo -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p tcp --dport 443 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -j REJECT

قوانین به ترتیب خوانده می‌شوند، بنابراین REJECT نهایی هر چیزی را که خطوط قبلی اجازه نداده‌اند، مسدود می‌کند. آن را با دسترسی عامل تست کنید:

sudo -u agent curl -sS -m 5 http://example.com

این دستور باید با curl: (7) Failed to connect to example.com port 80: Connection refused شکست بخورد، زیرا قانون reject به‌جای معلق نگه داشتن اتصال، بلافاصله پاسخ می‌دهد. یک درخواست HTTPS به همان میزبان همچنان باید موفقیت‌آمیز باشد.

دو محدودیت صادقانه وجود دارد. اول، این قوانین در reboot بعدی از بین می‌روند مگر اینکه آن‌ها را با sudo apt install -y iptables-persistent و سپس sudo netfilter-persistent save ذخیره کنید. دوم، این روش پورت‌ها و آدرس‌ها را فیلتر می‌کند، نه نام‌ها را. قانونی که اجازه دسترسی به پورت 443 را می‌دهد، اجازه دسترسی به تمام میزبان‌های HTTPS در اینترنت را صادر می‌کند؛ این برای دسترسی به API مدل کافی است و همچنین برای دسترسی به یک pastebin نیز کفایت می‌کند. یک لیست سفید (allow-list) واقعی برای دامنه‌ها نیازمند عبور ترافیک از یک پروکسی است که نام میزبان درخواستی را می‌خواند، که این کار پیچیدگی بیشتری نسبت به آنچه اکثر توسعه‌دهندگان انفرادی می‌خواهند، دارد. فقط به آنچه دارید بسنده کنید: کنترل خروجی در سطح پورت، روی ماشینی که آماده از دست دادن آن بوده‌اید.

بازگشت به وضعیت پاک بین وظایف

داشتن وضعیت پاک برای هر وظیفه، مزیتی است که اغلب نادیده گرفته می‌شود. عاملی (agent) که سه ساعت روی تیکت قبلی کار کرده، ممکن است بسته‌های نصب‌شده، migrationهای نیمه‌کاره، یک node_modules قدیمی و یک working tree در git با تغییراتی که هیچ‌کس بازبینی نکرده، بر جای بگذارد. وظیفهٔ بعدی تمام این موارد را به ارث می‌برد و شما باید بودجهٔ بازبینی خود را صرف تشخیص این کنید که کدام آشفتگی مربوط به کدام اجراست. یک عامل محدودتر، در وهلهٔ اول ردپای کمتری بر جای می‌گذارد؛ بنابراین ترکیب یک ماشین یک‌بارمصرف با مهارتی که عامل را به سمت کوچک‌ترین تغییرِ کارآمد سوق می‌دهد، باعث می‌شود هم diff و هم وضعیت باقی‌مانده به اندازهٔ کافی کوچک و قابل‌بازبینی باقی بمانند.

نسخهٔ ارزان‌تر، یک checkout تازه برای هر وظیفه است.

sudo -u agent -H bash -lc 'rm -rf ~/work/repo && git clone git@github.com:you/repo.git ~/work/repo'

نسخهٔ قوی‌تر، استفاده از snapshot ارائه‌دهنده (provider) است که دقیقاً پس از راه‌اندازی ماشین و پیش از آنکه هیچ عاملی به آن دسترسی پیدا کند، گرفته می‌شود. بازگردانی آن snapshot، کل سیستم—از جمله بسته‌ها—را به وضعیتی شناخته‌شده برمی‌گرداند. اکثر ارائه‌دهندگان این قابلیت را در پنل کنترل یا از طریق API ارائه می‌دهند و نه به عنوان یک دستور داخل ماشین؛ بنابراین مراحل دقیق کار به ارائه‌دهندهٔ شما بستگی دارد. انضباط کاری حکم می‌کند که snapshot را زمانی بگیرید که ماشین هنوز در وضعیت اولیه و بدون تغییر است.

هر چیزی که برایتان اهمیت دارد را خارج از ماشین یک‌بارمصرف نگه دارید؛ این یعنی به جای انباشتن branchها به صورت محلی، آن‌ها را push کنید. اگر ماشین نهایتاً حاوی چیزی شد که از دست دادن آن برایتان دشوار است، با استفاده از پشتیبان‌گیری restic روی یک VPS به درستی از آن نسخهٔ پشتیبان تهیه کنید. ماشینی که می‌توانید آن را نابود کنید، تنها زمانی مفید است که نابود کردنش واقعاً بی‌دردسر باشد.

اگر می‌خواهید چندین محیط ایزوله داشته باشید بدون اینکه هزینهٔ چندین سرور را بپردازید، یک VPS بزرگ‌تر می‌تواند مستقیماً میزبان ماشین‌های مجازی مهمان باشد. مجازی‌سازی تو در تو (Nested virtualisation) روی یک VPS نحوهٔ عملکرد این موضوع و چگونگی بررسی مجاز بودن آن توسط ارائه‌دهنده را پوشش می‌دهد. ایزولاسیون در اینجا دو جنبه دارد؛ اگر ترجیح می‌دهید دو عامل روی یک ماشین به جای ایزوله بودن از یکدیگر، با هم هماهنگ شوند، یک نشست Claude Code می‌تواند متن را مستقیماً به نشست دیگر بفرستد و نیازی نیست هر انتقال (handoff) از طریق شما انجام شود.

چه زمانی استفاده از لپ‌تاپ با رعایت نکات ایمنی واقعاً مناسب است

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

اگر پیش از اجرای هر دستور، آن را بررسی می‌کنید، استفاده از لپ‌تاپ مشکلی ندارد. اعلان مجوز (permission prompt) یک کنترل واقعی است و اجرای ایمن Claude Code روی سرور توضیح می‌دهد که هر سطح از آن دقیقاً چه چیزی را مسدود می‌کند. اگر کار شما محدود به یک مخزن (repository) واحد است و هیچ اعتبارنامه (credential) محیط تولیدی روی دستگاه وجود ندارد، شعاع آسیب (blast radius) از قبل کوچک است. اگر نشست‌های (session) عامل شما کوتاه و تحت نظارت هستند، پنجرهٔ در معرض خطر بودن نیز کوتاه است.

پاسخ به این پرسش در لحظه‌ای تغییر می‌کند که شما از تأیید اعلان‌ها صرف‌نظر کنید؛ موضوعی که با توجه به اینکه حالت خودکار از 14 August 2026 به تنظیم پیش‌فرض Claude Code تبدیل می‌شود و نصب تازه دیگر پیش از ویرایش فایل‌ها یا اجرای دستورات از شما سؤال نمی‌کند، ارزش تأمل دارد. اجراهای بدون نظارت، کارهای شبانه و هر گردش کاری که در آن طرحی را تأیید می‌کنید و سیستم را به حال خود رها می‌کنید، همگی عامل انسانی که وظیفهٔ محدودسازی را بر عهده داشت حذف می‌کنند. در این شرایط است که ماشین باید این وظیفه را انجام دهد. همین موضوع در مورد هر چیزی که دسترسی عامل را گسترش می‌دهد، از جمله اجرای یک عامل کدنویسی روی VPS برای چندین مخزن به‌طور همزمان، صدق می‌کند.

تصمیم نهایی در واقع دربارهٔ میزان اعتماد شما به مدل نیست؛ بلکه دربارهٔ این است که وقتی مدل دچار اشتباه می‌شود، چه چیزی در کنار آن قرار دارد.

FAQ

آیا کانتینر برای ایزوله‌سازی یک عامل کدنویسی کافی است؟

برای اکثر کارها، بله، با دو شرط. کانتینر نباید با --privileged اجرا شود و نباید /var/run/docker.sock در آن mount شده باشد، زیرا هر دوی این موارد به پردازش اجازه می‌دهند به دسترسی root روی میزبان (host) دست یابد. کانتینر از هسته (kernel) میزبان استفاده می‌کند، بنابراین مرز امنیتی آن ضعیف‌تر از یک ماشین مجازی است. اگر عامل در حال اجرای کد غیرقابل‌اعتمادی است که از اینترنت دریافت شده، از یک ماشین مجازی واقعی یا یک سرور مجزا استفاده کنید.

آیا عامل به sudo روی سرور نیاز دارد؟

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

چگونه بدون قرار دادن کلید SSH روی سرور، به عامل اجازه push به git بدهم؟

هنگام اتصال، SSH agent خود را با ssh -A فوروارد کنید. درخواست‌های امضا از طریق اتصال ارسال می‌شوند در حالی که کلید خصوصی روی لپ‌تاپ شما باقی می‌ماند، بنابراین ssh -T git@github.com احراز هویت می‌شود و git push بدون نیاز به کلید خصوصی روی سرور کار می‌کند. نکته مهم این است که کاربر root روی آن سرور می‌تواند در زمانی که شما متصل هستید از سوکت فوروارد شده استفاده کند، بنابراین روی هر ماشینی که با دیگران به اشتراک می‌گذارید، از یک deploy key با دامنه محدود به همان مخزن (repository-scoped) استفاده کنید.

یک عامل به چه اندازه VPS نیاز دارد؟

کار عامل عمدتاً ویرایش فایل‌ها، اجرای buildها و اجرای تست‌ها است، بنابراین اندازه ماشین را بر اساس نیاز build تنظیم کنید، نه بر اساس مدل. یک مدل میزبانی‌شده روی سخت‌افزار ارائه‌دهنده اجرا می‌شود که باعث ایجاد ترافیک شبکه شده و تقریباً هیچ بار پردازشی محلی ندارد. برای کارهای اسکریپت‌نویسی با 2 GB رم شروع کنید و اگر مخزن پروژه کانتینر می‌سازد یا عملیات کامپایل سنگینی دارد، به 8 GB ارتقا دهید.

هر چند وقت یک‌بار باید ماشین را تخریب و دوباره ایجاد کنم؟

زمانی که وضعیت سیستم دیگر قابل توضیح نیست، و حداقل هر زمان که ممکن است اعتبارنامه‌ای (credential) روی سیستم لو رفته باشد، آن را بازسازی کنید. یک checkout تازه بین وظایف، تغییرات روزمره را مدیریت می‌کند و اسنپی که پیش از اولین اجرای عامل گرفته شده، یک ایمیج سیستم تمیز برای بازگشت به شما می‌دهد. اگر بازسازی سیستم هزینه‌بر به نظر می‌رسد، این نشانه‌ای است که چیزی مهم روی ماشینی که آن را یک‌بارمصرف (disposable) نامیده‌اید، در حال اجراست.