tech-afternoon

📰 در باب مرور و تحلیل اخبار - بخش اول در مورد خبر «طرح خروج داوطلبانه ۶۰هزار کارمند مایکروسافت» که دیشب منتشر شد، یه پیشنهاد دوستانه دارم: قبل از لایک یا بازنشر کردن انبوه پست‌هایی که عموماً نویسنده‌هاشون به محض خوندن آخرین کلمه از «تیتر خبر»، و نه حتی پاراگراف اولش، دست به تایپ می‌شن؛ متن خبر رو دقیق بخونیم و کمی فکر کنیم. چند خطی رو درباره اخبار، خصوصاً موارد اینچنینی که حواشی زیادی درست می‌کنه، و البته مزخرفاتی که حولش شکل می‌گیره نوشتم؛ دوست داشتید بخونید...

🔗 وقتی یه Agent کافی نیست! ساختن AI Agent کار ساده‌ایه، اما وقتی چند ایجنت با مسئولیت‌های متفاوت داریم، چه کسی باید بینشون هماهنگی ایجاد کنه؟ اصلاً همیشه به چند ایجنت نیاز داریم؟! توی این مطلب، یعنی «مثالی از پیاده‌سازی Agent Orchestration» با یه مثال واقعی، یه پیاده‌سازی از معماری Multi-Agent و Agent Orchestration رو با ابزارهای متن‌باز مثل LangGraph، LiteLLM و Ollama، ساختار و نحوه پیاده‌سازی‌ش رو توضیح دادم. سعی کردم مثال بدون وابستگی به سرویس‌های ابری و قابل اجرا روی سیستم شخصی یا سرور باشه. 📖 مطالعه مطلب + کد پروژه 💬 بحث؟ نظر؟ کامنت؟

بنا به نتیجه نظرسنجی؛ مطلب بعدی: مثال از پیاده‌سازی یه سیستم multi-agent همراه با orchestrator توضیح اولیه که در تصویر است رو بخونید و اگر فیدبک و پیشنهادی دارید لطفا کامنت کنید 😊 به زودی... #موقت

🔗 معرفی LayerFS برای وقتی ایجنت‌ها زیاد می‌شن! فرض کنین یه پروژه نرم‌افزاری بزرگ دارین و به‌جای اینکه یه ایجنت رو مأمور Refactoring کنین، تصمیم می‌گیرین ۲۰ تا ایجنت رو هم‌زمان به کار بگیرین؛ ۵ تا برای refactoring، پنج‌تا هم برای پیدا کردن و رفع Bug، پنج‌تا برای نوشتن تست و پنج‌تای دیگه هم برای امتحان کردن روش‌های مختلف بهینه‌سازی performance. خب؟ روی کاغذ خوبه؛ ولی یه مشکل اساسی داریم: هر Agent برای کارش به سورس‌کد پروژه، dependencyها و یه محیط اجرایی مستقل نیاز داره. راه‌حل‌های دوران پیشاهوشواره (ماقبل AI) مثل git تا حد خوبی این نیاز رو برطرف می‌کنن، ولی وقتی تعداد Agentها به ده‌ها یا صدها برسه، مدیریت این محیط‌ها، نگهداری فایل‌های تکراری، آماده‌سازی dependencyها و هماهنگی تغییرات، خودش تبدیل به یه چالش جدی می‌شه. مثلاً وقتی یه پروژه‌ با سورس‌کد ۱۰۰ گیگابایتی دارین؛ چرا باید برای هر Agent یک کپی جداگانه از همه‌چیز داشته باشین؟ از طرفی هم نمی‌شه همه از یه نسخه مشترک استفاده کنن و فقط تغییرات خودشون رو مستقل نگه دارن؟ دلیل پیدایش پروژه متن‌باز LayerFS همین مسئله بود! ایده اصلیش Ephemeral Workspaces, Durable Shared History است؛ یعنی محیط‌های کاری موقت، با تاریخچه تغییرات ماندگار و مشترک. به زبون ساده، هر ایجنت یه workspace مستقل داره، بدون اینکه لازم باشه همه فایل‌ها و dependencyهای پروژه براش کپی بشن. همه از یه پایه مشترک استفاده می‌کنن و فقط تغییرات اختصاصی خودشون رو نگه می‌دارن. قابلیت جذاب‌ترش اینکه تغییرات می‌تونن به‌صورت checkpoint ثبت بشن. فرض کنین یه ایجنت برای refactoring چهار مرحله جلو رفته، ولی توی مرحله چهارم به بن‌بست رسیده. می‌شه از مرحله دوم یه branch جدید ساخت و به چند ایجنت دیگه سپرد تا مسیرهای متفاوتی رو امتحان کنن. حتی می‌شه ۵۰ تا ایجنت رو روی ۵۰ راه‌حل متفاوت برای یه مسئله به کار گرفت، بعد خروجی‌ها رو تست و مقایسه کرد و بهترین گزینه رو انتخاب کرد. البته انتخاب بهترین راه‌حل کار خود LayerFS نیست؛ این زیرساخت فقط اجرای چنین الگویی رو ساده‌تر می‌کنه. از نظر فنی هم پروژه با ترکیبی از تکنیک‌های شناخته‌شده و حتی قدیمی مثل Copy-on-Write، Content-Addressed Storage و SQLite پیاده‌سازی شده و ادعاهای جالبی درباره کاهش مصرف استورج و زمان آماده‌سازی Workspaceها داره. البته هنوز محدودیت‌هایی هم داره، مثل محدودیت اشتراک Store بین ماشین‌های مستقل، یا مدیریت Conflictهای منطقی و بعضی ملاحظات مربوط به Durability. بنابراین فعلاً نباید بهش به‌عنوان «امروزه، عصر، عسر LayerFS است و هر کس بلد نباشه یا استفاده نکنه، ابله است» نگاه کنیم. 💡 اما به نظرم نکته مهم‌تر از خود LayerFS؛ مسئله‌ایه که داره حل می‌کنه. ما داریم به سمتی می‌ریم که توسعه نرم‌افزار لزوماً به معنی همکاری یه برنامه‌نویس با یه ایجنت نیست. ممکنه به معنی اجرای ده‌ها یا صدها ایجنت باشه که هم‌زمان فرضیه‌های مختلف رو امتحان می‌کنن، شکست می‌خورن، به عقب برمی‌گردن و مسیرهای جدیدی رو پیش می‌گیرن. برای چنین آینده‌ای، فقط مدل‌های هوشمندتر کافی نیستن. به زیرساخت‌هایی نیاز داریم که این شکل از توسعه رو از نظر هزینه، سرعت، مدیریت state و قابلیت ردیابی عملی کنن. و LayerFS قرار نیست ایجنت‌ها رو باهوش‌تر کنه؛ می‌خواد کاری کنه که بتونیم تعداد خیلی بیشتری از اون‌ها رو به شکل مؤثر، کنار هم به کار بگیریم و هزینه منابع رو در سطح استورج و زمان، کنترل کنیم. و شاید این بخشِ کمتر دیده‌شده‌ یا کمتر پرداخته‌شده‌ای از تحول AI-Native Software Engineering باشه: تحول توی زیرساخت توسعه، نه صرفاً ابزار تولید کد یا حتی محصول. 🔗 وب‌سایتش 🔗 سورس‌کدش

