چرا مدل‌های زبانی در تولید کدهای پیچیده و بهینه شکست می‌خورند؟

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

به نقل از متیو روپرت (Mathieu Ropert)، مهندسی که در ۴ اوت ۲۰۲۶ نقد تندی بر برنامه‌نویسی با AI منتشر کرد، استدلال اصلی او این است که مدل‌هایی مثل Claude هوشمند نیستند؛ آن‌ها صرفاً شبکه‌های عصبی (Neural Network) — شبکه‌ای از سلول‌های کوچک، شبیه نقشهٔ مترو، که سیگنال را از ورودی به جواب می‌رساند — عظیم هستند که در تولید احتمالی متن تخصص دارند. او تأکید می‌کند که این مدل‌ها در واقع تخصص دارند در تولید متنی که از نظر آماری محتمل‌ترین ادامه برای ورودی باشد، نه درک منطقی از مفاهیم برنامه‌نویسی.

این وضعیت در حالی رخ می‌دهد که بسیاری از شرکت‌ها پذیرش AI را از بالا به پایین و به صورت اجباری تحمیل کرده‌اند، فارغ از اینکه مدیریت آن‌ها چه پیش‌زمینه‌ فنی دارند یا ندارند. روپرت اشاره می‌کند که این پذیرش اجباری اغلب شبیه به «شدیدترین حالت مدیریت خرد» (Micro-management) است و برای بسیاری از مهندسان، توهین‌آمیز است. برای توسعه‌دهندگان، این فشار شبیه به تکرار دوران «گلوله‌های نقره‌ای» گذشته است؛ درست مثل زمانی که مفاهیمی چون میکروسرویس‌ها یا NoSQL بدون تحلیل نیاز، توسط رهبرانی که هرگز یک خط کد ننوشته‌اند، به همه تحمیل می‌شدند. در دنیایی که مدل‌های زبانی بزرگ (LLM) به عنوان موتورهای «استدلال» (Reasoning) بازاریابی می‌شوند، واقعیت اغلب یک بازی پیچیده از تطبیق الگوهاست که می‌تواند یک توسعه‌دهنده غافل را به گمراهی بکشاند.

هوش مصنوعی «مصنوعی» و مکانیسم LLMها

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

آنچه امروز «گردش‌کار عامل‌محور» (Agentic Workflow) نامیده می‌شود، در واقع درک این نکته است که مسائل نرم‌افزاری را می‌توان با افزودن لایه‌هایی از واسط‌ها (Indirection) حل کرد. اگر خروجی یک شبکه عصبی با ورودی بیشتر بهبود یابد، ورودی‌های بیشتری به آن متصل می‌کنند. اگر بهترین راه برای یافتن آن ورودی این باشد که مدل یک دستور تولید کند و آن را از طریق تابع system() اجرا کند، حلقه به این ترتیب بسته می‌شود. این هرگز هوشمندی نیست، بلکه یک حلقه برنامه‌ریزی‌شده است تا زمانی که یک شرط خروج (Exit Condition) اجرا شود.

پارادوکس جست‌وجو

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

اما این مزیت در محیطی متزلزل و مخاطره‌آمیز قرار دارد:

• تخریب SEO: کیفیت جست‌وجو از دوران طلایی دهه ۲۰۰۰ میلادی افت کرده است، زیرا گوگل در نبردی دشوار علیه بهینه‌سازی موتورهای جست‌وجو (SEO) قرار دارد. روپرت اشاره می‌کند که این موضوع به‌ویژه هنگام جست‌وجو برای دستور پخت غذاها به وضوح دیده می‌شود.
• آشغال‌های اینترنتی (Internet Slop): مدل‌های زبانی هزینه تولید و غرق کردن وب در «سالاد کلمات» را پایین آورده‌اند. روپرت با ارجاع به ویدیویی از «فریا هولمر»، اشاره می‌کند که این راندن محتواهای تولید شده توسط AI در وب، باعث تغذیه یک مسابقه تسلیحاتی بی‌پایان در SEO می‌شود و یافتن داده‌های واقعی را سخت‌تر می‌کند.
• کیفیت منابع: یک خلاصه تولید شده توسط LLM هرگز نمی‌تواند بهتر از منابعی باشد که مدل بلعیده است. این موضوع باعث می‌شود که اگر کاربر منابع معتبر خاصی را برای یک موضوع می‌شناسد، جست‌وجوی دستی تنها گزینه قابل اعتماد باقی بماند.

