تصور کنید در میان هزاران خط کد گم شدهاید و دیگر نمیدانید هر تغییر کوچک چه اثرات زنجیرهای دارد؛ این حسِ ناخوشایند و عمیق از «گم شدن» در یک کدبیس، سالها تنها زنگ خطر واقعی و محرک اصلی برای بازنویسی (Refactoring) سیستمها بود. اما حالا عاملهای هوش مصنوعی (AI Agents) — شبیه دستیاری که میتواند در یک کتابخانه بههمریخته، دقیقاً کتاب مورد نظر شما را پیدا کند بدون اینکه از شلوغی آن اذیت شود — این هشدار درونی را برای مهندسان خاموش کردهاند.
به نقل از تحلیلهای منتشر شده در rosenfeld.page در ۲ سپتامبر ۲۰۲۶، این عاملها با اعتمادبهنفس کامل در محیطهای کثیفی کدنویسی میکنند که هیچ انسانی قادر به درک کامل آنها نیست. در نتیجه، تیمهای توسعه، حتی مهندسان باسابقه که پیش از این میدانستند چه زمانی باید متوقف شوند، بهطور خاموش فشار برای بازنویسی یا ساختاردهی مجدد بخشهای پیچیده و گرهخورده سیستمهایشان را متوقف کردهاند.
محدودیتهای حافظه انسانی
معماری نرمافزار همیشه سازشی با محدودیتهای حافظه کاری انسان بوده است. ظرفیت درک و زمینه (Context) ما کوچک است و همین موضوع شکلدهنده نحوه ساخت نرمافزارهاست. در مقابل، یک کامپیوتر میتواند حجم بسیار بیشتری از دادهها را در «حافظه کاری» خود نگه دارد تا یک انسان. ما نمیتوانیم درباره سیستمی استدلال کنیم که در دهها جهت مختلف شاخه شده است، بهویژه وقتی هر شاخه پیامدهای خاص خود را دارد و همه آنها به هم متصل هستند. این حجم از اطلاعات برای اینکه بهطور همزمان در ذهن ما جای بگیرد، بیش از حد زیاد است.
به همین دلیل، ما به مفاهیمی مثل ماژولار بودن، کپسولهسازی (Encapsulation) و لایهبندی تکیه میکنیم تا سیستمها را به تکههای کوچکی تبدیل کنیم که در ذهن یک نفر جای بگیرد. اینها صرفاً ترجیحات زیباییشناختی یا وسواس در کدنویسی نیستند، بلکه ابزارهای ضروری هستند که به توسعهدهندگان اجازه میدهند تغییرات را بهصورت ایمن بررسی کنند و کدهای همکارانشان را بهطور مؤثر بازبینی نمایند. ما سیستمها را به ماژولهایی تقسیم میکنیم که به اندازه کافی کوچک باشند تا در انزوا قابل درک باشند، و سپس تلاشی را صرف اتصال آنها از طریق رابطهایی (Interfaces) میکنیم که آنها هم قابل درک باشند.
رفلکس بازنویسی (Refactoring)
سیستمها بهندرت در ابتدا آشفته هستند. آنها با قوانین ساده شروع میشوند و در ابتدا کدها خوانا و شفاف هستند. اما با تغییر نیازها، توسعهدهندگان یک شاخه برای یک مورد جدید اضافه میکنند، سپس یکی دیگر برای یک استثنا، و بعد یک مورد خاص روی آن استثنا میسازند. پس از تکرارهای زیاد، «قانون» اصلی که کد بیان میکرد، زیر تپهای از استثنائات دفن میشود. گاهی اوقات نیازها چنان تغییر میکنند که کد دیگر چیزی جز مجموعهای از استثنائات نیست و هیچ قانون شفافی باقی نمانده است.
در دنیای پیش از هوش مصنوعی، لحظهای که یک توسعهدهنده ارشد هنگام عیبیابی (Debugging) گم میشد، متوقف میشد. همان حس سردرگمی یک سیگنال حیاتی بود. یک مهندس باتجربه میگفت: «این کد دیگر غیرقابل مدیریت شده است؛ قبل از اینکه هر چیز دیگری به آن اضافه کنم، باید آن را بازنویسی یا رفرکتور کنم تا دوباره قابل درک شود.» این رفلکس برای رسیدن به زیبایی کد نبود، بلکه برای تضمین این بود که او و هر کسی بعد از او بتواند درباره سیستم استدلال کند و تغییرات آینده را با ایمنی بازبینی کند.
همانطور که در تحلیلهای قبلی ما درباره امنیت مدلهای بازمتن اشاره کردیم، فشار ددلاینها، نقشههای راه (Roadmaps) و مدیرانی که میپرسند «چرا چیزی که کار میکند را بازنویسی میکنی؟» همیشه با این رفلکس در تضاد بوده است. بازنویسی معمولاً اولین چیزی بود که اولویتش کاهش مییافت. عاملهای هوش مصنوعی این ضعف را ایجاد نکردند، اما آخرین محرک درونی را که علیرغم فشارهای مدیریتی فعال میشد، حذف کردند: تجربه عینی و فیزیکیِ گم شدن یک انسان در کد. این موضوع بهویژه برای نسل جدید برنامهنویسان چالشبرانگیز است، چرا که ممکن است دستیارهای کدنویسی مانع از شکلگیری تفکر سیستمی در تازهکاران شوند و آنها را با توهمی از تسلط بر کد مواجه کنند.
نقطه کور عاملمحور
عاملهای هوش مصنوعی محدودیتهای شناختی ما را ندارند. یک عامل میتواند یک تابع درهمتنیده را بخواند، تمام فراخوانها را ردیابی کند و از آشفتگیای سر در بیاورد که یک انسان را کاملاً فلج میکند. او میتواند شاخه بعدی را بهدرستی اضافه کند و بعد از آن را هم همینطور، در حالی که با اعتمادبهنفس کامل در کدی کار میکند که دیگر هیچ انسانی در تیم بهطور کامل آن را نمیفهمد.
این یک پارادوکس خطرناک ایجاد میکند: عامل در کوتاهمدت موفق است، اما هرگز رفلکس «این سیستم غیرقابل مدیریت است» را فعال نمیکند. عامل هیچ سیگنال درونی ندارد که بگوید سیستم باید بازنویسی شود. unless این عامل از طریق یک پرامپت (Prompt) — هنر سؤال درست پرسیدن برای گرفتن بهترین جواب — یا از طریق چارچوب (Harness) یا معیارهای بازبینی صریح مجبور شود که یک قدم به عقب برگردد و ساختار را زیر سؤال ببرد، با خوشحالی یک آشفتگی را تا ابد نگهداری میکند. آشفتگی برای عامل مشکلی ایجاد نمیکند، بنابراین عامل هرگز آن را به عنوان یک مشکل گزارش نمیکند.
فرسایش نظارت انسانی
این تغییر منجر به یک شکست بحرانی میشود که در آن انسانها دیگر نمیتوانند بر سیستمهای خود نظارت کنند. مشکل این نیست که عامل کد بدی مینویسد، بلکه این است که ایستگاه بازرسی طبیعی حذف شده است. خطرات این وضعیت عبارتند از:
- تأییدات صوری (Rubber-Stamp Reviews): بازبینها نمیتوانند منطق را بهاندازه کافی دنبال کنند تا درباره تغییر قضاوت کنند، بنابراین صرفاً به خروجی عامل اعتماد کرده و آن را تأیید میکنند.
- اعتماد معکوس: تیمها دقیقاً به این دلیل به عامل اعتماد میکنند که دیگر کد را نمیفهمند؛ این دقیقاً برعکس نحوه عملکرد اعتماد فنی است که باید بر پایه درک استوار باشد.
- از دست دادن عاملیت: تیم توانایی استدلال درباره سیستم را بدون واسطهٔ هوش مصنوعی از دست میدهد.
این اتفاق بهتدریج رخ میدهد. هیچ لحظه تکاندهندهای وجود ندارد چون زنگ خطر — یعنی گم شدن انسان — بهآرامی از چرخه حذف شده است. در نهایت، هیچ توسعهدهندهای در تیم نمیتواند بهطور کامل درباره بخشهای کلیدی کد استدلال کند.
هزینه اقتصادی کدهای آشفته
نگهداری کدهای سازمانیافته فقط یک مسئله اخلاقی یا اصولی نیست، بلکه یک مسئله اقتصادی است. حتی برای یک عامل هم، کد درهمتنیده گرانتر تمام میشود. عاملی که هرگز گم نمیشود، باز هم بهای این آشفتگی را میپردازد:
- هزینه توکن: هرچه یک قطعه کد درهمتنیدهتر و متصلتر باشد، عامل باید زمینه (Context) بیشتری را بارگذاری کند. این یعنی خواندن فایلهای بیشتر، ردیابی شاخههای بیشتر و سوزاندن توکن (Token) — تکههای کوچکی از متن که مدل میخورد — بیشتر برای هر ویرایش ساده.
- کارایی عملیاتی: سیستمی که از ماژولهای کوچک و مستقل ساخته شده، ارزانتر است چون هر تغییر آینده برای عامل هزینه درک کمتری دارد.
- دقت و توهم: وقتی منطق در یک برش منسجم و محدود جای نمیگیرد، احتمال توهم (Hallucination) — وقتی مدل با اطمینان چیزی میگوید که وجود ندارد — افزایش مییابد. آنها ممکن است رشته افکار را گم کنند، فرض کنند یک شاخه کاری را انجام میدهد که نمیدهد، یا استثنائی را که سه سطح پایینتر دفن شده است، نادیده بگیرند.
مرزهای تمیز، اشتباهات را هم برای انسان و هم برای هوش مصنوعی کاهش میدهد. سازمانیافته نگه داشتن سورسکد، دقت عاملها را بهبود میبخشد و هزینه توکن هر تغییری که در آن کد ایجاد میشود را پایین میآورد.
بازپسگیری ایستگاه بازرسی
برای جلوگیری از این زوال، انسانها باید آگاهانه ایستگاههای بازرسی را بازگردانند. ما باید سؤالاتی بپرسیم که عامل هرگز نمیپرسد:
- آیا من هنوز این بخش از سیستم را میفهمم یا اجازه دادهام عامل بهجای من آن را بفهمد؟
- اگر یک انسان مجبور بود بدون عامل عیبیابی کند، آیا میتوانست مسیر را دنبال کند؟
- آیا نیازها آنقدر تغییر کردهاند که این کد حالا فقط مجموعهای از استثنائات است و هیچ قانون اصلی ندارد؟
- آیا اکنون لحظه توقف توسعه ویژگیهای جدید و بازنویسی این بخش است تا دوباره چیزی شود که یک انسان بتواند در ذهنش جای دهد؟
تیمها میتوانند این بررسیها را در چارچوبهای (Harness) عامل ادغام کنند. مثلاً عامل را پرامپت کنند تا وقتی یک ماژول بیش از حد بزرگ شد یا پیچیدگی شاخهبندی آن از حد معقول گذشت، هشدار دهد؛ بهجای اینکه فقط کد را گسترش دهد، بازنویسی را پیشنهاد کند و اعلام کند که یک تغییر در حال تبدیل شدن به چیزی است که استدلال درباره آن سخت شده است.
با این حال، مسئولیت نهایی بر عهده انسان باقی میماند. راحتیِ داشتن عاملی که هرگز گم نمیشود واقعی است، اما جمله «عامل هنوز میتواند از آن سر در بیاورد» با «سیستم سالم است» یکی نیست. اولی درباره ظرفیت عامل است و دومی درباره ظرفیت ما. مدام بپرسید که آیا زمان بازنویسی فرا رسیده است یا خیر؛ زیرا ابزاری که قبلاً با «گم شدن» به شما یادآوری میکرد، دیگر گم نمیشود.
گام بعدی شما
- در کدبیس خود به دنبال بخشهایی بگردید که در ۶ ماه اخیر فقط توسط AI تغییر کردهاند و سعی کنید بدون کمک مدل، منطق آنها را روی کاغذ رسم کنید.
- در پرامپتهای سیستمی عاملهای خود، دستورالعمل «تحلیل پیچیدگی ساختاری» را اضافه کنید تا مدل بهجای وصله زدن، نیاز به Refactor را گزارش کند.
- جلسات بازبینی کد (Code Review) را به جای تأیید عملکرد، بر روی «قابلیت درک انسانی» متمرکز کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما درباره تراشههای Blackwell مراجعه کنید.
گفتگو