Learning With M

📣 پرسش‌های شما، بخش دوم BuildGuild را می‌سازند همراهان عزیز، برنامه امروز در دو بخش برگزار می‌شود: ۱. پنل گفت‌وگو با مهمانان ☕️ استراحت و پذیرایی ۲. گفت‌وگوی آزاد با محوریت پرسش‌های شما درباره AI Engineering Governance اگر در طول پنل پرسشی برایتان ایجاد شد، همان لحظه آن را در X (توییتر) یا لینکدین منتشر کنید تا هم فراموش نشود و هم گفت‌وگو خارج از سالن ادامه پیدا کند. لطفاً: • در هر پست یک پرسش مشخص مطرح کنید. • حتماً از هشتگ #BuildGuild استفاده کنید. • پست یا حساب شما عمومی باشد تا بتوانیم آن را ببینیم. • در صورت امکان، لینک پست را در پاسخ همین پیام بفرستید. در بخش گفت‌وگوی آزاد تلاش می‌کنیم پرسش‌ها را به ترتیب انتشار و تا جایی که زمان برنامه اجازه می‌دهد مطرح کنیم. منتظر پرسش‌ها و دیدگاه‌های شما هستیم 🌱

📍 محل برگزاری میتاپ فردا: تهران، اتوبان شهید لشکری، جنب مترو بیمه، کارخانه نوآوری آزادی، فضای کار اشتراکی هفت و هشت https://maps.app.goo.gl/bvYVuWjdC4uL1ezT7 ⏳ زمان : 11 تا 14 لطفا 15 دقیقه قبل از شروع تشریف بیاورید

ثبت‌نام اولین میتاپ حضوری BuildGuild آغاز شد 🟢 هوش مصنوعی به‌سرعت وارد فرایندهای مهندسی نرم‌افزار شده، اما یک سؤال جدی باقی مانده است: چطور استفاده از AI را در تیم‌های فنی مدیریت کنیم، بدون اینکه کیفیت، امنیت و مسئولیت‌پذیری قربانی سرعت شوند؟ موضوع این میتاپ: AI Engineering Governance حکمرانی مهندسی هوش مصنوعی در بخش اول، با مهمانان ویژه‌مان، مسعود دانش‌پور و روح‌الله دلپاک، درباره این موضوع گفت‌وگو می‌کنیم. بعد از یک استراحت و پذیرایی، بحث را با مشارکت همه حاضران در قالب گفت‌وگوی آزاد ادامه می‌دهیم تا تجربه‌ها، سؤال‌ها و دیدگاه‌های واقعی تیم‌های فنی روی میز بیاید. 🗓 جمعه ۲۷ شهریور ۱۴۰۵ ⏰ ساعت ۱۱ تا ۱۴ 📍 تهران، کارخانه نوآوری آزادی، مرکز نوآوری هفت و هشت، سالن آمفی‌تئاتر 👥 ویژه مدیران فنی و برنامه‌نویسان سنیور حامیان این رویداد : گدار AI , ایران سرور برای ثبت درخواست حضور: 🔗 https://meetup.buildguild.ir ظرفیت رویداد محدود است و ثبت درخواست به‌معنای قطعی‌شدن حضور نیست. #BuildGuild #AIEngineeringGovernance

یه جمله برای تفکر در طول هفته:

پایایی در پویاییه !

#تفکر

تیام ۱۴ ساله است. مثل خودم، بیماری قلبی مادرزادی دارد و بازهم مثل خودم، بارها قلبش جراحی شده‌است. امروز این نامه را از او دریافت کردم و من هم «دارم پرواز می‌کنم.»

ته ته ته ته ته آرزوی یک مربی همچین چیزیه به نظرم.

🧠 بیایید کمی کمتر از هوشواره کمک بگیریم! 🔬 در دنیایی که هر روز بیشتر از قبل داریم کارهای خودمان را به هوشواره‌ها (AI Agent) می‌سپاریم، یک نگرانی کوچک دارم: نکند در کنار برون‌سپاری کارها، کم‌کم خودِ فکر کردن را هم برون‌سپاری کنیم؟ 🤔 قرار نیست استفاده از هوشواره را کنار بگذاریم؛ اتفاقاً یکی از موضوعات اصلی بحث‌های ما همین استفاده درست از آن است. اما شاید بد نباشد گاهی قبل از اینکه سؤال را از هوشواره بپرسیم، خودمان چند دقیقه با آن کلنجار برویم. از این به بعد می‌خواهم هر از گاهی چند سؤال کوتاه و باز از دل موضوعات مختلفی که در #معمار و Geniuses.Group روی آن‌ها فکر می‌کنیم مطرح کنم. 📌 قانون خاصی هم نداریم: می‌توانید از هوشواره کمک بگیرید، سرچ کنید، با دوستانتان بحث کنید یا اصلاً جواب ندهید! فقط یک پیشنهاد: اول خودتان فکر کنید، بعد سراغ هوشواره بروید. 😉 اگر هم به جواب یا زاویه جالبی رسیدید، خوشحال می‌شویم آن را زیر همین پست با بقیه به اشتراک بگذارید؛ شاید ارزشمندترین بخش این تمرین، خودِ پاسخ نباشد، بلکه مسیر رسیدن به پاسخ باشد. ⏳خب، برای شروع این ۱۰ سؤال را امتحان کنیم: 🔹 ۱. Transaction اگر یک Transaction هیچ پولی جابه‌جا نکند، آیا هنوز یک Transaction است؟ آیا اصلا واحد شمارش، داده‌ای وابسته به Transaction است؟ یا پیش فرض واحد پول تراکنش یک فرض میراثی گمراه کننده است؟ 🔹 ۲. State اگر چیزی را بتوانیم از دست بدهیم و سیستم همچنان دقیقاً همان رفتار درست را داشته باشد، آیا واقعاً بخشی از State سیستم بوده است؟ 🔹 ۳. Agent یا عامل آیا هر چیزی که بتواند از طرف یک موجودیت دیگر مسئولیتی را بر عهده بگیرد، یک Agent است؟ 🔹 ۴. Attribute یا Edge؟ اگر یک ویژگی بتواند به‌صورت مستقل تغییر کند و روی رفتار سیستم اثر بگذارد، چه زمانی باید آن را Attribute بدانیم و چه زمانی یک Edge؟ 🔹 ۵. Process یا فرآیند آیا هر دنباله‌ای از Activityها یک Process است؟ اگر نه، چه چیزی یک دنباله را به Process تبدیل می‌کند؟ 🔹 ۶. Service اگر یک Service هیچ کار مستقیمی برای کاربر انجام ندهد، اما مسئول ایجاد یک تغییر در سیستم باشد، آیا هنوز Service است؟ 🔹 ۷. Ownership آیا مالکیت یک Attribute از یک موجودیت است یا رابطه‌ای مستقل میان دو موجودیت؟ 🔹 ۸. Identity اگر دو موجودیت تمام ویژگی‌های فعلی یکسانی داشته باشند، چه چیزی باعث می‌شود بگوییم هنوز دو موجودیت متفاوت‌اند؟ 🔹 ۹. Architecture آیا می‌توان معماری یک سیستم را بدون دانستن اینکه سیستم با چه زبان، دیتابیس یا سیستم‌عاملی پیاده‌سازی خواهد شد، به‌درستی تعریف کرد؟ 🔹 ۱۰. Problem اگر چیزی را بتوانیم به‌سادگی با یک راه‌حل فنی حل کنیم، آیا حتماً از ابتدا یک Problem فنی داشته‌ایم؟ 🧐 قرار نیست جواب درست را سریع پیدا کنیم. قرار است کمی تمرین کنیم که قبل از پرسیدن از دیگران، خودمان سؤال را زندگی کنیم. مثلا پیش فرض سوالات بالا را متوجه شویم و خود پیش فرض ها را هم در صورت لزوم بهشون فکر کنیم. مثلا با خوانده سوالات آیا متوجه شدید که پیش فرض خیلی از سوالات، نظریه گراف در ریاضی ولی برای فاز مدل کردن در علوم کامپیوتر هست؟ #تلنگر_ذهنی #تفکر #تفکر_انتقادی #معمار #هوشواره

جمله برای تفکر در آخر هفته:

کسی شدن یا کاری کردن.

پ.ن: موفقیت، مقام، شهرت، قدرت، پول با کسی شدنه. انجام کار درست، معروف نشدن، معمولی بودن، روراست با خود و دیگران بودن و ... با کاری کردنه. #تفکر

چی میشه یه محصول با این دقت میشه ساخت؟ ورودی دقیق لازمه یا دقت در تولید یا تعهد یا همش یا یه چیز دیگه؟ هرچی هست، مثال همیشه من اینه:

فکر کن برای خانواده خودت داری می سازی.

پ.ن: مهندسی زیباست، چه تو کد، چه تو ساختمان، چه تو ساعت.

نگاه سایمون از وظیفه leadership جالبه: وقتی افراد به مدیرشان اعتماد ندارند(منظورش trusting teams یا تیم های مبتنی بر اعتماد هست)، انرژی زیادی صرف پنهان کردن اشتباه، وانمود کردن، محافظت از خود و ترس از سرزنش می‌کنند. اما در تیم‌های مبتنی بر اعتماد، آدم ها به راحتی میتونن بگن: اشتباه کردم کمک نیاز دارم ترسیدم بلد نیستم تو خونه مشکلی دارم که باعث میشه نتونم درست کار کنم و ... میگه وظیفه لیدرشیپ اینه که این فضا رو بسازه.

حالا من سوال بپرسم: آیا لیدرشیپ یه شغله؟ وظیفه مدیر با وظیفه لیدر چه فرقی داره؟

و بازم‌ یه سوال دیگه: کدوم یکی از کتاب های سایمون رو خوندید؟ #سایمون_سینک

وقتی جمله ای برای تفکر در آخر هفته نیست، یعنی کتابی خونده نشده، وقتی برای رشد گذاشته نشده و در کل اوضاع خرابه ! #این_بده

میشه با این ویدیو گریست. اکیدا پیشنهادش میکنم. #سایمون_سینک

فکر کن، تبلیغ کنی، هزینه کنی، کلی کار کنی و ... پیش خودت هم میگی، نه مهندس نرم افزار، نه دیزاینر و نه مالک محصول. AI هست ! میری تبلیغات می کنی و تهش اینو تحویل می گیری. اول باورم نشد، دیدم نه رمز درسته ! رفتم تو و براشون یه مقاله هم پابلیش کردم. #اسیر_شدیم

🖊 چرا سؤال نداریم؟ این موضوع رو در ۳ پُست مجزا، به ظاهر طولانی ولی در قسمت‌های کوتاه که منقطع خوندنشون آسون باشه تموم کردم. توی این سه بخش سعی کردم از سه زاویه متفاوت بهش نگاه کنم: 1️⃣ چرا سؤال اصلاً توی ذهن ما شکل نمی‌گیره؟ از شکاف اطلاعاتی و اطمینان کاذب، تا نقش آموزش و کودکی در ساختن یا خاموش‌کردن پرسشگری. 🔗 [لینک بخش اول] 2️⃣ وقتی سؤال داریم، چرا نمی‌پرسیم؟ از امنیت روانی و فاصله با قدرت، تا فرهنگ، و سکوتی که گاهی اصلاً نشانه رضایت نیست. 🔗 [لینک بخش دوم] 3️⃣وقتی سؤال می‌پرسیم، آیا واقعاً دنبال فهمیدنیم؟ و اثر هوش‌مصنوعی آیا فقط دنبال شاهدی برای تأیید جوابی هستیم که از قبل انتخاب کردیم؟ این بخش بیشتر درباره Confirmation Bias، هوش مصنوعی و خطر تازه‌ای به اسم Sycophancy است. 🔗 [لینک بخش سوم] به‌نظرم در هر شغل، موقعیت و سطحی، «پرسشگر» بودن، بلد بودنِ پرسش خوب و توانایی دیدن و حل مسئله، مهارت‌های بنیادی‌ای هستن. دعوت می‌کنم بخونید و اگه براتون مفید بود، برای بقیه هم بفرستید. پی‌نوشت: معرفی موضوع، ۲۰۸۸ بار دیده شد و ۳۲ بار بازنشر! ولی قسمت اول مطلب ۵۹ بار دیده شد. نمونه بانمکی از پیشی گرفتن آگهی از آگاهی بود!