پیمایش در پایگاه‌های دانش داخلی

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

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

اگرچه این روش از نظر محاسباتی ناکارآمد است — زیرا ایندکس کردن محتوا به روشی که گوگل ۲۰ سال پیش انجام می‌داد بسیار ارزان‌تر از اجرای یک LLM گران‌قیمت است — اما برای کاربر بسیار مطلوب‌تر است. این ابزار درمان کسالت جست‌وجو برای کلمه «UI» است که نتیجه صفر می‌دهد، صرفاً چون در سند اصلی از عبارت «User Interface» استفاده شده است.

تله‌ی توهم

با این حال، این کارایی با ریسک‌های سیستمیک همراه است. توهمات (Hallucinations) یک ویژگی ذاتی تولید توکن بر اساس آمار هستند، نه منطق؛ و هیچ راه شناخته شده‌ای برای اجتناب کامل از آن‌ها وجود ندارد. روپرت این تجربه را در تمام مدل‌ها، از نسخه رایگان Copilot در Bing تا نسخه‌های پذیری و گران‌قیمت Claude دیده است.

این خطاها زمانی که کاربر درباره ویژگی‌های تخصصی و کم‌کاربرد در ابزارهایی مثل CMake، Vulkan یا Xcode پرس‌وجو می‌کند، به بیشترین حد خود می‌رسند. مدل به‌جای پذیرفتن اینکه چنین قابلیتی وجود ندارد، محتمل‌ترین جواب آماری را ارائه می‌دهد؛ مثلاً دکمه‌ای را پیشنهاد می‌کند که وجود ندارد یا یک فلگ (Flag) غیرموجود را معرفی می‌کند. مدل شبیه به شخصی رفتار می‌کند که به طور کلی درباره یک حوزه اطلاعات دارد، اما درباره کتابخانه (Library) خاصی که در حال استفاده است، هیچ اطلاعی ندارد.

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

• منطق زبانی: یک LLM ممکن است تابع .sort() را برای یک کانتینر C++ پیشنهاد دهد چون در پایتون و سی‌شارپ این‌گونه است و تفاوت بنیادی C++ در مورد کانتینرها، ایتراتورها و الگوریتم‌ها را نادیده می‌گیرد.
• حلقه‌های خود-تقویت‌کننده: AI ممکن است یک قطعه از کار در حال پیشرفت (Work-in-progress) را به عنوان منبع حقیقت معرفی کند. روپرت متوجه شد که Claude با اصرار می‌گوید یک پیشنهاد توسط گزارش‌های گذشته پشتیبانی می‌شود، اما بعداً فهمید که آن «گزارش گذشته» در واقع همان گزارشی بود که خودش در حال حاضر می‌نوشت. این یک حلقه بازخورد ایجاد می‌کند که در آن همکارانی که همان پایگاه داده را می‌جویند، خلاصه‌های ناقص را به عنوان حقیقت مطلق می‌پذیرند.
• بازی تلفنی: یک AI ممکن است خلاصه‌ای را از AI دیگر بدون پرس‌ زیر سؤال برود. روپرت یک بار دید که Claude ادعا می‌کند یک طراحی «تصمیم آگاهانه» توسط تیم بوده است، در حالی که در واقع فقط داشت خلاصه‌ای از یک AI دیگر را می‌داد که آن AI هم دو کاربر را در یک فروم عمومی در حال گمانه‌زنی می‌دید.
• پرس‌وجوهای آیینی: کاربران به طور فزاینده‌ای مجبورند از «طلسمات» یا عبارات جادویی (مانند «اشتباه نکن») استفاده کنند تا جواب درست بگیرند؛ آیینی که باید هر بار با به‌روزرسانی مدل یا نسخه‌های جدید سالانه بازنگری شود.

