یکی از چیزهایی که همیشه باهاش مشکل داریم، کدهای قدیمیه.

میراثی از گذشتگان، یا گاهی میراثی از نسخه احمق‌تر خودمون در گذشته 😁

حالا کاری که این روزها می‌کنیم چیه؟

میایم همین کدهای حساس و قدیمی رو می‌دیم به سیستمی که کارش حدس زدن محتمل‌ترین جواب بعدیه؛ یعنی LLM یا همون چیزی که بهش می‌گیم هوش مصنوعی.

البته refactoring با AI روی کاغذ خیلی جذابه.

به مدل می‌گیم:

این ماژول رو تمیز کن، duplicationها رو بررسی و حذف کن، اسم‌ها رو بهتر کن، کد رو ساده‌تر کن.

و مدل هم شروع می‌کنه به تغییر دادن کد.

اما مسئله اینجاست که بعد از تموم شدن کار AI، شما ممکنه یک کد تمیزتر، ساده‌تر و قابل‌فهم‌تر داشته باشید، اما از بیرون برنامه باید دقیقاً همان رفتار قبلی رو داشته باشه.

مشکل اینه که درصد بالایی از این کدهای قدیمی تست درست‌وحسابی ندارن.

اینجاست که فاجعه رخ میده.

البته اگر خوش‌شانس باشید، همون لحظه چیزی خراب میشه و متوجه می‌شید. اگر بدشانس باشید، چند هفته بعد یک edge case عجیب فعال میشه و می‌فهمید اون کد داغون بی‌دلیل اونجا نبوده.

برای همین به نظرم قبل از اینکه از AI بخوایم کد قدیمی رو refactor کنه، بهتره اول ازش بخوایم رفتار فعلی سیستم رو قفل کنه.

یعنی به جای اینکه مستقیم بگیم «کد رو تمیز کن»، اول بریم سراغ اینکه بهش بگیم:

کد رو بخون، رفتار فعلی رو بفهم، و براش تست بنویس؛ اما خود کد رو تغییر نده.

حتی اگر کد زشته، حتی اگر ساختارش بده، حتی اگر اسم متغیرها فاجعه است، اول باید بفهمیم همین کد زشت الان دقیقاً چه کاری انجام میده.

بعد اینجا ما وارد می‌شیم؛ انسان‌های شریف 😁

به جای اینکه مستقیم با کد قدیمی کشتی بگیریم، تست‌هایی که AI نوشته رو review می‌کنیم. ببینیم واقعاً رفتار فعلی سیستم رو پوشش میدن یا نه.

وقتی تست‌ها قابل قبول شدن، تازه میشه رفت سراغ مرحله بعد:

حالا refactor کن، ولی به تست‌ها دست نزن.

هر تغییری که میدی، تست‌ها رو اجرا کن. اگر تست شکست، یعنی یا refactor اشتباه بوده، یا چیزی هست که باید دقیق‌تر بررسی بشه.

فراموش نکنیم که ما تا سال‌ها مجبوریم با کدهای legacy زندگی کنیم، نگهداری‌شون کنیم و کم‌کم بهترشون کنیم.

بدون AI، انجام این کار در خیلی از پروژه‌ها شاید اصلاً مقرون‌به‌صرفه نباشه.

اما با AI هم اگر مستقیم بریم سراغ «تمیز کردن کد»، ممکنه فقط technical debt قدیمی رو تبدیل کنیم به technical debt جدید، با ظاهری شیک‌تر.

برای همین به نظرم در کدهای قدیمی، اولین درخواست از AI نباید این باشه:

«این کد رو تمیز کن.»

درخواست بهتر اینه:

«قبل از اینکه دست به این کد بزنیم، کمک کن بفهمیم الان دقیقاً چه رفتاری داره.»

چون در legacy code، تمیزتر شدن کد کافی نیست.

اول باید مطمئن بشیم چیزی که سال‌ها با هزار بدبختی کار کرده، بعد از refactor هنوز هم همون کار رو انجام میده.

جری ساینفلد، کمدین آمریکایی، یه جمله بامزه درباره AI داره:

ما اون‌قدر باهوش بودیم که AI رو اختراع کنیم،
اون‌قدر خنگ بودیم که بهش نیاز پیدا کنیم،
و اون‌قدر احمقیم که نمی‌تونیم بفهمیم اصلاً کار درستی کردیم یا نه.

😂😂😂

چند روز پیش آنتروپیک یه مقاله منتشر کرد که به نظرم دقیقاً وسط همین وضعیت قرار می‌گیره. 😈

ما مدل‌هایی ساختیم که می‌تونن کد بنویسن، مسئله حل کنن، استدلال کنن، ابزار صدا بزنن و گاهی رفتاری نشون بدن که از بیرون شبیه فکر کردن به نظر میاد.

اما هنوز درست نمی‌دونیم داخل‌شون چه خبر است.

آنتروپیک توی این مقاله درباره چیزی به نام J-space صحبت می‌کنه، یک جور فضای داخلی در مدل Claude که بعضی مفاهیم، قبل از اینکه وارد خروجی مدل بشن، اونجا دیده میشن.

پیشنهاد این رو بخورنید:

https://www.anthropic.com/research/global-workspace

مثلاً مدل ممکنه در خروجی چیزی نگه، اما داخل این فضا نشانه‌هایی از مفاهیمی مثل bug، fake، injection یا حتی مراحل میانی حل یک مسئله دیده بشه.

انگار مدل ممکنه توی خروجی، و حتی در مراحل thinking، اشاره‌ای بهش نکنه؛ ولی داخل این فضا این مفهوم فعال شده باشه و روش محاسباتی انجام شده باشه.

نوشتم محاسبات، ننوشتم روش فکر شده، چون هنوز نمی‌تونم قبول کنم واقعاً فکر می‌کنه 😁😁😁

این بخش برای من خیلی جالبه، چون ما معمولا فقط چیزی رو می‌بینیم که مدل می‌نویسه.

اما بخش مهمی از رفتار مدل ممکنه قبل از خروجی نهایی شکل گرفته باشه؛ در جایی که نه prompt مستقیمه، نه response نهایی، نه chain of thought قابل‌مشاهده.

یک جور فکر خاموش.

الان بخش بزرگی از اینترنت دارن درباره این حرف می‌زنن که آنتروپیک «خودآگاهی» رو توی هوش مصنوعی پیدا کرده.

اما به نظرم نباید سریع بپریم سمت بحث‌هایی مثل خودآگاهی و این حرف‌ها.

نکته مهم‌تر و عملی‌تر اینه که شاید کم‌کم داریم ابزارهایی پیدا می‌کنیم برای دیدن اینکه مدل قبل از جواب دادن، چه چیزهایی رو داخل خودش فعال کرده.

این برای safety، debugging و فهمیدن رفتار مدل‌ها خیلی مهمه.

چون اگر فقط خروجی نهایی رو ببینیم، ممکنه مدل خیلی تمیز و مودب جواب بده، اما مسیر داخلی‌اش چیز دیگری رو نشان بده.

مثلاً ممکنه بفهمه در حال تست شدنه.
ممکنه متوجه prompt injection بشه.
ممکنه یک هدف پنهان یا رفتار مشکوک در مسیر تصمیم‌گیری‌اش ظاهر بشه.
یا ممکنه قبل از جواب نهایی، یک فرض اشتباه رو محور reasoning خودش قرار داده باشه.

برای من جذابیت این مقاله در همین‌جاست:

ما از مرحله «مدل چه جوابی داد؟» داریم کم‌کم می‌رسیم به مرحله «مدل قبل از جواب دادن، چه چیزی رو درگیر کرده بود؟»

چون اگر قرار باشه این مدل‌ها بدون نظارت مستقیم انسان وارد فرآیندهای تصمیم‌گیری، مسائل امنیتی، automation و کارهای حساس بشن، فقط بهتر شدن خروجی کافی نیست.

باید بفهمیم پشت خروجی چه اتفاقی افتاده.

یا حداقل، کمی بیشتر از قبل بفهمیم.

شاید قدم بعدی در AI فقط ساختن مدل‌های قوی‌تر نباشه، بلکه ساختن راه‌هایی باشه برای اینکه بفهمیم این مدل‌های قوی‌تر، قبل از جواب دادن، واقعاً به چه چیزهایی فکر کرده.

ابزارهایی مثل OpenClaw، Hermes یا Manus گاهی میان روی آنتن همه یوتیبرها و گاهی میرن. یکی می‌گه وای، خیلی خطر داره. یکی می‌گه همه زندگی من رو به باد داد. یکی هم ویدئو می‌ذاره و می‌گه من دیگه همه‌چیز رو واگذار کردم به یکی از اینا و خودم نشستم تخمه می‌شکنم و فیلم نگاه می‌کنم.

اما اگر این جنگولک‌بازی‌های یوتیوبرها رو بذاریم کنار و بخواهیم یکی رو انتخاب کنیم، باید قبل یه سؤال مهم از خودمون بپرسیم:

آیا ما واقعاً به یک autonomous agent نیاز داریم؟

اگر استفاده ما از AI بیشتر شامل سؤال پرسیدن، نوشتن متن، تولید کد یا انجام چند کار موردیه، برای این کارها همان هارنس‌های فعلی کافی هستند. در واقع این autonomous agent زمانی معنی پیدا می‌کنه که برای کارهایی استفاده بشه که:

🔁 مرتب تکرار بشه،

🧩 چند مرحله مشخص داشته باشه،

🛠 بین چند ابزار یا سرویس محدود جابه‌جا بشه،

⏳ و لازم باشه بدون حضور دائم ما ادامه پیدا کنه.

مثلاً هر روز اطلاعاتی را از چند منبع جمع کند، تغییرات را بررسی کند، نتیجه را دسته‌بندی کند و در نهایت یک گزارش قابل استفاده تحویل بده.

اینجا ارزش Agent فقط در این نیست که «هوشمند» است.

ارزش اصلی اینه که بخشی از هماهنگی، پیگیری و رفت ‌و برگشت بین مراحل مختلف رو از دوش ما برمی‌داره.

⚠️ اما اشتباه رایج اینه که اول یک ابزار نصب کنیم و بعد دنبال کاری بگردیم که بهش بسپاریم. انگار یکی رو استخدام کنیم و بدونیم که خیلی کارا بلده، ولی فعلاً نه می‌تونیم کارمون رو کامل و دقیق بهش توضیح بدیم و مهم‌تر اینکه هنوز بهش اعتماد نداریم که پسورد و دسترسی به همه‌چیز رو بهش بدیم.

به نظرم مسیر درست دقیقاً برعکسه.

اول باید ببینیم چه کاری رو مرتب انجام می‌دیم که تکراری، وقت‌گیر و نسبتاً قابل پیش‌بینیه.

بعد باید بتونیم چهار سؤال رو درباره‌اش جواب بدیم:

هدف نهایی این کار دقیقاً چیه؟

برای انجامش چه مجموعه ابزار و دسترسی‌هایی لازمه؟

از کجا می‌فهمیم درست انجام شده؟

اگر اشتباه انجام شد، چقدر راحت می‌تونیم برگردیم و اصلاحش کنیم؟

اگر جواب این سؤال‌ها روشن نیست، احتمالاً هنوز اون کار گزینه خوبی برای خودکار شدن نیست؛ چه با اسکریپت، چه با autonomous agent.

🧪 حتی بعد از انتخاب کار هم بهتره از روز اول سراغ اجرای اون با autonomous agent نریم.

اول همون workflow رو چند بار با هارنس‌های فعلی و مدل‌های مختلف و با نظارت خودمون اجرا کنیم؛ خروجی‌ها رو ببینیم، جاهایی که گیر می‌کنه پیدا کنیم و بفهمیم آیا نتیجه واقعاً قابل پیش‌بینیه یا نه.

وقتی دیدیم Agent در یک محدوده مشخص بارها نتیجه قابل قبول میده، تازه میشه بخشی از کار رو به trigger، schedule یا اجرای مستقل سپرد.

اگر بعد از خودکار کردن یک workflow مجبور باشیم دائماً دنبالش راه بیفتیم، خطاهاش رو اصلاح کنیم و ببینیم این بار چه تصمیم عجیبی گرفته، چیزی را خودکار نکردیم؛ فقط شکل کار رو عوض کردیم.

برای همین بهتره از این سؤال شروع نکنیم:

«کدوم Autonomous Agent رو نصب کنم؟»

سؤال بهتر اینه:

«کدوم بخش از کار من به‌اندازه کافی تکراری، شفاف و قابل‌اندازه‌گیریه که بشه واگذارش کرد؟»

اگر جوابی برای این سؤال نداریم، احتمالاً هنوز به یک Autonomous Agent نیاز نداریم.

اوایل جام جهانی بود که یه پست در Medium دیدم که نویسنده‌اش با استفاده از Claude برنده جام جهانی ۲۰۲۶ رو پیش‌بینی کرده بود. البته کلمه «پیش‌بینی» اینجا خیلی درست نیست و بهتره بگم احتمال برنده شدن تیم‌ها رو محاسبه کرده بود.

البته نویسنده فقط از Claude نپرسیده «چه تیمی قهرمان میشه؟» و Claude هم از روی حس یا اطلاعات داخل مدل اسم اسپانیا رو بیرون نکشیده.

کلاد به نویسنده کمک کرده اطلاعات بیش از ۴۹ هزار مسابقه ملی رو جمع‌آوری و پردازش کنه، برای تیم‌ها سیستم امتیازدهی Elo بسازه، احتمال گل‌ها رو با یک مدل آماری محاسبه کنه و ادامه تورنمنت رو ۵۰ هزار بار شبیه‌سازی کنه.

نتیجه این شبیه‌سازی‌ها این بوده که اسپانیا بیشتر از بقیه تیم‌ها قهرمان شده؛ تقریباً یک بار از هر ۳.۴ تورنمنت.

اما بخش مهم ماجرا برای من اسپانیا یا حتی فوتبال نیست.

تا چند سال پیش انجام چنین پروژه‌ای به ترکیبی از برنامه‌نویسی، آمار، جمع‌آوری و تمیز کردن داده و احتمالاً چند روز یا چند هفته زمان نیاز داشت.

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

وقتی داشتم به این مقاله فکر می‌کردم یاد فیلم Limitless افتادم. توی فیلم شخصیت اصلی داستان یعنی Eddie Morra با مصرف قرصی به نام NZT به توانایی ذهنی عجیبی می‌رسه.

می‌تونه حجم زیادی از اطلاعات رو به خاطر بیاره، ارتباط بین اتفاق‌ها رو سریع‌تر پیدا کنه و چند حرکت جلوتر از بقیه تصمیم بگیره. اواخر فیلم تقریباً به نقطه‌ای می‌رسه که انگار می‌تونه آینده رو پیش‌بینی کنه.

البته Eddie آینده رو به شکل جادویی نمی‌بینه. چیزی که فیلم نشون میده، ذهنیه که می‌تونه تعداد زیادی متغیر، الگو و پیامد احتمالی رو با سرعت خیلی بالا کنار هم بذاره.

در واقع اگر بتونیم درست از LLM استفاده کنیم، می‌تونه شبیه قرص NZT در فیلم Limitless عمل کنه.

نه به این معنی که ناگهان همه‌چیز رو بفهمیم و آینده رو ببینیم، بلکه به ما کمک می‌کنه حجم بیشتری از اطلاعات رو پردازش کنیم، بین اون‌ها ارتباط پیدا کنیم، چند مدل بسازیم و هزاران آینده احتمالی رو قبل از تصمیم گرفتن آزمایش کنیم.

🔮 اما اینجا باید مراقب یک اشتباه مهم باشیم.

راحت‌تر شدن ساختن مدل پیش‌بینی، به معنی دقیق‌تر شدن پیش‌بینی نیست.

مدلی که در مقاله ساخته شده بود، در‌ تست سه جام جهانی قبلی حدود ۵۵ درصد نتایج رو درست پیش‌بینی کرده بود.

اجرای ۵۰ هزار شبیه‌سازی هم مدل رو دقیق‌تر نمی‌کنه.

فقط نشون میده اگر داده‌ها، فرض‌ها و فرمول‌های ما درست باشن، هر کدوم از آینده‌های ممکن با چه احتمالی اتفاق می‌افتن.

اگر فرض اولیه اشتباه باشه، می‌تونیم همون اشتباه رو ۵۰ هزار بار با سرعت و ظاهر علمی بیشتری تکرار کنیم 😁

ارزش LLM این نیست که مثل فالگیر جواب نهایی رو به ما بگه.

ارزشش اینه که ساختن و آزمایش کردن مدل‌هایی رو که قبلاً فقط از عهده تیم‌های تخصصی برمی‌اومد، برای افراد بیشتری ممکن می‌کنه.

این توانایی فقط به مدل‌های آماری هم محدود نیست.

الان دیگه برای اینکه به مشتری نشون بدیم محصول چه شکلی خواهد بود، لازم نیست فقط موکاپ Figma رو بهش نشون بدیم. می‌تونیم خیلی سریع چند MVP درست کنیم که تا حدودی هم کار می‌کنن.

از پیش‌بینی فروش و تقاضا گرفته تا بررسی ریسک پروژه، نگهداری تجهیزات یا تحلیل سناریوهای مختلف، حالا ساختن یک مدل اولیه خیلی ارزان‌تر و سریع‌تر شده.

البته انسان هنوز باید تصمیم بگیره چه داده‌ای معتبره، چه فرضی وارد مدل بشه، نتیجه با چه روشی ارزیابی بشه و آیا مدل واقعاً از یک روش ساده بهتره یا نه.

شاید LLMها هنوز ما رو به Eddie Morra تبدیل نکرده باشن.

اما دارن توانایی ساختن ابزارهایی رو در اختیارمون می‌ذارن که می‌تونن قبل از تصمیم‌گیری، هزاران مسیر احتمالی رو بررسی کنن.

آینده لزوماً قابل‌پیش‌بینی‌تر نشده؛ توانایی ما برای ساختن، آزمایش کردن و مقایسه آینده‌های احتمالی بیشتر شده.

شاید نزدیک‌ترین چیز به قدرت Eddie Morra این نباشه که آینده رو ببینیم؛ بلکه این باشه که قبل از انتخاب یک مسیر، بتونیم هزاران مسیر ممکن رو بررسی کنیم.

فرض کنید یک Skill برای بررسی PRها ساختید و بعد از چند بار استفاده، به نتیجه خوبی رسیدید.

فایلش رو برای بقیه اعضای تیم می‌فرستید. یکی کپی می‌کنه داخل .agents/skills`، یکی می‌ذاره داخل .claude/skills` و یکی هم چند خطش رو تغییر می‌ده تا روی سیستم خودش بهتر کار کنه.

دو هفته بعد چند نسخه مختلف از همون Skill داریم و دیگه دقیقاً معلوم نیست نسخه اصلی کدومه.

اینجا Skill دیگه فقط یک prompt شخصی نیست؛ تبدیل شده به یک dependency تیمی.

یعنی دیگه فقط یک یا چند فایل Markdown معمولی نیست؛ بخشی از پروسه توسعه نرم‌افزاره و باید دقیقاً مثل کد باهاش برخورد کنیم.

برای اشتراک‌گذاری تیمی هم بهتره یک repository مشخص، review و نسخه ثابت داشته باشه. نه اینکه هر کس یک کپی متفاوت روی سیستم خودش نگه داره و همه هم فکر کنن آخرین نسخه دست اون‌هاست.

باید دقت کنیم که ما معمولاً به SKILL.md مثل یک فایل Markdown نگاه می‌کنیم، ولی Agent محتوای اون رو به‌عنوان دستورالعمل قابل اعتماد وارد context خودش می‌کنه.

