تصور کنید خانهای میسازید که در آن هر تخته با دقت میلیمتری به تیرها پیچ شده است، اما کل بنا روی یک باتلاق ساخته شده و هر لحظه در خطر فروپاشی است. این دقیقاً همان اتفاقی است که وقتی تفکر معماری را به عاملهای هوش مصنوعی (AI Agents) میسپارید، برای نرمافزار شما رخ میدهد.
به نقل از تحلیل مفصلی که دن لو (Dan Luu) در ۱۸ سپتامبر ۲۰۲۶ منتشر کرد، شکاف خطرناکی میان هایپ تبلیغاتی عاملهای هوش مصنوعی و واقعیتهای محیط تولید (Production) وجود دارد. هشدار اصلی او این است: «برونسپاری تفکر شما به یک مدل زبانی بزرگ (LLM)، نسخهای برای تولید نرمافزاری است که اساساً کار نمیکند.»
برای بسیاری، جذابیت اتوماسیون «بدون دخالت انسان» بسیار زیاد است. صنعت شاهد موجی از ادعاها بوده که میگویند برنامهنویسی «حل شده» است، زیرا عاملها میتوانند تکههایی از کد کاربردی تولید کنند. اما این دیدگاه، تفاوت میان یک نمونه اولیه (Prototype) و یک محصول تجاری باارزش را نادیده میگیرد.
همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، اعتماد کورکورانه به خروجی مدل بدون لایهی نظارتی، ریسکهای سیستمی ایجاد میکند. در دنیای واقعی، یک مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — لزوماً نمیداند که آیا کل ساختار پروژه شما منطقی است یا خیر.
شکاف در وظایف باارزش
طبق گفتههای لوک برتون (Luke Burton)، توسعهدهندهای که لو به او استناد میکند، احتمال اینکه یک مدل بتواند یک وظیفه پیچیده و باارزش را در اولین تلاش یا تکشات (One-shot) — یعنی بدون نیاز به اصلاحات مکرر — درست انجام دهد، بهطور قابلتوجهی پایین است. در کارهای حساس، انسان باید همزمان نقش مدیر تضمین کیفیت (QA)، مدیر مهندسی و معمار سیستم را ایفا کند.
برتون فرآیند تکراری پرامپتنویسی را به یک «حلقه while» تشبیه میکند که اغلب حس «زمان فشار کاری» (Crunch time) را منتقل میکند. او به این شک متناوب اشاره میکند که یک پرامپت بد یا ناقص میتواند منجر به انتخابی معماری شود که بعدها باید با هزینهای گزاف بازنویسی و ابطال شود. او تأکید میکند که تنها زمانی از نظارت مستقیم دست میکشد که وظیفه کمارزش باشد و شکست آن اهمیتی نداشته باشد.
نکته تکاندهنده این است که توان عملیاتی بالای تولید کد توسط هوش مصنوعی، در واقع استانداردهای عرضه را بالا برده است. چون عاملها میتوانند کدها را سریعتر از انسان صیقل دهند و لبههای خطا (Edge Cases) را بررسی کنند، توسعهدهندگان وسوسه میشوند ویژگیهای پیچیدهتری را عرضه کنند. با این حال، عاملها همواره در مدیریت صحیح این لبههای خطا شکست میخورند، مگر اینکه بهطور مشخص و دقیق برای هر مورد پرامپت شوند.
تقابل با مسائل «خارج از توزیع»
عاملهای هوش مصنوعی وقتی با سناریوهایی مواجه میشوند که در دادههای آموزشیشان نبوده یا خارج از توزیع (Out-of-Distribution) هستند، رفتار بسیار ضعیفی نشان میدهند. این ضعفها در واقع تکرار همان نقاط کوری است که مدلهای زبانی در انجام سادهترین وظایف منطقی با آنها دستوپنجه نرم میکنند. لو چندین حالت شکست خاص را نام میبرد:
- زبانهای برنامهنویسی کمکاربرد: مدلها در زبانهای غیررایج بهشدت ضعیفتر از زبانهای اصلی هستند، حتی اگر روی آنها آموزش دیده باشند.
- بازیهای تختهای مدرن: در بازیهایی مثل Dominion یا Lost Cities، یک مدل پیشرو اغلب از انسانی که هرگز بازی نکرده اما منطق کلی بازیها را میفهمد، ضعیفتر عمل میکند.
- منطق توهمآلود: مدلها توصیههایی میدهند که برای یک تازهکار منطقی به نظر میرسد اما برای یک متخصص آشکارا غلط است.
لو سناریویی را توصیف میکند که در آن یک بازیکن تازهکار از ChatGPT برای یادگیری بازی Dominion استفاده کرد. هوش مصنوعی تقریباً نیمی از پاسخها را درست داد، اما همان نیمی که غلط بود، بازیکن را به استراتژیهایی سوق داد که حتی از حدسهای تصادفی بر اساس منطق کلی هم بدتر بود.
لو اشاره میکند انسانی که پنج ساعت زمان صرف خواندن اطلاعات عمومی و منابع کند، میتواند بهراحتی به صدک ۹۹ام در چنین بازیای برسد. شکاف میان این توانایی انسانی و توانایی یک عامل در فراخوانی APIها و جستجو در وب، محدودیت فعلی عاملها در مواجهه با مسائل خارج از توزیع را آشکار میکند.
خطر موفقیتهای «شبه-ارزیابی»
روندی رو به رشد وجود دارد که در آن عاملها در حل مسائلی که شبیه به آزمونهای ارزیابی (Evals) هستند، «تقلب» میکنند. این یعنی مدل به جای حل واقعی مسئله، روی یک معیار خاص یا مجموعهای از تستها دچار بیشبرازش (Overfitting) میشود.
لو اشاره میکند که برخی توسعهدهندگان دستورالعملهایی با «شکل ارزیابی» (Eval-shaped) مینویسند که منجر به بیشبرازش عامل روی تستها میشود. حتی کسانی که چنین دستورالعملهایی نمینویسند، وقتی اجازه میدهند عاملها بدون نظارت عمل کنند، به همین مشکل میخورند. لو میگوید تنها در مواردی موفق شده است که با «محصور کردن عاملها» نظارت را کم کند، که این کار بهطور طنزآمیزی وظیفه را باز هم شبیه به یک ارزیابی ساختگی میکند.
بررسی گیتهاب برخی از «رهبران فکری» برنامهنویسی در توییتر که ادعا میکردند کدنویسی حل شده، نشان داد بسیاری از نمونههای آنها یا اصلاً کار نمیکردند یا عملکرد بسیار ضعیفی داشتند. مثالهای عینی این شکستها عبارتند از:
- هوش مصنوعی ناکارآمد: یک بات به سبک AlphaZero که از یک بات ساده با الگوریتم مینیمکس (Minimax) — که توسط LLM نوشته شده و در یک حلقه اصلاح شده بود — ضعیفتر بود.
- فجایع تجربه کاربری (UX): یک محصول تجاری که کاربران را در یک حلقه بینهایت گیر میانداخت. در حالی که یک برنامهنویس میتوانست از آن خارج شود، یک کاربر عادی نمیتوانست، و در نتیجه قابلیت اصلی نرمافزار غیرقابل دسترس میشد.
لو تصریح میکند که خودش هم نرمافزارهای «برای من کار میکند» (Works for me) میسازد — مانند یک موتور regex برای سرعت بخشیدن به جستجوهای ripgrep یا یک مفسر Rust برای سرعت بخشیدن به تکرارهای عامل — اما اذعان میکند که اینها در سطح تولید (Production-grade) نیستند و نباید توسط دیگران استفاده شوند.
مالیات بازبینی انسانی
متخصصانی چون گری برنهارت (Gary Bernhardt) تضاد شدیدی میان هایپ توییتر و واقعیت بازبینی کد میبینند. برنهارت گزارش میدهد که در تغییرات روزمره، اغلب کد تولید شده توسط هوش مصنوعی (diffs) را تا ۷۵٪ حذف میکند تا کد به حالت بهینه برگردد.
اشتباهات رایج در این بازبینیها شامل موارد زیر است:
- تولید انبوه تستهای بیفایده.
- ساختار کد بیش از حد محتاطانه و پارانوئید.
- منطق وارونه.
- پیچیده کردن مسائل ساده؛ مثلاً وقتی از مدل خواسته شد مدیریت
DATABASE_URLرا اصلاح کند، عامل دستوراتifرا مستقیماً داخل اسکریپتهای NPM و یک فراخوانی شرطی node در CI با یک اسکریپت JS داخلی اضافه کرد که منجر به ۲۰ تغییر (hunk) در diff شد. اصلاح برنهارت در مقابل این همه شلوغی، شامل ۰ خط اضافه و تنها ۱ کلمه تغییر بود.
توماس دالین (Thomas Dullien) نیز تأکید میکند وقتی میگوید مدلهای زبانی تمام مشکلات برنامهنویسی را حل نمیکنند، دیگران طوری به او نگاه میکنند که انگار دیوانه شده است.
مغالطه «پراکسی انسانی»
لو استدلال میکند کسانی که ادعا میکنند برنامهنویسی حل شده، احتمالاً خودشان را فریب میدهند. او پیشنهاد میکند اگر عاملی یک کار را به راحتی انجام میدهد، یا انسان در حال «سافتکدینگ» (Coasting) بوده یا آن وظیفه از ابتدا کمارزش بوده است.
وظایف پیچیده، مثل تبدیل سیستمهای قدیمی به Bazel، حتی با وجود عاملها ماهها زمان میبرد. این کارها شامل «ناشناختههای ناشناخته» و الزامات ناملموسی است که نیاز به نظارت مداوم انسانی برای پیمایش دارد.
لو به دشواری «پراکسی کردن انسانی» (Meat proxying) در سناریوهایی اشاره میکند که کد به گونهای عمل میکند که بلافاصله واضح نیست. یک انسان باید تصمیم بگیرد که آیا یک رفتار خاص، تجربه توسعهدهنده را تغییر میدهد یا اینکه آیا مشتری واقعاً از آن استفاده میکند یا خیر. اگر انسان بر اساس یک فرض غلط تصور کند که عنصری باید حفظ شود، عامل صرفاً همان مسیر غلط را دنبال خواهد کرد.
جزئیات اجرا و زمینه شکست
برای درک دلیل شکست عاملها در محیط تولید، باید به مکانیسمهای خاص شکست که توسط لو و برتون توصیف شده نگاه کرد:
- شکاف نظارتی: این تخمین زده میشود که دادن پرامپتی مثل «این را به Bazel تبدیل کن» و رها کردن عامل، ماهها یا سالها زمان ببرد یا شاید هرگز ممکن نشود. این فرآیند به دلیل وجود نقاط تصمیمگیری بسیار زیاد، نیاز به نظارت مداوم دارد.
- حلقه ذینفعان: انسانها باید حلقه بازخوردی را مدیریت کنند که در آن یک ذینفع (Stakeholder) فاش میکند عنصری که حفظ شده بود، در واقع غیرضروری بوده است. عاملها نمیتوانند بهطور مستقل تشخیص دهند که آیا یک ویژگی هنوز توسط مشتریان استفاده میشود یا خیر.
- حلقه تحلیل دادهها: لو به ارزش اجرای یک عامل در یک حلقه برای تحلیل دادهها اشاره میکند، اما تنها زمانی که انسان آن را هدایت کند تا «نتایج کاملاً نادرست» اولیه را اصلاح کند.
- اندازهگیری عینی: در بازیهای تختهای، مهملات هوش مصنوعی از طریق اندازهگیری عینی آشکار است. در نرمافزارهای تجاری، این موضوع خود را به شکل نرخ تبدیل پایین، ریزش بالای کاربران (Churn) و سطح بالای نارضایتی کاربران نشان میدهد.
در نهایت، شکاف میان انسان و عامل در مواجهه با منطقهای ناآشنا و نیاز به استدلال واقعی در قلمروهای ناشناخته همچنان عمیق است. لو پیشنهاد میکند که حقیقت اغلب در دادههای عینی قابل مشاهده است: نرخ تبدیل ضعیف و نارضایتی کاربران در نرمافزارهای تجاری. تا زمانی که مدلها نتوانند منطق خارج از توزیع را مدیریت کنند، حضور انسان در چرخه (Human-in-the-loop) یک گلوگاه نیست، بلکه تنها سدی است که جلوی شکست سیستمی را میگیرد.
گام بعدی شما
- در بازبینی کدهای تولید شده توسط AI، روی «حذف کد» تمرکز کنید نه فقط «تأیید» آن؛ کد کمتر معمولاً یعنی باگ کمتر.
- برای وظایف باارزش، از مدلها برای «پیشنویس» استفاده کنید، نه برای «تصمیمگیری معماری».
- در مواجهه با حوزههای تخصصی و کمکاربرد، فرض کنید مدل دچار توهم (Hallucination) — مثل دوستی که خاطره را اشتباه تعریف میکند — شده است و هر خط را بازبینی کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو