هدف این کانال فقط معرفی مدلهای جدید LLM یا ابزارهای مرتبط با آنها نیست.
تلاش من این است که صرفاً کپیکننده نباشم؛ یعنی هر چیزی را که ترند شد یا احتمالاً کلیک میخورد، بدون فکر اینجا بازنشر نکنم.
ممکن است درباره یک مدل LLM مطلب منتشر کنم، یک ابزار کاربردی را معرفی کنم، یا حتی سراغ کتاب، فیلم یا داستانی بروم که به نوعی با این موضوعات مرتبط است.
هدف اصلی این کانال این است که با هم درک بهتری از هوش مصنوعی و مدلهای زبانی پیدا کنیم؛ فناوریای که هنوز در ابتدای مسیر خود قرار دارد و قرار است بخش مهمی از آینده ما را شکل دهد.
امیدوارم بتوانیم با شناخت بهتر این فضا، سریعتر و آگاهانهتر خودمان را با آن تطبیق دهیم.
———
اگر شما هم بیشتر از هیجان خبرها، به فهمیدن پشت ماجرا علاقه دارید، خوش آمدید 🚀👍✌️
تلاش من این است که صرفاً کپیکننده نباشم؛ یعنی هر چیزی را که ترند شد یا احتمالاً کلیک میخورد، بدون فکر اینجا بازنشر نکنم.
ممکن است درباره یک مدل LLM مطلب منتشر کنم، یک ابزار کاربردی را معرفی کنم، یا حتی سراغ کتاب، فیلم یا داستانی بروم که به نوعی با این موضوعات مرتبط است.
هدف اصلی این کانال این است که با هم درک بهتری از هوش مصنوعی و مدلهای زبانی پیدا کنیم؛ فناوریای که هنوز در ابتدای مسیر خود قرار دارد و قرار است بخش مهمی از آینده ما را شکل دهد.
امیدوارم بتوانیم با شناخت بهتر این فضا، سریعتر و آگاهانهتر خودمان را با آن تطبیق دهیم.
———
اگر شما هم بیشتر از هیجان خبرها، به فهمیدن پشت ماجرا علاقه دارید، خوش آمدید 🚀👍✌️
❤9
بیشتر افراد میگویند: «من از Cursor AI استفاده میکنم» یا «دارم یک AI Agent میسازم.»
اما اینها لایههای متفاوتی از یک فناوری هستند:
🤖 ایجنتها (Agents) ← جریانهای کاری ساختهشده از پرامپتها، ابزارها، مجوزها و مدلها
🛠 هارنسها (Harnesses) ← Cursor، Copilot، Claude Code، OpenCode
🌐 ارائهدهندگان (Providers) ← OpenAI، Anthropic، Google، OpenRouter، Bedrock
🧠 مدلها (Models) ← GPT، Claude، Gemini، DeepSeek
در تصویر بالا:
🔴 فلش قرمز = وابستگی به یک ارائهدهنده خاص
🟢 فلش سبز = امکان انتخاب ارائهدهنده یا مدل
درک تفاوت این لایهها باعث میشود ارزیابی، طراحی و مقایسه سیستمهای هوش مصنوعی بسیار شفافتر و دقیقتر شود.
به هر چیزی «AI Agent» نگیم، اول مشخص کنیم دقیقاً درباره کدام لایه صحبت میکنیم.
اما اینها لایههای متفاوتی از یک فناوری هستند:
🤖 ایجنتها (Agents) ← جریانهای کاری ساختهشده از پرامپتها، ابزارها، مجوزها و مدلها
🛠 هارنسها (Harnesses) ← Cursor، Copilot، Claude Code، OpenCode
🌐 ارائهدهندگان (Providers) ← OpenAI، Anthropic، Google، OpenRouter، Bedrock
🧠 مدلها (Models) ← GPT، Claude، Gemini، DeepSeek
در تصویر بالا:
🔴 فلش قرمز = وابستگی به یک ارائهدهنده خاص
🟢 فلش سبز = امکان انتخاب ارائهدهنده یا مدل
درک تفاوت این لایهها باعث میشود ارزیابی، طراحی و مقایسه سیستمهای هوش مصنوعی بسیار شفافتر و دقیقتر شود.
به هر چیزی «AI Agent» نگیم، اول مشخص کنیم دقیقاً درباره کدام لایه صحبت میکنیم.
👌4❤3
🧠 بیشتر LLMهایی که امروز با آنها کار میکنیم یک ویژگی مشترک دارند: تلاش برای «کامل بودن».
💬 حتی اگر یک سؤال کوتاه بپرسید، معمولاً سعی میکنند پاسخی جامع، مفصل و پوششدهنده تمام جوانب ارائه دهند. برای یک Bash Script ساده هم اغلب کدی دریافت میکنید که از چیزی که واقعاً نیاز دارید طولانیتر و پیچیدهتر است.
⚖️ این رفتار همیشه بد نیست، اما گاهی برای تحلیل، دیباگ یا تصمیمگیری سریع فقط به یک پاسخ کوتاه و مستقیم نیاز داریم.
✍️ در چنین مواقعی میتوانید از این پرامپت استفاده کنید یا آن را در فایلهای AGENTS.md و CLAUDE.md قرار دهید:
🚀 این دستور مدل را ترغیب میکند به جای کاملترین پاسخ ممکن، روی کوتاهترین پاسخ مفید تمرکز کند.
📚 Credit: Matt Pocock
💬 حتی اگر یک سؤال کوتاه بپرسید، معمولاً سعی میکنند پاسخی جامع، مفصل و پوششدهنده تمام جوانب ارائه دهند. برای یک Bash Script ساده هم اغلب کدی دریافت میکنید که از چیزی که واقعاً نیاز دارید طولانیتر و پیچیدهتر است.
⚖️ این رفتار همیشه بد نیست، اما گاهی برای تحلیل، دیباگ یا تصمیمگیری سریع فقط به یک پاسخ کوتاه و مستقیم نیاز داریم.
✍️ در چنین مواقعی میتوانید از این پرامپت استفاده کنید یا آن را در فایلهای AGENTS.md و CLAUDE.md قرار دهید:
When reporting information to me, be extremely concise and sacrifice grammar for the sake of concision
🚀 این دستور مدل را ترغیب میکند به جای کاملترین پاسخ ممکن، روی کوتاهترین پاسخ مفید تمرکز کند.
📚 Credit: Matt Pocock
👌3❤2
⚔️ در اکوسیستم LLMها هم مثل بسیاری از حوزههای نرمافزار، به نظر میرسد دو جبهه وجود دارد: Open Source و Closed Source.
🚨 جالب است که بخش قابل توجهی از هشدارها درباره خطرات AI، رگولیشن و محدود کردن دسترسی عمومی، از سمت شرکتهایی مطرح میشود که مدلهایشان را بهصورت بسته توسعه میدهند.
📜 این داستان هم جدید نیست. سال ۲۰۱۹، OpenAI انتشار کامل GPT-2 را به دلیل «خطرات بالقوه سوءاستفاده» به تعویق انداخت. امروز هم روایتهای مشابهی را در قالب AGI، سناریوهای آخرالزمانی و ماجراهایی مثل Mythos و Fable میبینیم.
🌏 در مقابل، شرکتهایی مثل Qwen و Kimi مدلهای قدرتمند خود را منتشر میکنند و بخش بزرگی از این جریان نیز خارج از آمریکا شکل گرفته است.
❓سؤال اینجاست:
آیا نگرانیهای ایمنی واقعاً دغدغه اصلی هستند، یا «ایمنی» گاهی به ابزاری برای حفظ مزیت رقابتی تبدیل میشود؟
🔓 بهخصوص وقتی مدلهای متنباز این امکان را میدهند که افراد و سازمانها بدون وابستگی به ارائهدهندگان بزرگ، مدلها را روی زیرساخت خود اجرا کنند.
🚨 جالب است که بخش قابل توجهی از هشدارها درباره خطرات AI، رگولیشن و محدود کردن دسترسی عمومی، از سمت شرکتهایی مطرح میشود که مدلهایشان را بهصورت بسته توسعه میدهند.
📜 این داستان هم جدید نیست. سال ۲۰۱۹، OpenAI انتشار کامل GPT-2 را به دلیل «خطرات بالقوه سوءاستفاده» به تعویق انداخت. امروز هم روایتهای مشابهی را در قالب AGI، سناریوهای آخرالزمانی و ماجراهایی مثل Mythos و Fable میبینیم.
🌏 در مقابل، شرکتهایی مثل Qwen و Kimi مدلهای قدرتمند خود را منتشر میکنند و بخش بزرگی از این جریان نیز خارج از آمریکا شکل گرفته است.
❓سؤال اینجاست:
آیا نگرانیهای ایمنی واقعاً دغدغه اصلی هستند، یا «ایمنی» گاهی به ابزاری برای حفظ مزیت رقابتی تبدیل میشود؟
🔓 بهخصوص وقتی مدلهای متنباز این امکان را میدهند که افراد و سازمانها بدون وابستگی به ارائهدهندگان بزرگ، مدلها را روی زیرساخت خود اجرا کنند.
👍4❤3👏1👌1
⚠️ در ادامه پست قبلی، چند روز پیش استاد اعظم «بروس اشنایر» مقالهای منتشر کرده که امروز فرصت کردم بخوانمش.
مطالعهاش را به شدید توصیه میکنم.
https://www.schneier.com/blog/archives/2026/06/anthropics-fable-and-the-state-of-ai.html
مطالعهاش را به شدید توصیه میکنم.
https://www.schneier.com/blog/archives/2026/06/anthropics-fable-and-the-state-of-ai.html
Schneier on Security
Anthropic's Fable and the State of AI - Schneier on Security
On June 9th, Anthropic released its Fable generative AI model. Three days later, the US government classified it as a dangerous munition, and used its export-control authority to prohibit any foreign nationals from accessing it. Unable to differentiate between…
👌3🥰1
دنیای فیلمها و داستانهای علمیتخیلی معمولاً نگاه تاریکی به هوش مصنوعی دارد، از Skynet گرفته تا انواع سناریوهای آخرالزمانی
اما یک استثنای بزرگ وجود دارد: ایزاک آسیموف.
آسیموف نهفقط خالق «سه قانون رباتیک» بود، بلکه دهها داستان و رمان درباره رابطه انسان و ربات نوشت، داستانهایی که برخلاف جریان غالب، صرفاً بر پایه ترس از هوش مصنوعی ساخته نشدهاند.
البته آسیموف هم مثل خیلی از نویسندههای علمیتخیلی، برای پیش بردن داستان معمولاً به رباتها ظاهر و رفتار انسانگونه میداد. اما اگر پوسته داستان را کنار بزنیم، با سؤالها و چالشهایی روبهرو میشوید که شباهت عجیبی به بحثهای امروز AI دارند.
یکی از داستانهای مجموعه «روبات کامل» به نام Galley Slave دقیقاً از همین جنس است. داستانی که موقع خواندنش گاهی حس میکنید آسیموف چند دهه قبل نشسته و درباره روزگار ما نوشته است.
ترجمه فارسی «روبات کامل» توسط کتابسرای تندیس در سه جلد منتشر شده و این داستان با نام «جان کَن» در جلد دوم قرار دارد.
اگر هم حوصله خواندن ندارید، نریشن انگلیسی داستان را میتوانید از لینک زیر گوش کنید:
https://www.youtube.com/watch?v=C8e_0c8nbFA
اما یک استثنای بزرگ وجود دارد: ایزاک آسیموف.
آسیموف نهفقط خالق «سه قانون رباتیک» بود، بلکه دهها داستان و رمان درباره رابطه انسان و ربات نوشت، داستانهایی که برخلاف جریان غالب، صرفاً بر پایه ترس از هوش مصنوعی ساخته نشدهاند.
البته آسیموف هم مثل خیلی از نویسندههای علمیتخیلی، برای پیش بردن داستان معمولاً به رباتها ظاهر و رفتار انسانگونه میداد. اما اگر پوسته داستان را کنار بزنیم، با سؤالها و چالشهایی روبهرو میشوید که شباهت عجیبی به بحثهای امروز AI دارند.
یکی از داستانهای مجموعه «روبات کامل» به نام Galley Slave دقیقاً از همین جنس است. داستانی که موقع خواندنش گاهی حس میکنید آسیموف چند دهه قبل نشسته و درباره روزگار ما نوشته است.
ترجمه فارسی «روبات کامل» توسط کتابسرای تندیس در سه جلد منتشر شده و این داستان با نام «جان کَن» در جلد دوم قرار دارد.
اگر هم حوصله خواندن ندارید، نریشن انگلیسی داستان را میتوانید از لینک زیر گوش کنید:
https://www.youtube.com/watch?v=C8e_0c8nbFA
👍5❤2🔥1🥰1👏1
🛠 بین دهها «Code Harness» مختلف، تا الان فرصت کار با اینها رو داشتم:
* GitHub Copilot
* OpenCode
* Pi
* Kiro CLI
* Claude Code
🚀 شروع کار من هم مثل خیلیها با GitHub Copilot بود، اما کمکم به سمت ابزارهای ترمینالمحور و مستقلتر رفتم.
⚙️ فعلاً OpenCode هارنس پیشفرض منه، ولی کمکم دارم به مهاجرت به Pi فکر میکنم. از نظر تجربه کار در ترمینال و فلسفه طراحی، Pi به چیزی که از ابزارهای لینوکسی انتظار دارم نزدیکتره. حسی که دارم اینه که OpenCode بیشتر با ذهنیت کاربران macOS طراحی شده.
🔓 هم OpenCode و هم Pi متنباز هستند؛ بنابراین میتوانید دقیقاً ببینید هارنس چطور کار میکنه، System Prompt هارنس چیه و چه ابزارهایی در اختیار مدل قرار میده. اگر هم خواستید، بهراحتی میتوانید رفتارش را تغییر بدید.
🔒 از طرف دیگر، به نظر میرسه اکوسیستم Anthropic روزبهروز بستهتر میشه. Claude Code عملاً شما را به مدلهای خودش محدود کرده و به نظر میرسه تمرکز شرکت بیشتر روی هدایت کاربران به سمت اکوسیستم خودش باشه. حتی بعضی وقتها این حس رو دارم که تمام تلاششون اینه که هزینه استفاده از مدلها برای افراد خارج از اکوسیستم Claude Code بالاتر باشه.
⚠️ همانطور که در مقاله اخیر بروس اشنایر هم مطرح شده بود، ممکنه بشه با یک هارنس خوب از یک مدل بیشتر از چیزی که روی کاغذ نشون میده کار کشید.
🐧 فعلاً هنوز اول راه هستیم. یک زمانی که توی لینوکس تازهکار بودیم هر هفته توزیع عوض میکردیم؛ این روزها هم هر هفته یک هارنس جدید را امتحان میکنیم.
* GitHub Copilot
* OpenCode
* Pi
* Kiro CLI
* Claude Code
🚀 شروع کار من هم مثل خیلیها با GitHub Copilot بود، اما کمکم به سمت ابزارهای ترمینالمحور و مستقلتر رفتم.
⚙️ فعلاً OpenCode هارنس پیشفرض منه، ولی کمکم دارم به مهاجرت به Pi فکر میکنم. از نظر تجربه کار در ترمینال و فلسفه طراحی، Pi به چیزی که از ابزارهای لینوکسی انتظار دارم نزدیکتره. حسی که دارم اینه که OpenCode بیشتر با ذهنیت کاربران macOS طراحی شده.
🔓 هم OpenCode و هم Pi متنباز هستند؛ بنابراین میتوانید دقیقاً ببینید هارنس چطور کار میکنه، System Prompt هارنس چیه و چه ابزارهایی در اختیار مدل قرار میده. اگر هم خواستید، بهراحتی میتوانید رفتارش را تغییر بدید.
🔒 از طرف دیگر، به نظر میرسه اکوسیستم Anthropic روزبهروز بستهتر میشه. Claude Code عملاً شما را به مدلهای خودش محدود کرده و به نظر میرسه تمرکز شرکت بیشتر روی هدایت کاربران به سمت اکوسیستم خودش باشه. حتی بعضی وقتها این حس رو دارم که تمام تلاششون اینه که هزینه استفاده از مدلها برای افراد خارج از اکوسیستم Claude Code بالاتر باشه.
⚠️ همانطور که در مقاله اخیر بروس اشنایر هم مطرح شده بود، ممکنه بشه با یک هارنس خوب از یک مدل بیشتر از چیزی که روی کاغذ نشون میده کار کشید.
🐧 فعلاً هنوز اول راه هستیم. یک زمانی که توی لینوکس تازهکار بودیم هر هفته توزیع عوض میکردیم؛ این روزها هم هر هفته یک هارنس جدید را امتحان میکنیم.
👍2🔥2❤1
🔒 یکم بیشتر توضیح بدم که چرا «حس» میکنم اکوسیستم Anthropic روزبهروز بستهتر میشه.
قبلاً Anthropic اجازه میداد از اشتراک Claude در هارنسهای دیگر هم استفاده کنید. اما بعد از موفقیت ابزارهای دیگه، این امکان حذف شد و عملاً برای استفاده خارج از اکوسیستم Claude باید سراغ API میرفتید؛ روشی که معمولاً هزینه بسیار بیشتری نسبت به اشتراک عادی دارد.
بعدها حتی بسیاری از اپلیکیشنهایی که روی اشتراک Claude حساب کرده بودند هم مجبور شدند به API مهاجرت کنند. برای بعضی استارتاپها این فقط یک تغییر فنی نبود، بلکه مستقیماً روی هزینهها و مدل کسبوکارشان اثر گذاشت.
نکته دیگر این است که Claude Code متنباز نیست. وقتی بخشی از سورس آن به اشتباه منتشر شد، مشخص شد بخشهایی از پیادهسازی فاصله زیادی با تصویری دارد که معمولاً از آن ارائه میشود. از آنجایی که سورس بسته است، عملاً امکان بررسی مستقل رفتار هارنس هم وجود ندارد.
یک نکته دیگه که بهشدت رو اعصابه اینه که تقریباً اکثر هارنسها روی فایل AGENTS.md به یک توافق نانوشته رسیدهاند، اما Claude Code مسیر خودش را رفته و از CLAUDE.md استفاده میکند.
ممکن است بگن که Codex هم متنباز نیست، که درسته. اما تفاوتش برای من اینجاست که اگر از Codex استفاده نکنم (که نمیکنم)، همچنان میتوانم با همان هزینه معمول به مدلهای OpenAI دسترسی داشته باشم. در اکوسیستم Anthropic این انتخاب روزبهروز محدودتر به نظر میرسد.
در نهایت، چیزی که من را نگران میکند خود بسته بودن سورس نیست؛ بلکه این ساختار بسته اکوسیستم است که ممکنه بعد از مدتی با روشهای مختلف سعی کنه ما را به استفاده از ابزارهای خودش سوق بده.
قبلاً Anthropic اجازه میداد از اشتراک Claude در هارنسهای دیگر هم استفاده کنید. اما بعد از موفقیت ابزارهای دیگه، این امکان حذف شد و عملاً برای استفاده خارج از اکوسیستم Claude باید سراغ API میرفتید؛ روشی که معمولاً هزینه بسیار بیشتری نسبت به اشتراک عادی دارد.
بعدها حتی بسیاری از اپلیکیشنهایی که روی اشتراک Claude حساب کرده بودند هم مجبور شدند به API مهاجرت کنند. برای بعضی استارتاپها این فقط یک تغییر فنی نبود، بلکه مستقیماً روی هزینهها و مدل کسبوکارشان اثر گذاشت.
نکته دیگر این است که Claude Code متنباز نیست. وقتی بخشی از سورس آن به اشتباه منتشر شد، مشخص شد بخشهایی از پیادهسازی فاصله زیادی با تصویری دارد که معمولاً از آن ارائه میشود. از آنجایی که سورس بسته است، عملاً امکان بررسی مستقل رفتار هارنس هم وجود ندارد.
یک نکته دیگه که بهشدت رو اعصابه اینه که تقریباً اکثر هارنسها روی فایل AGENTS.md به یک توافق نانوشته رسیدهاند، اما Claude Code مسیر خودش را رفته و از CLAUDE.md استفاده میکند.
ممکن است بگن که Codex هم متنباز نیست، که درسته. اما تفاوتش برای من اینجاست که اگر از Codex استفاده نکنم (که نمیکنم)، همچنان میتوانم با همان هزینه معمول به مدلهای OpenAI دسترسی داشته باشم. در اکوسیستم Anthropic این انتخاب روزبهروز محدودتر به نظر میرسد.
در نهایت، چیزی که من را نگران میکند خود بسته بودن سورس نیست؛ بلکه این ساختار بسته اکوسیستم است که ممکنه بعد از مدتی با روشهای مختلف سعی کنه ما را به استفاده از ابزارهای خودش سوق بده.
👌2🔥1
🌐 تقریباً هر زمان که بخوام با یک مدل درباره موضوعات فنی صحبت کنم، سراغ انگلیسی میرم. اوایل این کار رو برای گرفتن جواب بهتر انجام میدادم و البته توضیح دادن موضوعات فنی به انگلیسی هم راحتتر بود. بعد کمکم تبدیل به عادت شد و رفتم ببینم این عادت درست هست یا نه که به چند چیز جالب رسیدم.
اول از همه اینکه تقریباً تمام مدلهای بزرگ روی حجم عظیمی از محتوای انگلیسی آموزش دیدهاند و بخش بزرگی از مستندات، کدها، مقالات و بحثهای فنی اینترنت هم به زبان انگلیسی هستند.
از اون مهمتر، تقریباً توی همه هارنسها System Prompt و پرامپتهای داخلی به زبان انگلیسی نوشته شده. یعنی شما از همون لحظه اول دارید با سیستمی کار میکنید که تقریباً همه اجزاش حول زبان انگلیسی ساخته شدهاند.
یه نکته دیگه هم اینه که مدلها کلمات رو «درک» نمیکنن. متن تبدیل به توکن میشه و تمام پردازش پشت صحنه روی همین توکنها انجام میشه. طبیعتاً هر زبانی که توی دادههای آموزشی، فرایند آموزش و ارزیابی مدل حضور پررنگتری داشته باشه، معمولاً خروجی بهتری هم میده.
از اون طرف، بخش بزرگی از Safety Training، Preference Tuning و حتی Benchmark Testing مدلها هم به زبان انگلیسی انجام میشه. برای همین خیلی عجیب نیست که مدلها توی خیلی از کارهای فنی روی انگلیسی عملکرد بهتری داشته باشن.
این به این معنی نیست که مدلها فارسی بلد نیستن؛ اتفاقاً فارسیشون هر روز بهتر میشه. اما وقتی پای بحثهای فنی وسط باشه، هنوز هم انگار زبان مادریشون انگلیسیه 😁
اول از همه اینکه تقریباً تمام مدلهای بزرگ روی حجم عظیمی از محتوای انگلیسی آموزش دیدهاند و بخش بزرگی از مستندات، کدها، مقالات و بحثهای فنی اینترنت هم به زبان انگلیسی هستند.
از اون مهمتر، تقریباً توی همه هارنسها System Prompt و پرامپتهای داخلی به زبان انگلیسی نوشته شده. یعنی شما از همون لحظه اول دارید با سیستمی کار میکنید که تقریباً همه اجزاش حول زبان انگلیسی ساخته شدهاند.
یه نکته دیگه هم اینه که مدلها کلمات رو «درک» نمیکنن. متن تبدیل به توکن میشه و تمام پردازش پشت صحنه روی همین توکنها انجام میشه. طبیعتاً هر زبانی که توی دادههای آموزشی، فرایند آموزش و ارزیابی مدل حضور پررنگتری داشته باشه، معمولاً خروجی بهتری هم میده.
از اون طرف، بخش بزرگی از Safety Training، Preference Tuning و حتی Benchmark Testing مدلها هم به زبان انگلیسی انجام میشه. برای همین خیلی عجیب نیست که مدلها توی خیلی از کارهای فنی روی انگلیسی عملکرد بهتری داشته باشن.
این به این معنی نیست که مدلها فارسی بلد نیستن؛ اتفاقاً فارسیشون هر روز بهتر میشه. اما وقتی پای بحثهای فنی وسط باشه، هنوز هم انگار زبان مادریشون انگلیسیه 😁
👍4🥰1👌1
AGENTS.md
1.5 KB
📝 در ادامه پست قبلی، یه نکته رو هم بگم:
با وجود اینکه معمولاً برای کارهای فنی با مدلها انگلیسی حرف میزنم، انگلیسی من اصلاً در حدی نیست که ادعا کنم بدون اشتباه مینویسم. مخصوصاً وقتی پرامپت طولانی میشه یا میخوام یه مسئله پیچیده رو توضیح بدم.
برای همین یه Agent جدا دارم که هیچ کار خاصی نمیکنه، نه کد مینویسه، نه تحلیل میکنه و نه جواب فنی میده. تنها وظیفهاش اینه که متن رو از نظر گرامری و املایی بررسی کنه و نسخه تمیزتری تحویل بده.
معمولاً پرامپتهای طولانی رو اول به اون Agent میدم، بعد خروجی اصلاحشده رو به Agent اصلی میدم که قراره کار فنی انجام بده. اینطوری احتمال اینکه به خاطر انگلیسی افتضاح من موضوع رو اشتباه متوجه بشه کمتر میشه.
فایل AGENTS.md که برای این Agent استفاده میکنم رو هم اینجا میذارم.
با وجود اینکه معمولاً برای کارهای فنی با مدلها انگلیسی حرف میزنم، انگلیسی من اصلاً در حدی نیست که ادعا کنم بدون اشتباه مینویسم. مخصوصاً وقتی پرامپت طولانی میشه یا میخوام یه مسئله پیچیده رو توضیح بدم.
برای همین یه Agent جدا دارم که هیچ کار خاصی نمیکنه، نه کد مینویسه، نه تحلیل میکنه و نه جواب فنی میده. تنها وظیفهاش اینه که متن رو از نظر گرامری و املایی بررسی کنه و نسخه تمیزتری تحویل بده.
معمولاً پرامپتهای طولانی رو اول به اون Agent میدم، بعد خروجی اصلاحشده رو به Agent اصلی میدم که قراره کار فنی انجام بده. اینطوری احتمال اینکه به خاطر انگلیسی افتضاح من موضوع رو اشتباه متوجه بشه کمتر میشه.
فایل AGENTS.md که برای این Agent استفاده میکنم رو هم اینجا میذارم.
👍4🔥1👌1
🤖 یکی از بحثهایی که با آمدن AI Agentها جدیتر شده اینه که اگر یک ایجنت خرابکاری کرد، مقصر کیه؟
مدل؟ ابزار؟ هارنس؟ یا کسی که اون ایجنت رو راه انداخته؟
⚠️ اسپویلر آلرت:مسئولیت نهایی همچنان با آدمه 😁😈.
فرقی نمیکنه کد رو خودت نوشته باشی یا Claude، GPT، Copilot یا هر Agent دیگهای تولیدش کرده باشه. در نهایت تو بودی که مدل رو انتخاب کردی، بهش ابزار دادی، دسترسی تعریف کردی، پرامپت نوشتی و اجازه دادی وارد محیط واقعی بشه.
📄 اینجا باید دقت کنیم که نوشتن Rules توی فایل AGENTS.md بهتنهایی کافی نیست. اگر بخوام همین موضوع رو بدون AI Agent توضیح بدم، میشه این:
شما به دولوپر میگید که چیزی رو مستقیم توی main پوش نکنه و حتماً برای تغییرات PR باز کنه. روز بعد دولوپر یه کد رو مستقیم توی main پوش میکنه، پایپلاین اجرا میشه و پروداکشن به فنا میره.
🔐 اینجا مقصر اصلی شما هستید، نه دولوپر؛ چون دسترسی push به main رو محدود نکردید.
با AI قضیه حساستر هم میشه. چون یک Agent میتونه در چند ثانیه کاری رو انجام بده که قبلاً شاید یک انسان برای انجام دادنش چند دقیقه یا چند ساعت وقت لازم داشت. اگر به چنین چیزی دسترسی production بدیم و همه چیز بریزه به هم، نمیتونیم بگیم «AI این کار رو کرد».
🧠این AI Agent فقط یه ابزار جدیده؛ تصمیم و مسئولیت هنوز با آدمه.
مدل؟ ابزار؟ هارنس؟ یا کسی که اون ایجنت رو راه انداخته؟
⚠️ اسپویلر آلرت:
فرقی نمیکنه کد رو خودت نوشته باشی یا Claude، GPT، Copilot یا هر Agent دیگهای تولیدش کرده باشه. در نهایت تو بودی که مدل رو انتخاب کردی، بهش ابزار دادی، دسترسی تعریف کردی، پرامپت نوشتی و اجازه دادی وارد محیط واقعی بشه.
📄 اینجا باید دقت کنیم که نوشتن Rules توی فایل AGENTS.md بهتنهایی کافی نیست. اگر بخوام همین موضوع رو بدون AI Agent توضیح بدم، میشه این:
شما به دولوپر میگید که چیزی رو مستقیم توی main پوش نکنه و حتماً برای تغییرات PR باز کنه. روز بعد دولوپر یه کد رو مستقیم توی main پوش میکنه، پایپلاین اجرا میشه و پروداکشن به فنا میره.
🔐 اینجا مقصر اصلی شما هستید، نه دولوپر؛ چون دسترسی push به main رو محدود نکردید.
با AI قضیه حساستر هم میشه. چون یک Agent میتونه در چند ثانیه کاری رو انجام بده که قبلاً شاید یک انسان برای انجام دادنش چند دقیقه یا چند ساعت وقت لازم داشت. اگر به چنین چیزی دسترسی production بدیم و همه چیز بریزه به هم، نمیتونیم بگیم «AI این کار رو کرد».
🧠این AI Agent فقط یه ابزار جدیده؛ تصمیم و مسئولیت هنوز با آدمه.
👍3👌1
📝 قبلاً درباره این نوشتم که نوشتن rules توی AGENTS.md بهتنهایی کافی نیست.
👨💻 از نظر من coding agentها شبیه برنامهنویس جونیوری هستن که کتاب و ویدئو زیاد دیدن و شدیداً علاقه دارن با کارشون شما رو تحت تأثیر قرار بدن. برای همین گاهی از خطوطی که براشون کشیدید خارج میشن تا بگن: «ببین من چقدر بلدم!»
⚠️ برای همین اینکه بهشون بگیم «این فایل رو تغییر نده»، «به production دست نزن» یا «secretها رو نخون»، تا وقتی از نظر فنی جلویش را نگرفتیم، بیشتر شبیه توصیه است تا محدودیت واقعی.
🖥 وقتی به یک AI Agent دسترسی shell میدیم، عملاً بهش اجازه میدیم فایل بخونه و تغییر بده، command اجرا کنه، package نصب کنه، network request بزنه و حتی به secretها نزدیک بشه. برای همین کنترل کردن چنین چیزی فقط با prompt یا denylist کافی نیست.
📦 برای کنترل این ریسک، میتونیم از sandbox استفاده کنیم. راههای زیادی برای این کار وجود داره و یکی از نمونههاش nono هست.
https://github.com/nolabs-ai/nono
🔒 ابزار nono یک sandbox برای اجرای Agentهاست که به جای اعتماد به خود مدل یا هارنس، دسترسیها را در سطح سیستمعامل محدود میکند. یعنی میتونید مشخص کنید Agent به کدام مسیرها دسترسی داشته باشه، کجا نتونه بنویسه، چه network accessی داشته باشه و چه چیزهایی براش از اساس غیرممکن باشه.
🔐 این دقیقاً همان تفاوت بین نصیحت کردن یک دولوپر و بستن دسترسی push به main است.
🧪 البته sandbox هم مثل هارنسها یک جواب واحد نداره؛ باید تست کنیم و ببینیم کدوم روش برای کدوم کار مناسبتره.
🚧 ممکنه چیزی که روی سیستم خودمون خوب جواب میده، برای pipeline گیت یا محیط CI/CD انتخاب مناسبی نباشه.
👨💻 از نظر من coding agentها شبیه برنامهنویس جونیوری هستن که کتاب و ویدئو زیاد دیدن و شدیداً علاقه دارن با کارشون شما رو تحت تأثیر قرار بدن. برای همین گاهی از خطوطی که براشون کشیدید خارج میشن تا بگن: «ببین من چقدر بلدم!»
⚠️ برای همین اینکه بهشون بگیم «این فایل رو تغییر نده»، «به production دست نزن» یا «secretها رو نخون»، تا وقتی از نظر فنی جلویش را نگرفتیم، بیشتر شبیه توصیه است تا محدودیت واقعی.
🖥 وقتی به یک AI Agent دسترسی shell میدیم، عملاً بهش اجازه میدیم فایل بخونه و تغییر بده، command اجرا کنه، package نصب کنه، network request بزنه و حتی به secretها نزدیک بشه. برای همین کنترل کردن چنین چیزی فقط با prompt یا denylist کافی نیست.
📦 برای کنترل این ریسک، میتونیم از sandbox استفاده کنیم. راههای زیادی برای این کار وجود داره و یکی از نمونههاش nono هست.
https://github.com/nolabs-ai/nono
🔒 ابزار nono یک sandbox برای اجرای Agentهاست که به جای اعتماد به خود مدل یا هارنس، دسترسیها را در سطح سیستمعامل محدود میکند. یعنی میتونید مشخص کنید Agent به کدام مسیرها دسترسی داشته باشه، کجا نتونه بنویسه، چه network accessی داشته باشه و چه چیزهایی براش از اساس غیرممکن باشه.
🔐 این دقیقاً همان تفاوت بین نصیحت کردن یک دولوپر و بستن دسترسی push به main است.
🧪 البته sandbox هم مثل هارنسها یک جواب واحد نداره؛ باید تست کنیم و ببینیم کدوم روش برای کدوم کار مناسبتره.
🚧 ممکنه چیزی که روی سیستم خودمون خوب جواب میده، برای pipeline گیت یا محیط CI/CD انتخاب مناسبی نباشه.
👍5🥰1
🔓 این روزها خیلی از LLMها رو با عنوان «Open Source» معرفی میکنن، اما شاید بهتر باشه کمی دقیقتر بهش نگاه کنیم.
هر مدلی که بشه دانلودش کرد، لزوماً متنباز نیست. بین اینها فرق وجود داره:
🧠 مدل Open-weight: یعنی وزنهای مدل منتشر شده و میتونید مدل رو دانلود و اجرا کنید.
🧩 مدل Open-source: یعنی علاوه بر خروجی نهایی، وزنها، اطلاعات کافی درباره کد، داده، روش آموزش، تنظیمات و لایسنس هم در دسترسه.
📦 به زبان سادهتر، اگر فقط فایل مدل رو به شما بدن، میتونید ازش استفاده کنید.
🔍 اما اگر مسیر ساخت مدل هم شفاف باشه، میتونید بفهمید چطور ساخته شده، چه محدودیتهایی داره، چطور میشه تغییرش داد و چقدر میشه بهش اعتماد کرد.
⚠️ این تفاوت کوچیکی نیست
توی نرمافزار، وقتی سورسکد بازه، فقط «برنامه قابل اجرا» نداریم؛ منطق پشت برنامه رو هم میبینیم.
🤖 توی LLM هم اگر فقط وزنها رو داشته باشیم، بیشتر شبیه اینه که باینری یک برنامه رو گرفته باشیم، نه الزاماً سورس کاملش رو.
الان معمولاً به همه اینها میگیم Open Source، اما فکر میکنم در آینده فرقشون رو خیلی بیشتر متوجه میشم.
چون این کلمات فقط بحث لغوی نیستن؛ روی اعتماد، امنیت، قابلیت بازبینی و حتی آینده رقابت توی این حوزه هم اثر میذارن.
هر مدلی که بشه دانلودش کرد، لزوماً متنباز نیست. بین اینها فرق وجود داره:
🧠 مدل Open-weight: یعنی وزنهای مدل منتشر شده و میتونید مدل رو دانلود و اجرا کنید.
🧩 مدل Open-source: یعنی علاوه بر خروجی نهایی، وزنها، اطلاعات کافی درباره کد، داده، روش آموزش، تنظیمات و لایسنس هم در دسترسه.
📦 به زبان سادهتر، اگر فقط فایل مدل رو به شما بدن، میتونید ازش استفاده کنید.
🔍 اما اگر مسیر ساخت مدل هم شفاف باشه، میتونید بفهمید چطور ساخته شده، چه محدودیتهایی داره، چطور میشه تغییرش داد و چقدر میشه بهش اعتماد کرد.
⚠️ این تفاوت کوچیکی نیست
توی نرمافزار، وقتی سورسکد بازه، فقط «برنامه قابل اجرا» نداریم؛ منطق پشت برنامه رو هم میبینیم.
🤖 توی LLM هم اگر فقط وزنها رو داشته باشیم، بیشتر شبیه اینه که باینری یک برنامه رو گرفته باشیم، نه الزاماً سورس کاملش رو.
الان معمولاً به همه اینها میگیم Open Source، اما فکر میکنم در آینده فرقشون رو خیلی بیشتر متوجه میشم.
چون این کلمات فقط بحث لغوی نیستن؛ روی اعتماد، امنیت، قابلیت بازبینی و حتی آینده رقابت توی این حوزه هم اثر میذارن.
👍4👏1
🔗 چند لینک برای مطالعه بیشتر:
1. Open Source Initiative — The Open Source AI Definition
https://opensource.org/ai/open-source-ai-definition
2. Hugging Face — Model Cards
https://huggingface.co/docs/hub/en/model-cards
3. Hugging Face — Models Hub
https://huggingface.co/models
4. Meta — Llama 3.1 Community License
https://www.llama.com/llama3_1/license/
5. Mistral AI — Models
https://mistral.ai/models
1. Open Source Initiative — The Open Source AI Definition
https://opensource.org/ai/open-source-ai-definition
2. Hugging Face — Model Cards
https://huggingface.co/docs/hub/en/model-cards
3. Hugging Face — Models Hub
https://huggingface.co/models
4. Meta — Llama 3.1 Community License
https://www.llama.com/llama3_1/license/
5. Mistral AI — Models
https://mistral.ai/models
🖥 این روزها اگر کمی توی اینترنت یا یوتیوب بگردید، با کلی عنوان شبیه این روبهرو میشید:
«Run AI locally for FREE»
یا
«بدون پرداخت هزینه، ChatGPT خودت رو روی لپتاپ اجرا کن»
⚠️ این جمله از یک نظر درسته، اما از یک نظر خیلی گمراهکننده است.
بله، امروز میشه LLMها رو روی سیستم لوکال اجرا کرد.
🛠 ابزارهایی مثل Ollama، LM Studio و چندین گزینه دیگه این کار رو خیلی سادهتر از قبل کردن. ما خودمون هم تقریباً روزانه از مدلهای لوکال استفاده میکنیم.
اما نه برای همه کارها؛ برای coding جدی، تحلیل دیتای بزرگ، کار با context طولانی، یا تولید تصویر حرفهای، معمولاً خیلی زود محدودیتها خودشون رو نشون میدن.
🧠 مسئله اینه که «اجرا شدن» با «مفید، سریع، دقیق و قابل اتکا بودن» یکی نیست.
استفاده لوکال میتونه برای تست، یادگیری، کارهای ساده، خلاصهسازی متنهای کوتاه، آزمایش prompt یا کارهای حساس به حریم خصوصی خیلی خوب باشه.
🔍 اما وقتی بحث میره سمت کدنویسی جدی، تحلیل پیچیده، context بزرگ، سرعت مناسب یا چند ساعت کار مداوم، معمولاً فاصلهاش با مدلهای قوی آنلاین خیلی زود خودش رو نشون میده.
از طرف دیگه، لوکال هم واقعاً «رایگان» نیست.
💸 شما هزینه سختافزار، RAM یا VRAM، مصرف برق، زمان تنظیمات، نگهداری مدلها، انتخاب quantization مناسب و محدودیت سرعت رو پرداخت میکنید؛ فقط این هزینهها مستقیم به شکل subscription یا API bill دیده نمیشن.
برای استفاده شخصی، یک لپتاپ قوی، Mac Studio یا حتی یک سیستم خوب با GPU مناسب میتونه تجربه خیلی خوبی بده.
🏢 اما برای استفاده شرکتی یا تیمی، ماجرا کاملاً فرق میکنه.
اونجا دیگه فقط نصب Ollama روی یک لپتاپ نیست. باید به concurrency، latency، مانیتورینگ، امنیت، دسترسیها، آپدیت مدلها، backup، سرویسدهی پایدار و هزینه واقعی زیرساخت فکر کرد.
🧱 حتی اگر سراغ سختافزارهای خیلی قدرتمند مثل DGX هم برید، باز هم خود دستگاه فقط بخشی از ماجراست، نه کل راهحل.
در مقیاس شرکتی، هزینهها میتونن خیلی سریع از چند هزار دلار به چندصد هزار دلار برسن؛ تازه این فقط هزینه خرید سختافزاره. نگهداری، برق، خنکسازی، شبکه، نیروی فنی و سرویسدهی پایدار داستان جداگانهای دارن.
برای همین به نظرم شعار «AI رایگان روی سیستم خودت» بیشتر برای شروع، تجربه و یادگیری خوبه، نه الزاماً برای جایگزین کردن ابزارهای حرفهای روزانه.
✅ استفاده از مدلها در لوکال روش خیلی خوبیه؛ فقط نباید با کلمه «رایگان» گول بخوریم.
«Run AI locally for FREE»
یا
«بدون پرداخت هزینه، ChatGPT خودت رو روی لپتاپ اجرا کن»
⚠️ این جمله از یک نظر درسته، اما از یک نظر خیلی گمراهکننده است.
بله، امروز میشه LLMها رو روی سیستم لوکال اجرا کرد.
🛠 ابزارهایی مثل Ollama، LM Studio و چندین گزینه دیگه این کار رو خیلی سادهتر از قبل کردن. ما خودمون هم تقریباً روزانه از مدلهای لوکال استفاده میکنیم.
اما نه برای همه کارها؛ برای coding جدی، تحلیل دیتای بزرگ، کار با context طولانی، یا تولید تصویر حرفهای، معمولاً خیلی زود محدودیتها خودشون رو نشون میدن.
🧠 مسئله اینه که «اجرا شدن» با «مفید، سریع، دقیق و قابل اتکا بودن» یکی نیست.
استفاده لوکال میتونه برای تست، یادگیری، کارهای ساده، خلاصهسازی متنهای کوتاه، آزمایش prompt یا کارهای حساس به حریم خصوصی خیلی خوب باشه.
🔍 اما وقتی بحث میره سمت کدنویسی جدی، تحلیل پیچیده، context بزرگ، سرعت مناسب یا چند ساعت کار مداوم، معمولاً فاصلهاش با مدلهای قوی آنلاین خیلی زود خودش رو نشون میده.
از طرف دیگه، لوکال هم واقعاً «رایگان» نیست.
💸 شما هزینه سختافزار، RAM یا VRAM، مصرف برق، زمان تنظیمات، نگهداری مدلها، انتخاب quantization مناسب و محدودیت سرعت رو پرداخت میکنید؛ فقط این هزینهها مستقیم به شکل subscription یا API bill دیده نمیشن.
برای استفاده شخصی، یک لپتاپ قوی، Mac Studio یا حتی یک سیستم خوب با GPU مناسب میتونه تجربه خیلی خوبی بده.
🏢 اما برای استفاده شرکتی یا تیمی، ماجرا کاملاً فرق میکنه.
اونجا دیگه فقط نصب Ollama روی یک لپتاپ نیست. باید به concurrency، latency، مانیتورینگ، امنیت، دسترسیها، آپدیت مدلها، backup، سرویسدهی پایدار و هزینه واقعی زیرساخت فکر کرد.
🧱 حتی اگر سراغ سختافزارهای خیلی قدرتمند مثل DGX هم برید، باز هم خود دستگاه فقط بخشی از ماجراست، نه کل راهحل.
در مقیاس شرکتی، هزینهها میتونن خیلی سریع از چند هزار دلار به چندصد هزار دلار برسن؛ تازه این فقط هزینه خرید سختافزاره. نگهداری، برق، خنکسازی، شبکه، نیروی فنی و سرویسدهی پایدار داستان جداگانهای دارن.
برای همین به نظرم شعار «AI رایگان روی سیستم خودت» بیشتر برای شروع، تجربه و یادگیری خوبه، نه الزاماً برای جایگزین کردن ابزارهای حرفهای روزانه.
✅ استفاده از مدلها در لوکال روش خیلی خوبیه؛ فقط نباید با کلمه «رایگان» گول بخوریم.
👍3👏3
⛈ طی یکی دو ماه اخیر، خیلیها با یک واقعیت نسبتاً تلخ روبهرو شدن:
استفاده از LLMها دیگر مثل قبل یک هزینه ساده و قابل پیشبینی ماهانه نیست.
تا همین چند وقت پیش، خیلی از ابزارهای AI مثل «اشتراک ماهانه» بودن. یعنی یک مبلغ ثابت میدادید و تا حد زیادی با خیال راحت استفاده میکردید.
اما کمکم providerها دارن مدل محاسبه هزینه رو عوض میکنن.
به جای اینکه فقط بگن ماهی ۲۰ دلار یا ۱۰۰ دلار، بیشتر دارن میرن سمت credit، usage limit، token-based billing و محاسبه بر اساس مصرف واقعی.
یعنی چی؟
یعنی مدل قویتر، context بزرگتر، خروجی طولانیتر، فایلهای بیشتر، agentهای فعالتر و retryهای بیشتر، همگی میتونن مستقیم تبدیل به هزینه بیشتر بشن.
قبلاً شاید یک prompt طولانی فقط کمی شلوغ و بدسلیقه به نظر میرسید، اما الان همون prompt طولانی میتونه مستقیماً limit شما رو بسوزونه یا billing شما رو بالا ببره.
اینجاست که بحث بهینهکردن prompt از یک موضوع فانتزی تبدیل میشه به یک موضوع اقتصادی.
یه Prompt خوب یعنی:
🎯 هدف واضحتر
📦 مقدار context کوتاهتر
✂️ خروجی کوتاهتر
🔁 تعداد loop کمتر
💸 هزینه قابل کنترلتر
برای همین ابزارهایی مثل Caveman و Ponytail بیشتر مورد توجه قرار گرفتن. ما داریم وارد دورهای میشیم که در اون باید با مدلها اقتصادیتر حرف بزنیم.
همونطور که در مهندسی نرمافزار یاد گرفتیم CPU، RAM، storage و network بینهایت نیستن و ممکنه هزینه زیادی روی دستمون بذارن، حالا داریم یاد میگیریم که token و context هم بینهایت نیستن.
- هر چیزی رو نباید وارد context کرد.
- هر چیزی رو نباید از مدل قوی خواست.
- هر کاری رو نباید به agent سپرد.
- و هر پاسخی هم که از LLM میگیریم، لازم نیست یک مقاله کامل باشه.
⚠️ البته نباید از اون طرف بام هم بیفتیم.
برای کارهای حساس، مثل امنیت، migration، incident، معماری یا تغییرات production، گاهی توضیح کامل و context بیشتر واقعاً لازمه.
صرفهجویی خوبه، اما باید حواسمون باشه کاری نکنیم که چند برابرش رو بعداً پرداخت کنیم.
به نظرم از این به بعد یکی از مهارتهای مهم کار با AI اینه:
نه فقط بلد باشیم چه چیزی از مدل بخواهیم، بلکه بلد باشیم چقدر از مدل بخواهیم.
استفاده از LLMها دیگر مثل قبل یک هزینه ساده و قابل پیشبینی ماهانه نیست.
تا همین چند وقت پیش، خیلی از ابزارهای AI مثل «اشتراک ماهانه» بودن. یعنی یک مبلغ ثابت میدادید و تا حد زیادی با خیال راحت استفاده میکردید.
اما کمکم providerها دارن مدل محاسبه هزینه رو عوض میکنن.
به جای اینکه فقط بگن ماهی ۲۰ دلار یا ۱۰۰ دلار، بیشتر دارن میرن سمت credit، usage limit، token-based billing و محاسبه بر اساس مصرف واقعی.
یعنی چی؟
یعنی مدل قویتر، context بزرگتر، خروجی طولانیتر، فایلهای بیشتر، agentهای فعالتر و retryهای بیشتر، همگی میتونن مستقیم تبدیل به هزینه بیشتر بشن.
قبلاً شاید یک prompt طولانی فقط کمی شلوغ و بدسلیقه به نظر میرسید، اما الان همون prompt طولانی میتونه مستقیماً limit شما رو بسوزونه یا billing شما رو بالا ببره.
اینجاست که بحث بهینهکردن prompt از یک موضوع فانتزی تبدیل میشه به یک موضوع اقتصادی.
یه Prompt خوب یعنی:
🎯 هدف واضحتر
📦 مقدار context کوتاهتر
✂️ خروجی کوتاهتر
🔁 تعداد loop کمتر
💸 هزینه قابل کنترلتر
برای همین ابزارهایی مثل Caveman و Ponytail بیشتر مورد توجه قرار گرفتن. ما داریم وارد دورهای میشیم که در اون باید با مدلها اقتصادیتر حرف بزنیم.
همونطور که در مهندسی نرمافزار یاد گرفتیم CPU، RAM، storage و network بینهایت نیستن و ممکنه هزینه زیادی روی دستمون بذارن، حالا داریم یاد میگیریم که token و context هم بینهایت نیستن.
- هر چیزی رو نباید وارد context کرد.
- هر چیزی رو نباید از مدل قوی خواست.
- هر کاری رو نباید به agent سپرد.
- و هر پاسخی هم که از LLM میگیریم، لازم نیست یک مقاله کامل باشه.
⚠️ البته نباید از اون طرف بام هم بیفتیم.
برای کارهای حساس، مثل امنیت، migration، incident، معماری یا تغییرات production، گاهی توضیح کامل و context بیشتر واقعاً لازمه.
صرفهجویی خوبه، اما باید حواسمون باشه کاری نکنیم که چند برابرش رو بعداً پرداخت کنیم.
به نظرم از این به بعد یکی از مهارتهای مهم کار با AI اینه:
نه فقط بلد باشیم چه چیزی از مدل بخواهیم، بلکه بلد باشیم چقدر از مدل بخواهیم.
👍4👏2
🔗 چند لینک برای مطالعه بیشتر:
1. GitHub — Copilot usage-based billing
https://github.blog/news-insights/company-news/github-copilot-is-moving-to-usage-based-billing/
2. GitHub Docs — Usage-based billing for Copilot
https://docs.github.com/copilot/concepts/billing/usage-based-billing-for-individuals
3. OpenAI — Codex Pricing
https://developers.openai.com/codex/pricing
4. Claude — Manage usage credits
https://support.claude.com/en/articles/12429409-manage-usage-credits-for-paid-claude-plans
5. Caveman
https://github.com/JuliusBrussee/caveman
6. Ponytail
https://github.com/DietrichGebert/ponytail
1. GitHub — Copilot usage-based billing
https://github.blog/news-insights/company-news/github-copilot-is-moving-to-usage-based-billing/
2. GitHub Docs — Usage-based billing for Copilot
https://docs.github.com/copilot/concepts/billing/usage-based-billing-for-individuals
3. OpenAI — Codex Pricing
https://developers.openai.com/codex/pricing
4. Claude — Manage usage credits
https://support.claude.com/en/articles/12429409-manage-usage-credits-for-paid-claude-plans
5. Caveman
https://github.com/JuliusBrussee/caveman
6. Ponytail
https://github.com/DietrichGebert/ponytail