چرا غول‌های فناوری و بنیادهای متن‌باز کدهای هوش مصنوعی را ممنوع می‌کنند؟

نکات کلیدی (چکیده سریع)

• پایان دوران شیفتگی کورکورانه: شرکت‌های بزرگ فناوری و پروژه‌های بنیادین مانند اوراکل (OpenJDK)، زبان Zig و جامعه Rust قوانین سخت‌گیرانه‌ای برای ممنوعیت یا محدودیت شدید کدهای تولیدشده توسط هوش مصنوعی وضع کرده‌اند.
• بحران فرسودگی نگه‌دارندگان (Maintainer Burnout): ارسال صدها پول‌ریکوئست به ظاهر درست اما سرهم‌بندی‌شده با هوش مصنوعی، توسعه‌دهندگان پروژه‌های متن‌باز را با پدیده «طوفان هوش مصنوعی» (AI Horde) مواجه کرده است.
• سراب درستی ظاهری کد: هوش مصنوعی کدهایی می‌نویسد که صرفاً «درست به نظر می‌رسند»، در حالی که هسته ماشین‌های مجازی و سیستم‌عامل‌ها به درستی ریاضی، پایداری حافظه و قطعیت نیاز دارند.
• تقسیم نرم‌افزار به ۳ لایه مجزا: آینده برنامه‌نویسی به ابزارهای موقت و یک‌بارمصرف (تولید سریع با AI)، نرم‌افزارهای تجاری و کاربرمحور (نیازمند مالکیت انسان)، و زیرساخت‌های حیاتی (کاملاً دست‌ساز و فوق‌دقیق) تقسیم می‌شود.

این روزها در دنیای مهندسی نرم‌افزار اتفاق بسیار جالبی در حال رخ دادن است. پس از چند سال هیاهوی سرسام‌آور درباره این‌که هوش مصنوعی قرار است جای برنامه‌نویسان را بگیرد، حالا شرکت‌های پیشرو و پروژه‌های بزرگ جهان متوجه واقعیت‌های فنی شده‌اند. آن‌ها در حال وضع قوانین سرسختانه‌ای برای ممنوعیت یا محدودسازی شدید استفاده از کدهای تولیدشده توسط مدل‌های زبانی (LLM) هستند.

شاید جالب‌ترین نمونه اخیر، غول باسابقه دنیای فناوری یعنی «اوراکل» (Oracle) باشد. شرکتی که بیش از ۲۰ هزار نفر از کارمندانش را در جریان سرمایه‌گذاری‌های سنگین روی هوش مصنوعی تعدیل کرد و مدیران ارشدش عاشقانه از کدهای تولیدشده با AI تمجید می‌کنند، ناگهان تصمیمی غیرمنتظره گرفت: ارسال هرگونه کد تولیدشده توسط هوش مصنوعی به پروژه OpenJDK رسماً ممنوع شد!

پاسخ کوتاه (Featured Snippet): شرکت‌های بزرگ فناوری و پروژه‌های متن‌باز کدهای هوش مصنوعی را به دلیل «فرسودگی نگه‌دارندگان»، «ریسک‌های امنیتی پنهان» و «چالش‌های مالکیت فکری» ممنوع کرده‌اند. مدل‌های زبانی کدهایی تولید می‌کنند که تنها در ظاهر درست به نظر می‌رسند؛ در حالی که زیرساخت‌های حیاتی مانند OpenJDK و لینوکس نیازمند درستی تضمین‌شده و مسئولیت‌پذیری مستقیم مهندسان انسانی هستند.

۱. تناقض اوراکل: هیاهوی تبلیغاتی در برابر واقعیت OpenJDK

برای درک اهمیت این تصمیم، باید تفاوت لفاظی‌های بازاریابی و مهندسی زیرساخت را بشناسیم. در حالی که مدیران در سخنرانی‌های خود ابزارهای هوش مصنوعی را انقلابی بی‌نقص توصیف می‌کنند، معماران واقعی سیستم‌ها می‌دانند که مدل‌های هوش مصنوعی تنها حدس‌های آماری با احتمال بالا تولید می‌کنند، نه کدهای تضمین‌شده و قابل‌اتکا.

نکته جالب در مورد سیاست جدید اوراکل برای پروژه OpenJDK (هسته اصلی زبان جاوا)، دقت و شفافیت بی‌نظیر آن است. این قانون، استفاده شخصی برنامه‌نویسان از چت‌بات‌هایی مانند ChatGPT یا Claude را ممنوع نمی‌کند. توسعه‌دهندگان همچنان می‌توانند به صورت خصوصی و در سیستم خود از هوش مصنوعی برای موارد زیر کمک بگیرند:

• درک بهتر و سریع‌تر بخش‌های پیچیده پایگاه کد
• دیباگ کردن مشکلات و کشف ریشه خطاهای شخصی
• ایده‌پردازی برای معماری و بررسی کدهای خود پیش از ارسال

graph TD
    subgraph Allowed ["مجاز: استفاده کمکی و شخصی توسعه‌دهنده"]
        A["برنامه‌نویس"] -->|پرسش و تحلیل| B["هوش مصنوعی (ChatGPT / Claude)"]
        B -->|توضیحات و ایده| A
        A -->|نوشتن کد اصلی توسط انسان| C["مشارکت دقیق و دست‌ساز"]
    end

    subgraph Prohibited ["ممنوع: ارسال مستقیم محتوای تولیدی AI"]
        D["دستیار هوش مصنوعی"] -->|تولید خودکار محتوا| E["کد، مستندات یا باگ‌ریپورت مصنوعی"]
        E -->|ارسال مستقیم Pull Request| F["مخزن OpenJDK (مسدود شده)"]
    end

اما خط قرمز اوراکل کجاست؟ هیچ توسعه‌دهنده‌ای حق ندارد خروجی مستقیم مدل‌های هوش مصنوعی را وارد مخزن OpenJDK کند.

این ممنوعیت تنها به کدهای سی‌پلاس‌پلاس یا جاوا محدود نمی‌شود، بلکه تمام این بخش‌ها را در بر می‌گیرد:

• کدهای منبع و پول‌ریکوئست‌ها (Pull Requests)
• ایمیل‌های ارسالی به لیست‌های پستی پروژه
• صفحات ویکی و مستندات رسمی
• گزارش‌های ثبت باگ و خطایابی
• تصاویر و متون توصیفی

اوراکل برای این اقدام قاطع، سه دلیل اصلی را مطرح کرده است: فشار کاری نگه‌دارندگان، امنیت سیستم و مسائل حقوقی و مالکیت معنوی.

۲. طوفان هوش مصنوعی و بحران فرسودگی نگه‌دارندگان متن‌باز

شاید مهم‌ترین و جذاب‌ترین دلیل از منظر مهندسی نرم‌افزار، همین مسئله حجم کار و فرسودگی روانی بررسی‌کنندگان کد (Reviewers) باشد.

برای سال‌ها، دنیای متن‌باز بر پایه یک فیلتر طبیعی فعالیت می‌کرد: نوشتن کد نیازمند تفکر، زمان و مطالعه مستندات بود. کسی که کدی می‌فرستاد، از قبل ساعت‌ها برای درک مسئله وقت گذاشته بود.

اما هوش مصنوعی مولد این تعادل را بر هم زد. حالا هر کاربری می‌تواند با چند پرامپت ساده، صدها خط کد نامفهوم تولید کند و بدون داشتن کمترین دانش فنی، آن را در قالب پول‌ریکوئست برای نگه‌دارندگان پروژه بفرستد.

| شاخص / ویژگی | مدل سنتی مشارکت متن‌باز | سیل کدهای هوش مصنوعی | | :--- | :--- | :--- | | زحمت ارسال‌کننده | بالا (نیاز به مطالعه عمیق و تست دستی) | تقریباً صفر (پرامپت و کپی‌پیست) | | زحمت بررسی‌کننده | منطقی (کد دارای منطق روشن انسانی است) | فوق‌العاده سنگین (شکار توهم‌های ظریف AI) | | تسلط مشارکت‌کننده | کامل (قابلیت دفاع از تصمیمات معماری) | بسیار ضعیف (عدم شناخت منطق پشت کد) | | پیامد بر اکوسیستم | رشد پایدار و تولید کد باکیفیت | فرسودگی شدید نگه‌دارندگان و قفل شدن توسعه |

یکی از نگه‌دارندگان ارشد اکوسیستم Node.js این وضعیت فاجعه‌بار را به زیبایی توصیف کرده است: «غربالگری سپاه ارک‌های هوش مصنوعی!»