چرا بازی‌سازی «غول مرحله آخر» است؟

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

بیشتر کدهای متن‌باز بازی‌ها مربوط به دهه‌های پیش است. برای مثال:

• Doom 3: آخرین بازی AAA بود که کدش منتشر شد (عرضه اصلی در ۲۰۰۴، یعنی ۲۲ سال پیش). این کد حتی چندرشته‌ای (Multithreading) نیست، هرچند یک پورت BFG در سال ۲۰۱۲ وجود دارد که بیشتر یک پورت است تا یک بازی جدید.
• مخازن قدیمی: سایر نسخه‌های گیت‌هاب اغلب مربوط به دهه ۹۰ هستند و از رستریزیشن نرم‌افزاری یا خط لوله‌های ثابت OpenGL 1.2 استفاده می‌کنند.

در نتیجه، مدل‌ها اغلب روی پروژه‌های آماتوری، گیم‌جم‌ها و دموهای آموزشی ساده آموزش دیده‌اند. این منجر به مشکلات «سفارشی» می‌شود: دوستان روپرت که از زبان‌های اسکریپتینگ داخلی شرکت استفاده می‌کردند، متوجه شدند خروجی LLM کاملاً با استانداردهای داخلی آن‌ها در تضاد است، زیرا تنها داده‌های آموزشی موجود از مودهای (Mods) بازی‌ها گرفته شده بود.

در یک تلاش خاص برای بهینه‌سازی یک بازی در Unity، روپرت از AI خواست تا متد Update() را از یک MonoBehaviour حذف کرده و آن را به یک کلاس مدیریت (Manager) منتقل کند تا از هزینه فراخوانی مجازی (Virtual Invocation) از موتور C++ به اسکریپت مدیریت شده C# جلوگیری کند. اما Claude به‌جای یک پیاده‌سازی مستقیم، راهکار را بیش‌ازحد پیچیده (Over-engineer) کرد؛ با ساخت یک کلاس پایه جدید به نام GameUpdateable دارای متد OnUpdate()، و مجبور کردن Foo به ارث‌بری از آن و ذخیره آرایه به صورت List<GameUpdateable> در مدیر. اگرچه این هنوز هم بهتر از پل C++/C# است، اما مدل یک الگوی طراحی OOP غیرضروری را به تغییری محلی اعمال کرد که تنها ۲ یا ۳ فایل را درگیر می‌کرد.

هزینه پایداری

از نظر مالی، مدل فعلی AI ناپایدار به نظر می‌رسد. شرکت‌های AI در حال حاضر با ضرر کار می‌کنند و اگر هزینه‌های تحقیق و توسعه (R&D) و سخت‌افزار کنار گذاشته شود، تنها یک «سود حاشیه‌ای» اندک دارند.

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

• قیمت‌گذاری: توکن‌های خروجی اغلب ۵ تا ۱۰ برابر گران‌تر از توکن‌های ورودی هستند.
• کارایی: این باعث می‌شود نوشتن کد — که خروجی آن سنگین است — بسیار گران‌تر از خلاصه‌سازی متن باشد، جایی که مدل بسیار بیشتر از آنچه تولید می‌کند، می‌بلعد.

او به تضاد گیج‌کننده‌ای در هزینه‌های شرکتی اشاره می‌کند: مدیریت ممکن است اشتراک Claude را برای تک‌تک کارکنان، حتی غیربرنامه‌نویسان، بخرد، اما از پرداخت ۲۰ یورو هزینه لایسنس ماهانه برای یک ابزار تخصصی پروفایلینگ (Profiling) خودداری کند. این نشان‌دهنده ترجیح «اسباب‌بازی‌های گران‌قیمت و براق» بر ابزارهای خاصی است که مهندسان برای انجام شغلشان واقعاً نیاز دارند. این موضوع به‌ویژه زمانی ناامیدکننده است که مدیریت از اعتماد به مهندسان برای هزینه ابزارهایشان خودداری می‌کند اما اشتراکی را تحمیل می‌کند که شاید اصلاً تغییری در نحوه کدنویسی آن‌ها ایجاد نکند.