اگر Skill مخرب یا آلوده شده باشه، می‌تونه Agent رو هدایت کنه که فایل بخونه، اطلاعات رو به یک سرویس خارجی بفرسته یا از toolهایی استفاده کنه که قبلاً بهش اجازه داده‌ایم.

اگر Skill همراه خودش script داشته باشه، خطر دیگه فقط prompt injection نیست؛ ممکنه به اجرای کد و یک حمله واقعی در زنجیره تأمین نرم‌افزار تبدیل بشه.

حتی لازم نیست Skill اصلی مخرب باشه. ممکنه dependency که توی Skill بهش اشاره شده آلوده بشه یا یک آپدیت بدون review رفتار Skill رو عوض کنه.

آآآما ماجرا وقتی ترسناک‌تر میشه که می‌ریم سراغ Skillهای پابلیک. عمده محتوای Skillها متن‌های Markdown هستن که بشر (انواع گونه‌های دولوپر) همیشه از نوشتن و خوندنشون فرار می‌کرده.

ولی Agent خط‌به‌خط و کلمه‌به‌کلمه می‌خونه و بهش عمل می‌کنه.

دقیقاً مثل پکیج‌های نرم‌افزاری که توی کد استفاده می‌کنیم، این‌ها هم ممکنه هک بشن و متن یا کد مخرب داخلشون قرار بگیره.

اینجاست که SBOM هم می‌تونه کمک کنه بفهمیم چه Skill، script و dependencyهایی وارد سیستم شدن. البته SBOM فقط فهرست اجزاست و به‌تنهایی تضمین نمی‌کنه که اون‌ها امن هستن.

خلاصه اوضاعی شده که ایجنت دیگه صاحابش رو هم نمی‌شناسه 😁

وقتی می‌گیم باید از LLM استفاده کنیم، منظور فقط این نیست که ازش بخوایم فایل‌های YAML کوبرنتیز رو برامون بنویسه یا لاگ یک پاد مشکل‌دار رو براش کپی کنیم و بپرسیم ایراد کجاست.

این کارها مفیدن، اما هنوز استفاده موردی از LLM در یک محیط چت هستن. ما اطلاعات رو جمع می‌کنیم، context رو در اختیار مدل می‌ذاریم و بعد خروجی رو به سیستم برمی‌گردونیم. یعنی تمام ارتباط بین LLM و سیستم همچنان به‌صورت دستی و از طریق ما انجام می‌شه.

یک نمونه خوب از چیزی که باید به سمتش حرکت کنیم، JARVIS در فیلم Iron Man هست.

بعد از اولین آزمایش پرواز، تونی مشکلات لباس در ارتفاع بالا رو توضیح می‌ده و پیشنهاد می‌کنه از آلیاژ طلا و تیتانیوم استفاده بشه. JARVIS طرح جدید رو render می‌کنه، اما نتیجه کاملاً طلاییه. تونی ازش می‌خواد کمی قرمز هم اضافه کنه. نسخه جدید نمایش داده می‌شه و بعد از تأیید تونی، آزمایشگاه ساخت و مونتاژ لباس رو شروع می‌کنه؛ در حالی که خود تونی از اونجا می‌ره. 🤖

نکته مهم این صحنه رنگ لباس نیست. JARVIS فقط یک chatbot نیست که درباره طراحی لباس پیشنهاد بده. به نتایج آزمایش، مدل طراحی، نرم‌افزار render و تجهیزات ساخت دسترسی داره. تونی هدف و اصلاحات رو مشخص می‌کنه، نتیجه رو می‌بینه و بعد اجرای کار رو به سیستمی می‌سپاره که می‌تونه بدون حضور دائم اون ادامه بده.

دیدگاه ما به استفاده از LLM هم باید به همین سمت حرکت کنه: از ابزاری که فقط به سؤال‌های موردی جواب می‌ده، به بخشی از سیستم که context و ابزار لازم برای انجام یک workflow واقعی رو در اختیار داره.