🤖 اهمیت تخصص «امنیت AI» در آینده شغلی! اخیراً لابه‌لای اخبار، مرتب از سرکشی و افسارگسیختگی ایجنت‌های هوش مصنوعی می‌خونیم؛ اینکه فلان ایجنت به سیستم‌های یک شرکت، سازمان دولتی یا حتی بیمارستان نفوذ کرده و به اطلاعاتی که نباید، دسترسی پیدا کرده، یا به طور خلاصه، یه غلطی کرده! اما به نظر من قبل از اینکه مثل اکثر رسانه‌ها، داستان‌سرایی کنیم که «هوش مصنوعی از کنترل خارج شد!» و واویلا شده و پس‌فردا میاد می‌خورتمون؛ باید یه سؤال اساسی رو جواب بدیم: اصلاً چی می‌شه که یه Agent تصمیم می‌گیره بره یه جایی رو هک کنه؟! طبیعتاً ماجرا این نبوده که ایجنت صبح از خواب بیدار شده، مسواک زده، بعد موقع سرکشیدن قهوه با خودش گفته: «خب امروز چیکار کنیم؟ آها! بریم Hugging Face رو هک کنیم!» 😁 این ایجنت‌ها مأموریتی داشتن که هدف اولیه‌اش توسط انسان تعیین شده بوده. برای رسیدن به اون هدف هم می‌تونستن برنامه‌ریزی کنن، از ابزارهای مختلف استفاده کنن، نتیجه کارشون رو بررسی کنن و اگر راهی به نتیجه نرسید، راه دیگه‌ای امتحان کنن. گزارش رسمی Hugging Face میگه ایجنت‌های درگیر، در یک ارزیابی امنیتی با استفاده از آسیب‌پذیری‌ها و دسترسی‌های به‌دست‌ اومده، در نهایت وارد زیرساختشون شدن. تحلیلشون اینه که ایجنت احتمالاً می‌خواستی پاسخ‌های مربوط به آزمون رو به دست بیاره، نه اینکه صرفاً یک هدف تصادفی رو هک کنه. ولی مسئله از اونجایی شروع می‌شه که ایجنت (یا ایجنت‌ها در تعامل با هم) توی مسیر رسیدن به هدف، با محدودیتی مواجه می‌شن و به‌جای اینکه متوقف بشن، اون محدودیت رو هم به چشم یک مسئله قابل‌حل می‌بینن! و ماجرا وقتی پیچیده‌تر می‌شه که مسئله، خودش به چند مسئله دیگه شکسته می‌شه. ایجنت برای حل مسئله اول، سراغ مسئله دوم می‌ره، بعد سوم و همین‌طور جلوتر می‌ره. حالا ممکنه توی مسئله دهم یا بیستم، محدودیت‌های مأموریت اولیه به‌درستی لحاظ نشده باشن و ایجنت مسیری رو انتخاب کنه که با هدف اصلی سازگاره، ولی با قواعد یا محدودیت‌هاش نه! البته همه رخدادهای امنیتی ایجنت‌ها از این جنس نیستن؛ گاهی هم پای Prompt Injection وسطه، گاهی ضعف زیرساخت و گاهی هم خود مأموریت یا اختیاراتی که به Agent داده می‌شه مشکل‌سازه. ولی نکته مهم اینه که مجاز بودن هدف، لزوماً به معنی مجاز بودن تمام مسیرهای رسیدن به اون هدف نیست. راه‌حل چیه؟ از این به بعد فقط مأموریت‌هایی به ایجنت‌ها بدیم که هیچ خطری نداشته باشن؟ یا توی پرامپت بنویسیم «لطفاً برای رسیدن به هدفت مرتکب هیچ نوع وندالیسمی نشو!» و امیدوار باشیم حرف‌گوش‌کن باشن؟! طبیعتاً نه! داستان روش‌های امنیت ایجنت، اینجا وسط میاد. همون‌طور که با گسترش شبکه‌ها و اینترنت، به‌تدریج فایروال‌ها، سیستم‌های تشخیص نفوذ، کنترل دسترسی و لایه‌های مختلف امنیتی شکل گرفتن، حالا هم با گسترش سیستم‌های Agentic، به مکانیزم‌هایی نیاز داریم که متناسب با قابلیت‌های جدید این سیستم‌ها طراحی شده باشن. ابزارهایی که فقط به نمی‌گن ایجنت چه کاری رو نباید انجام بده، بلکه بتونن جلوی عملیات غیرمجاز رو هم بگیرن (Preventive)، رفتارهای مشکوک رو شناسایی کنن (Detective) و در صورت وقوع تخلف، فعالیتش رو محدود یا متوقف کنن (Containment/Response). و این دقیقاً یکی از حوزه‌هاییه که در آینده جزو تخصص‌های مهندس و معماران نرم‌افزار و متخصصان امنیت خواهد بود و جایگزین برخی تخصص‌هایی میشه که شاید کمرنگ‌تر یا کم‌درخواست‌تر می‌شن. شرکت‌هایی پیشرو مثل SpaceXSI, NVIDIA، Microsoft، Google، AWS و بقیه هم دارن برای حل این مسئله راهکارهایی ارائه می‌دن و هر کدوم هم یه بخشی از مسئله رو هدف گرفتن... مثلاً NVIDIA اخیراً پلتفرم Open Agent Safety رو معرفی کرده. و OpenShell یکی از اجزاء این پلتفرمه که یه محیط اجرای ایزوله با کنترل دسترسی به شبکه، فایل‌ها و ابزارها فراهم می‌کنه. Sentry هم یکی دیگه از اجزائشه که هم با استفاده از DPU یه لایه مستقل نظارتی در سطح زیرساخت اضافه می‌کنه و هم می‌تونه ایجنت سرکش و از محدودیت‌ها خارج‌شده رو بگیره قرنطینه کنه. البته همه شرکت‌ها از یه مسیر به مسئله نگاه نمی‌کنن. مثلاً Microsoft روی هویت و مدیریت دسترسی Agentها، AWS روی اعمال Policy قبل از اجرای ابزارها، و NVIDIA روی ایزوله‌سازی و کنترل در سطح Runtime و زیرساخت تمرکز کردن. طبیعتاً هیچ‌کدوم از این رویکردها هم به‌تنهایی تمام مسئله رو حل نمی‌کنن. خلاصه اینکه به نظرم امنیت سیستم‌های ایجنتیک یا به‌صورت کلی امنیت AI یکی از حوزه‌هاییه که طی سال‌های آینده اهمیت بیشتری پیدا می‌کنه و یادگیری مفاهیم، روش‌ها و ابزارهاش برای مهندس‌های نرم‌افزار و متخصصین امنیت، می‌تونه فرصت‌های تازه‌ای ایجاد کنه. شاید به‌جای اینکه تمام وقتمون رو صرف اخبار آخرالزمانی درباره بیکارشدن برنامه‌نویس‌ها کنیم و نگران باشیم که بالاخره کی باید تحت پوشش مؤسسات خیریه و بهزیستی قرار بگیریم، بد نباشه بخشی از اون زمان رو صرف شناختن همین تغییرات و یادگرفتن تخصص‌های جدید کنیم! مسیر مهندسی نرم‌افزار بارها تغییر کرده و باز هم تغییر می‌کنه. مسئله این نیست که جاده چرا پیچ می‌خوره؛ مسئله اینه که آیا ما هم مهارت پیچیدن باهاش رو داریم یا نه! جاده داره می‌پیچه؛ باید یاد گرفت که چجوری فرمون رو هم چرخوند؛ چون با صاف‌رفتن، پیچ مستقیم نمی‌شه! 😉