توی دور آخر، با ضربان ۱۳۰ یه چیزی توی ریمیکسی که گوش میدادم پلی شد که انرژی رو بوست می کرد. ناخودآگاه به جای توجه به خستگی و افت قند، توجهم به متن موسیقی جلب شد.

چرا انقدر در اوج انرژیک بودن تلخه؟

اومدم و نسخه اصلی رو پیدا کردم. خالق این اثر، Posner خواننده ای هست که بعد از چند ترک موفق درگیر این میشه که شاید دیگه خوب نیست و میره پیش Avicii در ایبیزا و بقیه داستان ... بهش میگن سندروم ایمپاستر، وقتی خودت رو به اندازه موفقیتت خوب نمیدونی. #سوال_داشتم

چه قدر توی کار و زندگیمون کمک خواستیم؟ و همچنین آیا صدای کمک‌ خواستن دیگران رو شنیدیم؟ این ویدیو، بخشی از اثر بی بدیل: "پسرک، روباه، موش کور و اسب" هست که دیدن و مطالعه کردنش رو به همتون پیشنهاد میکنم. #کمک

یه نقل قول خفن برای آخر هفته:

اگر چیز های بد دنبالت می کنند، بهترین کاری که می تونی بکنی اینه که برگردی و تو دنبالشون کنی ! - جردن پیتر سون (روانشناس معروف کانادایی)

عاشق این مرد و طرز فکراشم. #تفکر

