arrow_backبازگشت به یادداشت‌های میدانی
AI منتشر شده 30 Jul 2026

توسعه‌دهندگان در استفاده از دستیاران AI چه اشتباهاتی می‌کنند؟

نگاهی عملی به رایج‌ترین روش‌های استفاده نادرست توسعه‌دهندگان از دستیاران کدنویسی AI و نحوه اجتناب از ارسال باگ و آسیب‌پذیری‌ها.

دستیاران AI مانند Copilot، Claude و مدل‌های داخلی Cursor نحوه نوشتن کد را تغییر داده‌اند. آن‌ها تغییری در نحوه بررسی دقیق آن‌ها ایجاد نکرده‌اند. اکثر خسارت‌هایی که از کدنویسی کمک‌شده با AI دیده‌ام از چند عادت تکراری ناشی می‌شود، نه از خود مدل‌ها.

پذیرش پیشنهادها بدون خواندن آن‌ها

بزرگ‌ترین مشکل، پذیرفتن tab یک تکمیل است زیرا معقول به نظر می‌رسد و compile می‌شود. معقول بودن یعنی صحیح نیست. من دیده‌ام که یک query SQL پیشنهادی به طور خاموشانه یک شرط WHERE را حذف کند و فرد آن را پذیرفته زیرا نام‌های متغیر مطابقت داشتند. اگر تمام خطوط ارائه شده توسط دستیار را با سرعتی که یک pull request از همکار را می‌خوانید بررسی نکنید، چیزی را ارسال خواهید کرد که نمی‌فهمید. هر پیشنهاد را مانند یک پیش‌نویس اول از یک توسعه‌دهنده جوان که سریع است اما هیچ خاطری از قراردادهای codebase شما ندارد، در نظر بگیرید.

اعتماد به آن برای کد حساس به امنیت

دستیاران AI بر روی توده‌های بزرگی از کد عمومی آموزش داده شده‌اند و بسیاری از این کدها مشکلات امنیتی درونی دارند. برای یک handler آپلود فایل سریع درخواست کنید و اغلب چیزی بدون بررسی پسوند، بدون محدودیت اندازه و با مسیری که با الحاق رشته‌ای به جای os.path.join یا یک فراخوانی کتابخانه امن ساخته شده است، دریافت خواهید کرد. همین داستان برای auth: دستیاران دوست دارند JWT را در localStorage ذخیره کنند یا رازها را با == به جای یک مقایسه زمان ثابت مقایسه کنند. هیچ‌کدام از این موارد بدخواه نیست، فقط از نظر آماری در داده‌های آموزشی رایج است. برای هر چیزی که به احراز هویت، I/O فایل، deserialization یا SQL می‌رسد، منطق را خودتان بنویسید یا خروجی AI را از طریق همان سؤالات threat-modeling بگذرانید که برای هر کد جدید می‌پرسید: اگر ورودی‌های بد آمده چه می‌شود، اگر این فراخوانی شکست بخورد چه می‌شود، چه کسی دیگری می‌تواند به این endpoint برسد.

اجازه دادن به آن برای اختراع dependencies و APIs

مدل‌ها نام‌های بسته و امضای تابع را با اطمینان کامل تهیم می‌کنند. این مشکل "slopsquatting" است — مهاجمان نام‌های بسته‌ای جعلی را ثبت می‌کنند که مدل‌ها اغلب پیشنهاد می‌دهند، بنابراین یک pip install یا npm install غیرتأیید شده می‌تواند چیزی را بکشد که کتابخانه logging شما نیست. قبل از افزودن هر dependency‌ای که دستیار توصیه می‌کند، بررسی کنید که واقعاً بر PyPI یا npm وجود دارد، تعداد دانلود و تاریخ انتشار آخر را بررسی کنید و اگر به‌اندازه کافی کوچک است، منبع را مرور کنید. همان احتیاط برای فراخوانی‌های API اعمال می‌شود: اگر دستیار به متدی اشاره می‌کند که نمی‌شناسید، قبل از فرض اینکه وجود دارد، مستندات واقعی را بررسی کنید.

از دست دادن مدل ذهنی کد خود

هنگامی که خودتان کد می‌نویسید، یک نقشه ذهنی از دلیل وجود هر قطعه می‌سازید. هنگامی که بلوک‌های بزرگی از کد تولید شده توسط AI را در طول یک جلسه می‌پذیرید، این نقشه سریع نازک می‌شود. سپس یک باگ سه هفته بعد ظاهر می‌شود و شما کدی را debug می‌کنید که هرگز واقعاً نوشتید نیست و به طور کامل یادتان نیست. راه حل این نیست که از کد تولید شده توسط AI دوری کنید، بلکه به‌اندازه کافی کند شوید تا هر قطعه را به خود یا به یک تیم‌مت، قبل از merge کردن آن توضیح دهید. اگر نمی‌توانید توضیح دهید که یک تابع چه می‌کند و چرا به این روش انجام می‌دهد، آن را هنوز merge نکنید.

صرف‌نظر از تست‌ها زیرا کد

با کمک هوش مصنوعی نوشته‌شده، بازبینی و منتشر‌شده توسط Michal Pilch (CISSP)، Korra Studio.

آماده برای پیش‌رفت بیشتر؟

این یکی از یادداشت‌های پایگاه دانش Korra Studio است — پلتفرم هر موضوع را با مربی یک‌به‌یک جفت می‌کند.

شروع رایگانarrow_forward