تفاوت نرم‌افزار AI-Native با نرم‌افزاری پیری که فقط بهش چت‌بات چسبونده شده، یا صرفاً کدش با پرامپت‌نویسی تولید شده؛ بی‌شباهت بین این دو تا تصویر نیست. هر دو تا برقی هستن؛ ولی در نگاه به طراحی‌، و انتظار از محصول نهایی، تفاوت‌های عمیقی وجود داره. خیلی نرم‌افزارها هم امروز، یا یه چت‌بات مبتنی بر AI بهشون چسبیده یا همون رویکرد و طراحی قدیمی رو دارن با این تفاوت که فقط کدشون توسط AI توسعه داده شده... اما AI-Native Product Design یعنی از اول دوباره فکر کنیم که با وجود AI، چه مسئله‌هایی رو می‌شه متفاوت حل کرد، چه تعاملاتی دیگه ضروری نیستن و حتی چه قابلیت‌هایی قبلاً امکان‌پذیر نبودن. نکته اینجاست که طراحی یک محصول AI-Native با توسعه کد اون محصول به کمک AI، دو تا موضوع کاملاً متفاوته! شاید سؤال مهم این نباشه که «چقدر از AI توی توسعه نرم‌افزار استفاده می‌کنیم؟»، بلکه این باشه که «اگر امروز محصولمون رو از صفر طراحی می‌کردیم، با وجود AI باز هم همین محصول رو می‌ساختیم؟» رونوشت: اولی‌الابصار جهت تفکر! 😁

