💡 استفاده از GenAI در توسعه نرم‌افزار، خوب، بد، زشت!

چند سالیه که سهم عبارت «AI» لابلای جملات، تیتر اخبار، صحبت‌های یومیه‌ی عوام تا متخصصین، شهروند تا دولتمرد، مصرف‌کننده تا صنعت‌گر روز به روز بیشتر شده. ترم‌هایی مثل Vibe Coding یا AI-Driven Development یا AI Slop به دایره‌ی واژگانمون اضافه شدن. حالا این وسط یه عده سودهای کوتاه‌مدت می‌برن، مثل پکیج‌فروش‌ها، سرویس‌هایی که چند تا API رو صدا می‌کنن و یه سرویس مثلا هوشمند ارائه می‌کنن؛ و برخی هم بیزنس‌های بر پایه‌ی این تحول ایجاد کردن، مثل سازنده‌های مدل‌های پایه، سرویس‌های کاربردی مدیریت AI مثل Agent Manager یا Prompt Engineering Platform و… یا اینکه AI رو مثل یک ابزار دیدن و کاربری اون رو «صحیح و اصولی» یاد گرفتن و مرتبا به‌روز می‌شن تا مثل دورانی که اکثریت با محدودیت‌های نرم‌افزارهای دسکتاپ دست‌وپنجه نرم می‌کردن و عده‌ای خیلی زود و به موقع، توسعه مبتنی بر وب رو جایگزین کردن، بتونن از مواهب AI به نفع بهره‌وری، خلاقیت، و توسعه پایدار بهره ببرن.
این مطلب رو در چند بخش می‌نویسم، با توجه به فضای جامعه توسعه نرم‌افزار، متن رو خیلی مطالعه‌-محور می‌نویسم تا مقاومت کمتری نسبت به تحلیل شخصی داشته باشه؛ اول به «بد»، و در ادامه به «زشت» و نهایتا به «خوب» می‌پردازم:

✅ هوش مصنوعی مولد (GenAI) می‌تونه بهره‌وری رو تا ۵۵٪ افزایش بده، اما اغلب، کدهای ناسازگار و شکننده تولید می‌کنه که نگهداری اون‌ها دشواره. (sloanreview.mit.edu)
✅ توی تیم‌های نوپا، GenAI ضعف‌های فنی رو پوشش می‌دهد اما بدهی فنی ایجاد می‌کنه و حتی تغییرات کوچک‌تغییرات رو پرریسک می‌کنه. (sloanreview.mit.edu)
✅ در شرکت‌های بالغ «با شیوه‌های استاندارد»، GenAI خطاها رو کاهش می‌ده و نوآوری رو تا ۶۴٪ بهبود می‌ده، هرچند نیاز به بررسی انسانی داره. (mckinsey.com)
✅ مطالعات نشون می‌ده ۴۸٪ کدهای GenAI دارای آسیب‌پذیری‌های امنیتی هستن، که البته این یه موضوع بحث‌برانگیزه. (secondtalent.com)

💩 فصل اول: The Bad: بدهی فنی‌ای که نمی‌بینیم

- کد چرخشی (Code Churn): سیگنال خطر: تحقیقات GitClear روی ۲۱۱ میلیون خط کد تغییریافته بین سال‌های ۲۰۲۰ تا ۲۰۲۴ نشون می‌ده که Code Churn (درصد کدی که کمتر از دو هفته پس از نوشته شدن اصلاح یا حذف می‌شه) در سال ۲۰۲۴ دو برابر سال ۲۰۲۱ شده. این یعنی کدی که AI تولید می‌کنه، اغلب ناقص یا اشتباهه و نیاز به بازنگری سریع داره.