نگه‌دارندگان متن‌باز نمی‌توانند این درخواست‌ها را نخوانده رد کنند؛ چون ممکن است در میان صدها خط کد بی‌ارزش، یک باگ امنیتی واقعی به شکل تصادفی کشف شده باشد. در نتیجه، افراد باسابقه مجبورند ساعت‌ها وقت باارزش خود را صرف خواندن کدهای سرهم‌بندی‌شده بکنند. ادامه این روند باعث می‌شود نگه‌دارندگان خسته و دلزده شوند و برای بازبینی کدها خودشان به هوش مصنوعی متوسل شوند؛ چرخه‌ای باطل از کدهای نامطمئن که توسط ماشین نوشته و توسط ماشین تایید می‌شوند!

۳. سراب «درستی ظاهری»: چرا ماشین مجازی جای کدهای سرهم‌بندی‌شده نیست؟

زبان جاوا هنوز هم یکی از ستون‌های اصلی دنیای فناوری و برترین زبان‌های گیت‌هاب در سال‌های اخیر است. پروژه OpenJDK مرجع و قلب تپنده‌ای است که در بانک‌های بزرگ، پلتفرم‌های ابری و حساس‌ترین سرورهای سازمانی جهان اجرا می‌شود.

درون OpenJDK، مهندسان با هسته اصلی ماشین مجازی یعنی HotSpot، کامپایلرهای JIT، الگوریتم‌های مدیریت حافظه و Garbage Collection (مانند ZGC)، پروتکل‌های رمزنگاری و ابزارهای هم‌زمانی (Concurrency) سر و کار دارند.

flowchart LR
    A["باگ ظریف در کامپایلر یا حافظه HotSpot"] --> B["ناهماهنگی در اجرای ماشین مجازی جاوا"]
    B --> C["زیرساخت‌های بانکی و سرورهای ابری جهان"]
    C --> D["خسارات مالی سنگین و قطعی‌های بحرانی"]

    style A fill:#f96,stroke:#333,stroke-width:2px
    style D fill:#f66,stroke:#333,stroke-width:2px

اگر یک خطای کوچک هم‌زمانی یا نشت حافظه در دل ماشین مجازی رخ دهد، این مشکل به میلیون‌ها نرم‌افزار حیاتی متصل به آن در سراسر دنیا سرایت خواهد کرد.

اوراکل این مشکل بنیادین را با جمله‌ای درخشان خلاصه کرده است:

«هوش مصنوعی در نوشتن کدهایی که در ظاهر درست به نظر می‌رسند فوق‌العاده ماهر است. اما متاسفانه اینجا مسابقه زیبایی نیست؛ و درست به نظر رسیدن، هیچ‌یک از تضمین‌هایی نیست که ما از یک ماشین مجازی انتظار داریم!»

مدل‌های هوش مصنوعی صرفاً بر اساس احتمالات آماری کلماتی را کنار هم می‌چینند که شبیه کدهای استاندارد باشد. اما مهندسی سیستم‌های حیاتی بر پایه درستی ریاضی، امنیت حافظه و محاسبات دقیق بنا شده است، نه حدس‌های خوش‌بینانه.

۴. طیف قوانین هوش مصنوعی: از ممنوعیت مطلق Zig تا عمل‌گرایی لینوکس

اوراکل تنها پروژه‌ای نیست که این مسیر را انتخاب کرده است. اگر به زبان‌ها و پروژه‌های دیگر نگاه کنیم، طیف متنوع و جذابی از سیاست‌گذاری‌ها را می‌بینیم:

graph LR
    Z["پروژه Zig<br><b>ممنوعیت مطلق</b><br>بدون ایده، باگ‌یابی یا کد AI"] 
    --> R["پروژه Rust<br><b>چارچوب سخت‌گیرانه</b><br>ممنوعیت داکیومنت، پذیرش آزمایشی کد با هماهنگی"]
    --> L["پروژه LLVM<br><b>مسئولیت مستقیم انسان</b><br>پذیرش کد مشروط به تسلط ۱۰۰٪ برنامه‌نویس"]
    --> K["هسته Linux<br><b>نگاه ابزاری عمل‌گرایانه</b><br>لینوس: مناسب باگ‌یابی با پذیرش مسئولیت حقوقی"]

بررسی رویکرد پروژه‌های بزرگ:

۱. زبان Zig (ممنوعیت کامل و سرسختانه): پروژه رسمی Zig سخت‌گیرانه‌ترین موضع را دارد. در این پروژه، حتی حق ندارید با یک مدل هوش مصنوعی طوفان فکری (Brainstorm) کنید و بعد همان ایده را با کلمات خودتان بنویسید! همچنین استفاده از AI برای گزارش باگ در زیگ کاملاً ممنوع است.