🧠 اهمیت درک عمیق از مفهوم کلمه عامل (Agent) برای حل مشکلات کار کردن با #هوشواره ها (AI) 🔬این روزها تقریباً همه دربارهٔ AI Agentها صحبت می‌کنند؛ ابزارهای جدید معرفی می‌شوند، دوره‌های آموزشی برگزار می‌شود و هر روز اصطلاحات تازه‌ای وارد اکوسیستم می‌شوند. اما احساس می‌کنم قبل از اینکه بخواهیم یاد بگیریم چگونه با AI Agentها کار کنیم، لازم است یک قدم به عقب برگردیم. شاید مسئله اصلاً هوشواره نباشد. شاید مسئله این باشد که ما هنوز مفهوم Agent (#عامل) را به‌درستی #مدل نکرده‌ایم. 🚨وقتی کلمهٔ Agent را می‌شنویم، ذهنمان مستقیم به سمت #هوش_مصنوعی می‌رود، در حالی که Agent مفهومی بسیار قدیمی‌تر و عمومی‌تر است. هر موجودیتی که از طرف یک سیستم (شخص، سازمان، ...)، مسئولیتی را بر عهده می‌گیرد، یک Agent است. اگر این تعریف را بپذیریم، آن وقت AI Agent فقط یکی از انواع Agentها خواهد بود؛ همان‌طور که یک کارمند، یک پیمانکار، یک نرم‌افزار، یک سرویس یا حتی یک سازمان نیز می‌تواند نقش یک Agent را ایفا کند. و دقیقاً همین‌جا است که نگاه ما به #مسئله تغییر می‌کند. یک #تلنگر_ذهنی و سوال باز #فلسفه_ذهن را هم مطرح کنیم که حتی میشه بدن انسان را هم به نوعی عامل هویت اون فرد در نظر بگیریم. اگر AI Agent را مفهومی کاملاً جدید تصور کنیم، ناخواسته بخش بزرگی از دانش انباشتهٔ گذشته دربارهٔ تعامل با Agentها را کنار می‌گذاریم و دوباره همان اشتباهات را با نام‌های جدید تکرار می‌کنیم. ⏳بخش بزرگی از مشکلاتی که امروز به هوشواره نسبت می‌دهیم، در واقع سال‌ها قبل از ظهور هوشواره هم وجود داشته‌اند. - وقتی مسئولیت را مبهم واگذار می‌کنیم... - وقتی انتظار خروجی را شفاف تعریف نمی‌کنیم... - وقتی زمینهٔ لازم را منتقل نمی‌کنیم... - وقتی دانش سازمان در ذهن افراد باقی می‌ماند و به دانش مشترک تبدیل نمی‌شود... نتیجه معمولاً قابل پیش‌بینی نیست؛ چه طرف مقابل یک انسان باشد، چه یک هوشواره. دقت کنیم هوشواره مشکل جدیدی ایجاد نکرده است؛ فقط کیفیت #مدل_ذهنی و کیفیت #مدیریت_دانش ما را با وضوح بیشتری نمایان کرده است. ⏳به همین دلیل، شاید بهتر باشد به جای اینکه فقط دربارهٔ نقش‌های کاذب (False Classification) منتسب به مهندسی مثل Prompt Engineering یا Harness Engineering صحبت کنیم، دربارهٔ اصول تعامل با هر Agent صحبت کنیم؛ اصولی که سال‌ها قبل از ظهور هوشواره نیز وجود داشته‌اند و احتمالاً سال‌ها بعد از تغییر فناوری‌های امروز نیز معتبر خواهند ماند. در چند کامنت زیر همین پست، سعی می‌کنم دربارهٔ همین اصول صحبت کنم؛ از #تفویض_اختیار و نحوهٔ #مستندسازی از نگارش درخواست‌ها گرفته تا انتقال زمینه، مرزهای مسئولیت، معیارهای پذیرش و نقش #مدیریت_دانش در تعامل با عامل‌ها. ⏳شاید هنگام خواندن این متن با خودتان گفته باشید: - ما هم مدام خروجی‌هایی می‌گیریم که با انتظارمان فاصله دارند. - هر بار باید دوباره همه چیز را توضیح بدهیم. - افراد مختلف برداشت‌های متفاوتی از یک درخواست دارند. - دانش پروژه بیشتر در ذهن افراد است تا در مستندات. - با وجود استفاده از هوشواره، کیفیت خروجی تیم بهتر نشده، فقط سرعت تولید بیشتر شده است. اگر چنین نشانه‌هایی را در #سازمان خود می‌بینید، احتمال دارد مسئلهٔ اصلی نه هوشواره باشد و نه حتی افراد تیم. این‌ها معمولاً نشانه‌هایی از ضعف در #مدیریت_دانش، نبود یک #چارچوب_توسعه مشترک، ابهام در تعریف مسئولیت‌ها یا ضعف در مدل‌سازی مسائل سازمان هستند. این‌ها با تعویض ابزار حل نمی‌شوند؛ نیازمند اصلاح شیوهٔ فکر کردن، انتقال دانش و طراحی فرآیندهای توسعه هستند. 🔗 در Geniuses.Group نیز دقیقاً همین دغدغه را دنبال می‌کنیم؛ کمک به سازمان‌ها برای ساختن سیستم‌هایی که پایداری آن‌ها تنها به فناوری وابسته نباشد، بلکه بر پایهٔ مدل‌های ذهنی دقیق‌تر، مدیریت دانش بهتر و تعامل مؤثرتر میان عامل‌ها شکل بگیرد.

مسئله ای که خیلی از بچه های با سواد ما دچارشن اینه : تمرکز زیاد روی یادگرفتن و‌خوندن و. جمع کردن دانش در نیاوردن یک ریال و نگرفتن حتی یه شغل معمولی دانشی که نتونیم به پول تبدیلش کنیم خوبه ها ، ولی زندگی مون رو سخت میکنه 🤷‍♂️