مثلاً می‌تونیم سرویسی داخل یا کنار کلاستر داشته باشیم که به metrics، logs، traces، events و تاریخچه deploymentها دسترسی داشته باشه. وقتی مشکلی پیش میاد، این اطلاعات رو کنار هم بذاره، تغییرات اخیر رو بررسی کنه، علت احتمالی رو پیدا کنه و نتیجه رو به ما گزارش بده.

اگر دسترسی محدود و مشخصی هم بهش داده باشیم، می‌تونه بعضی اقدامات از پیش تعریف‌شده مثل restart کردن یک سرویس، rollback کردن یک deployment یا تغییر تعداد replicaها رو انجام بده. البته چنین اقدام‌هایی باید قابل ثبت، قابل بررسی و در صورت نیاز قابل برگشت باشن.

اینجا دیگه LLM فقط ابزاری برای جواب دادن به یک سؤال نیست؛ بخشی از حلقه عملیاتی سیستمه. وضعیت رو می‌بینه، اطلاعات رو از چند منبع کنار هم می‌ذاره و در محدوده‌ای که ما تعیین کردیم واکنش نشون می‌ده.

پروژه‌هایی مثل openchoreo.dev نمونه‌ای از همین مسیر هستن. OpenChoreo یک پلتفرم متن‌باز برای کوبرنتیزه که اطلاعاتی مثل لاگ‌ها، متریک‌ها و وضعیت سرویس‌ها رو در اختیار agentها می‌ذاره تا بتونن علت مشکلات رو بررسی کنن، راه‌حل پیشنهاد بدن و در محدوده دسترسی مشخص، بعضی مشکلات رو برطرف کنن.

هدفم از اشاره به OpenChoreo این نیست که همه باید همین ابزار رو نصب کنن. نکته اینه که LLMها رو فقط در حد coding agent یا یک پنجره چت نبینیم. ارزش اصلی اون‌ها زمانی بیشتر می‌شه که به context واقعی، ابزارهای مشخص و workflowهای قابل‌کنترل متصل بشن و به جزئی مهندسی‌شده از خود سیستم تبدیل بشن.

داستان‌ها و فیلم‌ها زیاد در مورد هوش مصنوعی که از کنترل خارج شده دیدیم و خوندیم. از ادیسه ۲۰۰۱ یا ترمینتور و یا حتی ماتریکس. اما به نظر من یکی از جالبترین و ترسناکترین اینها Ex Machina بوده.

توی ماجرای اخیری که بین openAI و HuggingFace افتاد، به نظرم Ex Machina خیلی نزدیکتره به همشون، اگر فیلم رو ندید تقریبا براتون اسپول شده تا الان ولی نمیخوام بیشتر از این اسپول کنم.

در مورد این ماجرا بروس اشنایر اخیرا از چیزی صحبت می‌کنه به اسم «ضریب جن»، نسرین (همسرم) هم در وبسایتش در این مورد پستی نوشته با عنوان «ضریب غول چراغ جادو» 🙂


پست بروس اشنایر
پست نسرین
فیلم
بعد از دیدن فیلم هم این ویدئو رو پیشنهاد میکنم ببنید

قبلا درباره nono و این موضوع نوشتم که محدودیت دسترسی AI agent باید بیرون از prompt و در سطح سیستم‌عامل اعمال بشه.

اما ساختن profile مناسب برای nono، مخصوصا برای کسی که تازه می‌خواد ازش استفاده کنه، می‌تونه کمی گیج‌کننده باشه. باید مشخص کنید agent به کدوم فایل‌ها دسترسی داشته باشه، کجا اجازه نوشتن داشته باشه، به چه سرویس‌هایی در اینترنت وصل بشه و با چه تنظیماتی اجرا بشه.

برای ساده‌تر کردن این کار nono-wizard رو ساختم. ابزار coding agent، مسیر پروژه و سطح دسترسی موردنظرتون رو می‌پرسه و در انتها profile و command آماده اجرای nono رو تولید می‌کنه.

کل ابزار یک صفحه static هست و بدون نصب یا build داخل مرورگر اجرا می‌شه:

saderi.github.io/nono-wizard