دستیارهای کدنویسی هوش مصنوعی میتوانند در چند دقیقه چیزی را بسازند که قبلاً ساعتها وقت میگرفت. همین سرعت باعث شده خیلی از تیمها احساس کنند بهرهوریشان چند برابر شده است؛ اما پژوهشهای تازه نشان میدهد ماجرا همیشه به این سادگی نیست و احتمالا به زودی با مشکلات مهمی مواجه خواهیم شد…
بخشی از کدی که با کمک هوش مصنوعی تولید میشود، بعداً باید اصلاح، حذف یا دوباره نوشته شود. یعنی اگر فقط تعداد خط کد، تعداد تغییرات یا سرعت تولید را معیار موفقیت بدانیم، ممکن است پیشرفت واقعی را با حجم کار اشتباه بگیریم. اجازه دهید در ادامه به تجربیات چند شرکت بزرگ بپردازیم:
تولید کد، سریعتر از سنجشِ کیفیت
برای دههها یکی از سادهترین معیارها برای سنجش کار یک برنامهنویس، «تعداد خطوط کدی» بود که مینوشت. معیاری که شاید هیچوقت دقیق نبود، اما حداقل یک عدد ملموس به دست میداد. با ظهور ابزارهایی مانند «کلود کد» (Claude Code)، «کرسر» (Cursor)، «کدکس» (Codex) و «گیتهاب کوپایلوت» (GitHub Copilot)، معیارهایی مثل تعداد خط کد بیش از گذشته گمراهکننده شدهاند.
این دستیارهای هوشمند میتوانند در زمان کوتاه، حجم زیادی کد، پیشنهاد اصلاح یا تغییرات نرمافزاری تولید کنند و در نگاه اول بهرهوری را بالا ببرند؛ اما سنجش بهرهوری فقط با تعداد خط کد، تعداد تغییرات یا میزان مصرف توکن میتواند گمراهکننده باشد. آنچه در نهایت اهمیت دارد این است که چه مقدار از این کد واقعاً در محصول باقی میماند، درست کار میکند، قابل نگهداشت است و ریسک امنیتی تازهای ایجاد نمیکند.
سونامی «کدهای دورریز» در راه است
شرکتهای تحلیلگر با بررسی خروجی کدهای تولید شده توسط هوش مصنوعی متوجه پدیده جالبی شدهاند که آن را «ریزش کد» (Code Churn)1 مینامند.
به گفته مدیرعامل «ویدو» (Waydev)، این شرکت در دادههای مربوط به بیش از ۱۰ هزار مهندس نرمافزار در ۵۰ سازمان، الگویی دیده که در آن نرخ پذیرش اولیه کدهای تولیدشده با هوش مصنوعی در برخی تیمها به ۸۰ تا ۹۰ درصد میرسد؛ اما وقتی اصلاحات هفتههای بعد هم حساب شود، سهم کدی که بدون بازکاری جدی باقی میماند، ممکن است به حدود ۱۰ تا ۳۰ درصد کاهش پیدا کند.
گزارشهای صنعتی دیگری هم نشانههایی مشابه را مطرح کردهاند:
- گزارش «گیتکلیر» (GitClear) میگوید کاربران منظم ابزارهای هوش مصنوعی، بهطور متوسط ۹.۴ برابر بیشتر از همتایان خود با ریزش کد روبهرو بودهاند.
- «فاروس ایآی» (Faros AI) در گزارشی بر اساس دو سال داده مشتریان خود نوشته که در سازمانهای با پذیرش بالای هوش مصنوعی، ریزش کد ۸۶۱ درصد افزایش یافته است.
- «جلیفیش» (Jellyfish) با بررسی دادههای ۷۵۴۸ مهندس گزارش کرده مهندسانی که بیشترین «بودجه توکن» (Token Budget) را داشتهاند، «درخواست ادغام تغییرات» (Pull Request) بیشتری ثبت کردهاند؛ اما این افزایش خروجی با هزینه مصرفشده تناسب کامل نداشته است. آنها با صرف هزینه ۱۰ برابری برای توکنها، تنها به خروجی ۲ برابری رسیدهاند. به زبان سادهتر: این ابزارها در حال تولید «حجم» هستند، نه «ارزش».
به عبارتی، افزایش حجم کد بهتنهایی تصویر کاملی از بهرهوری نمیدهد. اگر بخش زیادی از کدهای تولیدشده بعداً حذف یا بازنویسی شود، تیمها باید بررسی کنند این تغییرها نشانه اصلاح مفید و بازطراحی درست است یا نشانه بازکاری پرهزینه و کیفیت پایین خروجی.
نوشدارو پلاس
این آمارها بیشتر از گزارشهای شرکتهای فعال در حوزه تحلیل بهرهوری توسعهدهندگان میآید؛ بنابراین نباید آنها را حکم قطعی درباره همه تیمهای نرمافزاری دانست. با این حال، شباهت یافتهها در چند گزارش مختلف نشان میدهد که مسئله «کد بیشتر، ارزش بیشتر» دستکم به بازبینی جدی نیاز دارد.
چرا این روند میتواند کیفیت و امنیت نرمافزار را تحت فشار بگذارد؟
ریزش کد و غلبه سرعت بر دقت، اگر با بازبینی درست همراه نباشد، میتواند کیفیت، پایداری و امنیت نرمافزار را تحت فشار بگذارد.
- انباشت بدهی فنی: کدهای عجولانه یا کمبررسیشده میتوانند نگهداشت محصول را سختتر کنند و در بلندمدت کیفیت معماری نرمافزار را پایین بیاورند.
- کاهش دقت در بازبینی: وقتی حجم تغییرات بالا میرود، برنامهنویسان ارشد و تیمهای بازبینی ممکن است فرصت کافی برای بررسی دقیق منطق، امنیت و معماری کد نداشته باشند.
- اعتماد بیش از حد به خروجی ماشین: اگر توسعهدهندگان، مخصوصاً نیروهای کمتجربهتر، کد تولیدشده را بدون فهم کامل، تست و بازبینی بپذیرند، احتمال ورود باگ یا آسیبپذیری به محصول بیشتر میشود.
برای مطالعه بیشتر
بهجای حجم کد، چه چیزهایی را بسنجیم؟
- چه مقدار از کد تولیدشده بعد از چند هفته هنوز در محصول باقی مانده است؟
- چند درصد تغییرات نیاز به بازنویسی یا اصلاح جدی پیدا میکنند؟
- آیا حجم تغییرات از توان تیم برای بازبینی دقیق بیشتر شده است؟
- نرخ باگ، رخدادهای امنیتی و بدهی فنی بعد از استفاده از ابزارهای هوش مصنوعی چه تغییری کرده است؟
- آیا کدهای تولیدشده تست کافی، مستندات روشن و مالک انسانی مشخص دارند؟
- آیا این کدها واقعاً محصول را بهتر کردهاند یا فقط حجم پروژه را بالا بردهاند؟
- هزینه مصرف توکن در برابر خروجی مفید چقدر است؟
در آخر؛ معیار بهرهوری را باید عوض کرد
موج جدید توسعه نرمافزار با هوش مصنوعی احتمالاً گذرا نیست و تیمها ناچارند کار با این ابزارها را یاد بگیرند؛ اما چالش اصلی دیگر فقط تولید کد بیشتر نیست؛ چالش این است که بدانیم کدام کد واقعاً در محصول میماند، درست کار میکند، قابل نگهداشت است و ریسک امنیتی تازهای ایجاد نمیکند.
بنابراین معیارهای قدیمی مثل تعداد خط کد، تعداد تغییرات یا حتی میزان مصرف ابزارهای هوش مصنوعی بهتنهایی کافی نیستند. تیمها باید در کنار سرعت تولید، چیزهایی مثل کیفیت بازبینی، نرخ باگ، ریزش کد، هزینه نگهداشت، تستپذیری و اثر واقعی روی محصول را هم بسنجند. هوش مصنوعی میتواند برنامهنویسی را سریعتر کند، اما ارزش نرمافزار هنوز به کیفیت تصمیمهای انسانی بستگی دارد.
- ریزش کد (Code Churn) یعنی بخشی از کد که بعد از اضافه شدن به پروژه، در مدت کوتاهی حذف، تغییر یا بازنویسی میشود. این اتفاق همیشه نشانه بدی نیست؛ گاهی بخشی از «بازطراحی کد» (Refactor) طبیعی پروژه است؛ اما اگر ریزش کد ناگهان زیاد شود، میتواند نشانه بازکاری، تصمیم عجولانه یا کیفیت پایین خروجی باشد. ↩︎