🧠 وقتی AI یاد می‌گیره روش کار کردن خودش رو بهتر کنه! مقاله‌ی اخیر Harness Learning Enables Generalizable Test-Time Adaptation (از دانشگاه کارنگی ملون که جزو بهترین دانشگاه‌های آمریکا توی علوم کامپیوتره) ایده‌ی بهبود عملکرد یه مدل، از طریق سیستمی که مدل داخلش کار می‌کنه، به جای تغییر وزن‌ها و آموزش مجددش رو مطرح می‌کنه. به مجموعه‌ی دستورالعمل‌ها، ابزارها، گردش کار و نحوه‌ی مدیریت اطلاعات که رفتار یک Agent رو شکل می‌ده؛ harness می‌گن. نویسنده‌ها مدلی رو آموزش دادن که با مشاهده‌ی نتیجه‌ی اجرای Agent، برنامه‌ی اجرایی اون رو اصلاح می‌کنه. جالب‌تر اینکه این تواناییِ اصلاح و سازگاری، تا حدی به مسئله‌های جدیدی که در زمان آموزش ندیده هم تعمیم پیدا کرده، بدون اینکه وزن‌های مدل اصلی تغییر کنن. شاید بخشی از آینده‌ی Agentها، نه فقط توی مدل‌های بزرگ‌تر، بلکه توی سیستم‌هایی باشه که از تجربه‌های قبلی یاد می‌گیرن چجوری از همون مدل‌ها بهتر استفاده کنن. این پژوهش هنوز به معنی خودبهبودی نامحدود Agentها نیست، اما مسیر تحقیقاتی خوبی رو نشون می‌ده که برخی شرکت‌ها هم مدت‌هاست روش کار می‌کنن. 📄 مطالعه‌ی مقاله در arXiv

