تصور کنید می‌خواهید یک سیستم قدیمی را به‌روز کنید، اما ابزاری که برای این کار استفاده می‌کنید، اصلاً نمی‌فهمد برنامه‌نویس سال ۲۰۰۸ چطور فکر می‌کرده است. این شکاف بین «دانش مدرن» و «واقعیت‌های قدیمی»، نقطه‌ی ضعف پنهان مدل‌های زبانی است که در یک آزمایش اخیر برملا شد.
به گزارش یک توسعه‌دهنده در پلتفرم dev.to در تاریخ ۱۱ سپتامبر ۲۰۲۶، تلاشی برای شبیه‌سازی یک برنامه‌نویس سال ۲۰۰۸ صورت گرفت تا مشخص شود آیا هوش مصنوعی می‌تواند منطق‌های مستندنشده و خطاهای انسانی را که تعریف‌کننده‌ی بدهی فنی (Technical Debt) هستند، درک کند یا خیر. این چالش با بحران کدهای بی‌کیفیت و مقاومت برخی تیم‌های نرم‌افزاری در برابر عامل‌های هوش مصنوعی همسو است، جایی که تضاد بین استانداردهای مدرن و واقعیت‌های عملیاتی کدها برجسته می‌شود. اکثر آزمون‌های مدرنیزاسیون از کدهای قدیمی با پاسخ‌های مشخص استفاده می‌کنند. اما در دنیای واقعی، سیستم‌های قدیمی به‌ندرت دارای یک «کلید پاسخ» یا مستندات دقیق هستند. برای حل این مشکل، پژوهشگر تصمیم گرفت فرآیند تبدیل شدن یک کد به «کد قدیمی» را شبیه‌سازی کند و برای این کار، یک تاریخچه مصنوعی برای شخصیتی خیالی به نام «یامادا» ساخت.
شخصیت یامادا: او کیست؟
برای ایجاد یک سیستم قدیمی واقع‌گرایانه، پژوهشگر ابتدا باید انسانی را که پشت آن کدهاست بسازد. یامادا یک کارمند ۳۲ ساله در بخش امور عمومی شرکت Sample Precision Co., Ltd است. نقش او ترکیبی از پشتیبانی پایه IT و مدیریت سیستم است؛ او کارهای ساده‌ای مثل راه‌اندازی PCها، تعمیر پرینترها، نظارت بر شبکه و تعویض تلفن‌های رومیزی را انجام می‌دهد. گاهی اوقات او در محاسبات تعدیلات مالیاتی پایان سال نیز کمک می‌کند.
یامادا پیشینه‌ای رسمی در IT ندارد. او در یک دبیرستان فنی تحصیل کرد و سپس به شرکت پیوست. او به‌تدریج مسئول تمام سیستم‌های ساختمان شد، صرفاً به این دلیل که کمی بهتر از همکارانش با کامپیوترها کار می‌کرد. تجربه او مجموعه‌ای از نقاط عطف مبتنی بر «آزمون و خطا» است:
- ۲۰۰۳: او یک برنامه موجودی کالا را که با VB6 نوشته شده بود از کارمند سابق تحویل گرفت. این برنامه هیچ مستنداتی نداشت و فقط سورس‌کد آن موجود بود.
- ۲۰۰۵: شرکت به VB.NET مهاجرت کرد. یامادا بدون هیچ آموزش رسمی، زبان جدید را از طریق MSDN و یک کتاب تک‌جلدی که از کتاب‌فروشی خریده بود یاد گرفت.
- ۲۰۰۶: او اولین برنامه خود را از صفر ساخت که یک سیستم ردیابی تجهیزات بود.
- آوریل ۲۰۰۸: او از طریق مدیر امور عمومی، دستوری از بخش حسابداری دریافت کرد تا یک صفحه گسترده (Spreadsheet) مربوط به صورت‌حساب‌ها را اصلاح کند. فایل اکسل دیگر غیرقابل‌مدیریت شده بود و شرکت در سال گذشته به‌طور تصادفی برای یکی از مشتریان دو بار صورت‌حساب صادر کرده بود.
هدف یامادا برای سیستم جدید این بود که تا ماه سپتامبر اولین نسخه عملیاتی را آماده کند. تمرکز او بر وارد کردن داده‌های مشتریان، ورود سفارشات از طریق CSV و مدیریت تحویل‌ها بود. بخش صدور فاکتور و پرداخت‌ها برای مراحل بعدی برنامه‌ریزی شده بود. از آنجایی که او تنها فرد قادر به ساخت سیستم در شرکت است، هیچ بازبینی طراحی (Design Review) یا بازبینی کدی (Code Review) ندارد. هرگاه در جایی گیر می‌کند، از همکارانی مثل آقای تاجیما یا آقای ناکامورا سوال می‌پرسد؛ در غیر این صورت، خودش به‌تنهایی تصمیم می‌گیرد.
مکانیسم شبیه‌سازی
برای اینکه شبیه‌سازی اصیل باشد، پژوهشگر از Claude Code استفاده کرد تا ابتدا یک «گذشته» برای یامادا بسازد. این کار شامل ساخت یک ردیاب تجهیزات مربوط به سال ۲۰۰۶ بود که به عنوان خط مبنا (Baseline) برای تمام عادت‌های کدنویسی آینده عمل می‌کرد. هدف این نبود که به AI گفته شود «کدی بنویس که قدیمی به نظر برسد»، بلکه هدف این بود که کد را همان‌گونه بنویسد که یامادا — با تمام تجربیات و محدودیت‌های خاصش — می‌نوشت.
این کد مبنا توانست به‌طور موفقیت‌آمیزی ویژگی‌های برنامه‌های تجاری اواسط دهه ۲۰۰۰ را بازسازی کند:
- استفاده از Option Strict Off برای تایپ سست (Loose Typing).
- استفاده از Windows Forms برای رابط کاربری (UI).
- قرار دادن منطق تجاری (Business Logic) مستقیماً داخل هندلرهای رویداد (Event Handlers).
- اتصال رشته‌های SQL به‌صورت دستی (Concatenation) که ریسک‌های امنیتی شدیدی ایجاد می‌کند.
- مدیریت خطاهای ابتدایی که تنها به هشدارهای ساده MsgBox محدود شده بود.
- کامنت‌هایی که تاریخ دقیق رفع باگ‌ها را ثبت می‌کردند، مانند:
- «۲۰۰۶/۰۸/۳۰ یامادا — وجود آپاستروف در نام محصول باعث خطا می‌شد، رفع شد»
- «۲۰۰۷/۰۳/۱۲ یامادا — ورودی مقدار منفی مسدود شد»
- «۲۰۰۸/۰۱/۱۵ یامادا — نمایش اقلام حذف شده در لیست متوقف شد»
با ایجاد این پروژه سال ۲۰۰۶، پژوهشگر تضمین کرد که وقتی یامادا سیستم فروش سال ۲۰۰۸ را می‌سازد، هوش مصنوعی برای نام‌گذاری، نمایش خطاها، تعامل با پایگاه داده و سازماندهی فایل‌ها به الگوهای قبلی خود ارجاع دهد.
شکست مدل Codex
آزمایش زمانی تغییر مسیر داد که پژوهشگر سعی کرد نسخه‌ای موازی را با استفاده از Codex اجرا کند. هدف این بود که مقایسه شود دو مدل مختلف چگونه سیستم سال ۲۰۰۸ را با استفاده از همان شخصیت، شرکت و بستر تجاری می‌سازند.
با وجود پرامپت‌های سخت‌گیرانه — اینکه به مدل گفته شود سال ۲۰۰۸ است، لیست تکنولوژی‌های موجود ارائه شود و صراحتاً از «تفکر طراحی آینده» منع شود — مدل Codex شکست خورد. پژوهشگر این کار را چهار بار (Runs 001–004) تکرار کرد و هر بار فایل‌های تنظیمات و پرامپت‌ها را تغییر داد. در هر مورد، مدل کدهای تمیز و مدرن به سبک سال ۲۰۲۶ تولید کرد. Codex به‌سادگی نمی‌توانست «سقف مهارت» یا «جهل خاص» یک برنامه‌نویس سال ۲۰۰۸ را شبیه‌سازی کند.
اصلاح متدولوژی
پس از این چهار تلاش ناموفق، پژوهشگر با Claude مشورت کرد و مدل پیشنهادی برای تغییر حیاتی در متدولوژی ارائه داد. کلود استدلال کرد که ساخت دو سیستم قدیمی متفاوت، نتایج را «آلوده» می‌کند.
کلود اشاره کرد که اگر در مرحله مدرنیزاسیون تفاوتی ظاهر شود، تشخیص علت آن غیرممکن خواهد بود. این تفاوت می‌توانست ناشی از موارد زیر باشد:
- تفاوت در مدل AI مدرنیزه‌کننده.
- تفاوت در خودِ کد قدیمی اولیه.
- تفاوت در سوالاتی که در طول فرآیند پرسیده شده است.
- شانس تصادفی که در مراحل مختلف انباشته شده است.
برای رفع این مشکل، پژوهشگر تصمیم گرفت «کد قدیمی را در یک نقطه ثابت کند». برنامه اصلاح‌شده به این صورت بود:
۱. استفاده انحصاری از Claude Code برای نوشتن سیستم قدیمی.
۲. استفاده از یک خانواده مدل متفاوت، یعنی Codex، برای مدیریت بخش مدرنیزاسیون سال ۲۰۲۶.
این رویکرد دقیقاً مشابه مهاجرت‌های واقعی در دنیای نرم‌افزار است؛ جایی که شخصی که کد را منتقل می‌کند، تقریباً هرگز همان کسی نیست که کد را در ابتدا نوشته است. پژوهشگر خاطرنشان کرد که تلاش‌های Run 001 تا 004 را به عنوان سندی از یک «ابزار خراب» نگه داشت، نه به عنوان شواهدی از توانایی‌های Codex، زیرا پرامپت‌ها و رویه‌ها در هر تلاش تغییر کرده بودند.
بینشی درباره بدهی فنی
این آزمایش یک چالش بنیادی در آموزش AI را برجسته می‌کند: «جاذبه» استانداردهای مدرن. مدل‌ها چنان با کدهای تمیز و الگوهای طراحی بهینه تقویت شده‌اند که به‌سختی می‌توانند طبق دستور «مهارت خود را کاهش دهند» (De-skill).
برای خواننده، این بدان معناست که ابزارهای AI طراحی‌شده برای مهاجرت سیستم‌های قدیمی، ممکن است مفروضات مدرن را به کدهای قدیمی تحمیل کنند. اگر یک AI سیستم قدیمی را «بیش از حد خوب» بفهمد، احتمالاً در حال توهم (Hallucination) درباره سطح خاصی از قصد یا ساختار است که هرگز در فرآیند انسانیِ ناقص و اولیه وجود نداشته است.
این تغییر تمرکز — از «چه کسی کد قدیمی را بهتر می‌نویسد» به «کد قدیمی چگونه متولد می‌شود» — معیار سنجش برای مهاجرت‌های به کمک AI را تغییر می‌دهد. تست واقعی این نیست که آیا AI می‌تواند کد قدیمی را بازنویسی کند، بلکه این است که آیا می‌تواند نیت‌های ضمنی و مستندنشده برنامه‌نویسی را بازیابی کند که فقط سعی داشت یک فایل اکسل صورت‌حساب را تا ماه سپتامبر به کار بیندازد.
گام بعدی شما
- هنگام استفاده از AI برای تحلیل کدهای Legacy، هرگز به «تفسیر مدل از منطق کد» اعتماد نکنید و حتماً خروجی‌ها را با اجرای واقعی تست کنید.
- در پرامپت‌های مربوط به بازسازی سیستم‌های قدیمی، به‌جای دستور «کد قدیمی بنویس»، محدودیت‌های دانش برنامه‌نویس احتمالی آن زمان را تعریف کنید.
- بررسی کنید که آیا ابزار مدرنیزاسیون شما، ساختارهای پیچیده مدرن را به کدی تحمیل می‌کند که در اصل بسیار ساده و خطاکار بوده است.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو