اگر نسخه دیجیتال این داستان را میخوانید، به تازگی از بخش کوچکی از نرمافزاری به نام cURL استفاده کردهاید. اگر آن را به صورت چاپی میخوانید، اما امروز از تلفن هوشمند، لپتاپ یا تبلت استفاده کردهاید، باز هم از cURL استفاده کردهاید. اگر به هر دلیلی مرورگر یا اپلیکیشنی را لمس نکردهاید، اما از یک خودروی مدرن، چاپگر، تلویزیون یا دستگاه بازی استفاده کردهاید، باز هم از cURL استفاده کردهاید. شما و اکثر انسانهای روی زمین هر روز چندین بار از آن استفاده میکنید، اگرچه تنها بخش کوچکی از کاربران آن از وجودش آگاه هستند.
در فضای آنلاین، شما دائماً در حال درخواست بستههای اطلاعاتی از ماشینهای دیگر هستید. اما این درخواستها باید از پروتکلهای خاصی در مورد مقصد، مسیریابی، قالب و مجوز پیروی کنند؛ cURL این جزئیات را مدیریت میکند. این نرمافزار که اولین بار در سال ۱۹۹۶ منتشر شد، اکنون بخشی از زیرساخت نامرئی اینترنت است، کوچک اما فراگیر، و جزئی از هزاران خط کدی است که دائماً در پسزمینه زندگی دیجیتال ما اجرا میشوند. نگهدارندگان آن تخمین میزنند که مؤلفه آن، libcurl، بیش از ۲۰ میلیارد بار نصب شده است. حتی تحسینکنندگان آن نیز به ندرت هنگام استفاده از آن آگاه هستند، درست همانطور که همیشه نمیتوان به پمپهایی که آب را به جریان میاندازند هنگام باز کردن شیر آب فکر کرد.
این همچنین یک پروژه نرمافزاری متنباز است. کد منبع cURL به صورت رایگان در پلتفرم نرمافزاری گیتهاب (GitHub) برای همه قابل مشاهده است. مجوز آزاد آن تضمین میکند که هر کسی «اجازه استفاده، کپی، تغییر و توزیع این نرمافزار را برای هر منظوری، با یا بدون هزینه» دارد. این پروژه همچنین مشارکتهای جامعه گستردهتری از توسعهدهندگان را میپذیرد و به آنها وابسته است – وبسایت cURL بیش از ۳۰۰۰ مشارکتکننده را فهرست کرده است. پرکارترین و ثابتقدمترین مشارکتکننده آن، خالقش، دانیل استنبرگ (Daniel Stenberg)، یک توسعهدهنده نرمافزار سوئدی است که پروژه را به صورت تماموقت اداره میکند.
استنبرگ به من گفت: «ما در واقع متعلق به هیچ چیز، متعلق به هیچ شرکتی نیستیم. ما فقط یک نام در اینترنت هستیم و گروهی از افراد که سعی میکنند این محصول را تا حد امکان خوب بسازند.»
استنبرگ یک نگهدارنده است، یک ناظر بر نرمافزاری که نیاز به مراقبت و توجه مداوم دارد. برای اینکه کد چیزی بیش از یک توده متن غیرقابل فهم باشد، باید در یک محیط – دستگاه، مرورگر، برنامه – اجرا شود. با تغییر این محیطها، کد نیز باید تغییر کند. کسی، چه خالق آن و چه دیگرانی که برای کمک استخدام شدهاند، یا برای نگهداری آن کار میکند یا شاهد مرگ تدریجی آن است و کاربرانش را با عواقب آن تنها میگذارد.
این امر بر نگهدارندگان فشار وارد میکند، که اغلب به عنوان نقاط شکست واحد برای پروژههای خود عمل میکنند. استنبرگ گفت: «من برای مدت طولانی تنها فرد تماموقت در cURL بودهام. بقیه همه داوطلب بودهاند و تمایل دارند که با گذشت زمان بیایند و بروند. من دقیقاً نمیدانم چه کسی فردا حضور خواهد داشت و نمیتوانم به آن وابسته باشم.»
اخیراً، استنبرگ و افراد مسئول نگهداری اینترنت با مشکل جدیدی مواجه شدهاند. در دسترس بودن ابزارهای کدنویسی هوش مصنوعی، که در پاسخ به دستورات زبان طبیعی کد تولید میکنند، منجر به هجوم عظیمی از مشارکتهای کد پیشنهادی شده است. بیشتر آنها چندان خوب نیستند. برخی مفید به نظر میرسند، اما زمینه مهمی را از دست میدهند یا به درستی کار نمیکنند. برخی خوب کار میکنند، اما چندان مفید نیستند و همچنان زمان زیادی برای بررسی نیاز دارند. این مشارکتها از سوی افرادی میآید که نیت خوبی دارند و از سوی افرادی که به دنبال اعتبار مشارکت در یک قطعه نرمافزاری بنیادی هستند. آنها از توسعهدهندگان حرفهای و همچنین از به اصطلاح «کدنویسان حسی» (vibe coders) میآیند که منحصراً با ابزارهای هوش مصنوعی کد مینویسند، گاهی اوقات بدون توانایی درک خروجی.
این هجوم، زیرساختها را مسدود میکند. برای سالها، cURL یک برنامه «پاداش اشکال» (bug bounty) را اجرا میکرد، سیستمی که به توسعهدهندگان خارجی که نقصهای امنیتی مشروع را شناسایی میکردند، پول پرداخت میکرد. (این یک موضوع بسیار فنی است؛ بزرگترین پاداش پرداخت شده ۴۶۶۰ دلار برای نقصی بود که باعث میشد «cURL یک بافر مبتنی بر پشته را در دستدهی پروکسی SOCKS5 سرریز کند».) اما در ژانویه، استنبرگ اعلام کرد که به دلیل «انفجار گزارشهای بیکیفیت هوش مصنوعی»، cURL این برنامه را متوقف میکند. او توضیح داد که «ارسالهای بیکیفیت بیپایان، فشار روانی جدی برای مدیریت ایجاد میکنند و گاهی اوقات زمان زیادی برای رد کردن آنها لازم است. زمان و انرژیای که کاملاً هدر میرود و همچنین اراده ما برای زندگی را از بین میبرد.»
تجربه استنبرگ قابل توجه است، اما منحصر به فرد نیست. در سراسر اکوسیستم متنباز، ابزارهای کد هوش مصنوعی مجموعهای از هنجارها را مختل میکنند که به توسعهدهندگان برای ساخت یا مشارکت در نرمافزاری که به نفع همه است، پاداش میداد. در گذشته، مشارکت در پروژههای متنباز، نقاط قوت در رزومه یک توسعهدهنده بود. اما اگر مشارکت شما توسط کلود (Claude) یا کدکس (Codex) نوشته شده باشد، آیا شما یک مشارکتکننده هستید؟ و اگر «جامعه کاربران» پروژه شما به طور فزایندهای از رباتها تشکیل شده باشد، آیا همچنان برای ساخت یا نگهداری آن انگیزه خواهید داشت؟ و اگر نه، پس وقتی شیر آب را باز میکنیم چه اتفاقی میافتد؟
استنبرگ گفت: «نرمافزار متنباز پیششرط وجود بیشتر نرمافزارهاست. برای اینکه امروز بتوانیم به روشی که کار میکنیم، به قطعات مشترک زیادی نیاز دارید که بتوانید آنها را به هم بچسبانید تا نرمافزار خود را بسازید. این سوال نیست که خوب است یا بد. این چیزی است که اکنون داریم.»
به طور کلی این کار به خوبی انجام میشود. آنقدر خوب که هر قطعه نرمافزاری که با آن سروکار دارید، چه متنباز باشد و چه اختصاصی، بر روی شبکهای از بستههای متنباز قرار دارد. به عنوان مثال، برنامه فایننشال تایمز (Financial Times) بر روی بیش از ۲۰۰۰ بسته دیگر قرار دارد. یکی از آنها ابزاری به نام axios (واکشی دادهها) است که به ابزاری به نام babel (ترجمه کد) وابسته است، که به Node (شکلی از زبان جاوا اسکریپت) وابسته است، که به زبان متنباز پایتون (Python) وابسته است. اما یک خطر وجود دارد. وقتی بر روی کد شخص دیگری میسازید، به یک وابستگی تبدیل میشود و وابستگیها میتوانند کهنه شوند.
در دوران شغلیام در کدنویسی، بیشتر به عنوان یک ساندویچساز در اکوسیستم «نرمافزار به عنوان ساندویچ» عمل کردهام. من برنامهها یا وبسایتهای کاربرمحور را با استفاده از مواد اولیه ارائه شده توسط زنجیره تامین متنباز میسازم. گاهی اوقات با مشتریان عصبانی مواجه میشوم که ساندویچها دیگر نمیرسند، یا گاهی اوقات از نحوه استفاده کسی از دستور پخت من ناراحت میشوم.
اما مشارکتها و مشکلات من در مقایسه با نانوایانی که نان من را میپزند، ناچیز است، چه رسد به کسانی که نان را اختراع کردند. وقتی مشکلی در محصول آنها پیش میآید، این ساندویچسازان هستند که باید پاسخگو باشند. بسیاری از ساندویچسازان ترجیح میدهند به نحوه پخت نان فکر نکنند؛ آنها فقط میخواهند نان حاضر شود، مبادا با جمعیتی از مشتریان گرسنه مواجه شوند که حتی کمتر به پخت نان اهمیت میدهند.
فرض کنید، به عنوان مثال، یک قانون محلی جدید نان پخته شده با انواع خاصی از گندم را ممنوع کند – این میتواند باعث درگیری در زنجیره تامین شود. ساندویچساز ممکن است به یک نانوای جدید نیاز داشته باشد، یا نانوا ممکن است به یک آسیاب جدید نیاز داشته باشد، یا آسیاب ممکن است به یک کشاورز جدید نیاز داشته باشد.
این «مشکلات وابستگی» به دلیل قوانین جدید، یا دستورالعملهای جدید، یا به دلیل بازنشستگی یک خمیرساز خسته، دائماً رخ میدهند. شاید ماشینهای آنها برای مدتی کار کنند و به مشتریانشان زمان برای سازگاری بدهند، اما دیر یا زود چیزی خراب میشود و کسی برای تعمیر آن نیست. وقتی این اتفاق میافتد، ساندویچسازان، که بسیاری از آنها فقط به طور مبهم از منبع نان خود آگاه بودند، با مشکلی برای حل مواجه خواهند شد، زیرا با مشتریان ناامیدی سروکار دارند که فقط میخواهند غذا بخورند.
اگر همه اینها کاملاً کابوسوار به نظر میرسد، میتوانید درک کنید که چرا نگهداری پروژهای مانند cURL – شاید یک آسیاب آرد در این تمثیل – برای استنبرگ یک شغل تماموقت است. به همین دلیل است که او به شبکهای از داوطلبان ماهر، کمکهای مالی و پاداشهای اشکالزدایی برای اطمینان از عملکرد روان آن تکیه کرده است.
حالا ابزارهای هوش مصنوعی را به آشپزخانه بیاورید. سازندگان «ساندویچساز خودکار» (sandwich-a-tron) قول میدهند که هر کسی میتواند ساندویچ درست کند. و این حقیقت دارد: بسیاری از مردم اکنون میتوانند ساندویچهای «حسی» (vibe) خوشمزه را بدون مراجعه به اغذیهفروشی درست کنند. برخی از صاحبان اغذیهفروشی اعتراض میکنند که ساندویچهای ماشینی کیفیت یکسانی ندارند، اگرچه بسیاری از آنها برای تهیه ساندویچهای ساده، ساندویچساز خودکار خود را میخرند. تقریباً همه موافقند که ساندویچساز خودکار در دستورالعملهای رایج عالی عمل میکند و این امر به صاحبان اغذیهفروشی زمان میدهد تا روی دستورالعملهای هنریتر خود تمرکز کنند.
اما ساندویچساز خودکار کارهای عجیبی با زنجیره تامین ظریف انجام میدهد. نان را از نانواییهایی سفارش میدهد که سالهاست تعطیل شدهاند، یا اصلاً وجود نداشتهاند. ترجیح شدیدی برای گوجهفرنگی از یک کشاورز کوچک در فرانسه نشان میدهد. کشاورز همیشه به تلفن مشتریانی که درخواستهای معقولی داشتند یا پیشنهاداتی در مورد تجهیزات برداشت یا جعبههای حمل و نقل ارائه میکردند، پاسخ میداد. اما ناگهان هر روز دهها درخواست و شکایت جدید دریافت میکند که انواع آفتکشها و کودهایی را پیشنهاد میکنند که در فرانسه قانونی نیستند. این رشد ناگهانی مشتریان، کشاورز گوجهفرنگی را تحت فشار قرار میدهد، به خصوص که جبران خسارت او به شکل کمکهای مالی یا حسن نیت از جامعهاش است، چیزی که این مشتریان رباتیک ارائه نمیدهند.
همه در جامعه متنباز گیتهاب (GitHub) را دوست ندارند. نسلهای قبلی جنبش «نرمافزار آزاد» از این ایده که توسعه متنباز با پلتفرمی که سودآور است و خودش متنباز نیست، در هم آمیخته شود، ناراحت بودند؛ مبارزهای که برخی از حامیان امروز نیز آن را ادامه میدهند. یکی از این سازمانها، «بنیاد آزادی نرمافزار» (Software Freedom Conservancy) است که به مالکیت شرکتی گیتهاب – که در سال ۲۰۱۸ توسط مایکروسافت خریداری شد – و استفاده آن از کدهای میزبانی شده در سایت برای آموزش محصولات هوش مصنوعی، گاهی با نادیده گرفتن شرایط مجوزهای پیوست شده به پروژهها، اعتراض میکند.
کارن سندلر (Karen Sandler)، مدیر اجرایی این بنیاد، به من گفت: «اینترنت و هر چیز دیگری اساساً بر روی نرمافزاری ساخته شده است که با یک پایه ایدئولوژیک ایجاد شده بود... و سپس تمام آن کار به صورت آنلاین منتشر شد و برای شرکتها بسیار مفید شد.» او افزود: «کدها به عنوان دادههای آموزشی به مدلهای زبان بزرگ (LLMs) بلعیده میشوند و سپس شما با مجموعهای از کارهای ایدئولوژیک مواجه میشوید که به عنوان غیرحقتکثیر (non-copyrighted) برچسبگذاری شدهاند، که احتمالاً در نرمافزارهای اختصاصی گنجانده میشوند.»
با وجود این ملاحظات، گیتهاب امروز تقریباً به همان اندازه که محصولات ادوبی (Adobe) برای کارهای طراحی ضروری هستند، برای توسعه نرمافزار حیاتی است. جایگزینهایی وجود دارند، اما میزبانی یک پروژه در جای دیگر معمولاً به معنای یک موضع ایدئولوژیک است. به طور کلی، برای نسل فعلی توسعهدهندگان، گیتهاب به سادگی مکانی است که توسعه نرمافزار در آن اتفاق میافتد.
اوایل سال جاری، گروهی از محققان به رهبری میکلوش کورن (Miklós Koren)، اقتصاددان دانشگاه اروپای مرکزی در وین، مقالهای با عنوان «کدنویسی حسی، متنباز را از بین میبرد» منتشر کردند. آنها استدلال میکنند که در دنیایی که مصرفکنندگان بستههای نرمافزاری به طور فزایندهای عاملان کدنویسی هوش مصنوعی هستند، انگیزههایی که مدل مشارکتی توسعه متنباز را به حرکت در میآورند، فرو میریزند.
کورن به من گفت: «ما با مدلهایی شروع کردیم که در تجارت بینالملل کاملاً استاندارد هستند، جایی که شرکتها محصولات با کیفیتهای مختلف تولید میکنند و در بازار رقابت میکنند... و متوجه شدیم که این تمثیل بدی برای متنباز نیست. شاید پول زیادی درگیر نباشد، اما هر توسعهدهندهای میخواهد بسته او محبوب باشد.»
من این را خوب درک میکنم. قبل از کار در اتاقهای خبر، مجموعهای از پروژههای متنباز شخصی را توسعه داده و منتشر کردم. یکی از آنها به طور خاص، که مسیرهای پاییندستی رودخانهها را تجسم میکرد، موفقیتی گیجکننده بود. این پروژه هنوز هم بیشتر از تمام داستانهایی که در فایننشال تایمز کار کردهام، دیده میشود و با توجه به تعداد بازدید، ممکن است موفقترین چیزی باشد که تا به حال خلق کردهام. من آن را تنها چند ماه قبل از مصاحبه برای شغلم منتشر کردم و در حالی که این ابزار را به صورت رایگان توسعه دادم، میتوانم یک خط مستقیم بین موفقیت آن و استخدام امروزم ترسیم کنم.
اما کورن دریافت که این دلایل اجتماعی-اقتصادی برای مشارکت توسعهدهندگان در پروژههای متنباز، زمانی که کاربران انسانی با رباتها جایگزین میشوند، کاهش مییابد؛ رباتهایی که نرمافزار را بدون ارائه تعاملات مثبت نصب میکنند. در مدل محققان، این موضوع بر این واقعیت که ابزارهای هوش مصنوعی ممکن است به توسعهدهندگان منفرد کمک کنند تا کد را سریعتر بنویسند، غلبه میکند. با گذشت زمان، رباتها اکوسیستم متنباز را فرسایش میدهند.
کورن گفت: «سوال برای توسعهدهنده این است که اگر میخواهم در میان انسانها محبوب باشم، چرا باید چیزی بنویسم که فقط توسط ماشینها استفاده میشود؟»
در آزمایشهایی با شش مدل کدنویسی، محققان دریافتند که بستههای نرمافزاری متنباز که به طور مکرر توسط مدلها توصیه میشدند، افزایش زیادی در تعداد دانلودها داشتند – اما این فعالیت به تعاملی که معمولاً نگهدارندگان را پایدار نگه میدارد، منجر نشد. این مقاله نتیجهگیری میکند که «تحت مدل تجاری سنتی، که درآمد توسعهدهنده کاملاً به تعامل مستقیم کاربر بستگی دارد، اکوسیستم متنباز نمیتواند از پذیرش گسترده هوش مصنوعی جان سالم به در ببرد.»
پایگاه کاربری پر از رباتها یکی از مشکلاتی است که عاملان کدنویسی ایجاد کردهاند. مشکل دیگر این است که توسعه جامعهمحور خود دشوارتر شده است، زیرا نگهدارندگان باید در میان باتلاقی از مشارکتهای تولید شده توسط هوش مصنوعی در پروژههای خود حرکت کنند.
نگهدارندگانی که با آنها صحبت کردم موافق بودند که مشارکتهای هوش مصنوعی اغلب بیفایده یا بیربط هستند. مشارکتکنندگان بالقوه که از ابزارهای هوش مصنوعی استفاده میکنند، بیشتر احتمال دارد «مشارکتهای استخراجی» (extractive contributions) انجام دهند، جایی که زمان و انرژی مورد نیاز برای نگهدارندگان برای بررسی آنها، ارزششان را تحتالشعاع قرار میدهد. عاملان کدنویسی هوش مصنوعی به طور چشمگیری هزینه ایجاد یک مشارکت استخراجی را کاهش دادهاند، اما بررسی آن همچنان به لمس انسانی نیاز دارد. با توجه به این خواستههای فزاینده بر زمان آنها، بسیاری از نگهدارندگان متنباز با این موضوع دست و پنجه نرم کردهاند که چگونه و آیا باید مشارکتهای خارجی را در عصر هوش مصنوعی مدیریت کنند.
استیو رویز (Steve Ruiz) تصمیم گرفته است که آنها را به طور کامل حذف کند. او خالق tldraw، یک ابزار محبوب وایتبرد دیجیتال است. او در ژانویه این تصمیم را در مواجهه با انبوهی از کدهای بیکیفیت تولید شده توسط هوش مصنوعی برای بررسی، اعلام کرد. رویز در یک پست وبلاگی، یک سوال فلسفی در مورد آینده توسعه مشارکتی مطرح کرد: «اگر نوشتن کد بخش آسان کار است، چرا باید بخواهم شخص دیگری آن را بنویسد؟»
اگر همه به هر حال از ابزارهای یکسانی برای نوشتن کد استفاده میکنند، ارزش همکاری، به خصوص با کسانی که با پروژه شما آشنا نیستند، چیست؟ در گذشته، یک مشارکتکننده جدید به تدریج دانش خود را در مورد پروژه شما افزایش میداد و امیدواریم روزی به یک نگهدارنده قابل اعتماد تبدیل شود. اما اگر آنها به سادگی ابزاری را به سمت آن نشانه بگیرند، دلیلی وجود ندارد که باور کنیم پذیرش مشارکت آنها منجر به رشد دانش یا سرمایهگذاری آنها در پروژه شما خواهد شد.
و چرا سایر توسعهدهندگان، نگهدارندگان و کارفرمایان بالقوه باید برای این مشارکتها ارزشی قائل شوند؟ اگر مشارکتها ارز جامعه متنباز باشند، در حال کاهش ارزش تا حد بیارزشی هستند. رویز گفت: «قرارداد اجتماعی و رویههای اجتماعی پیرامون یک مشارکت متنباز به سادگی از بین رفته است.»
بسیاری از نگهدارندگان به من گفتند که ابزارهای کدنویسی را برای برخی از اجزای نگهداری، مانند تجزیه و تحلیل پایگاههای کد بزرگ، مفید میدانند. اما اینها ابزارهایی هستند که همکاری با ماشین را تسهیل میکنند، نه همکاری بین انسانها. تا آنجا که ساندویچساز خودکار میتواند ساندویچها را به سبک اغذیهفروشی من بازسازی کند، بهتر است که من آن را اداره کنم. اگر فرد جدیدی را برای فشار دادن دکمههای دستگاه بیاورم، او هرگز واقعاً یاد نخواهد گرفت که ساندویچهای من را درست کند. و سپس چه کسی قرار است اغذیهفروشی را اداره کند؟
گیدو ون روسوم (Guido van Rossum)، خالق زبان برنامهنویسی پایتون، قبلاً اغذیهفروشی را ترک کرده بود. پس از انتشار این زبان در اوایل دهه ۱۹۹۰، او عنوان «دیکتاتور خیرخواه مادامالعمر» (benevolent dictator for life) را به خود گرفت، لقبی طنزآمیز که او را به عنوان تصمیمگیرنده نهایی پروژه معرفی میکرد، سیستمی از حکمرانی که بسیاری از پروژههای متنباز از آن زمان به بعد پذیرفتهاند. اما دو دهه به عنوان BDFL شامل اتخاذ تصمیمات گاه بحثبرانگیز بود که استرس ناشی از آن او را فرسوده کرد. پیامدهای یک ویژگی نحوی جدید، «عملگر گراز دریایی» (walrus operator) بدنام، آخرین ضربهای بود که او را در سال ۲۰۱۸ به کنارهگیری از این سمت سوق داد.
ون روسوم به من گفت: «نگهدارندگان تحت فشار زیادی هستند. هر پروژهای در نهایت نوعی جلسه اضطراری برگزار میکند که در آن تصمیماتی در مورد نحوه برخورد با جریان بیپایان کدهای بیکیفیت هوش مصنوعی گرفته میشود.» او خاطرنشان کرد که علاوه بر حجم آنها، مدلهای زبان بزرگ تمایل دارند که بسیاری از قسمتهای یک فایل را که مستقیماً به مشکلی که سعی در حل آن دارند مربوط نیست، لمس کنند، که هر بررسی را خستهکنندهتر میکند.
ون روسوم فکر میکند که بسیاری از افرادی که کدهای بیکیفیت با تلاش کم ارسال میکنند، صرفاً با ایده نوشتن «مشارکتکننده پایتون» در رزومه خود انگیزه میگیرند. (بر اساس برخی معیارها، پایتون محبوبترین زبان در جهان است، از جمله در میان مدلهای کدنویسی.) با این حال، او خاطرنشان کرد که برای پروژههای برجستهای مانند پروژه او، «همیشه انگیزه زیادی، حتی قبل از مدلهای زبان بزرگ (LLMs)، برای ارائه مشارکتهای گذرا که ارزش بالایی نداشتند، وجود داشته است. تعداد افرادی که فقط یک غلطگیر املایی را روی مستندات اجرا کردند و خروجی را به یک درخواست ادغام (pull request) تبدیل کردند نیز کاملاً شرمآور است.»
از بسیاری جهات، مشارکتهای کاملاً خودکار تولید شده توسط هوش مصنوعی تفاوتی با این مشارکتهای غلطگیر املایی ندارند: میانبرهایی برای تولید تغییرات کمارزش که به دنبال بهرهمندی از پاداشهای مشارکت در یک پروژه جمعی بدون بهبود معنادار آن هستند.
جاش کومو (Josh Comeau) یک توسعهدهنده و مربی مستقر در مونترال است. پس از کار در چندین نقش فناوری، از جمله مدتی در غول آموزش آنلاین خان آکادمی (Khan Academy)، او در سال ۲۰۲۰ شروع به ارائه دورههای توسعه وب خود کرد. اما زمانی که او امسال یک دوره جدید را منتشر کرد، ثبتنامها تنها یک سوم سطح راهاندازیهای قبلی بود. همکاران او در آموزش فنی نیز کاهشهای مشابهی را تجربه میکردند.
کومو به من گفت: «ساخت یک دوره حدود دو سال طول میکشد. اگر امروز کار روی دوره چهارم خود را شروع کنم، تا اواخر سال ۲۰۲۷ آماده نخواهد شد و چه کسی میداند که آیا مخاطبی وجود خواهد داشت یا خیر.» اگر سطح فعلی پایه جدید بود، «هنوز هم ارزش انجام دادن داشت، اما تشخیص اینکه آیا به یک کف جدید رسیدهاید یا نه، دشوار است.»
کومو نگران نسلی از توسعهدهندگان است که آموزش کدنویسی آنها با تعاملات با مدلهای زبان بزرگ (LLMs) جایگزین میشود، که اغلب سعی میکنند مشکلات را به طور مستقیم و محدود حل کنند، نه با ارائه زمینه گستردهتر.
او گفت: «هوش مصنوعی میداند چگونه به سوالی که شما دارید پاسخ دهد، اما شما نمیدانید چه سوالاتی را باید بپرسید که نمیپرسید.» عدم درک تصویر بزرگتر «به نظر میرسد یک کمبود جدی مهارت است که زمانی که نسل فعلی توسعهدهندگان، که قبل از وجود این ابزارها آموزش دیدند، شروع به بازنشستگی یا ترک کار کنند، به یک مشکل تبدیل خواهد شد.»
کومو کدنویسی با هوش مصنوعی را مانند رانندگی در بزرگراه با کروز کنترل میداند. خودرو به حرکت خود ادامه میدهد، اما همچنان به رانندهای پشت فرمان نیاز دارد. اینگونه او داستانهای افزایش قابل توجه بهرهوری از توسعهدهندگان باتجربه را با هزاران گزارش ناامیدکننده از توسعهدهندگان تازهکار که در تلاش برای استفاده از ابزار هوش مصنوعی برای ساخت یک قطعه نرمافزار، به دیواری برخورد میکنند که نمیتوانند از آن عبور کنند، تطبیق میدهد.
این با یکی از نتایج مقالهای در نوامبر ۲۰۲۵ همخوانی دارد که به دنبال شناسایی کدهای ارسال شده به گیتهاب (GitHub) به عنوان نوشته شده توسط انسان یا تولید شده توسط هوش مصنوعی و بررسی روندهای پذیرش هوش مصنوعی بود. محققان خاطرنشان کردند که در حالی که هوش مصنوعی گسترش توسعهدهندگان را به حوزههای جدید آسانتر کرد، «برنامهنویسان باتجربه تقریباً تمام این دستاوردهای بهرهوری و اکتشاف را به دست میآورند و شکاف مهارتی را به جای کاهش، افزایش میدهند.»
یوهانس واکس (Johannes Wachs)، یکی از نویسندگان مقاله، به من گفت: «برای یادگیری کدنویسی خوب، برای اینکه بتوانید خروجیهای یک مدل زبان بزرگ را تأیید کنید، باید چیزی در مورد کد بدانید.» او گفت که وقتی دورههای برنامهنویسی ترم اول را تدریس میکند، دانشجویانش مطالبی را یاد میگیرند که برای مدلهای زبان بزرگ بسیار آسان خواهد بود. او گفت: «به دانشجویان حسادت نمیکنم. آنها این تکلیف خانگی را دارند و یک دکمه قرمز در انتهای میز وجود دارد: 'این را فشار دهید و درد شما از بین میرود.'»
پیچیدگی بیشتر این است که بسیاری از منابع غیر هوش مصنوعی که دانشجویان و توسعهدهندگان در گذشته به آنها مراجعه میکردند، در حال ناپدید شدن هستند. همان عواملی که مخاطبان دورههای کومو را کاهش میدهند، نوشتن یک پست وبلاگ یا مشارکت در یک انجمن را نیز کمارزشتر میکنند.
شاید مهمتر از همه، استک اورفلو (Stack Overflow)، سایت پرسش و پاسخ زمانی فراگیر برای برنامهنویسان، از زمان راهاندازی چتباتهای مدرن، فعالیتش تقریباً به صفر رسیده است. این انجمن جایی بود که توسعهدهندگان وقتی در مشکلی گیر میکردند، به آن مراجعه میکردند. درست قبل از راهاندازی ChatGPT در سال ۲۰۲۲، بیش از ۱۰۰ هزار سوال ماهانه در این سایت پرسیده میشد؛ ماه گذشته، این تعداد کمتر از ۱۵۰۰ سوال بود. و نرخ پاسخ، که زمانی حدود ۸۰ درصد بود، به نصف کاهش یافته است. یک پست استک اورفلو اغلب سرشار از بحث بود و توسط کسی نوشته میشد که به همان اندازه در مشکل گیر کرده بود. حجم و تنوع پستها حیرتانگیز بود. در ۱۵ سال کدنویسی، برای من دشوار است که زمانی را به یاد بیاورم که انجمنهای آن برای مشکلی که سعی در حل آن داشتم، زمینه یا حتی راهحلی ارائه نمیکردند.
این زمینه غنی همچنین آن را به دادههای آموزشی فوقالعاده مفیدی برای مدلهای هوش مصنوعی که جایگزین آن شدهاند، تبدیل کرد. در حالی که تعداد خطوط کد در گیتهاب (GitHub) بسیار بیشتر از استک اورفلو است، مستندات کد همراه اغلب کم است. بنابراین، همانطور که انجمنهای ردیت (Reddit) تأثیر زیادی بر توصیهها یا پاسخهای روزمره ارائه شده توسط مدلهای زبان بزرگ (LLMs) داشتهاند، دو دهه پست استک اورفلو نیز ستون فقرات توصیههای برنامهنویسی مدلها را تشکیل میدهند.
مقالهای که یوهانس واکس (Johannes Wachs) در سال ۲۰۲۳ در آن مشارکت داشت، کاهش فعالیت این انجمن را تحلیل کرد و این سوال را مطرح نمود که آیا مدلها با از بین بردن دادههای آموزشی آینده خود، به دلیل عدم وجود استک اورفلو، کارایی کمتری پیدا خواهند کرد یا خیر. اکنون او معتقد است که این روش تفکر در مورد مشکل اشتباه بوده است. او گفت: «هنوز دادههای تعامل انسانی تولید میشود، اما اکنون خصوصی است. OpenAI و Anthropic چیزهای زیادی از کاربران خود یاد میگیرند.»
انجمنهای عمومی استک اورفلو از بین رفتهاند و با مکالمات خصوصی چتباتها جایگزین شدهاند. پراشانت چاندراسکار (Prashanth Chandrasekar)، مدیر عامل سایت، به من گفت: «ما باید بپذیریم که توسعه نرمافزار کاملاً تغییر کرده است، شما متوجه هستید، درست است؟» در ماه ژوئن، استک اورفلو یک سرویس پاسخدهی برای رباتهای کدنویسی را اعلام کرد. آرشیوهای انسانی آن هنوز مفید هستند، اما هر روز که ابزارها و مشکلات توسعه نرمافزار تغییر میکنند، کهنهتر میشوند. دیگر جایی نیست که بتوانید انتظار یافتن پاسخ را داشته باشید. در عوض، آن پاسخها در دادههای مکالمهای خصوصی زندگی میکنند که متعلق به شرکتهای بزرگ فناوری است.
ریچ هریس (Rich Harris) به من گفت: «تا همین اواخر، این ایده که شما عملاً به یک شرکت در سیلیکون ولی (Silicon Valley) برای امتیاز توانایی نوشتن نرمافزار اجاره پرداخت کنید، کاملاً پوچ تلقی میشد.»
هریس خالق یک چارچوب توسعه وب متنباز به نام Svelte است. او Svelte را در حالی که در نیویورک تایمز (The New York Times) کار میکرد، توسعه داد، جایی که تقریباً یک دهه به عنوان ویرایشگر گرافیک مشغول بود. Svelte رقیب مستقیم React، غول چارچوب ساخته و نگهداری شده توسط متا (Meta) است و دارای پیروان وفادار و مجموعهای فعال از مشارکتکنندگان است. این روزها، هریس پروژه را با حمایت پلتفرم ابری Vercel، که از سال ۲۰۲۱ او را استخدام کرده است، نگهداری میکند.
هریس نگران است که توسعهدهندگان نرمافزار به زودی با نوع دیگری از مشکل «وابستگی» مواجه شوند. حتی اگر «خودروهای خودران» به زودی از راه برسند، آنها متعلق به چند غول فناوری خواهند بود که برای آنها پول زیادی دریافت میکنند. ممکن است همچنان آرزو کنید که رانندگی را یاد گرفته بودید تا مجبور نباشید برای چند دقیقه رانندگی در یک جاده آرام و مستقیم، به تاکسی پول بپردازید.
هریس گفت: «یکی از زیباییهای توسعه نرمافزار این است که کاملاً بدون مجوز است. هر کسی میتواند آن را انجام دهد، و ابزارهایی که ما برای ایجاد نرمافزار استفاده میکنیم، خودشان نرمافزارهای متنباز کاملاً در دسترس هستند. اکنون، ناگهان، پرداخت ۱۰۰ یا ۲۰۰ دلار در ماه برای انجام توسعه نرمافزار کاملاً عادی شده است.»
هریس امیدوار است که در آینده، مدلهای هوش مصنوعی متنباز بتوانند با مدلهای اشتراکی پیشرفته مانند کلود (Claude) و کدکس (Codex) رقابت کنند. اما او اذعان میکند که فناوری هنوز برای اجرا بر روی ماشینهای مصرفکننده آماده نیست. او گفت: «بزرگترین خطر برای من این است که نتوانیم به این انتقال دست یابیم.»
هر توسعهدهندهای که با او صحبت کردم، از خود میپرسید که آیا عاملان کدنویسی هوش مصنوعی صرفاً لایه دیگری از انتزاع در حوزهای با سابقه طولانی در انتزاع جزئیات هستند یا خیر. توسعهدهندگان به ندرت دیگر مستقیماً زبان اسمبلی (assembly language) را لمس میکنند، کدهای سطح پایینی که درست بالای صفرها و یکها قرار دارند. زبانهایی که بر روی آن ساخته شدهاند، مانند C، بسیاری از جزئیات خستهکننده را مدیریت میکردند، و زبانهایی که بر روی C ساخته شدهاند، مانند پایتون (Python) ون روسوم، همه چیز را حتی بیشتر ساده کردند. شاید دستور دادن به یک مدل زبان بزرگ (LLM) فقط گام دیگری در این شیب انتزاع باشد.
برای من، این چیزی فراتر از آن است. کلاسهای علوم کامپیوتر یا مصاحبههای برنامهنویسی اغلب از دانشجویان میخواهند که چیزی به نام «شبهکد» (pseudocode) بنویسند، سبکی برای ثبت منطق یک برنامه بدون درگیر شدن در یک نحو خاص. وقتی یک مدل زبان بزرگ را در یک کار آشنا راهنمایی میکنم، احساس میکنم که با شبهکد آزادانه به آن دستور میدهم. اما وقتی وارد کاری میشوم که به خوبی نمیشناسم، وقتی وسوسه میشوم دکمه «قرمز» را که واکس (Wachs) توصیف کرد فشار دهم، احساس متفاوتی دارم. به جای یک برنامهنویس، به یک مدیر محصول – یا حتی یک مشتری – برای کد شخص دیگری تبدیل میشوم. ویژگیهایی مانند فرمان برقی ما را از جاده دورتر میکنند، اما ما هنوز در حال رانندگی هستیم. چه زمانی دیگر رانندگی نمیکنیم؟
من از خود پرسیدم که حامیان متنباز، که برخی از آنها حتی از ایده میزبانی کد در یک پلتفرم سودآور نیز ناراحت هستند، در مورد کدی که توسط محصولات شرکتهای بزرگ فناوری با هزینه ماهانه نوشته میشود، چه احساسی دارند. کارن سندلر (Karen Sandler)، حداقل، بیشتر از آنچه انتظار داشتم دچار تضاد بود.
او گفت: «اگر توسعهدهندگان نرمافزار آزاد اصلاً از این ابزارها استفاده نکنند، سرعت توسعه نرمافزار آزاد ممکن است کندتر از نرمافزار اختصاصی باشد و ما عقب خواهیم ماند.» در حالی که برخی در جامعه از ممنوعیت کامل کدهای تولید شده توسط هوش مصنوعی حمایت میکنند، برخی دیگر احساس میکنند که کار از کار گذشته است. سندلر گفت: «ما باید از این ابزارها استفاده کنیم، پس چگونه باید از آنها به صورت اخلاقی استفاده کنیم؟»
او ادامه داد: «چیزی وجود دارد که پتانسیل بسیار زیادی برای دموکراتیک کردن این ابزارها دارد. هدف این بود که در مورد نرمافزار خود آزادی داشته باشیم. نکته جالب در مورد این ابزارها این است که آنها این شانس را دارند که به هر کسی اجازه دهند نرمافزاری را که به آن وابسته هستند، تغییر دهد.»
این یک تناقض اصلی است. نوشتن کد آسانتر از همیشه شده است و متخصصان میتوانند سریعتر کار کنند. اما توسعه نرمافزار چیزی فراتر از نوشتن کد است و فرهنگی که نرمافزاری را که به آن وابسته هستیم ساخته است، تحت فشار ابزارهای هوش مصنوعی آموزشدیده بر خروجی آنها قرار دارد. ماهیت عمومی و جمعی نرمافزار متنباز خیالپردازانه نیست؛ بلکه یک دارایی حیاتی برای موفقیت آن است. اکنون همه چیز به سیستمی خصوصیتر و متمرکزتر اشاره دارد که در آن نرمافزار بیشتر با محصول یک شرکت فناوری ساخته میشود تا با یکدیگر.
استنبرگ از cURL میگوید: «به طور کلی، نوشتن کد برای اولین بار هرگز مشکل هیچ پروژهای نبوده است. چالش هر پروژهای، نگهداری آن در طول زمان، رفع اشکالات در طول زمان است. اگر آن را درک نکنید، باید به هوش مصنوعی تکیه کنید تا همه مشکلات را در آینده حل کند.»
او ادامه داد: «آنها در رفع مشکلات چندان خوب نیستند؛ در یافتن مشکلات بسیار بهتر عمل میکنند.»
مقالهای که در ماه مارس منتشر شد، نگرشهای اخیر توسعهدهندگان را از طیف وسیعی از بحثهای انجمنها بررسی کرد. محققان نتیجهگیری کردند: «یافتههای ما کدهای بیکیفیت هوش مصنوعی را به عنوان یک تراژدی مشترک (tragedy of the commons) قاببندی میکند، جایی که دستاوردهای بهرهوری فردی، هزینهها را به بازبینان، نگهدارندگان و جامعه گستردهتر تحمیل میکند.»
تقریباً ۶۰ سال پیش، هنرمند میرل لادرمن اوکلز (Mierle Laderman Ukeles) مقالهای با عنوان «مانیفست هنر نگهداری ۱۹۶۹!» نوشت. او استدلال کرد که کار نگهداری اغلب نادیده گرفته شده و بیارزش تلقی میشود – «یک بار اضافی؛ تمام وقت لعنتی را میگیرد» – در کنار کار آفرینش که بیشتر مورد ستایش قرار میگیرد. اوکلز، که از سال ۱۹۷۷ به عنوان هنرمند مقیم دپارتمان بهداشت شهر نیویورک خدمت کرده است، پرسید: «پس از انقلاب، چه کسی زبالههای صبح دوشنبه را جمع خواهد کرد؟» او استدلال کرد که جامعه «وضعیت بدی» به کسانی که کار نگهداری را انجام میدهند، میدهد.
این شاید در عصر «اقتصاد خالق» و صنعتگران فناوری که میسوزانند و میسازند و سریع حرکت میکنند و چیزها را خراب میکنند، بیش از هر زمان دیگری صادق باشد. ثروت و اعتبار به «خالقان» میرسد در حالی که نگهدارندگان در پسزمینه کار میکنند، زنگها را میتراشند و وجود خود را برای جامعهای که آنها را بدیهی میداند، توجیه میکنند.
به اینها نسلی از ابزارهای هوش مصنوعی مولد را اضافه کنید که به عنوان ابزارهای آفرینش طراحی و بازاریابی میشوند. این ابزارها ساخت تصاویر، نوشتن رمان، ساخت نرمافزار و آلوده کردن اینترنت با کدهای بیکیفیت را آسان کردهاند. به ندرت یک مدیرعامل فناوری ابزار هوش مصنوعی را تبلیغ کرده است که «نگهداری را فوقالعاده تقویت کند». نگهداری کاری دقیق است و به راحتی نمیتوان آن را میانبر زد.
خالقان سلاح دیگری را بر نگهدارندگان گشودهاند: رها کردن لشکری از مردم برای ساخت ساختمانها و پلهای جدید بدون هیچ فکری به معماری یا برنامهریزی شهری. سازندگان بیدقت هیولاهایی میسازند و آنها را به حال خود رها میکنند تا بپوسند. بدتر از آن، آنها در سازههای با دقت برنامهریزی شده ظاهر میشوند و بهبودهایی را در تعداد زیاد ارائه میدهند به طوری که کار نگهداری واقعاً مهم تحتالشعاع قرار میگیرد.
تخریب آسانتر از آفرینش است، و آفرینش آسانتر از نگهداری است. اغلب، ما تا زمانی که چیزی خراب نشود، از نگهداری قدردانی نمیکنیم، یا تا زمانی که نگهدارندگان کنار نروند، از آنها قدردانی نمیکنیم.
سام لرنر (Sam Learner) یک روزنامهنگار گرافیک در تیم داستانسرایی بصری فایننشال تایمز است.
اولین نفر از آخرین داستانهای ما مطلع شوید – مجله FT Weekend را در X و FT Weekend را در اینستاگرام دنبال کنید.