🏎 فرمول یکی که هنوز پیستش نساختن! راننده‌های فرمول یک قبل از مسابقه، پیچ‌وخم‌های پیست رو بارها مرور می‌کنن. می‌دونند کجا باید ترمز کنن، کجا گاز بدن و کدوم پیچ‌ها خطرناک‌ترن. حالا تصور کنین مسابقه‌ای برگزار شده که راننده‌ها با سرعت تمام در حال حرکت‌اند، اما برگزارکننده‌ها هنوز دارن چند کیلومتر جلوتر پیست رو می‌سازن! جالب‌تر اینکه خود طراحان پیست هم فقط یک طرح کلی از مسیر آینده دارن و هنوز دقیقاً نمی‌دونن پیچ بعدی قراره به کجا برسه. به نظرم وضعیت امروز ما توی tech، خصوصاً با ظهور AI، خیلی با این مثال فرق نداره. ماشین‌هامون هر سال سریع‌تر می‌شن، اما میدان دیدمون لزوماً بیشتر نشده. فقط فاصله‌ی بین چیزهایی که امروز می‌دونیم و اونچه که هنوز نمی‌دونیم رو سریع‌تر طی می‌کنیم. مثلاً امروز، در اکتبر ۲۰۲۶، واقعاً چقدر می‌تونیم درباره‌ی توانمندی‌های AI در ژانویه‌ی ۲۰۲۷ با اطمینان صحبت کنیم؟ در موج‌های قبلی فناوری، مثلاً فراگیر شدن معماری‌های توزیع‌شده، معمولاً فرصت بیشتری برای یادگیری، تجربه کردن و تطبیق مهارت‌هامون داشتیم. البته اون دوران هم برای همه آروم و قابل پیش‌بینی نبود. اما حالا چرخه‌ی تغییر برخی ابزارها و مهارت‌ها به‌قدری کوتاه شده که ممکنه هنوز چیزی رو درست یاد نگرفته باشیم و نسخه‌ی جدیدش از راه برسه. مسئله دیگه فقط سرعت حرکت نیست؛ سرعت یادگیری، فراموش کردن دانسته‌های منسوخ و سازگار شدن با مسیر جدیده. اما این مسابقه، یه ویژگی جالب دیگه هم داره: بعضی از مهارت‌هایی که دیروز برای رانندگی ضروری بودن، امروز دیگه مزیت رقابتی محسوب نمیشن که هیچ؛ کسی هم براشون تره خرد نمی‌کنه. یادتون هست یه روزگاری برای خرید یه کامپیوتر ساده‌ی خونگی باید دست‌به‌دامن «آقای مهندس» می‌شدیم؟ چند سال بعدش، دیگه نیازی به «آقای مهندس» نبود. کافی بود به کامبیز، خدمات کامپیوتری محله، سفارش می‌دادیم؛ تلفنی چهار تا قطعه از بازار می‌گرفت، سرهم می‌کرد و تحویل می‌داد. بعدتر همین کارها رو جمال، پسرِ خاله‌‌اعظم‌، انجام می‌داد که از تأمین VPN فامیل تا تنظیم تلویزیون مادربزرگ، همه‌چیز روی سبیلش بود! و امروز؟ شما با یه دست لقمه‌ی کوکو رو می‌دی سمت خندق بلا، و با اون‌یکی دستت، لپ‌تاپ موردنظرت رو آنلاین سفارش می‌دی. سؤال: آیا صنعت سخت‌افزار از بین رفت؟ اتفاقاً نه. سخت‌افزار پیچیده‌تر، قدرتمندتر و توی خیلی از بخش‌ها تخصصی‌تر شد. چیزی که تغییر کرد، دسترسی به محصول و ارزش اقتصادی بعضی لایه‌های خدمات واسطه‌ای بود. چیزی که روزی دانش تخصصی و کمیاب به حساب میومد، به‌تدریج، تبدیل به یه کار ساده و روتین، خودکار یا در دسترس عموم شد. البته تمام خدمات کامپیوتری‌ها تعطیل نشدن؛ و تمام تکنسین‌های مونتاژ هم بیکار نشدن. بعضی‌شون متخصص شدن، بعضی‌شون هم حوزه‌ی فعالیتشون رو تغییر دادن و بعضی‌شون هم احتمالاً الان دارن کنار دفتر مشق و مداد رنگی، خدمات پرینت و کپی ارائه می‌دن. حالا همین فرایند رو توی صنعت نرم‌افزار تصور کنید. این روزها شبکه‌های اجتماعی پر شده از دوستانی که با چند تا Agent، یه‌شبه محصول (بخونید پروتوتایپ) ساختن. بعضی از این تجربه‌ها واقعاً ارزشمندن. اتفاقاً پایین اومدن هزینه‌ی آزمودن ایده‌ها یکی از جذاب‌ترین دستاوردهای AI است. ولی بعضی‌هاشون هم وزن شوآفش بیشتر از هر چیز دیگه‌ایه. اما ساختن چیزی که روی لپ‌تاپ خودمون کار می‌کنه یا نهایتاً روی VPS اجاره‌ای‌مون، الزاماً به معنی ساختن یه محصول نرم‌افزاری نیست. آیا کاربر واقعی داره؟ مسئله‌ای رو حل می‌کنه؟ و اگه قراره تجاری باشه، کسی حاضره بابتش هزینه کنه؟ هزینه‌ی زیرساخت و توکن‌هاش قابل توجیه و بازگشته؟ امنیت و پایداری داره؟ شیش ماه دیگه می‌شه توسعه‌اش داد؟ وقتی توی محیط پروداکشن مشکلی پیش بیاد، کسی می‌تونه ریشه‌ی مشکل رو پیدا کنه؟ اینجاست که فاصله‌ی یک دمو جذاب با یه محصول مهندسی‌شده خودش رو نشون می‌ده. البته خیلی از محصولات موفق هم از روز اول محصول کامل نبودن. خیلی‌هاشون از یه آزمایش کوچیک شروع شدن. اشکالی هم نداره کسی صرفاً برای یادگیری یا سرگرمی چیزی بسازه. ایراد از جایی شروع می‌شه که توانایی ابزار رو با دانش و توانایی خودمون اشتباه بگیریم. ما انسان‌ها قرن‌هاست سعی کردیم سر از چجوری کار کردن هر چیزی در بیاریم؛ حتی سازوکار بدن خودمون رو که محصول طراحی مهندسی خودمون نیست، هنوز به‌طور کامل نمی‌شناسیم. قرن‌هاست داریم روی بدنمون مطالعه می‌کنیم و همچنان چیزهای تازه کشف می‌کنیم. حالا جالبه که به نقطه‌ای رسیدیم که سیستم‌هایی رو خودمون طراحی و آموزش می‌دیم، اما نمی‌تونیم تمام رفتارهای آموخته‌شده‌ی اون‌ها رو دقیقاً توضیح بدیم. می‌دونیم شبکه‌های عصبی چجوری ساخته و آموزش داده می‌شن، ولی اینکه دقیقاً چه الگوها و بازنمایی‌هایی یاد گرفتن و چرا در شرایط مشخص خروجی خاصی تولید می‌کنن، هنوز از موضوعات جدی پژوهشیه. پس اگه با ابزاری که خودتون سازوکارش رو درست نمی‌شناسید، خروجی خیره‌کننده‌ای تولید کردید، خوشحال باشید، تجربه کنید، یاد بگیرید و حتی گاهی، و به اندازه، بهش افتخار کنید. اما تمام توانایی‌های ابزار رو به حساب دانایی خودتون نگذارید. اخوی! اینکه سوار آسانسور بشی و به طبقه‌ی پنجاهم برسی، معناش این نیست که پنجاه طبقه پله‌نوردی بلدی! البته بلد بودن کار با آسانسور هم بد نیست، خصوصاً وقتی دیگران هنوز دنبال پله می‌گردن! این حرف به معنی بی‌ارزش بودن مهارت استفاده از ابزار نیست. اتفاقاً استفاده‌ی ماهرانه از ابزار خودش تخصصه. اما باید فرق بین استفاده از فناوری، ساختن محصول با فناوری و توسعه‌ی خود فناوری رو بدونیم. همه هم قرار نیست طراح موتور فرمول یک باشن. راننده‌ی خوب، مهندس مسابقه و طراح موتور هرکدوم مهارت و ارزش خاص خودشون رو دارن. مسئله اینه که بدونیم توی کدوم نقش هستیم و چه ارزشی خلق می‌کنیم. به گمان من AI قرار نیست لزوماً تمام مهندس‌های نرم‌افزار رو حذف کنه، همون‌طور که ساده‌تر شدن خرید کامپیوتر، صنعت سخت‌افزار رو نابود نکرد. اما می‌تونه بخشی از مهارت‌ها، خدمات و مدل‌های کسب‌وکار فعلی رو کم‌ارزش یا حتی غیرضروری کنه. از اون طرف، پیچیدگی‌های تازه‌ای هم ایجاد می‌کنه که به دانش و تخصص تازه نیاز دارن (مثل امنیت، یا compliance) شاید سؤال مهم امروز این نباشه که AI می‌تونه کد بنویسه یا نه. این سؤال رو تا حد زیادی پشت سر گذاشتیم. بلکه سؤال مهم‌تر اینه که وقتی تولید کد ارزون‌تر و آسون‌تر می‌شه، ارزش واقعی مهندس نرم‌افزار کجا خواهد بود؟ در شناخت مسئله؟ طراحی سیستم؟ تصمیم‌گیری بین چند راه‌حل؟ مدیریت پیچیدگی؟ امنیت، پایداری و مسئولیت نتیجه؟ یا توی حوزه‌هایی که هنوز حتی نمی‌دونیم به وجود خواهند آمد؟ شاید ترکیبی از همه‌ی این‌ها، شاید هم چیزی که امروز به اندازه‌ی کافی بهش توجه نمی‌کنیم. برای همین بد نیست بین این‌همه هیاهوی «AI فلان کار رو کرد» و «Agent بهمان شغل رو حذف کرد»، گاهی از خودمون بپرسیم: دانش و مهارت واقعی ما کجای زنجیره‌ی ارزش قرار داره؟ چقدر از ارزشی که خلق می‌کنیم حاصل توانایی خودمونه و چقدرش متکی به قابلیت‌هاییه که ابزارها در اختیارمون گذاشتن؟ و مهم‌تر از اون، آیا در حال یاد گرفتن رانندگی در مسیرهای ناشناخته هستیم، یا هنوز تمام اعتبار حرفه‌ای‌مون رو به عوض کردن دنده‌ای گره زدیم که ممکنه ماشین نسل بعدی اصلاً بهش نیازی نداشته باشه؟ 🏁 پیست هنوز تموم نشده، مسابقه هم متوقف نمی‌شه. قرار نیست همه طراح موتور باشن، اما بهتره هرکدوم بدونیم چرا هنوز پشت فرمون نشستیم.

به عنوان یک معلم، یادگیری برای من امیده، به عنوان یک پدر، یادگیری برای من مسیر نجات فرزندم از جهله، و به عنوان یک انسان، یادگیری برای من حق طبیعیه که نباید به خاطر جبر جغرافیایی از کسی گرفته بشه. در نهایت به عنوان یک دیجی کالایی،امروز دیجی کالا مهر برای من مسیر رسیدن به: امید یک معلم، مسیر نجات یک فرزند و احقاق حق اولیه یه انسانه. ازتون میخوام در صورتی که امکانش رو دارید در پویش "هر جا که تویی" شرکت کنید و برای آینده کودکان کشورمون سهمی داشته باشید : https://mehr.digikala.com/madrese-besaz/ @learning_with_m

سلام مسعود دانش‌پور عزیز این پویش رو توی کانالش با قلم زیباش معرفی کرده؛ که فکر کنم لازم باشه تا جای ممکن از چنین پویش‌هایی حمایت کنیم. اگر قرار بر فردای بهتری برای ایران باشه، این بهبود از پشت نیم‌کت‌ها خواهد بود، نه پشت تریبون‌ها. لذا هر کس از هر پویشی که به نحو صحیح به کودکان و خصوصا آموزش اون‌ها توجه داره؛ چه مدرسه صبح رویش باشه، چه قصه، رنگ، توپ؛ چه رعد؛ چه همین پویش دیجیکالا؛ کمک کنه، عملا به فردای بهتر ایران کمک کرده. اگر به اعداد بخوایم نگاه کنیم هم: مطالعات مشهور جیمز هکمن و همکارانش درباره برنامه‌های باکیفیت در کودکی برای خانواده‌های محروم، بازدهی سرمایه‌گذاری اقتصادی بلندمدت حدود ۱۳.۷ درصد در سال رو برآورد کردن؛ منفعتی که فقط توی درآمد آینده خلاصه نمی‌شه و سلامت، آموزش و حتی کاهش جرم رو هم شامل می‌شه. تخمین بانک جهانی هم به‌طور متوسط هر یک سال آموزش بیشتر، حدود ۱۰ درصد درآمد بیشتر در آینده رو میگه. یعنی کمک به آموزش یه کودک، اگر درست و مؤثر انجام بشه، صرفاً کمک به امروزش نیست؛ داریم روی چند دهه بعد یه جامعه سرمایه‌گذاری می‌کنیم. پی‌نوشت ۱: دلیل کم‌کاری و مطلب نداشتن، مشغله کاری است، ولی سعی می‌کنم تا زودتر مطلب مربوط به Jev (از نگاه چرایی، معماری و تعاریف پایه‌ایش) رو جمع کنم. تا بعدش ببینیم کی فرصت می‌شه تا «آیا بیکار خواهیم شد» رو بنویسم. 😊 پی‌نوشت ۲: اگر در حوزه AI کار می‌کنید حواستون به اتفاقات مهم و ریلیز‌های پیشِ رو در حوزه sandbox، memory، orchestration، subagents، باشه! غیب‌گویی نیست، ترند مقالاتی که دانشگاه‌های پیشرو یا هسته‌های تحقیقاتی گوگل و اوپن ای‌آی و... منتشر می‌کنن نشون میده بهینه‌سازی‌های بزرگی در راهه. اگر کسی علاقه‌مند پیام بده. پی‌نوشت ۳: اگر توی لایه اپلیکیشن فعالید؛ حواستون به ریلیزهای هفته‌های پیشِ رو، مثل پستگرس ۱۹، دات‌نت ۱۱، Python 3.15 باشه؛ نه در حد آپدیت کردن، بلکه تغییرات مهم زیر پوسته‌ی اصلی...

