CodeNeuron
یکم درباره این AI آخرالزمانی آروم‌تر باشید عزیزان دلم. چند تا نکته درباره اتفاقات اخیر: ۱. هک Hugging Face توسط Agentها این‌طور نیست که یک مدل نشسته باشه و خودش تصمیم گرفته باشه بره یک سرویس رو هک کنه. در ماجرای ExploitGym، دستورالعمل‌های مشخصی برای Agent…
پ.ن: اگر واقعاً این‌قدر نگران ریسک‌های تکنولوژی هستید، قبل از AI شاید بهتر باشه نگران چیزهای خیلی معمولی‌تری باشید که همین الان هم می‌تونن آدم رو بزنن.
فعلاً فاصله بین Agent قدرتمند و هوش خودمختار آخرالزمانی هنوز خیلی زیاده.
فعلاً فاصله بین Agent قدرتمند و هوش خودمختار آخرالزمانی هنوز خیلی زیاده.
🔥1
یه آپدیت جالب برای اجرای LLMها روی Apple Silicon
یک تیم کوچک به اسم Mirai، قابلیت Speculative Decoding رو به موتور Inference خودش اضافه کرده.
فعلاً از Qwen3.6 27B پشتیبانی می‌کنن و پشتیبانی از Qwen3.8 27B و Muse Glimmer هم در راهه.
نکته جالب اینه که ادعا می‌کنن عملکردشون روی Apple Silicon به شکل قابل‌توجهی از Stackهای موجود بهتره.
دلیلش هم رویکرد Co-design بوده.
یعنی Kernelها، Quantization و Speculative Decoding رو از پایه برای این سیستم طراحی کردن.
اگر این روند ادامه پیدا کنه، اجرای مدل‌های نسبتاً بزرگ روی دستگاه‌های شخصی و حتی موبایل، خیلی جدی‌تر از قبل میشه.
#AI
#LLM
#AppleSilicon
#Inference
#Qwen
#OnDeviceAI
یک تیم کوچک به اسم Mirai، قابلیت Speculative Decoding رو به موتور Inference خودش اضافه کرده.
فعلاً از Qwen3.6 27B پشتیبانی می‌کنن و پشتیبانی از Qwen3.8 27B و Muse Glimmer هم در راهه.
نکته جالب اینه که ادعا می‌کنن عملکردشون روی Apple Silicon به شکل قابل‌توجهی از Stackهای موجود بهتره.
دلیلش هم رویکرد Co-design بوده.
یعنی Kernelها، Quantization و Speculative Decoding رو از پایه برای این سیستم طراحی کردن.
اگر این روند ادامه پیدا کنه، اجرای مدل‌های نسبتاً بزرگ روی دستگاه‌های شخصی و حتی موبایل، خیلی جدی‌تر از قبل میشه.
#AI
#LLM
#AppleSilicon
#Inference
#Qwen
#OnDeviceAI
👍1
CodeNeuron
یه آپدیت جالب برای اجرای LLMها روی Apple Silicon یک تیم کوچک به اسم Mirai، قابلیت Speculative Decoding رو به موتور Inference خودش اضافه کرده. فعلاً از Qwen3.6 27B پشتیبانی می‌کنن و پشتیبانی از Qwen3.8 27B و Muse Glimmer هم در راهه. نکته جالب اینه که ادعا…
پ.ن: دوستان AI روی گوشی داره جدی‌تر میشه.
به نظرم با این سرعت پیشرفت در Inference، Quantization و Speculative Decoding، تا یک سال دیگه ممکنه واقعاً به اجرای مدلی در سطح Qwen3.8 27B روی گوشی برسیم.
اگر این اتفاق بیفته، بخش بزرگی از AI می‌تونه On-Device اجرا بشه؛ بدون Cloud و وابستگی دائمی به API.
به نظرم این مسیر خیلی جذاب‌تر از چیزی‌یه که الان به نظر میاد.
به نظرم با این سرعت پیشرفت در Inference، Quantization و Speculative Decoding، تا یک سال دیگه ممکنه واقعاً به اجرای مدلی در سطح Qwen3.8 27B روی گوشی برسیم.
اگر این اتفاق بیفته، بخش بزرگی از AI می‌تونه On-Device اجرا بشه؛ بدون Cloud و وابستگی دائمی به API.
به نظرم این مسیر خیلی جذاب‌تر از چیزی‌یه که الان به نظر میاد.
🔥1
انگار داستان Context Window خیلی قبل‌تر از LLMها شروع شده بود.
شرلوک ۱۴۰ سال پیش می‌گفت مغز مثل یک اتاق زیرشیروانیه و نباید هر آشغالی رو توش ریخت.
یودا گفت باید Unlearn کنیم.
دامبلدور اطلاعات اضافی رو ریخت توی Memory Pool.
نئو هم Kung Fu رو در چند ثانیه دانلود کرد.
و ما هنوز با افتخار داریم صدهزارمین Token از Documentation رو می‌ریزیم توی Context و انتظار داریم Agent همه‌چیز رو یادش بمونه.
شاید مسئله آینده فقط Context بیشتر نباشه.
شاید باید یاد بگیریم چی رو اصلاً وارد Context نکنیم.
#AI
#LLM
#ContextEngineering
#AIAgents
#ContextWindow
شرلوک ۱۴۰ سال پیش می‌گفت مغز مثل یک اتاق زیرشیروانیه و نباید هر آشغالی رو توش ریخت.
یودا گفت باید Unlearn کنیم.
دامبلدور اطلاعات اضافی رو ریخت توی Memory Pool.
نئو هم Kung Fu رو در چند ثانیه دانلود کرد.
و ما هنوز با افتخار داریم صدهزارمین Token از Documentation رو می‌ریزیم توی Context و انتظار داریم Agent همه‌چیز رو یادش بمونه.
شاید مسئله آینده فقط Context بیشتر نباشه.
شاید باید یاد بگیریم چی رو اصلاً وارد Context نکنیم.
#AI
#LLM
#ContextEngineering
#AIAgents
#ContextWindow
❤1😎1
من خودم به این نتیجه رسیدم که حتی قصد ندارم هیچ کاری رو صرفاً با استفاده از هوش مصنوعی خودکار کنم.
نه اینکه بهش اعتماد نداشته باشم؛ اتفاقاً خیلی هم ازش استفاده می‌کنم.
ولی می‌دونم که بعضی وقت‌ها بین چند پیام، ممکنه مسیر اشتباهی رو بره و این کاملاً طبیعیه.
به نظرم در نهایت، ابزار باید دست شما رو بلندتر کنه، نه اینکه از دستتون جدا بشه و با یه طناب بهتون وصل بمونه.
وقتی خودتون همچنان درگیر کار باشین، هم هزینه کمتری می‌کنین، هم تمرکز بیشتری دارین، هم توی حوزه‌های مختلف بیشتر یاد می‌گیرین و در نهایت نه‌تنها سریع‌تر میشین، بلکه سبک و اصالت خودتون رو هم حفظ می‌کنین.
من خودم دوست دارم حس نزدیکی با کاری که انجام میدم داشته باشم.
دوست دارم بدونم چیزی که دارم می‌سازم چطور کار می‌کنه و چرا به این شکل ساخته شده.
به نظرم مهمه که اصول فناوری رو بفهمین. بدونین این تکنولوژی چطور به این مرحله رسیده، قبل از اون چه چیزهایی وجود داشته و اصلاً چرا امروز به این نقطه رسیدیم.
اینکه بدون برنامه‌نویسی و به طور کلی علوم کامپیوتر نمیشه پیشرفت کرد، حرف درستیه؛ ولی برنامه‌نویسی بیشتر شبیه الفبای این حوزه‌ست.
بلد بودن الفبا به این معنی نیست که نویسنده شدین. باید بتونین این حروف رو کنار هم بذارین، کلمه و جمله بسازین و در نهایت بدونین کِی، کجا و چرا باید از هر چیزی استفاده کنین.
به نظرم الان بیشتر از همیشه باید هم کدنویسی بلد باشین، هم تئوری پشتش رو بفهمین.
لازم نیست حتماً همیشه دنبال یه roadmap مشخص باشین یا همه‌چیز رو از قبل بدونین.
اگه از کاری که انجام میدین لذت می‌برین و واقعاً کنجکاوین که بفهمین پشتش چه خبره، همین مسیر خودش می‌تونه باعث پیشرفتتون بشه.
نه اینکه بهش اعتماد نداشته باشم؛ اتفاقاً خیلی هم ازش استفاده می‌کنم.
ولی می‌دونم که بعضی وقت‌ها بین چند پیام، ممکنه مسیر اشتباهی رو بره و این کاملاً طبیعیه.
به نظرم در نهایت، ابزار باید دست شما رو بلندتر کنه، نه اینکه از دستتون جدا بشه و با یه طناب بهتون وصل بمونه.
وقتی خودتون همچنان درگیر کار باشین، هم هزینه کمتری می‌کنین، هم تمرکز بیشتری دارین، هم توی حوزه‌های مختلف بیشتر یاد می‌گیرین و در نهایت نه‌تنها سریع‌تر میشین، بلکه سبک و اصالت خودتون رو هم حفظ می‌کنین.
من خودم دوست دارم حس نزدیکی با کاری که انجام میدم داشته باشم.
دوست دارم بدونم چیزی که دارم می‌سازم چطور کار می‌کنه و چرا به این شکل ساخته شده.
به نظرم مهمه که اصول فناوری رو بفهمین. بدونین این تکنولوژی چطور به این مرحله رسیده، قبل از اون چه چیزهایی وجود داشته و اصلاً چرا امروز به این نقطه رسیدیم.
اینکه بدون برنامه‌نویسی و به طور کلی علوم کامپیوتر نمیشه پیشرفت کرد، حرف درستیه؛ ولی برنامه‌نویسی بیشتر شبیه الفبای این حوزه‌ست.
بلد بودن الفبا به این معنی نیست که نویسنده شدین. باید بتونین این حروف رو کنار هم بذارین، کلمه و جمله بسازین و در نهایت بدونین کِی، کجا و چرا باید از هر چیزی استفاده کنین.
به نظرم الان بیشتر از همیشه باید هم کدنویسی بلد باشین، هم تئوری پشتش رو بفهمین.
لازم نیست حتماً همیشه دنبال یه roadmap مشخص باشین یا همه‌چیز رو از قبل بدونین.
اگه از کاری که انجام میدین لذت می‌برین و واقعاً کنجکاوین که بفهمین پشتش چه خبره، همین مسیر خودش می‌تونه باعث پیشرفتتون بشه.
❤1
بچه‌ها، یه توصیه دوستانه و صمیمانه دارم برای کسایی که تازه دارن وارد دنیای AI و Agentها میشن.
به نظرم برای شروع، لازم نیست ده‌ها دوره و ویدیو و roadmap جمع کنین. چندتا چیز خیلی ساده‌تر از این حرفاست.
اول از همه، تمرین کنین.
یه Agent خوب داشته باشین و شروع کنین به کار کردن باهاش. نه اینکه از همون اول بخواین Agent بسازین؛ اول سعی کنین بفهمین همین ابزارهایی که الان وجود دارن چطور کار می‌کنن.
مثلاً باهاش یه کار واقعی انجام بدین، بعد ازش بخواین توضیح بده چطور به نتیجه رسیده، چه ابزارهایی استفاده کرده و چه مسیری رو طی کرده.
دوم، باید یه دید درست از هسته‌ی این سیستم‌ها پیدا کنین.
مهم‌ترین چیز اینه که بدونین تفاوت بین مدل و Context چیه، Agent Loop چطور کار می‌کنه و مدل چطور از Toolها استفاده می‌کنه.
خیلی ساده اگر بخوایم نگاه کنیم:
شما قبل از هر درخواست، یه Context در اختیار مدل می‌ذارین؛ پرامپت، فایل‌ها، تاریخچه، Toolها و هر چیزی که برای حل مسئله لازمه.
بعد مدل با توجه به همین Context تصمیم می‌گیره چه کاری باید انجام بده.
ممکنه یک Tool رو صدا بزنه، نتیجه رو ببینه، دوباره تصمیم بگیره، Tool دیگه‌ای رو اجرا کنه و همین چرخه ادامه پیدا کنه تا در نهایت به جواب برسه یا از شما سؤال بپرسه.
وقتی این چرخه رو بفهمین، خیلی از چیزهایی که اولش شبیه جادو به نظر میاد، دیگه اون‌قدر عجیب نیست.
این قسمت رو واقعاً جدی بگیرین.
از Agentتون بخواین Agent Loop خودش رو براتون توضیح بده. ازش بخواین مثال بزنه، مقاله و ویدیو پیدا کنه و چند ساعت باهاش کلنجار برین.
لازم نیست از همون اول برین سراغ ده‌ها فریم‌ورک و ابزار مختلف. اول همین چند مفهوم پایه رو درست بفهمین.
سوم، AI رو وارد کاری کنین که همین الان انجام میدین.
اگر برنامه‌نویسین، باهاش کد بزنین.
اگر طراحین، کارهای طراحی خودتون رو باهاش سریع‌تر کنین.
اگر تولید محتوا می‌کنین، ازش برای تحقیق، ایده‌پردازی یا آماده‌سازی محتوا استفاده کنین.
لازم نیست همه برنامه‌نویس بشن و یه SaaS بسازن.
به نظرم هدف اصلی این نیست که یه حرفه‌ی جدید رو از صفر شروع کنین؛ هدف اینه که کاری که همین الان بلدین رو با کمک AI بهتر و سریع‌تر انجام بدین.
بعد که یه کار رو چند بار انجام دادین، می‌تونین همون روند رو تبدیل به Skill یا Workflow کنین و کم‌کم سطح اتوماسیون رو بالاتر ببرین.
و چهارم، تنها پیش نرین.
وارد کامیونیتی‌ها و چت‌ها بشین. سؤال بپرسین، کارهاتون رو نشون بدین، ببینین بقیه چطور مسئله‌ها رو حل می‌کنن و از تجربه‌شون استفاده کنین.
اتفاقاً خیلی وقت‌ها چیزهایی که توی چت‌ها یاد می‌گیرین، توی هیچ دوره‌ای پیدا نمی‌کنین.
ولی در نهایت، به نظرم مهم‌ترین نکته اینه:
این AI رو جایگزین فهمیدن نکنین.
بذارین ابزار، دست شما رو بلندتر کنه؛ نه اینکه خودتون رو از کاری که انجام میدین جدا کنه.
من خودم دوست دارم بدونم چیزی که دارم می‌سازم چطور کار می‌کنه.
دوست دارم باهاش درگیر باشم، اشتباه کنم، بفهمم چرا اشتباه کردم و بعد دوباره درستش کنم.
چون وقتی همه‌چیز رو به AI می‌سپارین، شاید سریع‌تر بشین؛ ولی ممکنه کم‌کم ارتباطتون با کاری که انجام میدین هم کمتر بشه.
به نظرم بهترین حالت اینه که AI سرعت و توانایی‌تون رو چند برابر کنه، ولی همچنان خودتون پشت فرمون باشین.
لازم نیست همه‌چیز رو بدونین.
فقط کنجکاو باشین، بسازین، خراب کنین و دوباره بسازین.
بقیه‌ش کم‌کم میاد.
#توصیه
#مسیر
#AIAgents
به نظرم برای شروع، لازم نیست ده‌ها دوره و ویدیو و roadmap جمع کنین. چندتا چیز خیلی ساده‌تر از این حرفاست.
اول از همه، تمرین کنین.
یه Agent خوب داشته باشین و شروع کنین به کار کردن باهاش. نه اینکه از همون اول بخواین Agent بسازین؛ اول سعی کنین بفهمین همین ابزارهایی که الان وجود دارن چطور کار می‌کنن.
مثلاً باهاش یه کار واقعی انجام بدین، بعد ازش بخواین توضیح بده چطور به نتیجه رسیده، چه ابزارهایی استفاده کرده و چه مسیری رو طی کرده.
دوم، باید یه دید درست از هسته‌ی این سیستم‌ها پیدا کنین.
مهم‌ترین چیز اینه که بدونین تفاوت بین مدل و Context چیه، Agent Loop چطور کار می‌کنه و مدل چطور از Toolها استفاده می‌کنه.
خیلی ساده اگر بخوایم نگاه کنیم:
شما قبل از هر درخواست، یه Context در اختیار مدل می‌ذارین؛ پرامپت، فایل‌ها، تاریخچه، Toolها و هر چیزی که برای حل مسئله لازمه.
بعد مدل با توجه به همین Context تصمیم می‌گیره چه کاری باید انجام بده.
ممکنه یک Tool رو صدا بزنه، نتیجه رو ببینه، دوباره تصمیم بگیره، Tool دیگه‌ای رو اجرا کنه و همین چرخه ادامه پیدا کنه تا در نهایت به جواب برسه یا از شما سؤال بپرسه.
وقتی این چرخه رو بفهمین، خیلی از چیزهایی که اولش شبیه جادو به نظر میاد، دیگه اون‌قدر عجیب نیست.
این قسمت رو واقعاً جدی بگیرین.
از Agentتون بخواین Agent Loop خودش رو براتون توضیح بده. ازش بخواین مثال بزنه، مقاله و ویدیو پیدا کنه و چند ساعت باهاش کلنجار برین.
لازم نیست از همون اول برین سراغ ده‌ها فریم‌ورک و ابزار مختلف. اول همین چند مفهوم پایه رو درست بفهمین.
سوم، AI رو وارد کاری کنین که همین الان انجام میدین.
اگر برنامه‌نویسین، باهاش کد بزنین.
اگر طراحین، کارهای طراحی خودتون رو باهاش سریع‌تر کنین.
اگر تولید محتوا می‌کنین، ازش برای تحقیق، ایده‌پردازی یا آماده‌سازی محتوا استفاده کنین.
لازم نیست همه برنامه‌نویس بشن و یه SaaS بسازن.
به نظرم هدف اصلی این نیست که یه حرفه‌ی جدید رو از صفر شروع کنین؛ هدف اینه که کاری که همین الان بلدین رو با کمک AI بهتر و سریع‌تر انجام بدین.
بعد که یه کار رو چند بار انجام دادین، می‌تونین همون روند رو تبدیل به Skill یا Workflow کنین و کم‌کم سطح اتوماسیون رو بالاتر ببرین.
و چهارم، تنها پیش نرین.
وارد کامیونیتی‌ها و چت‌ها بشین. سؤال بپرسین، کارهاتون رو نشون بدین، ببینین بقیه چطور مسئله‌ها رو حل می‌کنن و از تجربه‌شون استفاده کنین.
اتفاقاً خیلی وقت‌ها چیزهایی که توی چت‌ها یاد می‌گیرین، توی هیچ دوره‌ای پیدا نمی‌کنین.
ولی در نهایت، به نظرم مهم‌ترین نکته اینه:
این AI رو جایگزین فهمیدن نکنین.
بذارین ابزار، دست شما رو بلندتر کنه؛ نه اینکه خودتون رو از کاری که انجام میدین جدا کنه.
من خودم دوست دارم بدونم چیزی که دارم می‌سازم چطور کار می‌کنه.
دوست دارم باهاش درگیر باشم، اشتباه کنم، بفهمم چرا اشتباه کردم و بعد دوباره درستش کنم.
چون وقتی همه‌چیز رو به AI می‌سپارین، شاید سریع‌تر بشین؛ ولی ممکنه کم‌کم ارتباطتون با کاری که انجام میدین هم کمتر بشه.
به نظرم بهترین حالت اینه که AI سرعت و توانایی‌تون رو چند برابر کنه، ولی همچنان خودتون پشت فرمون باشین.
لازم نیست همه‌چیز رو بدونین.
فقط کنجکاو باشین، بسازین، خراب کنین و دوباره بسازین.
بقیه‌ش کم‌کم میاد.
#توصیه
#مسیر
#AIAgents
👌1
CodeNeuron
بچه‌ها، یه توصیه دوستانه و صمیمانه دارم برای کسایی که تازه دارن وارد دنیای AI و Agentها میشن. به نظرم برای شروع، لازم نیست ده‌ها دوره و ویدیو و roadmap جمع کنین. چندتا چیز خیلی ساده‌تر از این حرفاست. اول از همه، تمرین کنین. یه Agent خوب داشته باشین و شروع…
پ.ن: یه چیز دیگه هم به نظرم خیلی مهمه؛ یه پروژه‌ای که مدت‌هاست توی ذهنتونه، یا یه ایده‌ی جالب که واقعاً دوست دارین بسازینش پیدا کنین.
یه چیزی که دلتون بخواد بشینین پاش و روش کار کنین؛ و اگه در نهایت بتونه براتون درآمد هم داشته باشه که چه بهتر.
وقتی یه پروژه‌ی واقعی داشته باشین که واقعاً براتون مهم باشه، انگیزه‌ی خیلی بیشتری برای نشستن، یاد گرفتن، خراب کردن و دوباره ساختنش پیدا می‌کنین.
به نظرم خیلی بهتر از اینه که فقط بشینین یه سری آموزش ببینین و منتظر باشین یه روز «آماده» بشین.
یه چیزی که دلتون بخواد بشینین پاش و روش کار کنین؛ و اگه در نهایت بتونه براتون درآمد هم داشته باشه که چه بهتر.
وقتی یه پروژه‌ی واقعی داشته باشین که واقعاً براتون مهم باشه، انگیزه‌ی خیلی بیشتری برای نشستن، یاد گرفتن، خراب کردن و دوباره ساختنش پیدا می‌کنین.
به نظرم خیلی بهتر از اینه که فقط بشینین یه سری آموزش ببینین و منتظر باشین یه روز «آماده» بشین.
🔥1
Forwarded from IranServer | ایران سرور
KWYPiransvGSZYacademyto100_kjuyaBUG-SUMMER1405_KKFQDOWETZBUG-SUMMER1405_NGFKFKCWZG⏱️ مهلت استفاده از این کدها فقط تا ساعت 22 امشب
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
به انتهای روز که می‌رسی، یه حس عجیبی میاد سراغت: «من امروز واقعاً کار کردم یا فقط الکی وقت گذروندم؟»
شما هم اینطوری هستید یا فقط منم؟
این حس بیشتر موقعی سراغم میاد که کل روز کد نزدم و چسبیدم به داکیومنت‌بازی، نوشتنِ مستندات، ویرایش یا تحقیق.
ما ناخودآگاه عادت کردیم به اینکه وقتی هر روز کد می‌زنیم (حتی با کمک هوش مصنوعی)، نتیجه جلوی ما مشخص هست: حجم زیادی از فایل‌های وایب‌کدشده یا پول‌ریکوئست‌های (PR) مرج‌شده.
اما وقتی روی مستندات کار می‌کنی، در بهترین حالت انتهای روز یکی دو تا سند تحویل می‌دهی و این فکر سمّی در سرت میپیچه که: «خب که چی؟ این‌ها رو نوشتی که چی بشه؟ اصلاً کار جدی‌ای نکردی که! مدرکی براش نداری!»
در حالی که مغزت کاملاً متوجه هست که کل روز کار کرده‌ای، خسته‌ای و کله‌ات سوت کشیده.
شما هم با این قضیه درگیر میشین ؟ اگر آره، چطور باهاش کنار میاین؟
شما هم اینطوری هستید یا فقط منم؟
این حس بیشتر موقعی سراغم میاد که کل روز کد نزدم و چسبیدم به داکیومنت‌بازی، نوشتنِ مستندات، ویرایش یا تحقیق.
ما ناخودآگاه عادت کردیم به اینکه وقتی هر روز کد می‌زنیم (حتی با کمک هوش مصنوعی)، نتیجه جلوی ما مشخص هست: حجم زیادی از فایل‌های وایب‌کدشده یا پول‌ریکوئست‌های (PR) مرج‌شده.
اما وقتی روی مستندات کار می‌کنی، در بهترین حالت انتهای روز یکی دو تا سند تحویل می‌دهی و این فکر سمّی در سرت میپیچه که: «خب که چی؟ این‌ها رو نوشتی که چی بشه؟ اصلاً کار جدی‌ای نکردی که! مدرکی براش نداری!»
در حالی که مغزت کاملاً متوجه هست که کل روز کار کرده‌ای، خسته‌ای و کله‌ات سوت کشیده.
شما هم با این قضیه درگیر میشین ؟ اگر آره، چطور باهاش کنار میاین؟
😁2
یک سری منبع کاربردی براتون پیدا کردم، گفتم اینجا به اشتراک بذارم:
مورد اول: aicss.dev — بلاک‌های UI برای تعاملاتِ ایجنت‌های هوش مصنوعی
مورد دوم: ui.halaska.com — کامپوننت‌های رابط کاربری برای محصولات مبتنی بر AI
مورد سوم: bencho.dev — بلاک‌های UI برای تجربه‌های تعاملیِ هوش مصنوعی
مورد چهارم: builtbydesigners.com — ویترینِ محصولاتی که طراحان ساختارشان را دیزاین کرده‌اند
مورد پنجم: torph.lochie.me — کتابخانه متن‌مورفینگ (morphing) بدون هیچ وابستگی (Zero dependencies)
مورد ششم: typehug.aliszu.com — ابزار تایپوگرافی برای کنار هم چسباندن و نگه داشتن کلمات
شما خودتون از این‌ها توی پروژه‌هاتون استفاده کردید، یا فقط دارید لینک جمع می‌کنید برای پروژه‌های بعدی؟ :)
مورد اول: aicss.dev — بلاک‌های UI برای تعاملاتِ ایجنت‌های هوش مصنوعی
مورد دوم: ui.halaska.com — کامپوننت‌های رابط کاربری برای محصولات مبتنی بر AI
مورد سوم: bencho.dev — بلاک‌های UI برای تجربه‌های تعاملیِ هوش مصنوعی
مورد چهارم: builtbydesigners.com — ویترینِ محصولاتی که طراحان ساختارشان را دیزاین کرده‌اند
مورد پنجم: torph.lochie.me — کتابخانه متن‌مورفینگ (morphing) بدون هیچ وابستگی (Zero dependencies)
مورد ششم: typehug.aliszu.com — ابزار تایپوگرافی برای کنار هم چسباندن و نگه داشتن کلمات
شما خودتون از این‌ها توی پروژه‌هاتون استفاده کردید، یا فقط دارید لینک جمع می‌کنید برای پروژه‌های بعدی؟ :)
👌1
یک زمانی پایپ‌لاین CI/CD گیت‌هاب اکشنزِ من شده بود ۱۵ الی ۱۸ دقیقه.
بعد تازه دوزاری‌ام افتاد که کلی از این زمان داره الکی میره روی کارهای تکراری:
هر پوش یعنی: اجرای دوباره‌ی
دانلود دوباره‌ی تمام وابستگی‌ها (Dependencies)
ری‌بیلد کردن کل اسکریپت‌های بیلد از صفر
حتی وقتی فقط چند خط کد رو تغییر داده بودم.
شما هم درگیر این کُندی‌های وقت‌تلف‌کن توی CI/CD هستین یا براتون خیلی اهمیتی نداره ؟
بعد تازه دوزاری‌ام افتاد که کلی از این زمان داره الکی میره روی کارهای تکراری:
هر پوش یعنی: اجرای دوباره‌ی
npm installدانلود دوباره‌ی تمام وابستگی‌ها (Dependencies)
ری‌بیلد کردن کل اسکریپت‌های بیلد از صفر
حتی وقتی فقط چند خط کد رو تغییر داده بودم.
شما هم درگیر این کُندی‌های وقت‌تلف‌کن توی CI/CD هستین یا براتون خیلی اهمیتی نداره ؟
👌1
شب‌ها اتوماسیون و کارِ سنگین رو می‌سپاریم دست سیستم، صبح‌ها کار رو پیش می‌بریم، بعدازظهر هم کلاً می‌بندیم میریم سراغ چمن لمس کردن و استراحت و کوه
❤1
یه مطلب جالب درباره امنیت زنجیره تأمین مدل‌های هوش مصنوعی خوندم که به نظرم ارزش گفتن داشت.
معمولاً وقتی درباره امنیت مدل‌های هوش مصنوعی حرف می‌زنیم، ذهنمون میره سمت خود مدل؛ ولی مشکل فقط مدل نیست.
کتابخانه‌ها، فایل‌های مدل، داده‌ها، سرویس‌های تبدیل، ابزارها و حتی سیستم‌هایی که مدل داخلشون اجرا میشه، همگی می‌تونن بخشی از مسیر حمله باشن.
مثلاً Hugging Face خودش درباره فایل‌های pickle هشدار داده، چون باز کردن این فایل‌ها می‌تونه باعث اجرای دستوراتی بشه که داخل فایل قرار داده شده. به همین دلیل هم مکانیزم بررسی این فایل‌ها رو داره و فرمت امن‌تری مثل safetensors رو پیشنهاد می‌کنه.
یه نمونه جالب‌تر هم توسط HiddenLayer گزارش شده؛ مهاجم با یک فایل مخرب PyTorch تونسته بود سرویس تبدیل مدل Hugging Face رو هدف قرار بده، توکن ربات رسمی رو به دست بیاره و حتی از طرف اون ربات درخواست تغییر ثبت کنه.
یعنی حمله فقط به «مدل» انجام نشده؛ بلکه به سرویس مورد اعتمادی انجام شده که اطراف مدل قرار داشته.
برای عامل‌های هوش مصنوعی این موضوع جدی‌تر هم میشه. چون عامل فقط متن تولید نمی‌کنه؛ ممکنه به فایل، API، مخزن کد، سیستم ساخت و استقرار یا ابزارهای مختلف دسترسی داشته باشه.
حالا تصور کنید یک صفحه وب، فایل یا داده‌ای که عامل می‌خونه، حاوی دستور مخربی باشه. اگر عامل بدون بررسی به اون اعتماد کنه، ممکنه کاری انجام بده که کاربر اصلاً درخواست نکرده.
اینجا یک اشتباه رایج وجود داره: فکر کنیم اگر خود مدل رو ایمن کنیم، کل سیستم امن شده.
در واقع باید دو بخش رو جداگانه محافظت کنیم:
یکی زنجیره تأمین مدل؛ یعنی منبع مدل، داده‌ها، فایل وزن‌ها، صحت فایل و سابقه تغییرات.
دومی لایه اجرای عامل؛ یعنی اینکه عامل به چه ابزارهایی دسترسی داره، چه دستوری می‌تونه اجرا کنه و چه اطلاعاتی می‌تونه بخونه یا تغییر بده.
چند کار ساده هم می‌تونه ریسک رو خیلی کمتر کنه:
۱. صحت فایل‌های مدل و داده‌ها رو قبل از استفاده بررسی کنیم.
۲. تا جای ممکن از قالب‌های ناامن برای مدل‌ها استفاده نکنیم.
۳. مدل و داده‌ای که منبعش مشخص نیست رو قابل اعتماد فرض نکنیم.
۴. دسترسی عامل‌ها رو تا حد ممکن محدود کنیم.
۵. دسترسی به کلیدها، رمزها و اطلاعات حساس رو از عامل‌ها جدا کنیم.
۶. اجرای ابزارها رو هم مثل خود مدل، بخشی از سطح حمله در نظر بگیریم.
به نظرم با گسترش عامل‌های هوش مصنوعی، «امنیت مدل» دیگه به‌تنهایی کافی نیست.
اگر یک عامل به ابزارهای واقعی دسترسی داشته باشه، یک ورودی مخرب می‌تونه از یک مشکل ساده در متن، تبدیل به دسترسی به فایل‌ها، اطلاعات حساس یا حتی سیستم‌های دیگر بشه.
در نهایت هوش مصنوعی فقط سرعت انجام کارها رو بیشتر نمی‌کنه؛ اگر دسترسی‌ها درست کنترل نشن، سرعت آسیب‌زدن رو هم بیشتر می‌کنه.
#AIAgents
#AI
معمولاً وقتی درباره امنیت مدل‌های هوش مصنوعی حرف می‌زنیم، ذهنمون میره سمت خود مدل؛ ولی مشکل فقط مدل نیست.
کتابخانه‌ها، فایل‌های مدل، داده‌ها، سرویس‌های تبدیل، ابزارها و حتی سیستم‌هایی که مدل داخلشون اجرا میشه، همگی می‌تونن بخشی از مسیر حمله باشن.
مثلاً Hugging Face خودش درباره فایل‌های pickle هشدار داده، چون باز کردن این فایل‌ها می‌تونه باعث اجرای دستوراتی بشه که داخل فایل قرار داده شده. به همین دلیل هم مکانیزم بررسی این فایل‌ها رو داره و فرمت امن‌تری مثل safetensors رو پیشنهاد می‌کنه.
یه نمونه جالب‌تر هم توسط HiddenLayer گزارش شده؛ مهاجم با یک فایل مخرب PyTorch تونسته بود سرویس تبدیل مدل Hugging Face رو هدف قرار بده، توکن ربات رسمی رو به دست بیاره و حتی از طرف اون ربات درخواست تغییر ثبت کنه.
یعنی حمله فقط به «مدل» انجام نشده؛ بلکه به سرویس مورد اعتمادی انجام شده که اطراف مدل قرار داشته.
برای عامل‌های هوش مصنوعی این موضوع جدی‌تر هم میشه. چون عامل فقط متن تولید نمی‌کنه؛ ممکنه به فایل، API، مخزن کد، سیستم ساخت و استقرار یا ابزارهای مختلف دسترسی داشته باشه.
حالا تصور کنید یک صفحه وب، فایل یا داده‌ای که عامل می‌خونه، حاوی دستور مخربی باشه. اگر عامل بدون بررسی به اون اعتماد کنه، ممکنه کاری انجام بده که کاربر اصلاً درخواست نکرده.
اینجا یک اشتباه رایج وجود داره: فکر کنیم اگر خود مدل رو ایمن کنیم، کل سیستم امن شده.
در واقع باید دو بخش رو جداگانه محافظت کنیم:
یکی زنجیره تأمین مدل؛ یعنی منبع مدل، داده‌ها، فایل وزن‌ها، صحت فایل و سابقه تغییرات.
دومی لایه اجرای عامل؛ یعنی اینکه عامل به چه ابزارهایی دسترسی داره، چه دستوری می‌تونه اجرا کنه و چه اطلاعاتی می‌تونه بخونه یا تغییر بده.
چند کار ساده هم می‌تونه ریسک رو خیلی کمتر کنه:
۱. صحت فایل‌های مدل و داده‌ها رو قبل از استفاده بررسی کنیم.
۲. تا جای ممکن از قالب‌های ناامن برای مدل‌ها استفاده نکنیم.
۳. مدل و داده‌ای که منبعش مشخص نیست رو قابل اعتماد فرض نکنیم.
۴. دسترسی عامل‌ها رو تا حد ممکن محدود کنیم.
۵. دسترسی به کلیدها، رمزها و اطلاعات حساس رو از عامل‌ها جدا کنیم.
۶. اجرای ابزارها رو هم مثل خود مدل، بخشی از سطح حمله در نظر بگیریم.
به نظرم با گسترش عامل‌های هوش مصنوعی، «امنیت مدل» دیگه به‌تنهایی کافی نیست.
اگر یک عامل به ابزارهای واقعی دسترسی داشته باشه، یک ورودی مخرب می‌تونه از یک مشکل ساده در متن، تبدیل به دسترسی به فایل‌ها، اطلاعات حساس یا حتی سیستم‌های دیگر بشه.
در نهایت هوش مصنوعی فقط سرعت انجام کارها رو بیشتر نمی‌کنه؛ اگر دسترسی‌ها درست کنترل نشن، سرعت آسیب‌زدن رو هم بیشتر می‌کنه.
#AIAgents
#AI
🔥1
یه جمله دیدم که به نظرم خیلی خوب اصل ماجرا درباره برنامه‌نویسی با هوش مصنوعی رو توضیح میده.
اینکه بتونی با AI حرف بزنی یا چندین عامل هوش مصنوعی رو همزمان اجرا کنی، به‌تنهایی مهارت خیلی خاصی نیست.
مشکل اصلی اینجاست که وقتی هوش مصنوعی برات کد تولید می‌کنه، باید خودت بتونی بفهمی این کد واقعاً خوبه یا نه.
باید برنامه‌نویسی بلد باشی، مبانی علوم کامپیوتر رو بفهمی و تجربه کافی داشته باشی تا بتونی خروجی AI رو بررسی کنی.
چون بخش زیادی از کدی که مدل‌ها تولید می‌کنن، مخصوصاً وقتی پروژه بزرگ‌تر و جدی‌تر میشه، ممکنه فقط ظاهراً درست باشه و در عمل پر از تصمیم‌های بد، پیچیدگی اضافه یا مشکلات معماری باشه.
حتی طراحی یک سیستم جدید با کمک AI هم بدون دانش کافی ساده نیست؛ چه برسه به بازطراحی یک سیستم قدیمی که باید اول معماری فعلیش رو عمیقاً بفهمی.
به نظرم مهارت اصلی در آینده این نیست که «چقدر خوب با AI کار می‌کنی».
مهارت اصلی اینه که بتونی تشخیص بدی:
چه چیزی باید ساخته بشه؟
چطور باید ساخته بشه؟
کدوم راه‌حل بهتره؟
کجا باید به خروجی AI شک کنی؟
و چه زمانی اصلاً نباید از راه‌حل پیشنهادی AI استفاده کنی؟
در نهایت چیزی که این توانایی رو می‌سازه، قضاوت مهندسیه.
و قضاوت مهندسی هم با زیادتر استفاده کردن از AI به وجود نمیاد؛ از یادگیری مبانی درست، تجربه و حل کردن مسائل واقعی به دست میاد.
#AI
اینکه بتونی با AI حرف بزنی یا چندین عامل هوش مصنوعی رو همزمان اجرا کنی، به‌تنهایی مهارت خیلی خاصی نیست.
مشکل اصلی اینجاست که وقتی هوش مصنوعی برات کد تولید می‌کنه، باید خودت بتونی بفهمی این کد واقعاً خوبه یا نه.
باید برنامه‌نویسی بلد باشی، مبانی علوم کامپیوتر رو بفهمی و تجربه کافی داشته باشی تا بتونی خروجی AI رو بررسی کنی.
چون بخش زیادی از کدی که مدل‌ها تولید می‌کنن، مخصوصاً وقتی پروژه بزرگ‌تر و جدی‌تر میشه، ممکنه فقط ظاهراً درست باشه و در عمل پر از تصمیم‌های بد، پیچیدگی اضافه یا مشکلات معماری باشه.
حتی طراحی یک سیستم جدید با کمک AI هم بدون دانش کافی ساده نیست؛ چه برسه به بازطراحی یک سیستم قدیمی که باید اول معماری فعلیش رو عمیقاً بفهمی.
به نظرم مهارت اصلی در آینده این نیست که «چقدر خوب با AI کار می‌کنی».
مهارت اصلی اینه که بتونی تشخیص بدی:
چه چیزی باید ساخته بشه؟
چطور باید ساخته بشه؟
کدوم راه‌حل بهتره؟
کجا باید به خروجی AI شک کنی؟
و چه زمانی اصلاً نباید از راه‌حل پیشنهادی AI استفاده کنی؟
در نهایت چیزی که این توانایی رو می‌سازه، قضاوت مهندسیه.
و قضاوت مهندسی هم با زیادتر استفاده کردن از AI به وجود نمیاد؛ از یادگیری مبانی درست، تجربه و حل کردن مسائل واقعی به دست میاد.
#AI
❤1
یه افزونه جالب برای Burp Suite پیدا کردم که برای بررسی فایل‌های JavaScript ساخته شده.
اسمش Burp JS LinkFinder Enhanced هست و هدفش پیدا کردن لینک‌ها، مسیرهای مخفی و اطلاعات حساس داخل فایل‌های JavaScript هست.
خیلی وقت‌ها وقتی یک سایت رو تست می‌کنیم، بخش زیادی از اطلاعات جالب داخل کدهای سمت کاربر قرار داره؛ مثلاً مسیرهای API، endpointهای مخفی، آدرس سرویس‌ها، پارامترهای مختلف و گاهی هم اطلاعاتی که اصلاً نباید داخل فایل JavaScript منتشر شده باشن.
این افزونه می‌تونه در کنار Burp Suite این موارد رو سریع‌تر استخراج کنه و به پیدا کردن سطح حمله برنامه کمک کنه.
به نظرم برای تست نفوذ وب، مخصوصاً مرحله جمع‌آوری اطلاعات و پیدا کردن مسیرهای پنهان برنامه، ابزار کاربردی‌ایه.
البته خروجی ابزار به‌تنهایی به معنی وجود آسیب‌پذیری نیست؛ بیشتر باید بهش به چشم یک راه برای پیدا کردن نقاطی نگاه کرد که ارزش بررسی دستی بیشتری دارن.
اگر با Burp Suite کار می‌کنید، ارزش امتحان کردن داره.
https://github.com/panchocosil/burp-js-linkfinder-enhanced
اسمش Burp JS LinkFinder Enhanced هست و هدفش پیدا کردن لینک‌ها، مسیرهای مخفی و اطلاعات حساس داخل فایل‌های JavaScript هست.
خیلی وقت‌ها وقتی یک سایت رو تست می‌کنیم، بخش زیادی از اطلاعات جالب داخل کدهای سمت کاربر قرار داره؛ مثلاً مسیرهای API، endpointهای مخفی، آدرس سرویس‌ها، پارامترهای مختلف و گاهی هم اطلاعاتی که اصلاً نباید داخل فایل JavaScript منتشر شده باشن.
این افزونه می‌تونه در کنار Burp Suite این موارد رو سریع‌تر استخراج کنه و به پیدا کردن سطح حمله برنامه کمک کنه.
به نظرم برای تست نفوذ وب، مخصوصاً مرحله جمع‌آوری اطلاعات و پیدا کردن مسیرهای پنهان برنامه، ابزار کاربردی‌ایه.
البته خروجی ابزار به‌تنهایی به معنی وجود آسیب‌پذیری نیست؛ بیشتر باید بهش به چشم یک راه برای پیدا کردن نقاطی نگاه کرد که ارزش بررسی دستی بیشتری دارن.
اگر با Burp Suite کار می‌کنید، ارزش امتحان کردن داره.
https://github.com/panchocosil/burp-js-linkfinder-enhanced
❤1
یه ابزار جالب به اسم FlareProx دیدم که از زیرساخت Cloudflare برای ساخت پراکسی‌های عبوری HTTP استفاده می‌کنه.
ایده‌ش نسبتاً ساده‌ست؛ درخواست‌های HTTP از طریق شبکه Cloudflare عبور می‌کنن و می‌تونی برای تست، ترافیک رو از مسیرهای مختلف شبکه عبور بدی.
از متدهای مختلف HTTP مثل GET، POST، PUT، DELETE، PATCH، OPTIONS و HEAD پشتیبانی می‌کنه و راه‌اندازیش هم ظاهراً خیلی ساده‌ست.
یکی از نکات جالبش استفاده از شبکه گسترده Cloudflare و محدودیت رایگان حدود ۱۰۰ هزار درخواست در روزه.
به نظرم برای آزمایش‌های امنیتی، بررسی رفتار سرویس‌ها و ساخت محیط‌های تست می‌تونه ابزار جالبی باشه.
البته مثل هر ابزار پراکسی دیگه‌ای، استفاده ازش باید در محیط‌هایی باشه که مجوز تستشون رو دارید.
https://github.com/MrTurvey/flareprox
ایده‌ش نسبتاً ساده‌ست؛ درخواست‌های HTTP از طریق شبکه Cloudflare عبور می‌کنن و می‌تونی برای تست، ترافیک رو از مسیرهای مختلف شبکه عبور بدی.
از متدهای مختلف HTTP مثل GET، POST، PUT، DELETE، PATCH، OPTIONS و HEAD پشتیبانی می‌کنه و راه‌اندازیش هم ظاهراً خیلی ساده‌ست.
یکی از نکات جالبش استفاده از شبکه گسترده Cloudflare و محدودیت رایگان حدود ۱۰۰ هزار درخواست در روزه.
به نظرم برای آزمایش‌های امنیتی، بررسی رفتار سرویس‌ها و ساخت محیط‌های تست می‌تونه ابزار جالبی باشه.
البته مثل هر ابزار پراکسی دیگه‌ای، استفاده ازش باید در محیط‌هایی باشه که مجوز تستشون رو دارید.
https://github.com/MrTurvey/flareprox
GitHub
GitHub - MrTurvey/flareprox: Use Cloudflare to create HTTP pass-through proxies for unique IP rotation, similar to fireprox
Use Cloudflare to create HTTP pass-through proxies for unique IP rotation, similar to fireprox - MrTurvey/flareprox
❤1
یه ابزار جالب برای تست امنیت GraphQL پیدا کردم به اسم Clairvoyance.
ایده‌ش اینه که باهاش میشه ساختار یک API مبتنی بر GraphQL رو بهتر شناسایی کرد و برای پیدا کردن بخش‌های مختلف API ازش استفاده کرد.
یکی از کاربردهای مهمش زمانی هست که قابلیت introspection در GraphQL غیرفعال شده باشه. ابزار تلاش می‌کنه با بررسی رفتار API، اطلاعاتی درباره schema و بخش‌های مختلف اون به دست بیاره.
این موضوع برای تست نفوذ جالبه، چون قبل از اینکه بخوایم سراغ آسیب‌پذیری‌های GraphQL بریم، باید بدونیم با چه queryها، typeها، fieldها و mutationهایی طرف هستیم.
در واقع ابزار بیشتر به مرحله شناسایی کمک می‌کنه؛ بعد از اون میشه مواردی مثل کنترل دسترسی، دسترسی به داده‌های حساس و منطق درخواست‌ها رو به‌صورت دستی بررسی کرد.
اگر روی APIهای GraphQL کار می‌کنید، Clairvoyance می‌تونه ابزار جالبی برای جعبه‌ابزار تست نفوذتون باشه.
https://github.com/nikitastupin/clairvoyance
ایده‌ش اینه که باهاش میشه ساختار یک API مبتنی بر GraphQL رو بهتر شناسایی کرد و برای پیدا کردن بخش‌های مختلف API ازش استفاده کرد.
یکی از کاربردهای مهمش زمانی هست که قابلیت introspection در GraphQL غیرفعال شده باشه. ابزار تلاش می‌کنه با بررسی رفتار API، اطلاعاتی درباره schema و بخش‌های مختلف اون به دست بیاره.
این موضوع برای تست نفوذ جالبه، چون قبل از اینکه بخوایم سراغ آسیب‌پذیری‌های GraphQL بریم، باید بدونیم با چه queryها، typeها، fieldها و mutationهایی طرف هستیم.
در واقع ابزار بیشتر به مرحله شناسایی کمک می‌کنه؛ بعد از اون میشه مواردی مثل کنترل دسترسی، دسترسی به داده‌های حساس و منطق درخواست‌ها رو به‌صورت دستی بررسی کرد.
اگر روی APIهای GraphQL کار می‌کنید، Clairvoyance می‌تونه ابزار جالبی برای جعبه‌ابزار تست نفوذتون باشه.
https://github.com/nikitastupin/clairvoyance
GitHub
GitHub - nikitastupin/clairvoyance: Obtain GraphQL API schema even if the introspection is disabled
Obtain GraphQL API schema even if the introspection is disabled - nikitastupin/clairvoyance
❤1
چند هفته‌ایه که جدی‌تر وارد دنیای توسعه با عامل‌های هوش مصنوعی شدم و چیزی که برام جالب بود، تفاوتش با تجربه‌های قبلیه.
قبلاً با کمک هوش مصنوعی پروژه‌های کوچیک و نمونه‌های اولیه ساخته بودم، ولی این بار تصمیم گرفتم یک پروژه بزرگ‌تر رو با حجم قابل‌توجهی از زیرساخت، تست و کد جلو ببرم.
هدفم هم فقط ساختن یک پروژه نبود. بیشتر می‌خواستم ببینم عامل‌های مختلف در کارهایی مثل طراحی معماری، نوشتن کد، مهاجرت بین چارچوب‌ها، نوشتن تست، پیدا کردن باگ و آسیب‌پذیری و حتی پیشنهاد قابلیت‌های جدید چقدر می‌تونن کمک کنن.
چند تا نکته مثبت واقعاً برام جالب بود:
اول اینکه برای ساخت نمونه اولیه فوق‌العاده سریع هستن. چیزی که قبلاً شاید چند روز زمان می‌برد، الان ممکنه در چند ساعت به یک نمونه قابل استفاده برسه.
نوشتن تست هم خیلی راحت‌تر شده. شاید تست‌هایی که تولید می‌کنن همیشه کامل یا ایده‌آل نباشن، ولی میشه در زمان خیلی کوتاهی بخش بزرگی از کد رو پوشش داد و مشکلات رو سریع‌تر پیدا کرد.
مستندسازی هم خیلی بهتر شده. اگر عامل رو درست تنظیم کنید، می‌تونه همزمان با توسعه، مستندات پروژه رو هم به‌روز نگه داره.
برای من به‌عنوان کسی که با داده و یادگیری ماشین کار کرده، یک تغییر جالب دیگه هم اینه که ساخت ابزارهای تعاملی خیلی راحت‌تر شده. قبلاً برای ساخت یک رابط مناسب باید زمان زیادی صرف می‌کردیم؛ الان ممکنه یک نوت‌بوک رو با چند دستور به یک برنامه تعاملی تبدیل کنیم.
اما بخش جالب‌تر، معایب ماجراست.
اگر از خود برنامه‌نویسی لذت ببرید، کار کردن با عامل‌ها می‌تونه کمی عجیب باشه.
قبلاً وقتی کد می‌نوشتم، یکی دو ساعت کامل وارد فضای پروژه می‌شدم و در نهایت احساس رضایت داشتم.
ولی حالا ممکنه مدام بین چند پنجره جابه‌جا بشم، به عامل دستور بدم، خروجی رو بررسی کنم، دوباره اصلاحش کنم و کار بعدی رو تعریف کنم.
دو ساعت گذشته، کلی کار انجام شده، ولی اون حس رضایت قبلی رو ندارم.
از طرف دیگه، وقتی می‌تونی چند عامل رو همزمان اجرا کنی، خیلی راحت وارد چرخه‌ای میشی که تقریباً تمام روز پروژه در حال پیشرفته.
شب قبل از خواب یک کار میدی، صبح نتیجه رو بررسی می‌کنی، موقع صبحانه کار بعدی رو می‌فرستی، در مسیر رفت‌وآمد دوباره خروجی‌ها رو چک می‌کنی و همین‌طور ادامه میدی.
ظاهراً داری فقط در یک چت کار می‌کنی، ولی در واقع ممکنه تمام روز درگیر پروژه باشی.
مشکل بعدی، کنترل روی کده.
وقتی حجم زیادی از کد رو عامل‌ها تولید می‌کنن، دیگه خیلی سخت میشه همه چیز رو در جزئیات فهمید.
گاهی حتی تصمیم‌هایی داخل پروژه گرفته میشه که برای فهمیدن درست یا غلط بودنشون باید زمان زیادی بذاری.
در نتیجه نقش برنامه‌نویس کم‌کم می‌تونه از «نوشتن کد» به «مدیریت و هدایت چند عامل» تغییر کنه.
یعنی باید بدونی چه کاری رو به کدوم عامل بدی، خروجی رو چطور بررسی کنی، کجا دخالت کنی و کجا اجازه بدی خودش ادامه بده.
و البته هزینه توکن‌ها هم شوخی نیست. وقتی چند عامل رو به‌صورت مداوم اجرا می‌کنی، مصرف خیلی سریع بالا میره.
با این حال، چیزی که بیشتر از همه ذهنم رو درگیر کرده اینه:
اگر هوش مصنوعی بتونه بخش بزرگی از کار فنی رو انجام بده، ارزش اصلی برنامه‌نویس از کجا میاد؟
به نظرم جواب هنوز همون چیزیه که قبلاً درباره‌ش صحبت کرده بودم:
قضاوت مهندسی.
اینکه بدونی چه چیزی باید ساخته بشه، معماری مناسب چیه، کجا باید به خروجی AI شک کنی و کجا اصلاً نباید اجازه بدی عامل تصمیم بگیره.
هوش مصنوعی می‌تونه مقدار زیادی کد تولید کنه.
ولی هنوز کسی باید تشخیص بده که آیا اصلاً این کد باید وجود داشته باشه یا نه.
#تجربه
#AI
قبلاً با کمک هوش مصنوعی پروژه‌های کوچیک و نمونه‌های اولیه ساخته بودم، ولی این بار تصمیم گرفتم یک پروژه بزرگ‌تر رو با حجم قابل‌توجهی از زیرساخت، تست و کد جلو ببرم.
هدفم هم فقط ساختن یک پروژه نبود. بیشتر می‌خواستم ببینم عامل‌های مختلف در کارهایی مثل طراحی معماری، نوشتن کد، مهاجرت بین چارچوب‌ها، نوشتن تست، پیدا کردن باگ و آسیب‌پذیری و حتی پیشنهاد قابلیت‌های جدید چقدر می‌تونن کمک کنن.
چند تا نکته مثبت واقعاً برام جالب بود:
اول اینکه برای ساخت نمونه اولیه فوق‌العاده سریع هستن. چیزی که قبلاً شاید چند روز زمان می‌برد، الان ممکنه در چند ساعت به یک نمونه قابل استفاده برسه.
نوشتن تست هم خیلی راحت‌تر شده. شاید تست‌هایی که تولید می‌کنن همیشه کامل یا ایده‌آل نباشن، ولی میشه در زمان خیلی کوتاهی بخش بزرگی از کد رو پوشش داد و مشکلات رو سریع‌تر پیدا کرد.
مستندسازی هم خیلی بهتر شده. اگر عامل رو درست تنظیم کنید، می‌تونه همزمان با توسعه، مستندات پروژه رو هم به‌روز نگه داره.
برای من به‌عنوان کسی که با داده و یادگیری ماشین کار کرده، یک تغییر جالب دیگه هم اینه که ساخت ابزارهای تعاملی خیلی راحت‌تر شده. قبلاً برای ساخت یک رابط مناسب باید زمان زیادی صرف می‌کردیم؛ الان ممکنه یک نوت‌بوک رو با چند دستور به یک برنامه تعاملی تبدیل کنیم.
اما بخش جالب‌تر، معایب ماجراست.
اگر از خود برنامه‌نویسی لذت ببرید، کار کردن با عامل‌ها می‌تونه کمی عجیب باشه.
قبلاً وقتی کد می‌نوشتم، یکی دو ساعت کامل وارد فضای پروژه می‌شدم و در نهایت احساس رضایت داشتم.
ولی حالا ممکنه مدام بین چند پنجره جابه‌جا بشم، به عامل دستور بدم، خروجی رو بررسی کنم، دوباره اصلاحش کنم و کار بعدی رو تعریف کنم.
دو ساعت گذشته، کلی کار انجام شده، ولی اون حس رضایت قبلی رو ندارم.
از طرف دیگه، وقتی می‌تونی چند عامل رو همزمان اجرا کنی، خیلی راحت وارد چرخه‌ای میشی که تقریباً تمام روز پروژه در حال پیشرفته.
شب قبل از خواب یک کار میدی، صبح نتیجه رو بررسی می‌کنی، موقع صبحانه کار بعدی رو می‌فرستی، در مسیر رفت‌وآمد دوباره خروجی‌ها رو چک می‌کنی و همین‌طور ادامه میدی.
ظاهراً داری فقط در یک چت کار می‌کنی، ولی در واقع ممکنه تمام روز درگیر پروژه باشی.
مشکل بعدی، کنترل روی کده.
وقتی حجم زیادی از کد رو عامل‌ها تولید می‌کنن، دیگه خیلی سخت میشه همه چیز رو در جزئیات فهمید.
گاهی حتی تصمیم‌هایی داخل پروژه گرفته میشه که برای فهمیدن درست یا غلط بودنشون باید زمان زیادی بذاری.
در نتیجه نقش برنامه‌نویس کم‌کم می‌تونه از «نوشتن کد» به «مدیریت و هدایت چند عامل» تغییر کنه.
یعنی باید بدونی چه کاری رو به کدوم عامل بدی، خروجی رو چطور بررسی کنی، کجا دخالت کنی و کجا اجازه بدی خودش ادامه بده.
و البته هزینه توکن‌ها هم شوخی نیست. وقتی چند عامل رو به‌صورت مداوم اجرا می‌کنی، مصرف خیلی سریع بالا میره.
با این حال، چیزی که بیشتر از همه ذهنم رو درگیر کرده اینه:
اگر هوش مصنوعی بتونه بخش بزرگی از کار فنی رو انجام بده، ارزش اصلی برنامه‌نویس از کجا میاد؟
به نظرم جواب هنوز همون چیزیه که قبلاً درباره‌ش صحبت کرده بودم:
قضاوت مهندسی.
اینکه بدونی چه چیزی باید ساخته بشه، معماری مناسب چیه، کجا باید به خروجی AI شک کنی و کجا اصلاً نباید اجازه بدی عامل تصمیم بگیره.
هوش مصنوعی می‌تونه مقدار زیادی کد تولید کنه.
ولی هنوز کسی باید تشخیص بده که آیا اصلاً این کد باید وجود داشته باشه یا نه.
#تجربه
#AI
👍1