نشت دانش سازمانی در اثر «سوزاندن توکن» توسط عامل‌های هوش مصنوعی

تصور کنید یک مهندس ارشد ساعت‌ها وقت صرف بررسی تغییرات کدی کند که یک هوش مصنوعی در چند ثانیه نوشته است، اما چون هیچ ردی از «منطقِ» پشت این کد باقی نمانده، باید همه چیز را از صفر بفهمد. این همان نقطه شکست فعلی در بهره‌وری است: ما سرعت تولید کد را بالا برده‌ایم، اما هزینه درک آن را به شدت افزایش داده‌ایم.

به نقل از یک توسعه‌دهنده ارشد در jg.gg، میلیون‌ها توکن (Token) — تکه‌های کوچکی از متن، شبیه برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد — توسط عامل‌های هوش مصنوعی (AI Agents) سوزانده می‌شوند؛ زیرا این عامل‌ها هر بار که یک جلسه (Session) بازنشانی می‌شود، باید تمام بستر سیستم را از ابتدا بسازند. این چرخه باعث ایجاد اثر «خردکننده دانش» (Knowledge Chipper) می‌شود و تضمین می‌کند که بخش اعظم کار شناختی یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — در لحظه ثبت کد (git commit) کاملاً محوشود.

شکاف زمینه (The Context Gap)

امروز، این ناکارآمدی در جریان کاری توسعه‌دهندگان دیده می‌شود. عامل‌ها حجم عظیمی از کارهای مقدماتی انجام می‌دهند: آن‌ها فایل‌ها را اسکن کرده و مستندات API را می‌جویند تا یک مدل ذهنی دقیق و مفصل از سیستم بسازند. با این حال، تمام این تلاش‌های گسترده فقط برای این انجام می‌شود که تعداد نسبتاً کمی از توکن‌های نهایی برای یک تغییر کد تولید گردند.

برخلاف یک انسان که ممکن است یادداشت‌های شخصی بردارد، (تقریباً) تمام این دانش از بین می‌رود. اگرچه برخی توسعه‌دهندگان از مدل می‌خواهند پیام کامیت را بنویسد یا جلسه را روی ماشین خود بازیابی کند، اما این روش‌ها با ثبت کامل و جامع وضعیتی (State) که مدل ساخته است، فرسنگ‌ها فاصله دارند. این وضعیت نشان‌دهنده یک فقدان عظیم در دانش سازمانی، قابلیت بازیابی جلسات و کارایی کلی است. برای مقابله با چنین پیچیدگی‌هایی، برخی رویکردها بر جداسازی مدل‌های کدنویسی برای جلوگیری از توهمات تمرکز کرده‌اند تا دقت عملیاتی افزایش یابد.

مشکل انتقال‌پذیری (The Portability Problem)

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

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

پیامدهای فنی (Technical Implications)

از نظر فنی، ادغام مدل‌های مختلف می‌تواند یک لایه نظارتی یا چک امنیتی ایجاد کند؛ مثلاً این‌که عامل گوگل کد تولیدشده توسط Claude را پیش از ثبت نهایی (Commit) بررسی کند. اما همین روند، حجم اتلاف منابع را برجسته می‌کند. اگر Claude از دسترس خارج شود، یا اگر برنامه‌نویس بخواهد مدل دیگری را روی کدی که قبلاً توسط Claude به شدت روی آن کار شده امتحان کند، باید برای n-امین بار توکن‌ها را در «آتش توکن‌ها» بسوزاند.

پیامدهای این وضعیت در فرآیند بازبینی کد (Code Review) مشهودتر است. نویسنده به تحلیل‌های Philip (عضو سابق OpenAI) اشاره می‌کند که درباره شکاف بین سرعت هوش مصنوعی و توانایی‌های بازبینی انسانی است. اکنون این امکان وجود دارد که تغییراتی در کد ارائه شود که چنان ظریف، پیچیده و حجیم هستند که بازبینی دستی آن‌ها تقریباً غیرممکن است.

جزئیات: گلوگاه‌های حیاتی (Critical Bottlenecks)

در حال حاضر، صنعت با چندین گلوگاه حیاتی مواجه است:

• گسستگی زمینه (Context Disconnection): یک برنامه‌نویس تازه‌کار ممکن است حجم زیادی از منطق‌های جدید حریم خصوصی را با روش Vibe Coding — یعنی کدنویسی بر اساس حس و حال کلی بدون دقت به ساختار دقیق — بنویسد. چون بستر (Context) این تصمیمات روی ماشین او باقی می‌ماند، بازبین ارشد فقط کد نهایی و یک پیام کوتاه کامیت را دریافت می‌کند.
• آتش توکن‌ها (The Token Fire): برای درک تغییری که تولیدش ۲۵۰ هزار توکن هزینه داشته، بازبین ممکن است مجبور شود ده‌ها هزار توکن دیگر صرف کند تا فقط پنجره زمینه (Context Window) — میزان متنی که مدل هم‌زمان «در ذهن» نگه می‌دارد، شبیه میز کاری که جا برای چند ورق دارد — را دوباره بارگذاری کند.
• آسیب جعبه‌های سیاه (Black-Box Damage): ابزارهای اختصاصی عامل‌ها به عنوان جعبه‌های سیاه عمل می‌کنند که مانع انتقال وضعیت (State) بین تامین‌کنندگان مختلف هوش مصنوعی می‌شوند. این امر «انتقال‌پذیری LLM» را به یک ضرورت تبدیل می‌کند، نه یک مفهوم ایده‌آل.
• خستگی بازبین (Reviewer Fatigue): مهندس ارشدی که لایه حریم خصوصی را می‌شناسد، باید بدون هیچ زمینه‌ای در توده‌ای از کدها جست‌وجو کند، در حالی که قادر نیست جلسه‌ای را که هرگز شروع نکرده، ادامه دهد.

این تغییر باعث می‌شود هر Pull Request به بسته‌ای از پیچیدگی‌های تازه تولیدشده (که مستند نشده یا نیمه‌مستند است) تبدیل شود. بهره‌وری حاصل از استفاده از یک عامل برای نوشتن کد، به‌دلیل بار شناختی شدیدی که بر دوش بازبین انسانی برای مهندسی معکوس منطق داخلی گمشده‌ی عامل می‌افتد، تا حد زیادی خنثی می‌شود.

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

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

گام بعدی شما

• شروع به حسابرسی میزان بستری (Context) کنید که در هر جلسه دور ریخته می‌شود.
• به‌دنبال استانداردهای جدید برای «فایل‌های وضعیت قابل انتقال» باشید تا مدل‌های ذهنی بین مدل‌ها یا انسان‌ها جابه‌جا شوند.
• فرآیند بازبینی کد را با الزام به ثبت «منطق تصمیم‌گیری عامل» به‌روز کنید.

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