در دنیای توسعه نرمافزار، یک باور خطرناک و رایج وجود دارد که خروجی برابر با نتیجه است. این ایده میگوید اگر ساعتها یا خطوط کد بیشتری به مسئله اختصاص دهیم، حتماً پیروز خواهیم شد. اما اخیراً شرکت fame این باور را با دقت و ظرافت از هم پاشاند.
اوروش مشاهدهای تکاندهنده در مورد فرهنگ کاری «996» (کار کردن از 9 صبح تا 9 شب، شش روز در هفته)، که توسط غولهای فناوری چینی ترویج شده است، مطرح کرد: «به سختی میتوانم یک شرکت 996 را نام ببرم که محصولی ارزشمند تولید کرده باشد که توجه کسی را به خود جلب کند، مگر اینکه کپی یا بازسازی محصولی بهتر باشد که قبلاً در جای دیگری عرضه شده است.» این برنامه و سرعت کاری نه تنها غیرانسانی هستند، بلکه ضد بهرهوری نیز میباشند.
زورگویی، حجم را افزایش میدهد اما معمولاً تمایز و (شاید) هرگز نوآوری ایجاد نمیکند.
البته قبل از اینکه شروع به سرزنش چین برای چنین شیوههای 996 کنیم، باید خودمان را مورد بررسی قرار دهیم. این فرهنگ تحت عنوان «فشارکاری»، «تمامعیار بودن» یا «فرهنگ تلاش بیوقفه» شناخته میشود، اما ایده یکسانی است: با ساعتهای کاری زیاد افراد را فشار دهید و امیدوار باشید چیزی ناب از آن بیرون بیاید. و اکنون ما در حال سعی هستیم تا این ایده را در کد یا به طور دقیقتر، هوش مصنوعی (AI) نهادینه کنیم. برخی تصور میکنند که اگر بتوانیم هوش مصنوعی را معادل هزاران ساعت کار کنند، با سرعت خارقالعادهای کد تولید کنیم، به طور جادویی نرمافزار بهتری خواهیم ساخت.
اینطور نخواهد شد. در عوض، ما بیشتر آنچه از قبل وجود دارد تولید میکنیم: کدهای مشتق شده، متورم و به طور فزایندهای غیرقابل مدیریت.
**هزینه بالای چرخش کد (Code Churn)**
من مدتی است که این هشدار را میدهم. اخیراً در مورد اینکه چگونه اینترنت توسط محتوای کمارزش و با حجم زیاد، به دلیل تسهیل تولید آن، خفه شده است، نوشتم. همین امر برای نرمافزار ما نیز در حال وقوع است.
ما دادههایی داریم که این موضوع را تأیید میکنند. همانطور که هنگام پوشش تحلیل سال 2024 GitClear از 153 میلیون خط کد اشاره کردم: «چرخش کد»، یا خطوطی که در عرض دو هفته تغییر یا دور ریخته میشوند، در حال افزایش است. این تحقیق نشاندهنده کپی-پیست شدن بیشتر کد و بازسازی کمتر است.
به عبارت دیگر، هوش مصنوعی به ما کمک میکند تا سریعتر کد بنویسیم (تا 55 درصد سریعتر، طبق گفتههای)، اما به ما کمک نمیکند نرمافزار بهتری بسازیم. ما خطوط بیشتری از کد تولید میکنیم، درک کمتری از آن داریم و بیشتر مجبور به رفع اشکال آن هستیم. خطر واقعی هوش مصنوعی این نیست که کد مینویسد، بلکه این است که ما را تشویق میکند کدی بنویسیم که قابل مدیریت نباشد (bloated code). پایگاههای کد متورم، امنتر کردن، استدلال و در نهایت بازسازی آنها را دشوارتر میکند. کمتر بودن کد بهتر است.
این تله 996 به ماشینها منتقل شده است. ذهنیت 996 فرض میکند که محدودیت نوآوری تعداد ساعتهای کاری است. ذهنیت «بومی هوش مصنوعی» فرض میکند که محدودیت تعداد کاراکترهای تایپ شده است. هر دو اشتباه هستند. محدودیت همیشه و خواهد بود، وضوح تفکر است.
**کد یک بدهی است، نه یک دارایی**
بیایید به اصول اولیه بازگردیم. همانطور که هر مهندس ارشد میداند، توسعه نرمافزار یک مسابقه تایپ نیست. این یک فرآیند تصمیمگیری است. شغل بیشتر در مورد نوشتن کد نیست، بلکه در مورد کشف آنچه باید کدنویسی شود است.
چارسیتي مجورز، بنیانگذار و CTO شرکت Honeycomb میگوید: «یک مهندس نرمافزار ارشد تا حد زیادی به توانایی شما در درک، نگهداری، توضیح و مدیریت یک بدنه بزرگ از نرمافزار در حال اجرا با گذشت زمان و همچنین توانایی ترجمه نیازهای تجاری به پیادهسازی فنی بستگی دارد.»
چرا ابزارهای کمکی کد هوش مصنوعی باعث کاهش بهرهوری برخی توسعه دهندگان در سال 2025 میشوند؟
چه تاثیری ابزارهای کدنویسی با کمک AI بر جدول زمانی تحویل پروژه در سال 2025 میگذارند؟
چه استراتژیهایی برای همکاری انسان و هوش مصنوعی در توسعه نرمافزار در سال 2025 تشویق میشوند؟
توسعه دهندگان چگونه بیشتر وقت خود را صرف اشکال زدایی کد تولید شده توسط هوش مصنوعی در سال 2025 میکنند؟
چه مشکلات کیفیتی پیشبینی میشود که ناشی از کد تولید شده توسط هوش مصنوعی در سال 2025 باشد؟
هر خط کدی که ارسال میکنید یک بدهی است. هر خط باید امن، رفع اشکال و در نهایت بازسازی شود. هنگامی که ما از هوش مصنوعی برای زورگویی فاز «ساخت» نرمافزار استفاده میکنیم، این بدهی را حداکثر میکنیم.
ما سطوح گستردهای از پیچیدگی ایجاد میکنیم که ممکن است بلیط Jira فوری را حل کند اما ثبات پلتفرم در آینده را به خطر میاندازد.
نکته اوروش در مورد شرکتهای 996 که کپی تولید میکنند، قابل توجه است. نوآوری نیازمند «فاصله» برای فکر کردن بدون وقفه مداوم جلسات است. با یک لحظه آرامش ممکن است متوجه شوید که ویژگیای که قرار بود بسازید در واقع غیر ضروری است. اگر توسعه دهندگان شما روزهای خود را صرف بررسی سیل درخواستهای کششی تولید شده توسط هوش مصنوعی میکنند، هیچ فضایی برای تفکر ندارند. آنها معمار نیستند؛ آنها سرایدارانی هستند که بعد از رباتی که هرگز نمیخوابد، نظافت میکنند.
هیچکدام از این موارد به معنای این نیست که هوش مصنوعی برای توسعه نرمافزار بد است. برعکس کاملاً درست است. ما به طور فزایندهای شاهد خواهیم بود که «انسانهایی با هوش مصنوعی» انسانهایی را بدون هوش مصنوعی جایگزین میکنند.
این مطلب از منابع بینالمللی ترجمه و بازنویسی شده است.