تولید بیوقفه کد ضعیف توسط هوش مصنوعی که انسانها مجبور به اشکالیابی و نگهداری آن هستند، هیچ کسبوکاری را به جلو نمیبرد.
یک تصور خطرناک و رایج در توسعه نرمافزار این است که خروجی برابر با نتیجه است. این ایده میگوید اگر فقط زمان یا خطوط کد بیشتری را صرف حل مسئله کنیم، حتماً پیروز خواهیم شد. شرکت فِمی اخیراً این باور نادرست را با دقت جراحیایی از بین برده است.
اوروش (Orosz) یک مشاهده انتقادی در مورد فرهنگ کاری «996» – برنامهای که کارمندان را از ساعت 9 صبح تا 9 شب، شش روز در هفته مجبور به کار میکند و توسط شرکتهای بزرگ فناوری چینی محبوب شده است – داشت: «نام بردن از یک شرکت 996 که محصولی با ارزش تولید کرده باشد که توجه کسی را جلب کند دشوار است، مگر اینکه کپی یا بازنشر محصولی باشد که قبلاً در جای دیگری عرضه شده است.» این برنامه و سرعت کار نه تنها غیرانسانی هستند، بلکه ضد بهرهوری نیز هستند.
زورگویی (Brute force) حجم زیادی تولید میکند اما به ندرت منجر به تمایز و تقریباً هرگز منجر به نوآوری نمیشود.
اما قبل از اینکه شروع به انتقاد از چین برای چنین شیوههای 996 کنیم، باید فرهنگ کار خودمان را نیز مورد بررسی قرار دهیم؛ فرهنگهایی که با عنوان «سختکوش»، «تمامعیار» یا «فشار زیاد» شناخته میشوند، اما ایدهشان یکسان است: انسانها را با ساعات طولانی تحت فشار قرار دهید و امیدوار باشید چیزی درخشان از آن بیرون بیاید. اکنون میخواهیم این ایده را در کد – یا به طور دقیقتر، هوش مصنوعی (AI) – پیادهسازی کنیم. برخی تصور میکنند که اگر بتوانیم هوش مصنوعی را معادل هزار ساعت کار اجبار کنیم تا با سرعتی فوقالعاده کد تولید کند، بهطور جادویی نرمافزار بهتری خواهیم داشت.
اینطور نخواهد بود. فقط حجم بیشتری از آنچه قبلاً داشتهایم – کدهای مشتق شده، متورم و فزایندهً غیرقابل مدیریت – تولید خواهیم کرد.
**هزینه بالای چرخش کد (Code churn)**
من مدتی است که در مورد این موضوع هشدار میدهم. اخیراً در مورد اینکه چگونه اینترنت توسط محتوای بیارزش و با حجم زیاد خفه شده است، زیرا تولید آن بسیار آسان شده نوشتم. همین اتفاق برای نرمافزار ما نیز در حال رخ دادن است.
ما دادههایی داریم که این موضوع را تأیید میکنند. همانطور که در پوشش تحلیل 2024 GitClear از 153 میلیون خط کد اشاره کردم، «چرخش کد» – یا خطوطی که طی دو هفته تغییر یا دور ریخته میشوند – رو به افزایش است. این تحقیق نشان داد کدهای کپی-پیست شده بیشتر و بازسازی (Refactoring) کمتر وجود دارد.
به عبارت دیگر، هوش مصنوعی به ما کمک میکند تا سریعتر کد بنویسیم (تا 55 درصد سریعتر، طبق گزارشها)، اما به ما کمک نمیکند نرمافزار بهتری بسازیم. ما خطوط بیشتری از کد تولید میکنیم، درک کمتری از آن داریم و مجبور هستیم اغلب بیشتر اشکال یابی کنیم. خطر واقعی هوش مصنوعی این نیست که کد مینویسد، بلکه این است که ما را تشویق میکند کدهای [نامناسب] را بنویسیم (Bloated code). پایگاههای کد متورم امنیت ضعیفتر، دشوارتر برای درک و بسیار سختتر برای انسانها هستند. کمتر نوشتن کد بهتر است.
این تله 996 به ماشینها منتقل شده است. طرز فکر 996 فرض میکند که محدودیت نوآوری تعداد ساعاتی است که کار میشود. طرز فکر «بومی هوش مصنوعی» فرض میکند که محدودیت تعداد کاراکترهای تایپشده است. هر دو اشتباه هستند. محدودیت همیشه و همواره روشنگری بوده است.
**کد یک بدهی است، نه یک دارایی**
به اصول اولیه باز میگردیم. همانطور که هر مهندس ارشد میداند، توسعه نرمافزار یک مسابقه تایپ کردن نیست. این یک فرآیند تصمیمگیری است. هدف نوشتن کد نیست، بلکه تعیین اینکه چه کدی نوشته شود.
چریتی میجرز (Charity Majors)، بنیانگذار و CTO شرکت Honeycomb میگوید: «وظیفه یک مهندس نرمافزار ارشد ارتباط زیادی با توانایی شما در درک، نگهداری، توضیح و مدیریت یک حجم بزرگ از کد در حال اجرا در طول زمان و همچنین توانایی ترجمه نیازهای تجاری به پیادهسازی فنی دارد.»
چگونه توسعهدهندگان بیشتر وقت خود را صرف اشکالیابی کدهای تولیدشده توسط هوش مصنوعی در سال 2025 خواهند کرد؟
آیا ابزارهای کمکی کد AI میتوانند فرسودگی شغلی توسعه دهندگان را در سال 2024 کاهش دهند؟
چگونه ابزارها و دستیاران کدینگ با کمک هوش مصنوعی بر جدول زمانی تحویل پروژه تأثیر میگذارند (در سال 2025)؟
چرا برخی از دستیارهای کد AI باعث کاهش بهرهوری توسعه دهندگان میشوند (در سال 2025)؟
چه استراتژیهایی برای پرورش همکاری انسان و هوش مصنوعی در توسعه نرمافزار در سال 2025 وجود دارد؟
هر خط کدی که ارسال میکنید یک بدهی است. هر خط باید ایمن، اشکالیابی، نگهداری و در نهایت بازسازی شود. هنگامی که ما از هوش مصنوعی برای زورگویی فاز «ساخت» نرمافزار استفاده میکنیم، این بدهی را به حداکثر میرسانیم. ما سطوح وسیعی از پیچیدگی ایجاد میکنیم که ممکن است بلیط Jira (مشکل موجود) فعلی را حل کند، اما ثبات پلتفرم را در آینده تهدید میکند.
نکته اوروش در مورد شرکتهای 996 که کپی تولید میکنند آموزنده است. نوآوری به «فاصله زمانی» نیاز دارد تا بدون وقفه جلسات فکر کنید. با یک لحظه آرامش، ممکن است متوجه شوید که ویژگیای که قصد ساخت آن را دارید در واقع غیر ضروری است. اگر توسعهدهندگان شما روزهای خود را صرف بررسی درخواستهای pull تولیدشده توسط هوش مصنوعی میکنند، فاصلهای برای تفکر ندارند. آنها معمار نیستند؛ آنها نظافتچیهایی هستند که بعد از روباتی که هرگز نمیخوابد، آشفتگیها را تمیز میکنند.
این به این معنی نیست که هوش مصنوعی برای توسعه نرمافزار بد است. برعکس کاملاً درست است. AI یک ابزار موثر است، اما فقط در صورتی که ما با دقت از آن استفاده کنیم و نه به عنوان چوبی برای تکرار وعده پوچ فرهنگ 996.
**بخش انسانی پشته (Stack)**
پس چگونه از ساختن فرهنگی 996 بر روی سیلیکون جلوگیری کنیم؟ باید از AI به عنوان جایگزینی برای توسعهدهنده استفاده نکنیم و در عوض آن را ابزاری بدانیم تا آنچه که فرهنگ 996 نابود میکند، بازگردانیم: زمان.
اگر هوش مصنوعی میتواند کارهای خستهکننده – تستهای واحد، کدها (boilerplate) تکراری، بهروزرسانی مستندات – را انجام دهد، نباید بهانهای برای فشردن ویژگیهای بیشتر در اسپرینت باشد. این باید فرصتی برای کاهش سرعت و تمرکز بر بخش «انسانی» پشته باشد، مانند:
«ما واقعاً قصد انجام چه کاری داریم؟» شاید ساده به نظر برسد، اما همین نکته باعث شکست بسیاری از پروژههای نرمافزاری میشود. انتخاب مشکل مناسب یک کار با زمینه بالا و همدلی است. یک LLM (مدل زبان بزرگ) میتواند پنج راه برای ساختن ویجت (Widget) به شما پیشنهاد دهد؛ اما نمیتواند به شما بگوید که آیا ویجت، راهحل درستی برای گردش کار مشتری است یا خیر.
اگر هوش مصنوعی نوشتن کد را تقریباً رایگان میکند، باارزشترین مهارت، گفتن «نه» خواهد بود. ما باید توسعهدهندگان را نه بر اساس سرعت commitهایشان (تغییرات اعمال شده به پروژه) بلکه بر اساس سادگی طراحیهایشان تشویق کنیم. ما باید commitهای «کد منفی» را جشن بگیریم: آنهایی که پیچیدگی را کاهش میدهند، نه اینکه به آن اضافه میکنند.
این مطلب از منابع بینالمللی ترجمه و بازنویسی شده است.