تصور کنید ماه‌ها وقت صرف حل یک مشکل فنی پیچیده کنید، راهکار را بیابید و سپس تنها به دلیل صادق بودن درباره ابزاری که به شما کمک کرده، دست رد روی شما زده شود. این دقیقاً اتفاقی است که برای یکی از توسعه‌دهندگان Emacs در ۲۶ ژوئن ۲۰۲۶ رخ داد. «من از یک مدل هوش مصنوعی برای کمک به شناسایی باگ و پیش‌نویس اصلاحیه استفاده کردم.» این افشای صادقانه توسط توسعه‌دهنده منجر شد تا پروژه GNU یک وصله (Patch) با کارایی بالا را برای سیستم‌عامل macOS رد کند. نکته تلخ این است که این تصمیم نه بر اساس نقص‌های فنی کد، بلکه بر پایه یک سیاست سازمانی سخت‌گیرانه علیه کدهای تولیدشده یا اصلاح‌شده توسط هوش مصنوعی زاینده (Generative AI) — که شبیه دستیاری است که میلیاردها خط کد را خوانده و حالا پیشنهادهای سریع می‌دهد — اتخاذ شده است.
این تضاد در زمانی رخ می‌دهد که جامعه متن‌باز در تلاش است تا مرز بین کدهای «تالیف‌شده توسط انسان» و «تولیدشده توسط ماشین» را تعریف کند. در حالی که بسیاری از متخصصان اکنون از AI به عنوان یک ابزار پیشرفته برای تکمیل خودکار کد (Autocomplete) یا یک ابزار جست‌وجوی هوشمند استفاده می‌کنند، پروژه GNU برای اطمینان از خلوص حقوقی و اخلاقی مشارکت‌های خود، موضعی بسیار سخت‌گیرانه در مورد منشأ کدها اتخاذ کرده است.
شکار فنی برای بهبود عملکرد
به نقل از توضیحات توسعه‌دهنده، او چندین ماه را صرف تحلیل عملکرد Emacs به‌طور خاص در محیط macOS کرد. این تلاش‌ها به‌صورت مداوم نبود، بلکه در بازه‌ای چند ماهه شامل اتصال ابزارهای اندازه‌گیری (Instrumentation) و ایجاد بنچ‌مارک‌ها (Benchmark) صورت گرفت. در این بازه زمانی، او تلاش کرد از چندین مدل زبانی مختلف (LLM) برای جست‌وجوی مسائل خاص در کدبیس استفاده کند، هرچند اشاره کرد که نتایج این تلاش‌های اولیه معمولاً ضعیف بود. وصله‌هایی که از این تلاش‌های اولیه حاصل شد، یا تأثیر بسیار اندکی داشتند و یا ناشی از درک نادرست مدل از صورت مسئله بودند.
او در نهایت توانست سه گلوگاه اصلی و خاص در محیط macOS را شناسایی کند:
- مشکلات رندرینگ و «تلاطم حافظه» (Memory Thrashing) که بر اثر تخصیص و آزادسازی بسیار سریع حافظه رخ می‌داد.
- نبود قابلیت فشرده‌سازی حافظه (Memory Compaction) در تابع malloc سیستم‌عامل macOS، که منجر به تورم حافظه مجازی و از دست رفتن محلی بودن حافظه نهان (Cache Locality) می‌شد.
- ناکارآمدی در هسته Emacs، به‌ویژه در بخش پردازش عبارات منظم (Regexp)؛ ابزاری که به‌صورت جهانی در سراسر کدبیس استفاده می‌شود و بنابراین هرگونه بهبود در آن، تأثیری گسترده و اهرمی بر کل عملکرد سیستم دارد.
برای یافتن نقاط قابل اصلاح، توسعه‌دهنده زمان زیادی را صرف تحلیل مجدد این نواحی و ایجاد وصله‌های اولیه برای محدود کردن دامنه جست‌وجو کرد. سرانجام، از طریق اشتراک z.ai Max که توسط یکی از دوستانش در اختیارش قرار گرفت، به مدل GLM 5.2 دسترسی پیدا کرد. طبق روایت این توسعه‌دهنده در ۲۵ ژوئن ۲۰۲۶، این مدل تقریباً سه ساعت زمان صرف تحلیل بستر پروژه (Project Context) کرد و سپس چندین گزارش تحلیلی و کدهای پیش‌نویس برای بهینه‌سازی ارائه داد.
پذیرش یا رد؟
توسعه‌دهنده امیدوارکننده‌ترین نتیجه از گزارش‌های GLM 5.2 را انتخاب کرد، آن را از نظر صحت و میزان تأثیر بازبینی نمود و سپس به‌طور دستی کد را ویرایش کرد تا برای ارسال آماده شود. او سپس یک وصله ۹۲ خطی را به لیست پستی emacs-devel ارسال کرد. او برای اطمینان از شفافیت کامل، چندین اظهارنامه صریح را در پیام خود گنجاند:
- منشأ (Provenance): او تصریح کرد که باگ توسط GLM 5.2 شناسایی و پیش‌نویس وصله توسط آن تهیه شده است؛ مدلی که آن را یک مدل چینی با «وزن‌های باز» توصیف کرد.
- نظارت انسانی: نویسنده تأکید کرد که شخصاً گزارش را از نظر صحت بررسی کرده، وصله را بازبینی نموده، تغییرات لازم را اعمال کرده و در نهایت وصله را به‌طور دستی تست کرده است.
- مسئولیت حقوقی: او برای مقاصد قانونی، نویسندگی اثر را بر عهده گرفت و بیان کرد که سهم او در نهایی کردن کد بیشتر از LLM بوده و مسئولیت کامل ارسال آن را می‌پذیرد.
- دامنه اثر: او اشاره کرد که دامنه پیاده‌سازی محدود است و استدلال کرد که نمی‌توان آن را به عنوان «کدهای بی‌ارزش یا زاید» (Slop) دسته‌بندی کرد، زیرا دلیل وجودی (Raison d’être) این کد در بخش کامنت‌ها توضیح داده شده است.
با وجود این شفافیت حداکثری، وصله مذکور بر اساس سیاست GNU علیه مشارکت‌های کمک‌گرفته از LLM، رد شد (Bounced). توسعه‌دهنده استدلال می‌کند که این سیاست در واقع «جریمه برای صداقت» است. او اشاره می‌کند که می‌توانست حقیقت استفاده از LLM را پنهان کند و به راحتی کد را بگذراند، اما با راستگویی، جایگاه خود را از دست داد. او پیشنهاد می‌کند که چون کارهای کمک‌گرفته از AI در واقع به بررسی‌های دقیق‌تر و چشم‌های بیشتری نیاز دارند (نه کمتر)، این سیاست کاملاً معکوس و غیربه‌ثمر است.
بحث‌های حقوقی و اخلاقی
این برنامه‌نویس منطق پروژه GNU را از دو mặt «شفافیت» و «قانونمند بودن» به چالش کشید. او اشاره کرد که تردیدها در مورد مشارکت‌های AI معمولاً حول این محور است که آیا این مدل‌ها «به اندازه کافی باز» هستند یا «استفاده از آن‌ها قانونی است» یا خیر.
در مورد باز بودن، او استدلال کرد که چون GLM 5.2 یک مدل با وزن‌های باز است، تفاوت بین اجرای آن از طریق یک سرویس ابری (SaaS) مانند OpenRouter یا اجرای محلی روی سخت‌افزار، یک نکته فنی پوچ و بی‌معنی است. او خاطرنشان کرد که اگر ۲۵۶ گیگابایت رم و ۲۴ گیگابایت VRAM فعلی‌اش را داشت، می‌توانست مدل را کاملاً محلی اجرا کند و استدلال «سرویس ابری بسته است» را به‌طور کلی کنار بزند. او این رویکرد GNU را به ایده‌ی ممنوع کردن دسترسی به اینترنت هنگام نوشتن کد تشبیه کرد، صرفاً به این دلیل که اینترنت حاوی محتواهای غیرآزاد است.
در جبهه حقوقی، نویسنده پارانویا و نگرانی شدید GNU را با کل صنعت مقایسه کرد. او مشاهده کرد که شرکت‌های بازی‌سازی بسیار حساس‌تر و پارانوئیدتر نسبت به مالکیت معنول (IP) هستند، اما با این حال استفاده از LLM در آنجا مشهود است و ChatGPT میلیاردها کاربر فعال دارد. او به برداشت خود از موضع دفتر کپی‌رایت ایالات متحده اشاره کرد: آثاری که توسط طبیعت، حیوانات یا گیاهان تولید شوند قابل ثبت نیستند، اما اثری که «تحت الهام یک روح الهی» باشد، می‌تواند ثبت شود.
او استدلال کرد که مسئله اصلی، توانایی قرار دادن مهر کپی‌رایت روی اثر است، نه خودِ عمل خلق کردن. علاوه بر این، او از این واقعیت انتقاد کرد که این سیاست‌ها در لیست‌های داخلی GNU و بدون شفافیت در برابر کاربران مورد بحث قرار می‌گیرند و این نبودِ گشودگی را با فرآیندهای تصمیم‌گیری داخلی و بسته در شرکت Meta مقایسه کرد.
پیامدهای دنیای متن‌باز
این رد درخواست، سیگنالی از یک شکاف احتمالی در خط لوله جذب توسعه‌دهندگان است. نویسنده صراحتاً اعلام کرد که دیگر به Emacs مشارکت نخواهد کرد و دلیل آن را بیزاری از این دانست که وقتی با اراده و میل شخصی کار می‌کند، به او گفته شود که «چوب را اشتباه می‌گیرد».
ضرر عملی این تصمیم برای پروژه GNU قابل توجه است. طبق گفته این توسعه‌دهنده، حدود ۴۰ وصله بهینه‌ساز دیگر روی دیسک سخت او قرار دارد. اگرچه برخی از این‌ها هم‌پوشانی دارند یا تأثیر واقعی‌شان هنوز اثبات نشده، اما او پیش از این تعدادی از آن‌ها را که تأثیر معنادارشان تأیید شده بود، منتشر کرده است. او دیگران را تشویق می‌کند که این وصله‌ها را بررسی کنند، زیرا «واقعاً تغییر ایجاد می‌کنند».
برای جامعه گسترده‌تر، این مورد یک «اثر مرتبه دوم» از پذیرش AI را نشان می‌دهد: ایجاد «مالیات صداقت». وقتی سیاست‌های سازمانی عقب‌تر از پذیرش ابزارها حرکت می‌کنند، ممکن است به‌طور ناخودآگاه توسعه‌دهندگان را تشویق کنند تا برای دور زدن موانع بوروکراتیک، درباره گردش کار خود دروغ بگویند. اگر معتبرترین پروژه‌های متن‌باز به رد کارهای کمک‌گرفته از AI ادامه دهند، ریسک از دست دادن موجی از بهینه‌سازی‌های عملکرد را می‌پذیرند؛ بهینه‌سازی‌هایی که یافتن آن‌ها برای انسان‌ها از نظر محاسباتی گران و دشوار است، اما شناسایی آن‌ها برای مدل‌های پیشرفته، تrivial یا بدیهی است.
گام بعدی شما
- اگر در پروژه‌های متن‌باز مشارکت می‌کنید، پیش از ارسال کد، سیاست‌های صریح هر پروژه درباره AI را بررسی کنید.
- برای بهینه‌سازی‌های پیچیده، از مدل‌های استدلالی برای تحلیل الگوهای حافظه استفاده کنید اما بازبینی انسانی را حذف نکنید.
- بررسی کنید که آیا ابزارهای تحلیل کد شما می‌توانند ردپای AI را شناسایی کنند یا خیر تا در مواجهه با سیاست‌های سخت‌گیرانه آماده باشید.
اما این تنها بخشی از چالش‌هاست؛ تأثیر این سیاست‌ها بر آینده لایسنس‌های نرم‌افزاری را در گزارش بعدی بررسی خواهیم کرد.
گفتگو