۲. زبان Rust (مرزبندی دقیق و فرآیند کنترل‌شده): تیم‌های رسمی راست موضعی شفاف و چندلایه اتخاذ کرده‌اند. استفاده خصوصی از AI آزاد است، اما تولید مستندات، پیام‌های خطایابی (Diagnostics) و کامنت‌ها با هوش مصنوعی کاملاً ممنوع اعلام شده است. کدهای تولیدی تنها تحت یک فرآیند آزمایشی سخت، با هماهنگی قبلی بازبین و در بخش‌های غیربحرانی پذیرفته می‌شوند تا از آسیب به سیستم پیچیده مدیریت حافظه (Borrow Checker) جلوگیری شود.

۳. پروژه LLVM (پذیرش با مسئولیت‌پذیری انسان): پروژه کامپایلر LLVM رویکرد میانه‌ای دارد؛ کدهای هوش مصنوعی در صورتی پذیرفته می‌شوند که یک برنامه‌نویس انسانی آن‌ها را خط‌به‌خط بخواند، بفهمد و مسئولیت کامل عملکرد آن‌ها را بر عهده بگیرد. عوامل خودکار (Autonomous Agents) اجازه فعالیت مستقل ندارند.

۴. هسته لینوکس و دیدگاه لینوس توروالدز: «لینوس توروالدز» تصریح کرده که لینوکس پروژه‌ای ضد هوش مصنوعی نیست. او هوش مصنوعی را ابزاری عالی برای پیدا کردن باگ‌های پنهان در هسته می‌داند. با این حال، قوانین مشارکت در لینوکس صراحتاً بیان می‌کنند که تمام مسئولیت حقوقی، رعایت لایسنس، بازتولید خطا و تست پچ‌ها کاملاً بر دوش شخص ارسال‌کننده است.

۵. آینده مهندسی نرم‌افزار: تفکیک به سه لایه متمایز

با فروکش کردن تب‌و‌تاب اولیه هوش مصنوعی، تصویر آینده توسعه نرم‌افزار روشن‌تر می‌شود. دنیای نرم‌افزار به جای نابودی، در حال تقسیم شدن به سه سطح کاملاً مشخص است:

graph TD
    subgraph Tier1 ["لایه اول: نرم‌افزارهای موقت و کم‌اهمیت"]
        T1["داشبوردهای داخلی، اسکریپت‌های موقت، ابزارهای اتوماسیون ساده"]
        T1_Action["تولید سریع با AI؛ کمترین نیاز به بازبینی؛ خطای جزئی اهمیتی ندارد"]
    end

    subgraph Tier2 ["لایه دوم: نرم‌افزارهای تجاری و کاربرمحور"]
        T2["سرویس‌های SaaS، اپلیکیشن‌های موبایل، وب‌سایت‌های تجاری"]
        T2_Action["تولید کدهای تکراری با AI؛ لزوم درک عمیق انسان از معماری، تست و پایش"]
    end

    subgraph Tier3 ["لایه سوم: زیرساخت‌های حیاتی و پرریسک"]
        T3["ران‌تایم زبان‌ها (JVM)، هسته سیستم‌عامل (Linux)، دیتابیس‌ها و سیستم‌های بانکی"]
        T3_Action["کدهای کاملاً دست‌ساز؛ ممنوعیت کدهای سرهم‌بندی‌شده؛ استانداردهای فوق‌العاده بالا"]
    end

لایه اول: نرم‌افزارهای موقت و یک‌بارمصرف (Disposable Software)

داشبوردهای داخلی شرکت‌ها، اتوماسیون‌های ساده اداری، یا ابزارهای CRUD برای چند کارمند محدود. در این پروژه‌ها سرعت همه‌چیز است. اگر کلود یا چت‌جی‌پی‌تی دو روز در زمان صرفه‌جویی کنند و کدی نامرتب تحویل دهند، هیچ مشکلی پیش نمی‌آید (البته همچنان بهتر است مهاجرت‌های دیتابیس را با دقت بررسی کنید!).

لایه دوم: نرم‌افزارهای متداول تجاری و کاربرمحور

