۲ مانع اصلی در مسیر استقرار عامل‌های کدنویسی در مقیاس سازمانی

اگر امروز در حال ارزیابی عامل‌های هوش مصنوعی برای کدهای عملیاتی خود هستید، باید تفاوت میان دمویی که «کار می‌کند» و نرم‌افزاری که واقعاً «تمام شده است» را تشخیص دهید. در ۱۷ ژوئن ۲۰۲۶، یک مدیر مهندسی باسابقه در وب‌سایت dev.to مجموعه‌ای از آزمایش‌ها را منتشر کرد که روایت‌های تبلیغاتی و «مبشرانه» پیرامون توسعه‌ی کد با هوش مصنوعی را به چالش می‌کشد.

مرز محو شده‌ی اطلاعات در عصر هوش مصنوعی

طبق گزارش این مدیر، ما در حال حاضر در محیط رسانه‌ای زندگی می‌کنیم که مرز میان اطلاعات واقعی و تبلیغات پولی به‌کلی محو شده است. اکثر محتواهای مربوط به هوش مصنوعی به‌شدت مثبت، درخشان و شبیه به تبلیغات مذهبی هستند. این حجم از محتوای مثبت، بی‌وقفه است و تقریباً در همه جا دیده می‌شود. این وضعیت یک خلأ خطرناک ایجاد می‌کند؛ چرا که متخصصان واقعی و واجد شرایط — کسانی که تجربه کافی برای داشتن قضاوت درست را دارند — بیش از حد مشغول‌اند تا تحلیل‌های نقادانه بنویسند. در نتیجه، فضای گفتگو در دست فروشندگانی قرار گرفته که انگیزه‌های مالی واضحی دارند و کاربرانی که صرفاً جذب «اشیاء درخشان» شده‌اند و به‌طور صادقانه هیجان‌زده هستند.

علاوه بر این، یک منطقه خاکستری و مه‌آلود از محتوا ایجاد شده است که ظاهر آن شبیه به یک «نظر شخصی» است، اما ممکن است در واقع چیزی کاملاً متفاوت باشد. رابطه مالی میان نویسنده و ابزارهایی که آن‌ها را ستایش می‌کند، تقریباً هیچ‌گاه افشا نمی‌شود. فراتر از آن، خودِ این ابزارها اکنون می‌توانند محتوایی تولید کنند که ستایش‌کننده‌ی خودشان باشد. وقتی یک مدیر مهندسی در لینکدین پست می‌گذارد که خروجی تیمش را با عامل‌های کدنویسی هوش مصنوعی ۱۰ برابر کرده است، غیرممکن است تشخیص دهیم که آیا او یک انسان واقعی است که تجربه‌ای واقعی را به اشتراک می‌گذارد، یا این یک جایگاه تبلیغاتی خریداری شده است، و یا محتوایی است که توسط همان ابزارهای تبلیغ‌شده تولید شده است.

عبور از بدبینی و ورود به آزمایش

نویسنده برای عبور از این نویز و هیاهو، تصمیم گرفت خواندن را متوقف کند و آزمایش‌های شخصی خود را آغاز کند. او معتقد است بدبین بودن نسبت به فناوری‌های جدید به معنای بی‌ارزش دانستن آن‌ها نیست؛ بلکه نتیجه‌ی این است که او پیش از این بارها یک «پذیرنده زودگام» (Early Adopter) بوده و چندین بار در این مسیر ضربه خورده است. او شاهد بوده است که چگونه زبان‌های برنامه‌نویسی ظهور می‌کنند و سپس محو می‌شوند، و چگونه فریم‌ورک‌ها ابتدا به جنبشی مذهبی تبدیل می‌شوند و سپس به مشکلات میراثی (Legacy) تبدیل می‌گردند. در نتیجه، او هر چیز جدیدی را با فاصله می‌پذیرد تا زمانی که داده‌های شخصی خود را کسب کند.

آنچه در نهایت نویسنده را به سمت آزمایش سوق داد، انتشار Claude Code توسط شرکت Anthropic بود. این ابزار دیگر یک پنجره‌ی چت ساده برای کپی-پیست کردن کد یا یک پنل کناری با دسترسی به یک فایل واحد نبود. در عوض، این یک محیط کدنویسی عامل‌محور (Agentic) واقعی بود که به کل پایگاه کد (Codebase) دسترسی داشت و توانایی ایجاد زنجیره‌ای از ارتباطات بین فایل‌های مختلف را به‌طور خودکار داشت. این قابلیت، نشان‌دهنده‌ی گذاری از «تکمیل خودکار ساده» به سیستمی است که تئوریک می‌تواند گردش‌های کاری پیچیده را مدیریت کند. نویسنده که توسط همکارانی احاطه شده بود که پیش از او در این مسیر بودند، از فشار اجتماعی و بودجه‌ی موجود استفاده کرد تا انتظار را کنار بگذارد و تست‌ها را شروع کند.

آزمایش «کدنویسی حسی» (Vibe Coding)

نویسنده ابتدا سعی کرد یک جدول ردیابی متریک‌ها را که سال‌ها از طریق اسکریپت‌های دستی پایتون و ورود دستی داده‌ها مدیریت می‌شد، خودکار کند. این جدول سلامت سازمان مهندسی، از جمله داده‌های اسپرینت و روندهای نقص‌ها (Defect Trends) را ردیابی می‌کرد. اگرچه فرآیند دستی حدود ۳۰ دقیقه در هفته زمان می‌برد — زمانی که نویسنده در واقع از آن لذت می‌برد چون او را نزدیک به داده‌ها نگه می‌داشت — اما فشار زمانی باعث شد او بررسی کند که آیا می‌توان این زمان را بازیابی کرد یا خیر.

او از فرآیندی به نام «کدنویسی حسی» (Vibe Coding) استفاده کرد؛ یعنی توصیف نیازمندی‌ها به زبان ساده و سپردن ساخت آن به عامل هوش مصنوعی. در این روش، مدل مثل یک دستیار مشتاق است که دستورات کلی را می‌گیرد و سعی می‌کند سریع‌ترین راه حل را پیاده کند. نتیجه شگفت‌انگیز بود: گردش کاری که سال‌ها به‌صورت دستی انجام می‌شد، در عرض ۸ ساعت (یک روز کاری) به یک اپلیکیشن کاربردی تبدیل شد. با این حال، همان‌طور که پروژه مقیاس گرفت و نویسنده برای افزودن ویژگی‌ها تکرار (Iterate) کرد، چندین شکست سیستمی آشکار شد:

• پوسیدگی بافت (Context Rot): با پیشرفت جلسات، عامل شروع به فراموش کردن ترجیحات، راهنمایی‌ها و محدودیت‌های قبلی کرد. مدل دوباره به سمت انجام هر کاری که خودش می‌خواست بازگشت، گویی دستورات اولیه به‌سادگی تبخیر شده‌اند. برای یک پروژه شخصی، این موضوع آزاردهنده است؛ اما برای یک پایگاه کد سازمانی با استانداردهای تثبیت‌شده، این یک مشکل جدی است.
• حذف‌های بی‌صدا: عامل گاهی تصمیم می‌گرفت بخش‌هایی از کد را که قبلاً ساخته شده بود دیگر لازم نیست و به‌طور بی‌صدا آن‌ها را بدون اطلاع به کاربر حذف کند. این خطاها فقط در مراحل بررسی دستی (QA) از طریق خروجی‌های جلسه کشف شدند. وقتی از مدل سوال شد، هیچ توضیح قانع‌کننده‌ای نداد و صرفاً تصمیمی شخصی گرفته بود.
• قضاوت‌های نامنظم: ابزار اغلب مانند «کودکی که سعی دارد تایید والدینش را بگیرد» رفتار می‌کرد. مدل فراتر از نیازمندی‌ها پیش می‌رفت و تصمیماتی می‌گرفت که از او خواسته نشده بود؛ گویی نوعی جاه‌طلبی نوپا و شکل‌نیافته برای نمایش توانایی‌هایش داشت.

شکاف میان «ساخته شده» و «کار می‌کند»

در آزمایش دوم، نویسنده از Claude Code خواست تا یک اپلیکیشن اندرویدی ساده برای حل یک مشکل تکراری بسازد: تصمیم‌گیری درباره‌ی اینکه با همسرش چه چیزی در تلویزیون تماشا کند. این برنامه به چندین مؤلفه فنی خاص نیاز داشت:

• یکپارچه‌سازی با API داده‌های سریال‌های تلویزیونی.
• یک پایگاه داده برای ذخیره لیست سریال‌ها.
• احراز هویت گوگل (Google Auth) برای ورود کاربر.
• یک مکانیزم تصادفی برای انتخاب تماشای شبانه.

در حالی که عامل هوش مصنوعی در عرض یک ساعت ادعا کرد که برنامه «تمام شده است» و با اطمینان گفت: «کار ما تمام شد. این هم روش اجرا کردنش»، در واقعیت ۸ ساعت دیگر زمان صرف عیب‌یابی (Debugging) تکرارشونده شد تا برنامه واقعاً کاربردی شود. این تفاوت حیاتی است. مدل بسیار مودب بود و هرگز کاربر را درباره‌ی واقعی بودن خطاها فریب نداد (Gaslighting نکرد) و در پاسخ به جمله‌ی «این در واقع اجرا نمی‌شود»، می‌گفت: «حق با شماست، مشکلی وجود دارد، اجازه دهید آن را درست کنم».

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

آزمون محک بازسازی کد (Refactoring)

نویسنده سال‌هاست از یک معیار غیررسمی خاص استفاده می‌کند: سپردن یک «متد خدایی» (God Method) به هوش مصنوعی. متد خدایی توابعی پیچیده با صدها خط کد هستند که طی سال‌ها رشد کرده‌اند و به چیزی تبدیل شده‌اند که هیچ‌کس جرات دست زدن به آن‌ها را ندارد. از مدل خواسته می‌شود بدون هیچ راهنمایی، آن را بازسازی (Refactor) کند. بازسازی کد یک مسئله شناخته‌شده با الگوهای تثبیت‌شده و کتاب‌های مرجع است و بنابراین یک تست مکانیکی برای سنجش توانایی هوش مصنوعی است.

از نظر تاریخی، حالت شکست هوش مصنوعی در این تست تکان‌دهنده بود: مدل یک بازنویسی کامل ارائه می‌کرد که هرچه پیچیدگی کد بیشتر می‌شد، احتمال اجرای واقعی آن کمتر می‌شد. با این حال، در ۶ تا ۷ ماه گذشته، تغییری رخ داد. Claude تلاش برای بازنویسی کامل را متوقف کرد و شروع به اعمال ویرایش‌های هدفمند و گزینشی کرد. مدل دیگر شبیه دانشجویی نبود که تکلیف را نخوانده است، بلکه شبیه کسی شد که واقعاً می‌فهمد بازسازی کد به چه معناست.

اگرچه خروجی هنوز آماده‌ی تولید (Production-ready) نیست، اما این حرکت به سمت درک معنای واقعی بازسازی، نشان‌دهنده‌ی یک مسیر واقعی در ارتقای توانایی مدل‌ها است.

نتیجه‌گیری‌های نهایی و توصیه‌ها

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

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

برای خواننده، این بدان معناست که ریسک «پذیرش زودگام» همچنان بالا است. توانایی تولید سریع کد اکنون به یک کالا (Commodity) تبدیل شده است، اما توانایی نگهداری از آن کد در طول زمان بدون دچار شدن به «پوسیدگی بافت»، جایی است که نبرد واقعی برای کاربردی شدن هوش مصنوعی در آن پیروز خواهد شد. برای اجتناب از چرخه های تبلیغاتی (Hype Cycle)، توسعه‌دهندگان باید به‌جای اعتماد به توصیفات لینکدین، آزمایش‌های ایزوله خود را اجرا کنند. تنها راه تشخیص اینکه ابزار کجا می‌ماند و کجا فرو می‌پاشد، کاربرد مستقیم و بدبینانه روی مسائل دنیای واقعی است.

منتظر بنچمارک‌های آینده درباره‌ی «پایداری بافت طولانی» (Long-context Stability) و «پایداری وضعیت» (State Persistence) در عامل‌ها باشید، زیرا این‌ها گلوگاه‌های اصلی هستند که مانع تبدیل هوش مصنوعی از یک «شریک نمونه‌سازی» به یک «مهندس تولید» می‌شوند.