- کپی‌پیست به جای معماری: در سال ۲۰۲۴، GitClear افزایش ۸ برابری در بلوک‌های کد تکراری (۵ خط یا بیشتر) رو ثبت کرده (یعنی ۱۰ برابر بیشتر از دو سال پیشش). مشکل اینجاست که AI به جای refactor کردن و استفاده مجدد از کد موجود، ترجیح می‌ده کد جدید بنویسه. نتیجه؟ نقض اصل (DRY (Don't Repeat Yourself و کدبیسی که مدیریتش کابوسه.
در سال ۲۰۲۴، ۴۶٪ تغییرات کد، خطوط جدید بودند و کد کپی‌پیست شده، بیش از کد جابجا شده (moved) بوده (یعنی کمتر refactoring شده و بیشتر به صورت بی‌رویه کد اضافه شده).

- افزایش باگ و کاهش پایداری: مطالعه شرکت Uplevel که توسعه‌دهنده‌های با دسترسی به Copilot رو بررسی کرده، نشون می‌ده این دولوپرها به طور معناداری نرخ باگ بالاتری تولید کردن، در حالی که بهره‌وری کلی‌شون ثابت مونده. گزارش DORA 2024 گوگل هم تأیید می‌کنه: ۲۵٪ افزایش در استفاده از AI منجر به بهبود در code review و مستندات می‌شه، اما ۷.۲٪ کاهش در پایداری تحویل (delivery stability) ایجاد می‌کنه. همچنین گزارش Harness 2025 نشون داد اکثر توسعه‌دهندگان زمان بیشتری صرف debugging کد تولیدشده توسط AI و رفع آسیب‌پذیری‌های امنیتی می‌کنند.


💬 قبل از پردختن به بخش دوم، یعنی «زشت» و بخش سوم، یعنی «خوب» نظرتون رو در مورد استفاده خوب بگید و بنویسید که آیا این آسیب‌ها رو قبول دارین؟

💡💡 قسمت دوم: استفاده از GenAI در توسعه نرم‌افزار، خوب، بد، زشت!

🥴 فصل دوم: The Ugly: تبعات طولانی‌مدت

اگر "بد" نمایانگر اصطکاک عملیاتیه، "زشت" نمایانگر ریسک سیستمیه. داده‌های سال‌های ۲۰۲۴ و ۲۰۲۵ به بحرانی قریب‌الوقوع در قابلیت نگهداری و امنیت نرم‌افزار اشاره می‌کنن...

جنبه‌ی «زشت» ماجرا اینه که نتیجه‌ی نهایی استفاده از هوش مصنوعی مولد به‌شدت وابسته به بلوغ فنی و انضباط تیمه. اگر تیمی فرهنگ کدنویسی سالم، معیارهای کیفی و فرایندهای بازبینی روشن نداشته باشه، برای استفاده از GenAI دستورالعمل «فکر شده» و متناسب با نیازها و استعداد تیم نداشته باشه؛ AI می‌تونه هرج‌ومرج ایجاد کنه یا هرج‌ومرج موجود رو تشدید کنه. توی برخی نظرسنجی‌ها دیده شده که کارکنان احساس کردن بهره‌وری‌شون با وجود هوش مصنوعی کاهش یافته!

بدهی فنی که قابل پرداخت نیست
پروفسور Armando Solar-Lezama استاد دانشگاه MIT می‌گه: "AI مثل یه کارت اعتباری جدیده که به ما اجازه می‌ده بدهی فنی رو به روش‌هایی انباشته کنیم که هرگز قبلاً نتونسته بودیم."
مطالعه دانشگاه Carnegie Mellon روی ۸۰۷ ریپو GitHub که بین ژانویه ۲۰۲۴ تا مارچ ۲۰۲۵ که از Cursor استفاده کرده بودن، نشون می‌ده که با وجود بهبودهای مدل‌های AI (Sonnet، GPT و غیره)، الگوی کاهش کیفیت کد همچنان ادامه داره. حتی با ارتقای ابزارها، کیفیت کد مسیر خودش رو به سمت افول طی می‌کنه! دلایلی مثل زمان صرف زیاد برای آزمون‌وخطا با ابزار یا رفع خطاهای ناشی از اون رو می‌شه در نظر گرفت؛ و تفاوت نتایج بین شرکت‌های مختلف (از افزایش کارامدی تا معضلات عمیق) نشون می‌ده که صرف خریداری یا فعال‌سازی ابزار یا سرویس هوش‌مصنوعی تضمینی برای موفقیت نیست.

- نابودی دانش تیمی: باز هم مطالعات نشون می‌دن در ۱۶.۸٪ از چت‌های ChatGPT، کد تولید شده به صورت دقیق (با تغییرات جزئی) توی پروژه‌های GitHub استفاده شدن. مشکل اینجاست: وقتی توسعه‌دهنده‌ها کد AI رو بدون درک عمیق copy می‌کنن، expertise model توی تیم توسعه آسیب می‌بینه و Truck Factor (تعداد اعضای تیم که از دست دادنشون پروژه را می‌تونه نابود کنه، گاهی هم bus factor گفته می‌شه) بدتر می‌شه.

- معضل Context Collapse در آینده: اگه کدهایی که مدل‌های آینده از روی اون‌ها train می‌شن، پیچیده‌تر و غیرقابل نگهداری‌تر بشه، خطر واقعی اینه که مدل‌های جدیدتر این روندها رو به صورت نمایی تقویت و تشدید می‌کنن و کد بدتری تولید خواهند کرد؛ دلیلش هم اینه که از روی کدهای شلوغ و بی‌کیفیتی آموزش دیده‌اند.

- مشارکت‌کننده دوره‌گرد: کدهای تولید شده توسط هوش مصنوعی شبیه کار یک پیمانکار کوتاه‌مدته: از نظر عملکردی در انزوا، صحیح، اما منفک از قراردادها و معماری سیستم کلی! این منجر به تکه‌تکه شدن (Fragmentation) سبک و منطق کد می‌شه.

- پارادوکس بهره‌وری مهندسی: ترکیب "خوب" (سرعت) و "زشت" (ریزش/کیفیت) منجر به شکل‌گیری "پارادوکس بهره‌وری مهندسی" شده. سازمان‌ها شاهد افزایش چشمگیر خروجی (پول‌ریکوئست‌ها، ویژگی‌ها) هستن، اما همزمان کاهش پایداری و افزایش هزینه‌های نگهداری رو تجربه می‌کنن. گزارش سال ۲۰۲۵ DORA از گوگل نشون داد که افزایش ۹۰ درصدی در پذیرش هوش مصنوعی با افزایش ۹ درصدی نرخ باگ و افزایش ۹۱ درصدی زمان بازبینی کد همبستگی داره (بدتر از گزارش DORA در سال ۲۰۲۴ که پیش‌تر در بخش افزایش باگ و کاهش پایداری قسمت اول اشاره کردم). زمان صرفه‌جویی شده در تایپ کردن کد، عملاً به مرحله بازبینی و دیباگ منتقل شده؛ با این تفاوت که هزینه این مرحله بالاتره، چون خوندن کد تولید شده سخت‌تر از نوشتنشه.

- انباشت بدهی فنی: انباشت کدهای ضعیف ساختاری، که با پیچیدگی بالا (Cyclomatic Complexity) و تکرار زیاد مشخص می‌شن؛ بدهی‌ای ایجاد می‌کنه که باید با بهره پرداخت بشه. Forrester پیش‌بینی می‌کنه که سال ۲۰۲۶، ۷۵٪ از شرکت‌ها به دلیل تولید کد کنترل‌نشد‌ه‌ی هوش مصنوعی، با بدهی فنی "متوسط تا شدید" مواجه خواهند شد.

💬 قسمت بعدی از بخش دارک ماجرا خارج خواهیم شد و به بخش «خوب 👌» خواهم پرداخت ولی نظر و تجربه شما رو دوست دارم بدونم...

♻️ فیدبک، راه‌حل بهبود و توسعه مداوم...
فیدبک، یک فرهنگه، که برای ایجادش باید تلاش کرد، ممارست داشت و رهاش نکرد. باید مستندش کرد، آموزشش دارد، به عنوان ارزش و روش نهادینه‌اش کرد و از روز آنبوردینگ روش تکیه کرد؛ تا بتونه در میان/بلند مدت میوه بده.

🥕🪓 فیدبک: فراتر از هویج و چماق

خیلی از ما فیدبک رو با «نقد کردن» یا «تشویق کردن» اشتباه می‌گیریم. فکر می‌کنیم ابزاریه که الزاما مدیر از موضوع بالا نسبت به کارمند استفاده می‌کنه تا بتونه با تشویق و تنبیه یا ملقمه‌ای از هر دو وادارش کنه تا رفتار و کارآمدی دلخواهش رو دنبال کنه! (رویکرد هویج و چماق).

اما واقعیت چیز دیگه‌ایه: فیدبک یک فرهنگه، نه یک سخنرانی یک‌طرفه. برای اینه که یک تیم یا سازمان یا حتی ارتباط انسانی، زنده بمونه و رشد کنه، بازخورد باید در تمام رگ‌های سازمان جریان داشته باشه؛ از مدیر به همکار، از همکار به مدیر، و از همکار به همکار. فیدبک سازنده، اکسیژنِ فضای کاری سالمه.

چرا فیدبک‌های "حسی" کار نمی‌کنند؟
همه ما جمله‌هایی مثل «کارت عالی بود» یا «باید بیشتر دقت کنی» را شنیدیم. این‌ها فیدبک نیستن؛ این‌ها نظرات گُنگ هستند! فیدبک مبهم نه تنها باعث بهبود یا اصلاح رفتارها نمی‌شه، بلکه می‌تونه باعث سوءتفاهم و گارد گرفتن طرف مقابل بشه. برای حل این مشکل، ما به مدل‌های ساختاریافته نیاز داریم تا بتونیم قبل از ارائه بازخورد محتوا رو بریزیم توی یک قالب استاندارد، ببینیم آیا قالب رو پر می‌کنه؟ یا باید ازش کم و زیاد کنیم!

۱. مدل SBI: شفافیت به جای قضاوت
مدل SBI (مخفف Situation-Behavior-Impact) یکی از بهترین روش‌ها برای حذف قضاوت شخصی و تمرکز روی واقعیت‌هاست.

- موقعیت (Situation): دقیقاً بگید این عمل کِی و کجا رخ داده. (عمل یا اتفاق می‌تونه مثبت یا منفی باشه)
- رفتار (Behavior): دقیقاً چه رفتاری دیدید؟ (بدون استفاده از صفاتی مثل تنبل، بی‌دقت، عالی، دقیق و...).
- اثر (Impact): آن رفتار چه تاثیری روی شما، تیم یا پروژه گذاشته.

❌ مثال غلط: «تو توی جلسات خیلی بی‌نظمی.»
✅ مثال با SBI: «امروز صبح در جلسه بررسی اسپرینت (موقعیت)، وقتی وسط صحبت جعفر پریدی و صدات رو بالا بردی (رفتار)، باعث شد بقیه اعضای تیم ساکت بشن و دیگه ایده‌هاشون رو مطرح نکنن (اثر).»

۲. مدل EEC: چرخه یادگیری و اصلاح
مدل EEC (مخفف Example-Effect-Change/Continue) هم برای بازخورد اصلاحی (منفی) و هم برای بازخورد تقویتی (مثبت) خوبه.

- مثال (Example): یک مثال مشخص از رفتار رو بیان کنید.
- اثر (Effect): نتیجه رو شفاف بیان کنین.
- تغییر/ادامه (Change/Continue): اگر بازخورد منفیه، چه تغییری انتظار دارید؟ اگر مثبته، به ادامه دادنش تشویق کنید.

مثال برای ادامه (Continue): «گزارشی که دیروز فرستادی (مثال)، خیلی داده‌های دقیقی داشت و باعث شد مشتری قانع بشه (اثر). لطفاً همین ساختار رو برای گزارش‌های بعدی هم حفظ کن (ادامه).»

⚠️خطر » سوگیری‌های ناخودآگاه در کمین ما هستن! (Unconscious Biases)
یه فیدبک رو می‌شه ریخت توی قالب SBI یا EEC یا هر مدل دیگه‌ای. ولی این کافیه؟ نه. باید حواسمون باشه که فیدبک دادن می‌تونه به سوگیری‌های ناخودآکاه ما یا Unconscious Biases آلوده بشه و از مسیر سازنده بودن خارج! ۳ دشمن نامرئی فیدبک سازنده:

۱. سوگیری شباهت (Similarity Bias)
ما ناخودآگاه با کسانی که شبیه به ما فکر می‌کنن، لباس می‌پوشن یا پیش‌زمینه مشابهی دارن، راحت‌تریم. توی فیدبک، این باعث می‌شه با افراد «شبیه به خودمون» مهربون‌تر باشیم و خطاهاشون را نادیده بگیریم، در حالی که نسبت به بقیه سخت‌گیرتریم. این سمِ تنوع و رشد تیمه.

۲. سوگیری تأییدی (Confirmation Bias)
اگر من باور داشته باشم که «فلانی کارمند بی‌دقتیه»، مغز من فقط لحظاتی رو ثبت می‌کنه که اون اشتباه کرده و تمام کارهای دقیقش رو نادیده می‌گیره تا باور قبلی‌ام تأیید بشه! فیدبک بر اساس این سوگیری، فقط تکرار مکرراتِ ذهن فیدبک‌دهنده است؛ نه واقعیتِ عملکرد فیدبک‌گیرنده.

۳. سوگیریِ رویدادهای اخیر (Recency Bias)
این آفتِ ارزیابی‌های پایان سال (Year-end reviews) است. ممکنه همکار شما ۱۰ ماه عالی کار کرده باشه، اما چون دو هفته پیش یک اشتباه کرده، تمام ارزیابی سالانه‌اش تحت‌الشعاع اون خطای اخیر قرار می‌گیره. یا برعکس؛ یک سال کم‌کاری کرده ولی با یک ماه تلاشِ دقیقه نودی، همه‌چیز پوشیده می‌شه!

❓ پادزهر سوگیری چیه؟ ساختار به جای احساس
یکی از دلایل پیدایش مدل‌هایی مثل SBI یا EEC همینه، که جلو سوگیری‌ها گرفته بشه. باید با داده صحبت کنیم، پس باید داده‌ها رو ثبت کنیم و مغزمون رو مجبور کنیم از قضاوت حسی فاصله بگیره و به فکت‌ها نگاه کنه.

💬 میشه ساعت‌ها در مورد شیوه‌های بیان فیدبک، اشتباهات رایج، عکس‌العمل در قبال سوءبرداشت‌ها و شرایط پیچیده‌ی تقابلی صحبت کرد. خوشحال می‌شم تجربیات و نظراتتون رو بشنوم 😊