تحلیل: دستیار در مقابل نویسنده

این شواهد نشان‌دهنده یک تغییر حیاتی در نحوه نگاه ما به AI در محیط IDE است. LLMها به عنوان «دستیاران کدنویسی» (Coding Assistants) بسیار مؤثر هستند. روپرت در اینجا مشابهتی با کارهای استافورد بیر، مشاور مدیریت بریتانیایی و حوزه سایبرنتیک مدیریت می‌کشد.

نظریه بیر — مبنی بر اینکه توانایی یک مدیر در تصمیم‌گیری توسط ظرفیت او برای پردازش اطلاعات (سیگنال) محدود می‌شود — در اینجا کاربرد دارد. بیر تحت تأثیر «دبلیو. راس اشبی» بود که کارهای کلود شانون (هم‌نام با مدل LLM) را گسترش داده بود. همان‌طور که یک مدیر برای جلوگیری از نادیده گرفتن عوامل حیاتی به «تنوع» (Variety) در داده‌ها نیاز دارد، توسعه‌دهنده‌ای که وارد یک کدبیس جدید می‌شود نیز نیاز دارد حجم عظیمی از داده‌ها را سریعاً پردازش کند. در این ظرفیت، یک LLM به توسعه‌دهنده کمک می‌کند تا کدبیس را کاوش کرده و «رشته‌ها را بکشد» تا ببیند به کجا ختم می‌شوند.

با این حال، آن‌ها در حال حاضر به عنوان «نویسندگان کد» (Coding Authors) شکست می‌خورند. تجربه روپرت در پروژه رندرینگ شخصی‌اش این را نشان می‌دهد:

• باگ Culling: کلود یک راهکار «کتابخانه‌ای» برای مشکل جهت‌داری (Handedness) ارائه داد که کار می‌کرد، اما بسیار ناکارآمد‌تر از متریالی بود که خود کلود قبلاً تجزیه کرده بود.
• نورپردازی PBR: هوش مصنوعی پیشنهاد داد کل سیستم نورپردازی بازنویسی شود، مکان نور اصلی تغییر کند و نور محیطی اضافه شود؛ اما روپرت ساعت‌ها بعد متوجه شد که مشکل صرفاً یک تکسچر فلز/زبری (Metallic/Roughness) معیوب روی یک مدل بود.

در نهایت، همان‌طور که در پستی در ۱۹ ژوئن ۲۰۲۶ در سایت pikuma.com اشاره شده، AI اغلب در مورد چیزهایی که کاربر در آن‌ها متخصص است اشتباه می‌کند، اما درباره چیزهایی که کاربر هیچ اطلاعی ندارد، «همیشه درست» به نظر می‌رسد. این موضوع AI را برای موضوعات جدید خطرناک می‌کند. اگر توسعه‌دهنده‌ای از AI برای نوشتن کدهای تکراری (Boilerplate) استفاده کند و تمایلی به بررسی آن‌ها نداشته باشد، مشکل از AI نیست، بلکه از طراحی API نرم‌افزاری است که آن‌ها در حال ساختش هستند.

گام بعدی شما

• از AI برای «پیمایش» (Exploration) کدبیس‌های قدیمی و یافتن مترادف‌های جست‌وجو استفاده کنید، نه برای پیاده‌سازی منطق اصلی.
• هرگز کدهای تولید شده در حوزه‌های نیتیو (مانند C++ یا Vulkan) را بدون بررسی دقیق در مقابل مستندات رسمی تایید نکنید.
• در صورت مشاهده الگوهای بیش‌ازحد پیچیده (Over-engineering) در پیشنهادات AI، آن را به چالش بکشید و پیاده‌سازی ساده‌تر را بخواهید.

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