بخش عمده‌ای از نرم‌افزارهای مدرن شامل پلتفرم‌های SaaS و اپلیکیشن‌ها در این لایه قرار دارند. هوش مصنوعی می‌تواند حجم بالایی از کدهای تکراری (Boilerplate) را بنویسد؛ اما حس مالکیت و تسلط انسان حیاتی است. داشتن تایپ‌های دقیق، آزمون‌های یکپارچه‌سازی، بررسی موشکافانه کد و مانیتورینگ دقیق غیرقابل چشم‌پوشی است. شاید لازم نباشد هر خط را دستی تایپ کنید، اما باید ساعت ۳ صبح توانایی رفع باگ‌های سیستم را داشته باشید.

لایه سوم: زیرساخت‌های حیاتی و پرریسک (High-Leverage Systems)

هسته سیستم‌عامل‌ها، موتورهای پایگاه داده، ران‌تایم زبان‌ها، نرم‌افزارهای کنترل پرواز، سیستم‌های رمزنگاری و تراکنش‌های بانکی. در این لایه، یک فرض اشتباه یا یک باگ کوچک، خسارات میلیون‌دلاری به بار می‌آورد. اینجا هیچ جایی برای کدهای سرهم‌بندی‌شده هوش مصنوعی وجود ندارد و کدهای دست‌ساز و مهندسی اصیل انسانی حرف اول و آخر را می‌زنند.

جمع‌بندی: ارزش کدهای اصیل و دست‌ساز انسانی

تصمیم اخیر غول‌های دنیای متن‌باز برای محدود کردن هوش مصنوعی، نشانه‌ای از پختگی صنعت نرم‌افزار است. شناخت مرز میان جایی که هوش مصنوعی بازدهی را بالا می‌برد و جایی که ماهیت آماری آن خطرساز می‌شود، تفاوت یک مهندس ارشد با یک کاربر عادی است.

در سیستم‌های حیاتی، دقت و درستی صددرصدی شوخی‌بردار نیست. همان‌طور که «مایکل لوئیس» در کتاب فوق‌العاده Flash Boys نشان می‌دهد که چگونه نرم‌افزارها بازارهای مالی را دگرگون کردند، در سازه‌های مهندسی با مقیاس بالا، کوچک‌ترین تصمیم نرم‌افزاری پیامدهای سنگینی به همراه دارد.

در نهایت، ترجیح می‌دهیم پولمان را در یک سرمایه‌گذاری پرریسک از دست بدهیم تا این‌که به خاطر اعتراف معروف هوش مصنوعی («حق با شماست، اشتباه کردم!») در هسته یک سیستم بانکی، کل پس‌اندازمان نابود شود!

پرسش‌های متداول (FAQ)

:::details آیا برنامه‌نویسان دیگر نمی‌توانند برای توسعه OpenJDK از ابزارهای هوش مصنوعی استفاده کنند؟ توسعه‌دهندگان همچنان مجاز هستند در سیستم شخصی خود از ابزارهایی مانند Claude یا ChatGPT برای درک منطق کدها، ایده‌پردازی و عیب‌یابی استفاده کنند. اما ارسال مستقیم کدهای تولیدشده توسط هوش مصنوعی، متون داکیومنت، ایمیل‌ها و گزارش‌های باگ به مخازن OpenJDK رسماً ممنوع است. :::

:::details چرا پروژه‌هایی مانند OpenJDK یا Zig بسیار سخت‌گیرانه‌تر از فریم‌ورک‌های وب عمل می‌کنند؟ زیرساخت‌هایی مانند ماشین مجازی جاوا یا زبان‌های سیستمی، بستر اجرای میلیون‌ها نرم‌افزار حیاتی و بانکی هستند. از آنجا که مدل‌های هوش مصنوعی صرفاً کدهایی تولید می‌کنند که «در ظاهر درست به نظر می‌رسند» و هیچ تضمینی برای درستی منطقی آن‌ها وجود ندارد، بروز یک باگ پنهان در سطح ماشین مجازی می‌تواند کل اکوسیستم را با بحران مواجه کند. :::

:::details دلیل اصلی گلایه توسعه‌دهندگان متن‌باز از پول‌ریکوئست‌های هوش مصنوعی چیست؟ دلیل اصلی، فرسودگی شدید ذهنی و حجم کاری بازبین‌ها است. تولید صدها خط کد با هوش مصنوعی برای یک کاربر چند ثانیه طول می‌کشد، اما بررسی موشکافانه آن توسط یک نگه‌دارنده ارشد برای اطمینان از نبود باگ‌های ظریف، ساعت‌ها انرژی و تمرکز نیاز دارد. :::