☑ چک‌لیست آماده‌سازی تیم، فرایندها و زیرساخت برای توسعه با AI توجه: هیچ چک‌لیستی جهان‌شمول نیست؛ ولی می‌تونه بهانه و سرنخ‌هایی برای فکر کردن باشه. توی این مطلب موضوعاتی رو که برای آماده‌سازی یک تیم توسعه نرم‌افزار (نه کارهای شخصی یا تجربی و...) برای توسعه با AI نیازه مرور کردم؛ اگر حوصله خوندن متن ندارید، به آخر متن مراجعه کنید. 🔗 لینک به مطلب کامل

گوفر رو رنجوندید! شرم بر شما 😂 سومین بار بود این موضوع تحلیل عمیق GC جدید گو رو توی نظرسنجی‌ها گذاشتم؛ و زیباجویان عزیز نادیده گرفتید. پکیج موفقیت و راز شادابی پوست ۱۷ رأی؛ مطلب به اون عمیق ۴ رأی!؟

۱۳ سپتامبر، روز برنامه‌نویس... چی شد که برنامه‌نویس شدم! برای هر کسی که به نحوی ذیل این عنوان شغلی جا می‌گیره؛ یه مشوق یا دلیل یا محرک اولیه وجود داشته که مرورش بعد از چند سال می‌تونه جالب باشه. برای یکی رتبه کنکور بوده، برای یکی علاقه‌ای که یه معلم توی مدرسه براش ایجاد کرده، یکی دیگه شاید توسط یکی از اقوام و آشنایانش و... برای من، چهارم ابتدایی رفتم (ثبت‌نامم کردن) کلاس برنامه‌نویسی، ولی حتی یک کلمه هم یاد نگرفتم! 😅 به معنی واقعی کلمه «هِچ!» تا اینکه اول راهنمایی، توی سیلابس رسمی مدرسه، برنامه‌نویسی داشتیم، درس رسمی بود و فوق‌برنامه یا دل‌بخواه نبود، عین دروس رسمی هم سخت می‌گرفتن. خوبیش این بود که اصولی از اینکه کامپیوتر و نرم‌افزار قراره چی «مسئله‌ای» رو حل کنه شروع شد؛ بعدترش الگوریتم و فلوچارت، از شکستن مراحل کلی به جزئی و... بعد هم زبان لوگو روی کومودور؛ بعدش زبان قلم‌طراح، بعدش GW-Basic و... ولی کماکان یه درسی بود مثل ریاضی و علوم، با اینکه نمراتم خوب بود، ولی علاقه خاص و متفاوتی از بقیه درس‌ها نداشتم. تا سوم راهنمایی: اون وقت‌ها سال تحصیلی ۳ تا ثُلث بود؛ برای پروژه درس برنامه‌نویسی ثُلث دوم به من «معادله درجه دوم در صورت دلتای منفی» رو دادن! اون وقت‌ها معادله درجه دوم رو اول دبیرستان درس می‌دادن، دلتای منفی رو هم می‌گفتن جواب نداره و برید سال اول دانشگاه یاد بگیرید. برای من چالش بزرگ، فهمیدن ذات معادله درجه دوم بود بعدش دلتای منفی و... باید وقت ناهار از ناظم نامه می‌گرفتم می‌رفتم کتابخونه‌ی دبیرستان بگردم ببینم اصلا چی به چیه! سرتون رو درد نیارم؛ روزی که پروژه رو با زبان فورترن انجام دادم و با ذوق روی فلاپی ریختم و بردم تحویل دادم؛ تقریبا مطمئن بودم، این کاریه که دوست دارم توی زندگیم انجام بدم. و یه پروژه مدرسه، یه چالش که توسط یه معلم طرح شد، مسیر زندگی من رو شکل داد... امروز بعد از گذشت این همه سال، من هنوز خیلی خوشحالم از این مسیر؛ و این خوشحالی ریشه‌ و شروعش توی دانشگاه و محیط کار و مهاجرت شکل نگرفت؛ بلکه توی مدرسه و مقطع راهنمایی شکل گرفت؛ ای کاش حاکمان، خانواده‌ها، مدرسه‌ها؛ اهمیت فوق‌العاده‌ی مدرسه و خصوصا مقاطع پایین تحصیلی رو روی سرنوشت انسان‌های جامعه جدی‌تر می‌گرفتن و می‌فهمیدن میزان اثرگذاریش رو. تنبلی نکنید و کامنت کنید چی باعث شد بیاید سمت نرم‌افزار 😊 ولو اینکه بگید جبر زمانه، شانس، رفیق بد و زغال مرغوب؛ حتماً جالبه!

