آینده Coding Agentها؛ حافظه مهم‌تر است یا درک هدف؟
به مناسبت روز برنامه‌نویس، در این خبر تکنولوژی سراغ یکی از موضوعات مهم در مسیر آینده برنامه‌نویسی رفته‌ایم: اینکه Coding Agentها برای عملکرد بهتر واقعاً به چه چیزی نیاز دارند؟
با گسترش ابزارهای هوش مصنوعی که می‌توانند کد بنویسند، باگ‌ها را پیدا کنند، تست ایجاد کنند و حتی بخشی از توسعه یک نرم‌افزار را انجام دهند، یک مشکل مهم بیشتر خودش را نشان می‌دهد: وقتی یک پروژه طولانی می‌شود، AI چطور باید تصمیم‌ها و محدودیت‌هایی را که قبلاً در پروژه تعیین شده‌اند، به یاد بیاورد؟
راه‌حل ظاهراً ساده است؛ تاریخچه بیشتری در اختیار Agent قرار دهیم. اما یک مقاله جدید در Towards Data Science نشان می‌دهد که مسئله اصلی لزوماً کمبود تاریخچه نیست. مشکل این است که Agent باید بفهمد از میان اطلاعات گذشته، چه چیزی هنوز معتبر و مرتبط است.
مشکل تاریخچه طولانی چیست؟
فرض کنید یک برنامه‌نویس در ابتدای پروژه تصمیم گرفته است احراز هویت با JWT انجام شود. چند هفته بعد، تیم تصمیم می‌گیرد این روش را به OAuth۲ تغییر دهد.
حالا اگر Coding Agent فقط تاریخچه مکالمات را جست‌وجو کند، ممکن است هر دو تصمیم را پیدا کند:
JWT
OAuth۲
اما مسئله مهم این نیست که Agent هر دو مورد را پیدا کند؛ مسئله این است که تشخیص دهد کدام تصمیم جدیدتر و معتبر است.
این دقیقاً همان جایی است که مفهوم Intent Continuity مطرح می‌شود؛ یعنی حفظ تداوم هدف، تصمیم و محدودیت‌های پروژه در طول زمان.
در این رویکرد، Agent تنها نمی‌پرسد «در گذشته چه چیزی درباره احراز هویت گفته شده؟»، بلکه باید بپرسد:
«کدام تصمیم هنوز برای این Task معتبر است؟»
از «بازیابی اطلاعات» به «درک تصمیم معتبر»
در بسیاری از سیستم‌های فعلی، برای برگرداندن اطلاعات قبلی از روش‌هایی مثل Search، Keyword Retrieval یا Vector Search استفاده می‌شود.
برای مثال، اگر Task جدید این باشد:
Implement the new authentication flow
سیستم می‌تواند در تاریخچه پروژه به دنبال عبارت‌هایی مثل authentication، JWT یا OAuth۲ بگردد.
اما پیدا کردن چند نتیجه مرتبط، الزاماً به معنی پیدا کردن قانون درست نیست.
ممکن است در تاریخچه پروژه چند تصمیم درباره Authentication وجود داشته باشد؛ یکی مربوط به نسخه قدیمی سیستم و دیگری مربوط به معماری جدید. اگر Agent نتواند تشخیص دهد کدام تصمیم Superseded شده، ممکن است کد جدیدی تولید کند که با معماری فعلی پروژه در تضاد باشد.
به زبان ساده، تفاوت این دو رویکرد چنین است:
Search می‌گوید:
«این اطلاعات به Task مربوط است.»
Intent-aware Retrieval می‌گوید:
«این اطلاعات به Task مربوط است و هنوز باید در تصمیم‌گیری استفاده شود.»
یک آزمایش کوچک، اما جالب
نویسنده برای بررسی این ایده، یک پروژه آزمایشی با ۷۰ تعامل، ۱۲ Requirement و ۸ Task ایجاد کرده است. در این محیط، بخشی از اطلاعات مربوط به نیازمندی‌ها و تصمیم‌های فنی بوده و بخش دیگری عمداً اطلاعات اضافی و غیرمرتبط بوده است.
سه وضعیت با هم مقایسه شدند:
بدون History:
Agent هیچ اطلاعاتی از تصمیم‌های قبلی دریافت نکرد.
Keyword Search:
سیستم به دنبال اطلاعات مرتبط در تاریخچه گشت.
Intent-aware Retrieval:
علاوه بر بازیابی اطلاعات، سیستم بررسی کرد که آیا Requirement پیدا شده هنوز معتبر است یا قبلاً با تصمیم جدیدتری جایگزین شده است.
نتایج قابل توجه بود:
بدون تاریخچه، Agent از هر ۸ Task هیچ‌کدام را درست انجام نداد.
با جست‌وجوی معمولی، ۴ مورد از ۸ Task با موفقیت انجام شد.
اما در حالت Intent-aware، هر ۸ Task از ۸ Task با موفقیت انجام شدند. همچنین Recall نیازمندی‌ها از حدود ۵۷ درصد به ۱۰۰ درصد رسید و تصمیم‌های قدیمیِ نامعتبر به Agent منتقل نشدند.
چرا این موضوع برای برنامه‌نویس‌ها مهم است؟
در پروژه‌های واقعی، کد فقط مجموعه‌ای از Functionها و Classها نیست. پشت هر بخش از Code، معمولاً تصمیم‌هایی وجود دارد:
چرا این Database انتخاب شد؟
چرا این API باید Backward Compatible باشد؟
کدام Field نباید در پاسخ API نمایش داده شود؟
کدام Constraint امنیتی باید همیشه رعایت شود؟
کدام تصمیم معماری دیگر منسوخ شده است؟
برنامه‌نویس انسانی معمولاً این Context را به مرور زمان در ذهن خود نگه می‌دارد. اما Coding Agent باید این Context را از روی Repository، Issueها، Pull Requestها و Conversationهای قبلی استخراج کند.
بنابراین چالش اصلی فقط Context Window بزرگ‌تر نیست.
یک Agent ممکن است هزاران خط History در اختیار داشته باشد، اما اگر نتواند بین یک تصمیم قدیمی و تصمیم جدید تفاوت بگذارد، همین اطلاعات بیشتر می‌تواند نتیجه را بدتر کند.
از نگاه مهندسی نرم‌افزار، مسئله شبیه این است که در یک Codebase چند نسخه از یک Configuration داشته باشید، اما ندانید کدام نسخه Source of Truth است.
یک نکته مهم: هدف، کاهش Token نیست
جالب اینجاست که راهکار پیشنهادی الزاماً باعث کاهش مصرف Token نمی‌شود.
در آزمایش انجام‌شده، سیستم Intent-aware حدود ۱۹۹ Token اطلاعات را در اختیار Agent قرار داد، در حالی که روش جست‌وجوی معمولی حدود ۱۵۵ Token ارائه می‌کرد.
پس مزیت اصلی این روش، کم‌کردن حجم Context نیست؛ بلکه بالا بردن دقت Context است.
یعنی مسئله این نیست که:
«چطور اطلاعات کمتری به AI بدهیم؟»
بلکه سؤال مهم‌تر این است:
«چطور اطلاعات درست و معتبر را در زمان درست به AI بدهیم؟»
آینده Coding Agentها؛ حافظه بیشتر یا Context هوشمندتر؟
این ایده می‌تواند مسیر توسعه Coding Agentها را تا حدی تغییر دهد.
تا امروز، وقتی صحبت از بهتر شدن حافظه AI می‌شود، معمولاً به Long Context، Memory، Vector Database و Retrieval فکر می‌کنیم.
اما مرحله بعدی می‌تواند حرکت از Remembering به سمت Understanding باشد.
یعنی Agent فقط حافظه نداشته باشد؛ بلکه بتواند تاریخچه پروژه را تحلیل کند، تصمیم‌های جدیدتر را تشخیص دهد، Requirementهای منسوخ‌شده را کنار بگذارد و فقط Constraintهایی را وارد Context کند که واقعاً برای Task فعلی اهمیت دارند.
در چنین مدلی، برنامه‌نویس لازم نیست هر بار برای AI توضیح دهد:
«این تصمیم را قبلاً گرفته بودیم.»
«این Rule دیگر معتبر نیست.»
«این API باید Backward Compatible باشد.»
Agent باید بتواند این ارتباط را از تاریخچه پروژه استخراج کند.
جمع‌بندی
Agent باید بتواند بین اطلاعات گذشته و تصمیم فعلی ارتباط برقرار کند؛ بفهمد چه چیزی هنوز معتبر است، چه چیزی منسوخ شده و کدام Requirement باید هنگام تولید کد رعایت شود.
به بیان ساده:
Coding Agent خوب فقط کد قبلی شما را به یاد نمی‌آورد؛ دلیل تصمیم‌های قبلی را دنبال می‌کند.
و شاید این یکی از قدم‌های مهم بعدی در مسیر تبدیل AI از یک Code Generator به یک Software Engineering Agent واقعی باشد.
منبع: Towards Data Science، ۱۱ September ۲۰۲۶. این آزمایش کوچک و کنترل‌شده است و نویسنده نیز تأکید کرده که نتایج آن را نباید به همه Coding Agentهای تولیدی تعمیم داد.