اگر هم علاقه‌مند بودید در مورد اینکه «سرمایه‌گذاری قبل از دبستان از دانشگاه اثرگذارتره» بیشتر بدونید پیشنهاد می‌کنم تحقیقات Perry، Abecedarian و Heckman رو بخونید

لیدرشیپ فنی؛ یک انتخاب در مسیر رشد، یا گذرگاهی اجباری؟ مهندس خوبی بوده، پس مدیرش کنیم! حقوق بیشتری می‌خواد؟ یه تیم هم بهش بدیم! گاهی همین تصمیمِ ظاهراً خیرخواهانه، هم یک مهندس توانمند رو از کار موردعلاقه‌اش دور می‌کنه، هم یک تیم رو گرفتار. توی این مطلب، اینکه قبل از پذیرفتن یا سپردن مسئولیت، چه چیزهایی رو باید بررسی کنیم رو نوشتم. 🔗 لینک مطلب 💬 خوشحال می‌شم نظر و نقدتون رو بخونم.

🤖 بررسی Agent-First Development؛ چه کاری رو واگذار می‌کنیم، و از کجا می‌فهمیم می‌ارزه؟ ایجنت تست رو سبز کرده؛ ولی با ضعیف‌کردن خودِ تست! این مثال ساده، شروع مطلبی درباره Agent-First Development است. اینکه چجوری کار رو به Agent واگذار کنیم، درستیِ خروجیش رو بسنجیم و بفهمیم مجموع هزینهٔ اجرا و بازبینی واقعاً می‌ارزه؟ دربارهٔ شواهد بهره‌وری، مرز اختیار و تصمیم به ادامه‌دادن یا متوقف‌کردن هم نوشته‌ام. چون قرار نیست هر آزمایشی به استفادهٔ بیشتر از AI ختم بشه. لینک مطالعه مطلب: 🔗 بررسی Agent-First Development 💬 نظر و تجربه‌تون رو اگر بنویسید خوشحال می‌شم. در ضمن موضوع بعدی، بر اساس آراء نظرسنجی در مورد پیش‌نیازهای لیدرشیپ خواهد بود؛ تا زمان نوشتنش اگر نکته یا سوالی دارید حتمن طرح کنید تا گپ بزنیم در موردش