با فراگیر شدن GenAI، تبِ چیزی که بعدتر وایبکدینگ اسم گرفت هم روز به روز داغتر شد. لزوم ساختار دادن به تعامل توسعهدهنده و مدل زبانی، برای همین به تدریج فایلهای prompts.md و بعدتر instructions.md و پشتیبانی از tools و MCPها به گیتهاب کوپالوت اومدن (قبلا در مورد همه اینها توی کانال نوشتهام). ولی همونطور که مدلها پیشرفت کردن، ابزارها و ساختارهایی که کمک میکردن تا مدلها رو بهتر به خدمتِ ساختاردهی توسعه دربیاریم هم پیشرفت کردن. مثلا فایلهای prompts.md با وجود کاربردی بودنشون، خیلی زود محدودیتهاشون رو نشون دادن، پس پشتیبانی از instructions.md و tools هم اضافه شد. ولی جای چند تا چیز خالی بود:
- دانش دائمی، به خصوص، و تکرارشونده
- پشتیبانی از ورژن
- فقط فایل markdown نباشه، بشه بهش مثال و منبع و... هم معرفی کرد. عین دوره آموزشی؛ ولی خیلی سادهتر و سرراستتر از RAG ساختن
پس برای همین skills به وجود اومد، ساختاری که مهارت به خصوص، مثل دانش مرور کدها برای عدم تخطی از اصول امنیتی مورد توافق تیم/سازمان. یا حتی مهارت ایجاد تغییرات لازم برای استفاده از ORM جدید به جای ORM فعلی یا... ولی اینبار:
- باید یک فولدر باشه
- حتماً فایل SKILL.md داشته باشه
- میتونه همراهش اسکریپت، مثال، الگو، منابع آموزشی، و تعریف workflow داشته باشه
- هدفش اینه که دانش تکرارشونده و procedural رو در قالبی قابل اشتراک و بارگذاری تعریف کنه
- این یعنی Skills از نظر قابلیتهای عملیاتی و قابل استفاده مجدد خیلی جلوتر از فایلهای markdown ساده هست
.github\skills
.agents\skills
.claude\skills
ولی Skills یک استاندارد متنباز و جامعهمحوره که با مجوز Apache 2.0 توسط agentskills.io در دسترس عموم قرار داده شده؛ و چه Claude Code چه خانواده GitHub Copilot (plugin, CLI, SDK) و... ازش پشتیبانی میکنن و marketplaceهای به اشتراکگذاری skillها که زیاد شدن. به بیان خیلی ساده، Skill همون چیزیه که ما دوباره و دوباره میخوایم هوش مصنوعی انجام بده، ولی این بار در قالب یک بسته تعریفشده، نه پرامپت دستی.
🔧 ترکیب قابلیتها: میتونین چند Skill رو با هم ترکیب کنین تا workflowهای پیچیدهتر رو پوشش بدین.
📦 صرفهجویی در زمان و خطا: چون مراحل کاری، چکلیستها و اسکریپتها از قبل تعریف شدهان، نتایج قابل پیشبینیتر هستن.
🧠 مثال کاربردی:
فرض کنید هر بار که یک Pull Request در گیتهاب ایجاد میکنین، باید این کارها رو انجام بدید:
- اول چک کنه تیکت مرتبط با PR هر چی خواسته، توی تغییرات اومده و Acceptance criteria ها جا نیوفتاده از دست توسعهدهنده
- چکلیست امنیتی رو اجرا کنه
- تستهای یکپارچهسازی رو بررسی کنه
- معیارهای کیفی رو حساب کنه
- خروجی رو گزارش بده
به جای اینکه هر بار با پرامپت اینها را توضیح بدید، میتونید یک Skill بسازید با یک فولدر شامل: .github/skills/pr-review/SKILL.md و در ضمن فایلهای مثال و توضیح رو هم توی همین پوشه قرار بدید و توی فایل SKILL.md بگید ازشون استفاده کنه برای یاد گرفتن.
مثلا بنویسید:
- چه زمانی این Skill باید فعال بشه
- چه مراحلی رو باید انجام بده
- چه منابع یا چکلیستهایی همراه داشته باشه
بعدش هر ابزاری که از Agent Skills پشتیبانی کنه، مثل GitHub Copilot CLI یا Copilot coding agent، وقتی prompt مرتبط رو ببینه، این Skill رو بارگذاری و اجرا میکنه، بدون اینکه شما دوباره توضیح بدید.
🚀 چه چیزهایی میتونن به Skill تبدیل بشن؟
هر چیزی که تکرارشونده یا قابل استانداردسازی باشه:
- الگوی نوشتن مستندات (RFC، Arch review، design doc)
- چکلیستهای Code Review
- ایجاد template برای Issue و Task
- گامهای یونیت تست، تست یکپارچهسازی یا تست امنیت
- متدهای اتوماسیون workflowهای سازمانی
یا مثالهای اینجا یا اینجا یا اینجا
وقتی یک Skill تعریف میکنید، ابزارهای مختلفی که از استاندارد پشتیبانی میکنن میتونن ازش بهرهمند بشن و این یعنی دانش تیمی یا سازمانی رو قابل استفاده مجدد میکنین. Agent Skills داره تبدیل به استاندارد رایج برای تعریف تواناییهای هوش مصنوعی میشه. این یعنی دیگه نیاز نیست هر بار از صفر به هوش مصنوعی بگید چه کار کنه. شما میتونید مراحل، چکلیستها، اسکریپتها و دانش خودتون رو در قالب Skill تعریف کنین و ابزارهای مختلف مثل Copilot اونها را به صورت قابل استفاده مجدد بارگذاری کنن. این کار باعث میشه خروجیهای هوش مصنوعی قابل پیشبینیتر، استانداردتر و کمتر وابسته به پرامپت دستی باشه.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8👍5
بچههای معصومی که پرپر شدند، آرزو داشتن تا بزرگ بشن، موفق بشن و بهترینِ خودشون باشن...
این بچهها آرزو داشتن تا به اندازهی توانشون موفق بشن، برای خودشون، خانوادهشون، شهرشون یا کشورشون مفید باشن. اون پسربچهای که برای آخرین بار با مادرش خداحافظی کرد، رفت مدرسه، تا شاد بودن، یاد گرفتن، پیشرفت کردن رو با خودش برگردونه و مادرش رو خوشحال کنه. نفرین بر جنگ، نفرین بر کسی که دستور داد، همراهی کرد و نهایتا ماشهی اون ۲ موشک نحس رو کشید تا این داغ به دل انسانیت بشینه.
روزهای تلخی گذشت، و خدا میدونه سایهی نحس جنگ تا چه زمانی تن ایران رو رنجور و زخمی خواهد کرد؛ و بعد از آخرین شلیک، چهرهی کشور ما چه شکلی خواهد داشت...
مدرسه، پالایشگاه، فرودگاه و هر جایی ویران بشه دردناکه، ولی درد بزرگتر، جهل و فقر فکری است که این روزها کالای رایجی شده؛ و «خِرَد» متاعی کمیاب. از اونهایی که موشک میفرستن تا اونهایی که برای اصابتش کف میزنن. پس، باید نوشت، یاد داد، تلاش کرد؛ بیش از گذشته... به حد بضاعت؛ این تنها کاریه که شاید بلد باشیم یا از دستمون ساخته باشه. به نیت تکتک بچههایی که دوست داشتن یاد بگیرن، و بهترینِ خودشون باشن. برای تکتک بچههایی که کشورشون، خانوادهشون، زبانشون، و «زندگی» رو دوست داشتن.
یادمون نره، این کشور حملهی مغول رو هم از سر گذروند، تاریخ گواهی میده که اون زمان هم عدهای که بضاعت فکری و ارادهی عملی نداشتن، برای حمله به خاک کشور شادی کردن، ولی ما امروز اسم سعدی رو میدونیم، و کمتر کسی نام کسانی رو که از سر جهل و طمع، زهر افعی رو دوای زخم کشور تجویز کردن به یاد داره...
برای همه آرزوی سلامتی و امنیت دارم، خصوصا برای تکتک اعضای کادر درمان، نیروهای امدادی، و بچههایی که قراره دنیا رو به جای بهتری تبدیل کنند... 🖤😔🌱
این بچهها آرزو داشتن تا به اندازهی توانشون موفق بشن، برای خودشون، خانوادهشون، شهرشون یا کشورشون مفید باشن. اون پسربچهای که برای آخرین بار با مادرش خداحافظی کرد، رفت مدرسه، تا شاد بودن، یاد گرفتن، پیشرفت کردن رو با خودش برگردونه و مادرش رو خوشحال کنه. نفرین بر جنگ، نفرین بر کسی که دستور داد، همراهی کرد و نهایتا ماشهی اون ۲ موشک نحس رو کشید تا این داغ به دل انسانیت بشینه.
روزهای تلخی گذشت، و خدا میدونه سایهی نحس جنگ تا چه زمانی تن ایران رو رنجور و زخمی خواهد کرد؛ و بعد از آخرین شلیک، چهرهی کشور ما چه شکلی خواهد داشت...
مدرسه، پالایشگاه، فرودگاه و هر جایی ویران بشه دردناکه، ولی درد بزرگتر، جهل و فقر فکری است که این روزها کالای رایجی شده؛ و «خِرَد» متاعی کمیاب. از اونهایی که موشک میفرستن تا اونهایی که برای اصابتش کف میزنن. پس، باید نوشت، یاد داد، تلاش کرد؛ بیش از گذشته... به حد بضاعت؛ این تنها کاریه که شاید بلد باشیم یا از دستمون ساخته باشه. به نیت تکتک بچههایی که دوست داشتن یاد بگیرن، و بهترینِ خودشون باشن. برای تکتک بچههایی که کشورشون، خانوادهشون، زبانشون، و «زندگی» رو دوست داشتن.
یادمون نره، این کشور حملهی مغول رو هم از سر گذروند، تاریخ گواهی میده که اون زمان هم عدهای که بضاعت فکری و ارادهی عملی نداشتن، برای حمله به خاک کشور شادی کردن، ولی ما امروز اسم سعدی رو میدونیم، و کمتر کسی نام کسانی رو که از سر جهل و طمع، زهر افعی رو دوای زخم کشور تجویز کردن به یاد داره...
برای همه آرزوی سلامتی و امنیت دارم، خصوصا برای تکتک اعضای کادر درمان، نیروهای امدادی، و بچههایی که قراره دنیا رو به جای بهتری تبدیل کنند... 🖤😔🌱
💔27👎20❤6👍4
مصاحبهگر بودن در دل یه بحران
واقعبین باشیم، از پیِ بحران اقتصادی، بحران اجتماعی برخواست و از دل فاجعهی دیماه، جنگ اسفندماه؛ و این یعنی موج ورشکستگی شرکتها، موج تعدیلها و لزوم توجه به فرایند جذب نیرو و مهارت مصاحبه دادن و مصاحبه گرفتن. لذا تصور میکنم بد نباشه تا طی دو مطلب، از دو زاویه به موضوع نگاه کنیم.
بخش ۱: مصاحبهگر
الان که داری مصاحبه میگیری، احتمالاً طرف مقابلت چندین هفتهست که اینترنت کلن نداشته یا با دشواریهای زیادی منقطع وصل بوده. شاید توی شهرش یا همسایگیاش بمب خورده. شاید یکی از آشناهای نزدیکش کشته شده. شاید سه شب پشت سر هم درست نخوابیده.
و تو داری ازش میپرسی که تفاوت MPI و OpenMPرو توضیح بده.
این مطلب برای مصاحبهگرهاست، اونهایی که احتمالا مجبور خواهند بود مصاحبههای دقیقتری بگیرن چون بودجه و زمان کمتری برای قمار دارن و باید کاندیدی رو پیدا کنن که بتونه خروجی بهموقعتر، مستقلتر از AI و اینترنت بده و خلاصه اینکه آدم روزهای سختتر از گذشته باشه...
۱: بپذیر که شرایط عوض شده
در شرایط عادی، یه مصاحبهی ضعیف یعنی کاندیدا آماده نبوده. الان اما این معادله خیلی پیچیدهتره. آدمی که جلوی توئه ممکنه:
- دو ماه با قطعی اینترنت زندگی کرده، یعنی به LeetCode، دورههای آنلاین، و حتی جستجوی ساده دسترسی نداشته
- توی یه فضای روانی سنگین کار کرده (یا اصلاً نتونسته کار کنه)
- شغلش رو از دست داده نه به خاطر عملکرد، بلکه چون شرکت تعطیل شده
اگه اینها رو نبینی، داری یه ارزیابی ناقص میکنی؛ هرچقدر هم فرآیندت «استاندارد» باشه.
۲: قدرت دستته، این رو جدی بگیر
توی یه بازار کار نرمال، کاندیدا گزینه داره. الان نداره.
این یعنی فشار روانی مصاحبه برای طرف مقابل چند برابر شده. اضطراب بیشتر، اشتباه بیشتر، و تصویری که از طرف میگیری احتمالاً کمتر از واقعیتشه.
یه مصاحبهگر خوب این رو میدونه و فضا میده، نه از سر ترحم، بلکه چون میخواد ببینه این آدم واقعاً چیه؛ چون خودش هم تحت فشار است تا زمان، و بودجه شرکت رو برای بهینهترین خروجی و اثرگذاری تخصیص بده، نه برای کسی که بدون اینترنت، بدون راهنما، بدون AI دچار سردرگمی میشه.
۳: با منابع کمتر داری استخدام میکنی؛ این فشار رو روی کاندیدا خالی نکن
شرکتها الان کمتر استخدام میکنن. این یعنی هر نفر باید بیشتر کار کنه، هر استخدام ریسک بالاتری داره، و تیم تحمل اشتباه کمتری داره.
میفهمم که این فشار رو به مصاحبه منتقل میکنه. ولی فشار بیشتر روی کاندیدا، مصاحبه بهتری نمیده؛ فقط نشون میده کی بهتر تحمل اضطراب میکنه، که لزوماً همون کسی نیست که بهترین مهندسه.
چکلیست عملی، قبل از هر مصاحبه
۱. مصاحبه رو با جملاتی شروع کن که فضا رو باز کنه
نه از سر تعارف، بلکه یه چیز صادق: «میدونم اوضاع این روزا سنگینه. اگه وسط مصاحبه لازم داشتی یه لحظه وایسی، بگو.» این یه جملهست. ولی چیزهایی رو تغییر میده.
۲. سوالهایی که به اینترنت وابستهاند رو بازبینی کن
اگه کاندیدا با یه API یا فریمورک آشنا نیست، قبل از قضاوت از خودت بپرس: آیا ممکنه دو ماه به documentation دسترسی نداشته بوده باشه؟
۳. تمرکزت رو از «حفظیات» ببر روی «تفکر محساباتی و حل مسئله»
بپرس چطور فکر میکنه، نه چی حفظه. الان تفاوت این دو خیلی مهمتر از همیشهست.
۴. اگه عملکرد ضعیف دیدی، یه سوال ازش بپرس
«چیزی بوده این مدت که روی آمادگیت تأثیر گذاشته؟» ممکنه جواب تصویر کاملاً متفاوتی بده.
۵. feedback بده؛ حتی به رد شدهها
این یه چیز کوچیکه ولی الان وزن بیشتری داره. آدمی که رد شده و میدونه چرا، بهتر از آدمیه که فقط سکوت گرفته.
۶. دنبال آدم مناسب و تواناییهای «واقعبینانه» مورد نیازت باش، نه سوپرمن!
بیشتر از گذشته فکر کن دقیقا اون آدمی که مورد نیاز پروژه و پوزیشن است چه خصوصیاتی داره، نه آدمی که آرزو داری پیداش کنی و تمام چیزهایی که تا ۵ سال دیگه هم کاربردی توی محصول نداره رو مسلط باشه.
حرف آخر
مصاحبه گرفتن توی این شرایط یه مسئولیت اخلاقیه، نه فقط یه فرآیند HR.
تو داری در مورد معاش یه نفر تصمیم میگیری، کسی که شاید همین دیروز خبر بدی شنیده. این رو نمیگم که نرم باشی یا استانداردهات رو پایین بیاری. میگم که آدم باشیم. این دو تا با هم در تضاد نیستن.
قسمت بعدی: مصاحبهدهنده
1
واقعبین باشیم، از پیِ بحران اقتصادی، بحران اجتماعی برخواست و از دل فاجعهی دیماه، جنگ اسفندماه؛ و این یعنی موج ورشکستگی شرکتها، موج تعدیلها و لزوم توجه به فرایند جذب نیرو و مهارت مصاحبه دادن و مصاحبه گرفتن. لذا تصور میکنم بد نباشه تا طی دو مطلب، از دو زاویه به موضوع نگاه کنیم.
بخش ۱: مصاحبهگر
الان که داری مصاحبه میگیری، احتمالاً طرف مقابلت چندین هفتهست که اینترنت کلن نداشته یا با دشواریهای زیادی منقطع وصل بوده. شاید توی شهرش یا همسایگیاش بمب خورده. شاید یکی از آشناهای نزدیکش کشته شده. شاید سه شب پشت سر هم درست نخوابیده.
و تو داری ازش میپرسی که تفاوت MPI و OpenMPرو توضیح بده.
این مطلب برای مصاحبهگرهاست، اونهایی که احتمالا مجبور خواهند بود مصاحبههای دقیقتری بگیرن چون بودجه و زمان کمتری برای قمار دارن و باید کاندیدی رو پیدا کنن که بتونه خروجی بهموقعتر، مستقلتر از AI و اینترنت بده و خلاصه اینکه آدم روزهای سختتر از گذشته باشه...
۱: بپذیر که شرایط عوض شده
در شرایط عادی، یه مصاحبهی ضعیف یعنی کاندیدا آماده نبوده. الان اما این معادله خیلی پیچیدهتره. آدمی که جلوی توئه ممکنه:
- دو ماه با قطعی اینترنت زندگی کرده، یعنی به LeetCode، دورههای آنلاین، و حتی جستجوی ساده دسترسی نداشته
- توی یه فضای روانی سنگین کار کرده (یا اصلاً نتونسته کار کنه)
- شغلش رو از دست داده نه به خاطر عملکرد، بلکه چون شرکت تعطیل شده
اگه اینها رو نبینی، داری یه ارزیابی ناقص میکنی؛ هرچقدر هم فرآیندت «استاندارد» باشه.
۲: قدرت دستته، این رو جدی بگیر
توی یه بازار کار نرمال، کاندیدا گزینه داره. الان نداره.
این یعنی فشار روانی مصاحبه برای طرف مقابل چند برابر شده. اضطراب بیشتر، اشتباه بیشتر، و تصویری که از طرف میگیری احتمالاً کمتر از واقعیتشه.
یه مصاحبهگر خوب این رو میدونه و فضا میده، نه از سر ترحم، بلکه چون میخواد ببینه این آدم واقعاً چیه؛ چون خودش هم تحت فشار است تا زمان، و بودجه شرکت رو برای بهینهترین خروجی و اثرگذاری تخصیص بده، نه برای کسی که بدون اینترنت، بدون راهنما، بدون AI دچار سردرگمی میشه.
۳: با منابع کمتر داری استخدام میکنی؛ این فشار رو روی کاندیدا خالی نکن
شرکتها الان کمتر استخدام میکنن. این یعنی هر نفر باید بیشتر کار کنه، هر استخدام ریسک بالاتری داره، و تیم تحمل اشتباه کمتری داره.
میفهمم که این فشار رو به مصاحبه منتقل میکنه. ولی فشار بیشتر روی کاندیدا، مصاحبه بهتری نمیده؛ فقط نشون میده کی بهتر تحمل اضطراب میکنه، که لزوماً همون کسی نیست که بهترین مهندسه.
چکلیست عملی، قبل از هر مصاحبه
۱. مصاحبه رو با جملاتی شروع کن که فضا رو باز کنه
نه از سر تعارف، بلکه یه چیز صادق: «میدونم اوضاع این روزا سنگینه. اگه وسط مصاحبه لازم داشتی یه لحظه وایسی، بگو.» این یه جملهست. ولی چیزهایی رو تغییر میده.
۲. سوالهایی که به اینترنت وابستهاند رو بازبینی کن
اگه کاندیدا با یه API یا فریمورک آشنا نیست، قبل از قضاوت از خودت بپرس: آیا ممکنه دو ماه به documentation دسترسی نداشته بوده باشه؟
۳. تمرکزت رو از «حفظیات» ببر روی «تفکر محساباتی و حل مسئله»
بپرس چطور فکر میکنه، نه چی حفظه. الان تفاوت این دو خیلی مهمتر از همیشهست.
۴. اگه عملکرد ضعیف دیدی، یه سوال ازش بپرس
«چیزی بوده این مدت که روی آمادگیت تأثیر گذاشته؟» ممکنه جواب تصویر کاملاً متفاوتی بده.
۵. feedback بده؛ حتی به رد شدهها
این یه چیز کوچیکه ولی الان وزن بیشتری داره. آدمی که رد شده و میدونه چرا، بهتر از آدمیه که فقط سکوت گرفته.
۶. دنبال آدم مناسب و تواناییهای «واقعبینانه» مورد نیازت باش، نه سوپرمن!
بیشتر از گذشته فکر کن دقیقا اون آدمی که مورد نیاز پروژه و پوزیشن است چه خصوصیاتی داره، نه آدمی که آرزو داری پیداش کنی و تمام چیزهایی که تا ۵ سال دیگه هم کاربردی توی محصول نداره رو مسلط باشه.
حرف آخر
مصاحبه گرفتن توی این شرایط یه مسئولیت اخلاقیه، نه فقط یه فرآیند HR.
تو داری در مورد معاش یه نفر تصمیم میگیری، کسی که شاید همین دیروز خبر بدی شنیده. این رو نمیگم که نرم باشی یا استانداردهات رو پایین بیاری. میگم که آدم باشیم. این دو تا با هم در تضاد نیستن.
قسمت بعدی: مصاحبهدهنده
1
❤19
مصاحبهدهنده بودن در دل یه بحران
در ادامه بخش اول که مربوط به مصاحبهگر بودن نوشتم، ای مطلب یه مرور سریع روی مصاحبه دادنه. شاید قبلاً توی مصاحبهها، یه چیزهایی گفتی که کاملاً درست، نبودن! یه پروژه رو کمی بزرگتر نشون دادی. یه تکنولوژی رو گفتی «آشنام»، در حالی که فقط اسمش رو شنیده بودی. یه مسئولیت رو به اسم خودت ثبت کردی که teamwork بود.
الان جای اینها (white lies، بلوف) نیست، نه به خاطر اینکه اخلاقاً درست نیست (که نیست)، بلکه چون ریسکش برای خودت چند برابر شده.
چرا بلوف الان خطرناکتره
شرکتی که الان استخدام میکنه، احتمالاً قصد داره روی حداقل تعداد نیرو، حداکثر خروجی رو بگیره. یعنی اگه وارد بشی و اون چیزی نباشی که گفتی، خیلی سریعتر از قبل معلوم میشه؛ و خیلی سریعتر از قبل منجر به حذف میشه.
بدتر از اون: توی یه بازاری که کوچکتر شده، این چیزها بین آدمها میچرخه.
قبل از مصاحبه دادن، شرکت رو بشناس
این شاید مهمترین نکتهی این مطلب باشه و کمتر بهش اشاره بشه. الان دو سوال مهمتر از «آیا این شغل به دردم میخوره» وجود داره:
این شرکت شش ماه دیگه هنوز هست؟
و اگه هست، توی چه وضعیتی هست؟
بازار نرمافزار احتمالا در شرایط دشوار کنونی، بشه به سه گروه شرکت تقسیم کرد:
دسته اول: کمتر از پنج درصد: اونهایی که قبل از بحران بنیهشون رو ساختن. cash flow دارن، بدهی ندارن، و احتمالاً الان دست به کارهایی میزنن که توی شرایط عادی جرأتش رو نداشتن، چون رقیبها ضعیف شدن. اگه اینجا راه پیدا کنی، احتمالاً داری وارد جالبترین دورهی کاریشون میشی.
دسته دوم: اکثریت: شرکتهایی که زندهاند ولی توی فاز محافظهکاریاند. کمتر ریسک میکنن، کمتر استخدام میکنن، بیشتر نگران بقا هستن تا رشد. اینجا میشه کار کرد، ولی باید بدونی که داری وارد یه محیط پایدار ولی محدود میشی.
دسته سوم: شرکتهایی که اصلاً برنامه ندارن. یه روز استخدام میکنن، یه روز تعدیل. یه ماه حقوق نمیدن، یه روز لاین جدید محصول باز میکنن فرداش لغوش میکنن. اینجا وارد نشو! هرچقدر هم عنوان شغلی جذاب باشه.
چطور بفهمی کدوم دستهان؟
شرکتها این رو اعلام نمیکنن. باید دنبال نشونهها گشت، باید سابقه، بازار هدف و حتی مقدم بر محصولشون، «خط تولید نرمافزاریشون» رو بررسی کرد. نهایتا هم باید پرسوجو کرد، خصوصا از آدمهای درست.
قبل از مصاحبه: دنبال کسی بگرد که قبلاً اونجا کار کرده. نه برای اینکه بدگویی بشنوی، بلکه بپرسی «اگه الان جای من بودی، میرفتی؟»
توی مصاحبه: بپرس «بزرگترین چالشی که تیم الان باهاش روبروئه چیه؟». نه آخر مصاحبه، اول. جواب این سوال چیزهای زیادی بهت میگه. و تجربه و مهارت مذاکره/گفتوگو اینجا کمککننده خواهد بود.
روی اثبات توانایی کار کن، نه پر کردن خلاءها
یه اشتباه رایج اینه که آدمها قبل از مصاحبه سعی میکنن همهی ضعفهاشون رو پوشش بدن، یه دورهی سریع K8s، یه پروژهی نیمهکاره روی GitHub، یه آشنایی سطحی با granular scalability یا...
این انرژی رو بهتره بگذاری روی تعمیق دانش و مهارت پایه و اون چیزی که واقعاً بلدی، و سعی کن اونها رو قابل ارائه کنی (منظورم یه ارائهی با اعتمادبهنفس و مقتدرانه است). یه پروژهی کوچیک که کامله، از یه پروژهی بزرگ نیمهکاره خیلی بهتره. یه مشکل که واقعاً حلش کردی، از ده تا چیزی که «آشنام» ارزشمندتره.
مهارتهای نرم، و اینکه چرا الان جدیتر شدن
شاید بشه اینطور گفت که شرکتی که الان استخدام میکنه، داره روی یه آدم قمار میکنه، نه فقط روی مهارتش، روی اینکه توی شرایط سخت چطوره.
صبوری، قناعت، و اینکه بتونی با ابهام کنار بیای، اینها الان فقط «nice to have» نیستن. شرایط سختی که به همه از جمله شرکتها تحمیل شده، و کسی که این رو میدونه و باهاش کنار اومده، یه قدم جلوئه.
این رو نمیگم که تحمل بیاحترامی یا حقوق پایین رو توجیه کنیم چون نه تنها قابل توجیه نیست بلکه مذمومه. منظور اینه که آدمی که انتظاراتش با واقعیت و ظرفیت بازار، همآهنگ شده، توی مصاحبه هم این رو نشون میده، و مصاحبهگر میفهمه.
مهارتهای نرم دیگه، مثل کنترل هیجان، تمرکز و تفکیک فضای شخصی از کار (خصوصا این روزها که تشتت آراء بین افراد زیاده و باید فضای کار، تا حد امکان منفک از بحث و جدل باشه)؛ و یا تیمورک و انعطافپذیری و... همگی مهارتهایی هستن که در این شرایط خیلی واضحتر به چشم میان و ضروری به نظر میرسن.
در ادامه بخش اول که مربوط به مصاحبهگر بودن نوشتم، ای مطلب یه مرور سریع روی مصاحبه دادنه. شاید قبلاً توی مصاحبهها، یه چیزهایی گفتی که کاملاً درست، نبودن! یه پروژه رو کمی بزرگتر نشون دادی. یه تکنولوژی رو گفتی «آشنام»، در حالی که فقط اسمش رو شنیده بودی. یه مسئولیت رو به اسم خودت ثبت کردی که teamwork بود.
الان جای اینها (white lies، بلوف) نیست، نه به خاطر اینکه اخلاقاً درست نیست (که نیست)، بلکه چون ریسکش برای خودت چند برابر شده.
چرا بلوف الان خطرناکتره
شرکتی که الان استخدام میکنه، احتمالاً قصد داره روی حداقل تعداد نیرو، حداکثر خروجی رو بگیره. یعنی اگه وارد بشی و اون چیزی نباشی که گفتی، خیلی سریعتر از قبل معلوم میشه؛ و خیلی سریعتر از قبل منجر به حذف میشه.
بدتر از اون: توی یه بازاری که کوچکتر شده، این چیزها بین آدمها میچرخه.
قبل از مصاحبه دادن، شرکت رو بشناس
این شاید مهمترین نکتهی این مطلب باشه و کمتر بهش اشاره بشه. الان دو سوال مهمتر از «آیا این شغل به دردم میخوره» وجود داره:
این شرکت شش ماه دیگه هنوز هست؟
و اگه هست، توی چه وضعیتی هست؟
بازار نرمافزار احتمالا در شرایط دشوار کنونی، بشه به سه گروه شرکت تقسیم کرد:
دسته اول: کمتر از پنج درصد: اونهایی که قبل از بحران بنیهشون رو ساختن. cash flow دارن، بدهی ندارن، و احتمالاً الان دست به کارهایی میزنن که توی شرایط عادی جرأتش رو نداشتن، چون رقیبها ضعیف شدن. اگه اینجا راه پیدا کنی، احتمالاً داری وارد جالبترین دورهی کاریشون میشی.
دسته دوم: اکثریت: شرکتهایی که زندهاند ولی توی فاز محافظهکاریاند. کمتر ریسک میکنن، کمتر استخدام میکنن، بیشتر نگران بقا هستن تا رشد. اینجا میشه کار کرد، ولی باید بدونی که داری وارد یه محیط پایدار ولی محدود میشی.
دسته سوم: شرکتهایی که اصلاً برنامه ندارن. یه روز استخدام میکنن، یه روز تعدیل. یه ماه حقوق نمیدن، یه روز لاین جدید محصول باز میکنن فرداش لغوش میکنن. اینجا وارد نشو! هرچقدر هم عنوان شغلی جذاب باشه.
چطور بفهمی کدوم دستهان؟
شرکتها این رو اعلام نمیکنن. باید دنبال نشونهها گشت، باید سابقه، بازار هدف و حتی مقدم بر محصولشون، «خط تولید نرمافزاریشون» رو بررسی کرد. نهایتا هم باید پرسوجو کرد، خصوصا از آدمهای درست.
قبل از مصاحبه: دنبال کسی بگرد که قبلاً اونجا کار کرده. نه برای اینکه بدگویی بشنوی، بلکه بپرسی «اگه الان جای من بودی، میرفتی؟»
توی مصاحبه: بپرس «بزرگترین چالشی که تیم الان باهاش روبروئه چیه؟». نه آخر مصاحبه، اول. جواب این سوال چیزهای زیادی بهت میگه. و تجربه و مهارت مذاکره/گفتوگو اینجا کمککننده خواهد بود.
روی اثبات توانایی کار کن، نه پر کردن خلاءها
یه اشتباه رایج اینه که آدمها قبل از مصاحبه سعی میکنن همهی ضعفهاشون رو پوشش بدن، یه دورهی سریع K8s، یه پروژهی نیمهکاره روی GitHub، یه آشنایی سطحی با granular scalability یا...
این انرژی رو بهتره بگذاری روی تعمیق دانش و مهارت پایه و اون چیزی که واقعاً بلدی، و سعی کن اونها رو قابل ارائه کنی (منظورم یه ارائهی با اعتمادبهنفس و مقتدرانه است). یه پروژهی کوچیک که کامله، از یه پروژهی بزرگ نیمهکاره خیلی بهتره. یه مشکل که واقعاً حلش کردی، از ده تا چیزی که «آشنام» ارزشمندتره.
مهارتهای نرم، و اینکه چرا الان جدیتر شدن
شاید بشه اینطور گفت که شرکتی که الان استخدام میکنه، داره روی یه آدم قمار میکنه، نه فقط روی مهارتش، روی اینکه توی شرایط سخت چطوره.
صبوری، قناعت، و اینکه بتونی با ابهام کنار بیای، اینها الان فقط «nice to have» نیستن. شرایط سختی که به همه از جمله شرکتها تحمیل شده، و کسی که این رو میدونه و باهاش کنار اومده، یه قدم جلوئه.
این رو نمیگم که تحمل بیاحترامی یا حقوق پایین رو توجیه کنیم چون نه تنها قابل توجیه نیست بلکه مذمومه. منظور اینه که آدمی که انتظاراتش با واقعیت و ظرفیت بازار، همآهنگ شده، توی مصاحبه هم این رو نشون میده، و مصاحبهگر میفهمه.
مهارتهای نرم دیگه، مثل کنترل هیجان، تمرکز و تفکیک فضای شخصی از کار (خصوصا این روزها که تشتت آراء بین افراد زیاده و باید فضای کار، تا حد امکان منفک از بحث و جدل باشه)؛ و یا تیمورک و انعطافپذیری و... همگی مهارتهایی هستن که در این شرایط خیلی واضحتر به چشم میان و ضروری به نظر میرسن.
❤6👏2
ادامه مطلب قبل:
حرف آخر
حرف مطلب قبلم این بود که: قدرت دستته، پس مراقب باش. و این مطلب اینه که قدرت دست بازار است، پس هوشمند باش...
انتخاب شغل همیشه مهم بوده. ولی الان یه تصمیم اشتباه (یه شرکت یا یه پوزیشن اشتباه) میتونه شش ماه دیگه فرد رو دوباره توی همین موقعیت بذاره، ولی با انرژی کمتر و بازار سختتر.
پس قبل از اینکه فکر کنی چطور مصاحبه بدی، فکر کن کجا مصاحبه میدی و باید برای اون مصاحبه چجوری محیا باشی...
2
حرف آخر
حرف مطلب قبلم این بود که: قدرت دستته، پس مراقب باش. و این مطلب اینه که قدرت دست بازار است، پس هوشمند باش...
انتخاب شغل همیشه مهم بوده. ولی الان یه تصمیم اشتباه (یه شرکت یا یه پوزیشن اشتباه) میتونه شش ماه دیگه فرد رو دوباره توی همین موقعیت بذاره، ولی با انرژی کمتر و بازار سختتر.
پس قبل از اینکه فکر کنی چطور مصاحبه بدی، فکر کن کجا مصاحبه میدی و باید برای اون مصاحبه چجوری محیا باشی...
2
❤4👍3
سلام به همه؛
در طول یک سال گذشته، ایران ۳ دورهی تلخ و دشوار رو توی دفتر خاطرات چند هزارسالهاش نوشت. مرور کردنش توسط منی که از دور شاهد بود و به قول نسیم طالب، پوستی در بازی نداشتم، شاید بیشتر یک متن احساسی یا مرثیه باشه. پس از تکرارش پرهیز میکنم. پرواضحه که شرایط روحی همه، و البته شرایط اقتصادی جامعه و شرکتها در تنگنای کمسابقهای قرار داره. وضعیت اینترنت و تعدیلها و... هم بار مضاعف است به دوش همه. این روزها که ارتباطات قطع بود، اخبار به صورت قطرهچکونی منتقل میشد و همه اضطراب حال عزیزانمون و ایران رو داشتیم، بارها با خودم مرور کردم که چه کمکی از دستم ساخته است تا سهمی هرچند ناچیز در کاستن از آلام ایران داشته باشم.
سادهترین پاسخی که برای پرسش «چه کاری از من برای ایران ساخته است» به ذهنم رسید، این بود که مشاوره و همفکری بتونه مفید باشه، برای همین هم بخشی از زمان شنبه و یکشنبهام رو برای این کار در نظر خواهم گرفت. حوزه تخصصی من معماری نرمافزار، سیستمهای توزیعشده، پردازش سریع، و بهینهسازی الگورتیمی است. و به طور خلاصه عمده تجربیات من طی بیست و چند سال گذشته، شرکتها یا پروژههایی بوده که مسئله اصلیشون دیتای بزرگ، پرفرمنس سیستمهای پیچیده یا معماری نرمافزار بوده. اگر کمکی از من ساخته بود از طریق همین تلگرام پیام بدید و خوشحال میشم صحبت کنیم.
به امید روزهای بهتر، و حالِ بهتر همگی 🌱
در طول یک سال گذشته، ایران ۳ دورهی تلخ و دشوار رو توی دفتر خاطرات چند هزارسالهاش نوشت. مرور کردنش توسط منی که از دور شاهد بود و به قول نسیم طالب، پوستی در بازی نداشتم، شاید بیشتر یک متن احساسی یا مرثیه باشه. پس از تکرارش پرهیز میکنم. پرواضحه که شرایط روحی همه، و البته شرایط اقتصادی جامعه و شرکتها در تنگنای کمسابقهای قرار داره. وضعیت اینترنت و تعدیلها و... هم بار مضاعف است به دوش همه. این روزها که ارتباطات قطع بود، اخبار به صورت قطرهچکونی منتقل میشد و همه اضطراب حال عزیزانمون و ایران رو داشتیم، بارها با خودم مرور کردم که چه کمکی از دستم ساخته است تا سهمی هرچند ناچیز در کاستن از آلام ایران داشته باشم.
سادهترین پاسخی که برای پرسش «چه کاری از من برای ایران ساخته است» به ذهنم رسید، این بود که مشاوره و همفکری بتونه مفید باشه، برای همین هم بخشی از زمان شنبه و یکشنبهام رو برای این کار در نظر خواهم گرفت. حوزه تخصصی من معماری نرمافزار، سیستمهای توزیعشده، پردازش سریع، و بهینهسازی الگورتیمی است. و به طور خلاصه عمده تجربیات من طی بیست و چند سال گذشته، شرکتها یا پروژههایی بوده که مسئله اصلیشون دیتای بزرگ، پرفرمنس سیستمهای پیچیده یا معماری نرمافزار بوده. اگر کمکی از من ساخته بود از طریق همین تلگرام پیام بدید و خوشحال میشم صحبت کنیم.
به امید روزهای بهتر، و حالِ بهتر همگی 🌱
❤29
شاید مرور این جمله ماریو کوینتانا، شاعر برزیلی، این روزها که شرایط مطلوبمون نیست، و شاهد احاطه شدن پروفایلهای لینکدین با حلقههای سبزرنگ هستیم؛ بد نباشه!
«اگر وقتت رو صرف دنبال کردن پروانهها کنی، ازت فرار میکنن. اما اگر وقتت رو صرف ساختن یک باغ زیبا کنی، پروانهها خودشون به سراغت میان.
با این حال، اگر هم نیومدن، دستکم تو یک باغ زیبا برای خودت ساختهای.»
غم، جنگ، اقتصاد، اینترنت و خیلی چیزها میتونن به سرعت باطری ما رو از انرژی خالی کنن، با اینکه گفتنش ساده است و عمل کردن بهش اونم به وقت ابتلا خیلی سخته؛ ولی خوبه اینقدری انرژی رو ذخیره نگه داریم برای ساختن اون باغ! اون باغ یادگیری و تمرینه؛ همین. شاید به سرعت موقعیت کاری یا اقتصادی مطلوب به سراغمون نیاد، ولی دستکم؛ مهارت و دانش قابل اتکا خواهیم داشت... دیر یا زود امیدوارم بازار خودش رو با شرایط، تنظیم کنه؛ چرا که انطباقپذیری و میل به تعادل، خصوصیت قدیمی نوع بشره. حالا توی این فرایند، «زمان» تنها دارایی غیرقابل جبران؛ و «دانش و مهارت» تنها پساندازیه که میشه بهش تکیه کرد.
این شرایطِ سختی که به صورت جمعی تحمیل شده رو شاید بشه با حرکت جمعی، بهتر مدیریت کرد؛ یعنی یادگیری جمعی؛ پس موضوعاتی که شما پیشنهاد میدید، و نه چیزی که من تنها براش تصمیم میگیرم؛ شاید حرکت جمعی ما باشه. موضوع بعدی رو از کامنت دوستان انتخاب کردم: «فرهنگ و ساختار نسخهدهی توی تیمهای نرمافزاری». اینکه کِی و چرا monorepo، چرا و کِی gitflow یا github flow یا trunk یا... و مهمتر اینکه «فرهنگ» تیم چطور میتونه «روش» مورد استفاده رو به سمت کارآمدی یا عکسش پیش ببره.
If you spend your time chasing butterflies, they will run away. But if you spend your time creating a beautiful garden, then the butterflies will come to you.
However, if they don’t come, at least you have yourself a beautiful garden.
«اگر وقتت رو صرف دنبال کردن پروانهها کنی، ازت فرار میکنن. اما اگر وقتت رو صرف ساختن یک باغ زیبا کنی، پروانهها خودشون به سراغت میان.
با این حال، اگر هم نیومدن، دستکم تو یک باغ زیبا برای خودت ساختهای.»
غم، جنگ، اقتصاد، اینترنت و خیلی چیزها میتونن به سرعت باطری ما رو از انرژی خالی کنن، با اینکه گفتنش ساده است و عمل کردن بهش اونم به وقت ابتلا خیلی سخته؛ ولی خوبه اینقدری انرژی رو ذخیره نگه داریم برای ساختن اون باغ! اون باغ یادگیری و تمرینه؛ همین. شاید به سرعت موقعیت کاری یا اقتصادی مطلوب به سراغمون نیاد، ولی دستکم؛ مهارت و دانش قابل اتکا خواهیم داشت... دیر یا زود امیدوارم بازار خودش رو با شرایط، تنظیم کنه؛ چرا که انطباقپذیری و میل به تعادل، خصوصیت قدیمی نوع بشره. حالا توی این فرایند، «زمان» تنها دارایی غیرقابل جبران؛ و «دانش و مهارت» تنها پساندازیه که میشه بهش تکیه کرد.
این شرایطِ سختی که به صورت جمعی تحمیل شده رو شاید بشه با حرکت جمعی، بهتر مدیریت کرد؛ یعنی یادگیری جمعی؛ پس موضوعاتی که شما پیشنهاد میدید، و نه چیزی که من تنها براش تصمیم میگیرم؛ شاید حرکت جمعی ما باشه. موضوع بعدی رو از کامنت دوستان انتخاب کردم: «فرهنگ و ساختار نسخهدهی توی تیمهای نرمافزاری». اینکه کِی و چرا monorepo، چرا و کِی gitflow یا github flow یا trunk یا... و مهمتر اینکه «فرهنگ» تیم چطور میتونه «روش» مورد استفاده رو به سمت کارآمدی یا عکسش پیش ببره.
❤21👏4
انتخاب Gitflow یا Trunk-Based Development؟
انتخاب Monorepo یا Multirepo؟
انتخاب GitHub Flow یا GitLab Flow؟
به نظرم سؤال اصلی این نیست که «کدوم بهتره؟»
سؤال بهتر اینه که «هر کدوم برای حل چه مسئلهای ساخته شده؟»
خیلی از تیمها مدلهایی رو از شرکتهای بزرگ کپی میکنن، بدون اینکه همون سطح از CI/CD، تست، ownership، feature flag، release management و tooling رو داشته باشن. نتیجهاش هم معمولاً شلختگی، merge conflict، releaseهای پراسترس و کیفیت ناپایداره.
طی این دو پست، که پاسخی به سوال یکی از دوستان کانال است؛ به فرهنگ و ساختار نسخهدهی رو از چند زاویه بررسی کردم:
ساختار repository: شامل Monorepo، Multirepo، Microrepo
مدلهای branching: شامل: Gitflow، GitHub Flow، GitLab Flow، Trunk-Based Development
و بعد ترکیب اینها در سناریوهای واقعی: مثل monolith، microservice، تیم کوچیک، چند تیم، SemVer، CalVer و چکلیست تصمیمگیری.
هدفم نسخه پیچیدن نیست؛ بیشتر اینه که انتخابمون از روی شناخت باشه، نه تقلید.
🔗 بخش اول
🔗 بخش دوم
3
Please open Telegram to view this post
VIEW IN TELEGRAM
امین مصباحی
فرهنگ و ساختار نسخهدهی در تیمهای نرمافزاری (بخش اول)
مقدمه:فرهنگ و ساختار نسخهدهی توی تیمهای نرمافزاری، با اینکه پیشینه طولانی داره و نسل اولش به دهههای ۶۰ و ۷۰ و میلادی برمیگرده و حتی ابزارهای مدرنترش مثل git توی بیستسالگیشون به سر میبرن؛ ولی کماکان موضوعی مهم و اثرگذار روی تیمهاست. و البته کم نیستن…
❤8
♻️ مدیر محصول و مهندس نرمافزار: همکاری یا تنش؟ (بخش اول)
توی بیشتر تیمهای نرمافزاری، تنش بین مدیر محصول و مهندس یه چیز آشنا و گاها حتی رایجه. یه طرف میگه «این فیچر باید تا آخر ماه آماده بشه»، طرف دیگه میگه «نمیشه» و این گفتگو هر بار همینجا تموم میشه. بدون اینکه کسی بپرسه چرا این الگو تکرار میشه.
این دو مطلب رو نوشتم که نشون بده ریشهی این تنش نه بدنیتیه، نه ضعف فردی؛ ساختاریه. و هر مشکل ساختاری، راهحل ساختاری داره. بخش اول به این پرداختم که این چالش از کجا شکل میگیره، چه مدلهای سازمانی اونو تشدید میکنه، و شرکتهای بزرگ چطور باهاش کنار اومدن. بخش دوم فلوی عملیاتی رو از لحظهی شکلگیری یه ایده تا رسیدنش به محیط عملیاتی مرحله به مرحله بررسی میکنم.
🔗 بخش اول
توی بیشتر تیمهای نرمافزاری، تنش بین مدیر محصول و مهندس یه چیز آشنا و گاها حتی رایجه. یه طرف میگه «این فیچر باید تا آخر ماه آماده بشه»، طرف دیگه میگه «نمیشه» و این گفتگو هر بار همینجا تموم میشه. بدون اینکه کسی بپرسه چرا این الگو تکرار میشه.
این دو مطلب رو نوشتم که نشون بده ریشهی این تنش نه بدنیتیه، نه ضعف فردی؛ ساختاریه. و هر مشکل ساختاری، راهحل ساختاری داره. بخش اول به این پرداختم که این چالش از کجا شکل میگیره، چه مدلهای سازمانی اونو تشدید میکنه، و شرکتهای بزرگ چطور باهاش کنار اومدن. بخش دوم فلوی عملیاتی رو از لحظهی شکلگیری یه ایده تا رسیدنش به محیط عملیاتی مرحله به مرحله بررسی میکنم.
🔗 بخش اول
در ضمن این مطلب رو بنا به سوال یکی از دوستان کانال نوشتم. اولویت فعلیم برای موضوع مطالب، چالشها و سوالهای شماست؛ پس اگر پیشنهادی دارید خوشحال میشم مطرح کنید.
امین مصباحی
مدیر محصول و مهندس نرمافزار: همکاری یا تنش؟ (بخش اول)
بخش اول: ریشهشناسی یک تنش ساختاری مقدمه: دعوای ظاهری، مشکل ساختاری این گفتوگو تکراری، بین مدیرمحصول و مهندس نرمافزار رو توی خیلی از تیمهای نرمافزاری میبینیم:– مدیر محصول یه فیچر رو تعریف میکنه+ مهندس نرمافزار: «اینجوری نمیشه»– مدیر محصول: «چرا…
❤13
♻️♻️ مدیر محصول و مهندس نرمافزار: همکاری یا تنش؟ (بخش دوم)
بخش ۲، فلوی شکلگیری ایده تا رسیدن به محصول و محیط عملیاتی
در بخش اول دیدیم که ریشهی تنش بین مدیر محصول و مهندس، بیشتر از اینکه یه موضوع فردی باشه، یک مشکل ساختاریه. ابهام در مالکیت، اشتباه گرفتن Product Manager با Project Manager، و موندن توی مدل Feature Team، باعث میشه سیستم به سمت اصطکاک هدایت بشه، نه همکاری.
اما دونستن ریشه کافی نیست. سوال عملی اینه: یک ایده چطور باید از ذهن مدیر محصول به محیط عملیاتی برسه؟ چه کسی در هر مرحله مالک است؟ چه ابزاری کمک میکنه؟ و شرکتهای بزرگ این مسیر رو چطور طی میکنن؟ در این بخش به همین سوالها خواهم پرداخت.
فلوی کامل: از ایده تا Production
مسیر یک فیچر از لحظهی تولد تا استقرار، از شش مرحلهی مجزا عبور میکنه. هر مرحله یک مالک مشخص، یک ورودی مشخص، و یک خروجی مشخص باید داشته باشه.
مطلب کامل رو از لینک زیر مطالعه کنید:
🔗 بخش اول
🔗 بخش دوم
💬 نظر و تجربه شما چیه؟
بخش ۲، فلوی شکلگیری ایده تا رسیدن به محصول و محیط عملیاتی
در بخش اول دیدیم که ریشهی تنش بین مدیر محصول و مهندس، بیشتر از اینکه یه موضوع فردی باشه، یک مشکل ساختاریه. ابهام در مالکیت، اشتباه گرفتن Product Manager با Project Manager، و موندن توی مدل Feature Team، باعث میشه سیستم به سمت اصطکاک هدایت بشه، نه همکاری.
اما دونستن ریشه کافی نیست. سوال عملی اینه: یک ایده چطور باید از ذهن مدیر محصول به محیط عملیاتی برسه؟ چه کسی در هر مرحله مالک است؟ چه ابزاری کمک میکنه؟ و شرکتهای بزرگ این مسیر رو چطور طی میکنن؟ در این بخش به همین سوالها خواهم پرداخت.
فلوی کامل: از ایده تا Production
مسیر یک فیچر از لحظهی تولد تا استقرار، از شش مرحلهی مجزا عبور میکنه. هر مرحله یک مالک مشخص، یک ورودی مشخص، و یک خروجی مشخص باید داشته باشه.
Discovery → Shaping → Spec → RFC → Development → Release
مطلب کامل رو از لینک زیر مطالعه کنید:
🔗 بخش اول
🔗 بخش دوم
Please open Telegram to view this post
VIEW IN TELEGRAM
امین مصباحی
مدیر محصول و مهندس نرمافزار: همکاری یا تنش؟ (بخش دوم)
بخش ۲، فلوی شکلگیری ایده تا رسیدن به محصول و محیط عملیاتی در بخش اول دیدیم که ریشهی تنش بین مدیر محصول و مهندس، بیشتر از اینکه یه موضوع فردی باشه، یک مشکل ساختاریه. ابهام در مالکیت، اشتباه گرفتن Product Manager با Project Manager، و موندن توی مدل Feature…
❤10
نقش AI در آینده شغلی و حرفهای ما و البته خیلی رشتههای دیگه نه تنها غیرقابل انکاره، بلکه همراه با ملاحظاتی است که اگه ازشون غافل باشیم، شاید از گردونه رقابت حذف شیم یا در حالت خوشبینانهترش، نقشمون کمرنگ و موقعیتمون متزلزل بشه.
استفاده از AI برای توسعه نرمافزار، فقط این نیست که «چقدر سریعتر کد تولید میکنیم». مسئله مهمتر اینه که «چه کسی» «چه» تصمیمی رو «چرا» میگیره؟! «مدل» تصمیمگیر و تعیینکنندهی «جهت» است یا «دانش ما»؟!
برای درک این مطلب، یک قابلیت ساده مثل احراز هویت و دسترسی رو توی یک REST API را از سه سطح نگاه بررسی کردم:
سطح اول: پرامپتی که قابلیت رو مطالبه میکنه
سطح دوم: پرامپت مهندسیشده که جهتگیری و چگونگی رو تبیین میکنه
سطح سوم: Skill، Agent و استانداردسازی سازمانی
خلاصهی مطلبم اینه که:
امروز AI میتونه سرعت بده؛ اما جهت رو هنوز دانش مهندسی تعیین میکنه.
پس AI در توسعه نرمافزار؛ یه ضریبه.
اگر دانش داری، ضریبی که سرعتت رو بالا میبره. اگر دانش نداری، ضریبی که اشتباهاتت رو سریعتر تولید میکنه.
🔗 لینک مطلب
Please open Telegram to view this post
VIEW IN TELEGRAM
❤11👍8
طی چند ماه اخیر، چند نمونه از بازنویسی محصولات بزرگ با کمک AI منتشر شد که ارزش توقف و مرور عمیقتر و بینسطور این اخبار رو داره!
مثلا کلادفلر نسخه اولیه EmDash رو منتشر کرد؛ بازنویسی وردپرس با TypeScript، با معماری AI-native که هم امنتره هم سبکتر. همین کلادفلر کمی قبلترش، vinext رو هم به عنوان نسخه بهینهتر از Next.js طی مدت کوتاهی توسعه داد. LakeSail نشون داد که میشه یه SQL parser رو با Rust در یک هفته نوشت که از نمونههای مشابه (PySpark) عملکرد بهتری داشته باشه. و نمونه مفهومیتر، پروژه cpp-to-rust-skill بود که البته برای کدبیسهای واقعی و بزرگ به تنهایی کافی نیست.
نکته مشترک همه این مثالها: این تیمها از AI برای تسریع چیزی استفاده کردن که خودشون بهش تسلط داشتن. دانش domain، تجربه معماری، و درک عمیق از مشکلی که میخواستن حل کنن؛ اینا پیشنیاز بود، نه خروجی AI. ابزار سرعت داد، نه جهت.
البته نمونههای زیادی هم هست که اولش خیلی سریع با AI تولید شده، بعدن توی دیباگ و نگهداری و… عاجز موندن.
این تمایز، یه سوال جدیتر رو باز میکنه و من به عنوان بهانه برای مطالب بعدی میخوام ازش استفاده کنم (در صورت استقبال)
وقتی یکی از مراحل SDLC؛ یعنی توسعه؛ سریعتر و ارزونتر میشه، بقیه بلاکهای چرخه نمیتونن بدون تغییر بمونن. Requirements & Analysis باید دقیقتر بشه، نه سطحیتر. Testing باید پوشش بیشتری بده، چون خروجی بیشتره و حالتها غیرقابل پیشبینی، بیشتر. Maintenance باید پذیرای کدی باشه که شاید کمتر «دستساز» احساس بشه. حتی ownershipها باید بازنگری شن. مسئولیتهای tech lead هم دیگه مثل قبل نیست.
اگه علاقهمند باشید، یه مطلب مفصلتر درباره تغییرات لایهبهلایه SDLC در دوره AI مینویسم.
💬 به نظرتون در سازمان شما، کدوم بلاک SDLC بیشترین lag رو داره؟ لیدرشیپ سازمان و تیمتون خودش رو با دوره AI همآهنگ کرده؟!
6
Please open Telegram to view this post
VIEW IN TELEGRAM
The Cloudflare Blog
Introducing EmDash — the spiritual successor to WordPress that solves plugin security
Today we are launching the beta of EmDash, a full-stack serverless JavaScript CMS built on Astro 6.0. It combines the features of a traditional CMS with modern security, running plugins in sandboxed Worker isolates.
استفاده از مدلهای آفلاین AI برای توسعه نرمافزار
اپیزود اخیر پادکست Merge Conflict، در مورد موضوع جالبیه که که شاید توی شرایط فعلی اینترنت ایران، مرورش بد نباشه. استفاده از مدلهای مختلف AI داخل VS Code و GitHub Copilot، ولی از طریق BYOK (یا Bring Your Own Key).
یعنی به جای اینکه فقط از مدلهای پیشفرض Copilot، Claude Code، Cursor یا ابزارهای مشابه استفاده بشه، بتونیم کلید API خودمون را از OpenAI، Anthropic، Azure Foundry، OpenRouter یا حتی سرویسهای دیگه که خودمون هاست کردیم بگیریم. بدون وابستگی به اینترنت. بدون مصرف اعتبار Copilot. مثلا Qwen با حدود ۲۷ میلیارد پارامتر، با quantization چهار بیتی، روی یک GPU با ۲۴ گیگابایت VRAM اجرا میشه. و تجربه گوینده توی خیلی از کارهای روزمره کدنویسی، تشخیص تفاوت بین این مدلهای کوچیک و لوکال از مدلهای بزرگی مثل Opus یا Sonnet رو سخت کرده!
نکته اول اینکه شاید ما بیش از حد روی «اسم مدل» حساس شدیم. یا اولویت مدل رو به فرایند برتری دادیم.
به جای اینکه بپرسیم Claude بهتره یا GPT؟ Sonnet بهتره یا Opus؟ شاید سوال مهمتر این باشه که آیا workflow ما درست طراحی شده یا نه؟ این چالش فقط برای دلداری دادن برای استفاده از مدل آفلاین نیست؛ خیلی شرکتها و تیمها چالش هزینه مصرف توکن رو دارن (و مثلا مایکروسافت اشتراک Claude code نیروهاش رو داره قطع میکنه) یا تجربه شخصی خودم: اعدادی که هر ماه از میزان مصرف توکن و هزینهی AI تیمم میگیرم؛ باعث شد بفهمم خیلی از برنامهنویسها ولو اینکه توی حوزه خودشون که اتفاقا AI هم هست، تخصص عمیق و تجربه طولانی دارن؛ الزاما LLM رو به خوبی نمیشناسن و ۵ رکن Harness و Model و Context و Tools و Prompts رو درک نکردند. برای همین مصرف توکنشون و هزینهشون خیلی بالاست؛ و مثلا برای تولید توضیحات PR هم از مدلهای بزرگ و گرون مثل Opus 4.7 و GPT 5.5 و... استفاده میکنن!! اگر دوست داشتید میتونیم روی این موضوع عمیقتر صحبت کنیم بعدن.
ولی به صورت کلی؛ اگه context رو خوب بسازیم؛ فایلهای درست رو در اختیار agent بگذاریم، planning داشته باشیم، task رو خوب خرد کنیم و خروجی رو مرحله به مرحله review کنیم، شاید تفاوت مدلها توی خیلی از سناریوهای روزمره کمتر از چیزی باشه که تصور میکنیم.
دوم اینکه agent فقط مدل نیست. و چیزی که ما توی VS Code، Copilot، Claude Code یا Cursor یا گراکبیلد تجربه میکنیم، فقط یه LLM خام نیست. پشتش کلی system prompt، ابزار خوندن و ویرایش فایل، حافظه، planning mode، sub-agent، permissions و کلی glue code دیگه وجود داره. به همین دلیل دو ابزار مختلف با یک مدل یکسان، لزوما تجربه یکسانی نمیدن.
مدل مهمه؛ اما harness یا همون محیطی که مدل رو تبدیل به یه دستیار کدنویسی واقعی میکنه هم به همون اندازه مهمه و باید خوب یادش بگیریم. باز به تجربه خودم برگردم که چند ماه پیش متوجه شدم که بعضی از بچههای تیم؛ در مورد امکان و شیوه دیباگ کردن مدل AI و ایجنتهاش بیاطلاعن؛ این یعنی همونطور که ما در رابطه با یک IDE جدید، زیر و بم امکانات، میانبرها و ابزارهای دیباگ کردنش رو یاد میگیریم؛ باید کارکرد و اجزاء ابزارهایی مثل کوپایلوت و کلادکد و... رو هم عمیق و اصولی یاد بگیریم و مثل چت تلگرام ازشون استفاده نکنیم.
و اینکه هنوز محدودیتها جدیان. همه یک RTX 3090 یا 4090 ندارن (البته وقتی وضع اینترنت اینه شاید شرکتها بتونن بهش فکر کنن؛ من سعی کردم ببینم الان قیمت ریالی این کارتها چنده؛ ولی به طور شرمآوری هر سایت داخلی که توی صفحه اول گوگل اومد، در دسترس نبود!!).
نهایتا این مطلب هم برای استفاده از مدلهای لوکال و Copilot CLI شاید مفید باشه.
امیدوارم چنین راهکارهایی از سر انتخاب و ترجیح انجام باشه به جای اجبار و ناچاری.
خوشحال میشم نظر یا تجربه شما رو هم بدونم 😊
از اینکه این مطلب رو نه الزاما به عنوان یک موضوع مهندسی، بلکه با در نظر گرفتن شرایط تحمیلی این روزهای اینترنت ایران؛ و تفکر مخرب اینترنت طبقاتی دارم مینویسم؛ حس بدی دارم!
اپیزود اخیر پادکست Merge Conflict، در مورد موضوع جالبیه که که شاید توی شرایط فعلی اینترنت ایران، مرورش بد نباشه. استفاده از مدلهای مختلف AI داخل VS Code و GitHub Copilot، ولی از طریق BYOK (یا Bring Your Own Key).
یعنی به جای اینکه فقط از مدلهای پیشفرض Copilot، Claude Code، Cursor یا ابزارهای مشابه استفاده بشه، بتونیم کلید API خودمون را از OpenAI، Anthropic، Azure Foundry، OpenRouter یا حتی سرویسهای دیگه که خودمون هاست کردیم بگیریم. بدون وابستگی به اینترنت. بدون مصرف اعتبار Copilot. مثلا Qwen با حدود ۲۷ میلیارد پارامتر، با quantization چهار بیتی، روی یک GPU با ۲۴ گیگابایت VRAM اجرا میشه. و تجربه گوینده توی خیلی از کارهای روزمره کدنویسی، تشخیص تفاوت بین این مدلهای کوچیک و لوکال از مدلهای بزرگی مثل Opus یا Sonnet رو سخت کرده!
نکته اول اینکه شاید ما بیش از حد روی «اسم مدل» حساس شدیم. یا اولویت مدل رو به فرایند برتری دادیم.
به جای اینکه بپرسیم Claude بهتره یا GPT؟ Sonnet بهتره یا Opus؟ شاید سوال مهمتر این باشه که آیا workflow ما درست طراحی شده یا نه؟ این چالش فقط برای دلداری دادن برای استفاده از مدل آفلاین نیست؛ خیلی شرکتها و تیمها چالش هزینه مصرف توکن رو دارن (و مثلا مایکروسافت اشتراک Claude code نیروهاش رو داره قطع میکنه) یا تجربه شخصی خودم: اعدادی که هر ماه از میزان مصرف توکن و هزینهی AI تیمم میگیرم؛ باعث شد بفهمم خیلی از برنامهنویسها ولو اینکه توی حوزه خودشون که اتفاقا AI هم هست، تخصص عمیق و تجربه طولانی دارن؛ الزاما LLM رو به خوبی نمیشناسن و ۵ رکن Harness و Model و Context و Tools و Prompts رو درک نکردند. برای همین مصرف توکنشون و هزینهشون خیلی بالاست؛ و مثلا برای تولید توضیحات PR هم از مدلهای بزرگ و گرون مثل Opus 4.7 و GPT 5.5 و... استفاده میکنن!! اگر دوست داشتید میتونیم روی این موضوع عمیقتر صحبت کنیم بعدن.
ولی به صورت کلی؛ اگه context رو خوب بسازیم؛ فایلهای درست رو در اختیار agent بگذاریم، planning داشته باشیم، task رو خوب خرد کنیم و خروجی رو مرحله به مرحله review کنیم، شاید تفاوت مدلها توی خیلی از سناریوهای روزمره کمتر از چیزی باشه که تصور میکنیم.
دوم اینکه agent فقط مدل نیست. و چیزی که ما توی VS Code، Copilot، Claude Code یا Cursor یا گراکبیلد تجربه میکنیم، فقط یه LLM خام نیست. پشتش کلی system prompt، ابزار خوندن و ویرایش فایل، حافظه، planning mode، sub-agent، permissions و کلی glue code دیگه وجود داره. به همین دلیل دو ابزار مختلف با یک مدل یکسان، لزوما تجربه یکسانی نمیدن.
مدل مهمه؛ اما harness یا همون محیطی که مدل رو تبدیل به یه دستیار کدنویسی واقعی میکنه هم به همون اندازه مهمه و باید خوب یادش بگیریم. باز به تجربه خودم برگردم که چند ماه پیش متوجه شدم که بعضی از بچههای تیم؛ در مورد امکان و شیوه دیباگ کردن مدل AI و ایجنتهاش بیاطلاعن؛ این یعنی همونطور که ما در رابطه با یک IDE جدید، زیر و بم امکانات، میانبرها و ابزارهای دیباگ کردنش رو یاد میگیریم؛ باید کارکرد و اجزاء ابزارهایی مثل کوپایلوت و کلادکد و... رو هم عمیق و اصولی یاد بگیریم و مثل چت تلگرام ازشون استفاده نکنیم.
و اینکه هنوز محدودیتها جدیان. همه یک RTX 3090 یا 4090 ندارن (البته وقتی وضع اینترنت اینه شاید شرکتها بتونن بهش فکر کنن؛ من سعی کردم ببینم الان قیمت ریالی این کارتها چنده؛ ولی به طور شرمآوری هر سایت داخلی که توی صفحه اول گوگل اومد، در دسترس نبود!!).
نهایتا این مطلب هم برای استفاده از مدلهای لوکال و Copilot CLI شاید مفید باشه.
امیدوارم چنین راهکارهایی از سر انتخاب و ترجیح انجام باشه به جای اجبار و ناچاری.
خوشحال میشم نظر یا تجربه شما رو هم بدونم 😊
بعضی آدمها مثل Andrej Karpathy اسمشون فقط یک رزومه نیست؛ بلکه سیگناله!
کسی که رهبری بخش AI و Autopilot Vision تسلا رو بر عهده داشت، عضو اولیه OpenAI بوده، و البته از چهرههای مهم آموزش Deep Learning بوده هزاران نفر بخشی از سواد AIشون رو از محتوای آموزشی ایشون دارن.
حالا ایشون رفته Anthropic؛ و میدونیم که احتمالا امسال آنتروپیک در مسیر IPO شدن و عرضه عمومی سهام است. و ماموریتش pre-training مدلهای Claude است.
بعد از خبر پیوستنش به آنتروپیک، بعضیها نوشتند که حضور Karpathy به تنهایی دهها میلیارد دلار به ارزشگذاری Anthropic اضافه کرده. (عدد دقیقش رو باید با احتیاط دید؛ چون سوشالمدیا اغراق دوست داره)
چیزی که همیشه برام جذاب بوده اینه که حضور یه آدم، همیشه پر کردن یک position نیست. گاهی مولفه اثرگذار روی سرنوشت محصول یا شرکته. گاهی یه signal مهم به بازار. گاهی سیگنال به استعدادهای اون حوزه. گاهی سیگنال به سرمایهگذارها. و گاهی حتی یه سیگنال به رقباست.
به نظرم هر از گاهی خوبه تا از خودمون بپرسیم:
«روی زمین، و نه پای منقل و سماور، من واقعاً چقدر برای سازمانم ارزش میسازم؟»
نه توی ذهن خودم یا گندهگوییهام پیش رفقا. نه توی عنوان شغلی. نه بنا به تعداد جلسهها یا میزان شلوغی تقویممون.
بلکه توی توان حل مسئله، کاهش ریسک، ساختن سیستم، تربیت آدمهای بهتر، و بالا بردن کیفیت تصمیمهای سازمان.
همه قرار نیست Karpathy باشیم. ولی همه میتونیم از خودمون بپرسیم: حضور من چه چیزی رو با چه میزان ارزشی واقعا بهتر میکنه؟
کسی که رهبری بخش AI و Autopilot Vision تسلا رو بر عهده داشت، عضو اولیه OpenAI بوده، و البته از چهرههای مهم آموزش Deep Learning بوده هزاران نفر بخشی از سواد AIشون رو از محتوای آموزشی ایشون دارن.
حالا ایشون رفته Anthropic؛ و میدونیم که احتمالا امسال آنتروپیک در مسیر IPO شدن و عرضه عمومی سهام است. و ماموریتش pre-training مدلهای Claude است.
بعد از خبر پیوستنش به آنتروپیک، بعضیها نوشتند که حضور Karpathy به تنهایی دهها میلیارد دلار به ارزشگذاری Anthropic اضافه کرده. (عدد دقیقش رو باید با احتیاط دید؛ چون سوشالمدیا اغراق دوست داره)
چیزی که همیشه برام جذاب بوده اینه که حضور یه آدم، همیشه پر کردن یک position نیست. گاهی مولفه اثرگذار روی سرنوشت محصول یا شرکته. گاهی یه signal مهم به بازار. گاهی سیگنال به استعدادهای اون حوزه. گاهی سیگنال به سرمایهگذارها. و گاهی حتی یه سیگنال به رقباست.
به نظرم هر از گاهی خوبه تا از خودمون بپرسیم:
«روی زمین، و نه پای منقل و سماور، من واقعاً چقدر برای سازمانم ارزش میسازم؟»
نه توی ذهن خودم یا گندهگوییهام پیش رفقا. نه توی عنوان شغلی. نه بنا به تعداد جلسهها یا میزان شلوغی تقویممون.
بلکه توی توان حل مسئله، کاهش ریسک، ساختن سیستم، تربیت آدمهای بهتر، و بالا بردن کیفیت تصمیمهای سازمان.
همه قرار نیست Karpathy باشیم. ولی همه میتونیم از خودمون بپرسیم: حضور من چه چیزی رو با چه میزان ارزشی واقعا بهتر میکنه؟
❤28
اگر با مفهوم و ساختار skill آشنا نیستین، پیشتر در موردش نوشتم (مقدمهای بر Skills، مهارتآموزی AI برای توسعه نرمافزار)
دیگه Skill خوب نوشتن، مثل خوب کد نوشتن، یکی از معیارهای برنامهنویس خوب بود شده. گاهی فکر میکنم صرف نوشتن یه Agent Skill همه چیز تمومه؛ در حالی که اینطور نیست و معلوم نیست اسکیلی که نوشتیم چقدر خوب کار میکنه و شاید حتی استفاده نشه یا برای مدل، بدآموزی داشته باشه! طی یک سال گذشته، به جز کدریویو، من کلی اسکیلریویو هم کردم و قبل از این ابزارها، که توی این مطلب معرفی خواهم کرد؛ ابزارهای داخلی برای تیم توسعه دادیم چون بنچمارکهایی که روی کدبیسهای بزرگ داشتم نشون میده که مدلهای AI و ابزارهای مختلف، خیلی به کیفیت و ساختار اسکیل اهمیت میدن (یا به بیان بهتر ازش اثرپذیری دارن). ولی الان ابزارهای کدبازی مثل waza یا skill validator هستن که در مورد کیفیت اسکیلها بررسی انجام میدن و اگر از AI استفاده میکنین؛ استفاده ازشون حیاتی به نظر میاد.
مثلا شاید بگین ساختار و spec رو رعایت کردم؛ ولی لینکهات سالمن؟ token budget رو رعایت کردی؟ روی Claude و GPT هر دو یهجور رفتار میکنه؟ agent واقعاً میدونه کِی باید این skill رو استفاده کنه؟
دو تا ابزار که این سؤالها رو جواب میدن: یکی Waza و skill-validator هستن که میشه به صورت مستقل یا توی پایپلاین CI/CD ازشون استفاده کرد.
در مورد این دوتا اینجا نوشتم؛ اگر دوست داشتید بخونید :)
🔗 [لینک مطلب]
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7
هفته گذشته رایان پیترمن، مصاحبه مفصلی با بیارنه استراستروپ، خالق سیپلاسپلاس منتشر کرد که حداقل برای من بیشتر یک درس بود تا مصاحبه.
اگر دوست دارید از مهندسی عمیق؛ تجربه؛ و موضوعاتی فارغ از حبابهای زودگذر بشنوین؛ این مصاحبه خیلی ارزشمنده.
- داستان پیدایش ++C و دوران آزمایشگاههای بل
- فلسفه طراحی زبان و بحث شیءگرایی
- چالشهای فنی پیادهسازی و مفهوم abstraction با هزینه صفر (Zero/Negative Overhead):
- پاسخ به انتقادها درباره امنیت حافظه و کدهای مدرن ++C
داستان شکلگیری کمیته استاندارد ISO برای ++C و دموکراسی در توسعه زبان
- آینده برنامهنویسی و نقش هوش مصنوعی (LLMs)
- اشتباهات گذشته و حسرتها
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8👍4
بهینهسازی خودکارِ مهارتها، SkillOpt
چند سال پیش یکی از مهمترین دغدغههای استفاده از AI این سوالها بود: «کدوم مدل رو استفاده کنیم؟» یا «چجوری پرامپت بهتری بنویسیم؟»
حالا سوال مهمتر اینه: «این مدل با چه skillهایی کار میکنه، و کی کیفیتشون رو تضمین میکنه؟»
خروجی یه پروژهی تحقیقاتی مشترک Microsoft و چند دانشگاه چینی شده SkillOpt که این هفته بهصورت کدباز منتشر شد. ایدهاش سادهست: به جای fine-tune کردن مدل، فایل skill رو train کن.
یعنی یه فایل Markdown به عنوان trainable parameter یه agent frozen در نظر گرفته میشه. و optimizer، مسیر حل مسئله رو تحلیل میکنه، تغییرات ساختارمند پیشنهاد میده، و فقط اگه روی مرحله ارزیابی، بهتر شده بود، تغییرات رو قبول میکنه.
خروجی نهایی؟ یه best_skill.md بین ۳۰۰ تا ۲۰۰۰ توکن. بدون تغییر وزن مدل، بدون overhead در inference. نتایج تجربیشون روی ۵۲ از ۵۲ سلول ارزیابی بهترین یا مساوی بهترین بوده. روی GPT-5.5 بهطور میانگین +۲۳.۵ امتیاز نسبت به حالت بدون skill.
اما به نظرم مهمتر از خود ابزار، پیامشه:
اسکیل خوب میتونه خروجی یه مدل معمولی رو خیلی بهتر کنه. اسکیل بد میتونه خروجی یه مدل قوی رو خراب کنه. و اسکیل بدون validation و lifecycle، دیر یا زود تبدیل میشه به همون بدهی فنی قدیمی، فقط این بار در لباس AI.
اگه ۲۰ دقیقه وقت دارید و میخواید بدونید این چرخه بهینهسازی، چجوری کار میکنه، چه فرقی با prompt tuning معمولی داره، و چرا governance روی اسکیلها برای تیمهای انترپرایز جدیه، نسخهی مفصلتر رو روی بلاگ بخونید.
🔗لینک مطلب کامل روی بلاگ خودم
چند سال پیش یکی از مهمترین دغدغههای استفاده از AI این سوالها بود: «کدوم مدل رو استفاده کنیم؟» یا «چجوری پرامپت بهتری بنویسیم؟»
حالا سوال مهمتر اینه: «این مدل با چه skillهایی کار میکنه، و کی کیفیتشون رو تضمین میکنه؟»
خروجی یه پروژهی تحقیقاتی مشترک Microsoft و چند دانشگاه چینی شده SkillOpt که این هفته بهصورت کدباز منتشر شد. ایدهاش سادهست: به جای fine-tune کردن مدل، فایل skill رو train کن.
یعنی یه فایل Markdown به عنوان trainable parameter یه agent frozen در نظر گرفته میشه. و optimizer، مسیر حل مسئله رو تحلیل میکنه، تغییرات ساختارمند پیشنهاد میده، و فقط اگه روی مرحله ارزیابی، بهتر شده بود، تغییرات رو قبول میکنه.
خروجی نهایی؟ یه best_skill.md بین ۳۰۰ تا ۲۰۰۰ توکن. بدون تغییر وزن مدل، بدون overhead در inference. نتایج تجربیشون روی ۵۲ از ۵۲ سلول ارزیابی بهترین یا مساوی بهترین بوده. روی GPT-5.5 بهطور میانگین +۲۳.۵ امتیاز نسبت به حالت بدون skill.
اما به نظرم مهمتر از خود ابزار، پیامشه:
اسکیل خوب میتونه خروجی یه مدل معمولی رو خیلی بهتر کنه. اسکیل بد میتونه خروجی یه مدل قوی رو خراب کنه. و اسکیل بدون validation و lifecycle، دیر یا زود تبدیل میشه به همون بدهی فنی قدیمی، فقط این بار در لباس AI.
اگه ۲۰ دقیقه وقت دارید و میخواید بدونید این چرخه بهینهسازی، چجوری کار میکنه، چه فرقی با prompt tuning معمولی داره، و چرا governance روی اسکیلها برای تیمهای انترپرایز جدیه، نسخهی مفصلتر رو روی بلاگ بخونید.
🔗لینک مطلب کامل روی بلاگ خودم
❤10
وقتی ابزار بودن AI Agent تبدیل به «باور» میشه!
اگر پیگیر تحولات حوزه AI باشین، تکاپوی شرکتهای بزرگ تکنولوژی برای تکمیل تکههای پازل «AI در انترپرایز» رو درک کردید؛ و کمکم ابزارها، تحقیقها، و روشهایی که پیشتر به صورت داخلی استفاده میکردن رو علنی میکنن یا از ابدا به صورت عمومی توسعه میدن. اما تمرکز از مدل، یا چتبات به سمت «زیرساخت» رفته.
دو نمونه برای مثال یا سرنخ:
🔐 انتشار NVIDIA SkillSpector: یه security scanner برای AI agent skills. بر اساس کار تحقیقی روی ۴۲ هزار skill واقعی که نشون داده ۲۶٪ شون آسیبپذیری دارن و ۵٪ هم احتمالاً مخرب هستن! SkillSpector تا الا ۶۴ تا الگوی مشخص رو اسکن میکنه: از prompt injection و data exfiltration گرفته تا privilege escalation، memory poisoning، و MCP tool poisoning.
⚖️ انتشار Microsoft Agent Governance Toolkit: که یه لایه governance برای دپلوی کردن ایجنتها در محیط عملیاتیه. سه سوال اصلی رو هدف میگیره: این action مجاز هست؟ کدوم ایجنت این کار رو کرد؟ میتونی ثابت کنی چه اتفاقی افتاد؟ از policy enforcement با YAML/OPA/Cedar گرفته تا identity با SPIFFE و audit log با Merkle chain. حتی cost و token budget هم داخلش هست.
اما این همه ماجرا نیست. وقتی agent ها از اسباببازی به ابزار کاری تبدیل میشن، یه لایه کامل از مشکلات ظاهر میشه که قبلاً وجود نداشت:
- چه کسی هزینه inference رو میپردازه و چطور باید ردیابیش کرد؟
- اگر agent ای یه تصمیم اشتباه گرفت و خسارت زد، مسئولیت با کیه؟
- چطور ثابت میکنی که ایجنت در لحظهی تصمیم، دقیقاً با همون policy که تأیید شده بود کار میکرد؟
- وقتی دهها ایجنت به هم وکالت میدن (delegation chain)، اعتماد بینشون چجوری منتقل میشه؟
اینها سوالهای فنی نیستن. یا دقیقتر بگم: فقط فنی نیستند.
شرکتهای بزرگ دارن میفهمن که مشکل اصلی ایجنتها، هوش مصنوعی داخل شون نیست. مشکل اصلی، اعتماد، مسئولیت، و قابلیت audit است.
درست مثل همون چیزی که سالها پیش با مایرکوسرویسها صنعت یاد گرفت؛ ولی این بار با ریسک بالاتر!
سوال: ایا این موضوعات جایی بین دغدغههای سازمان و تیم شما داره؟
اگر پیگیر تحولات حوزه AI باشین، تکاپوی شرکتهای بزرگ تکنولوژی برای تکمیل تکههای پازل «AI در انترپرایز» رو درک کردید؛ و کمکم ابزارها، تحقیقها، و روشهایی که پیشتر به صورت داخلی استفاده میکردن رو علنی میکنن یا از ابدا به صورت عمومی توسعه میدن. اما تمرکز از مدل، یا چتبات به سمت «زیرساخت» رفته.
دو نمونه برای مثال یا سرنخ:
🔐 انتشار NVIDIA SkillSpector: یه security scanner برای AI agent skills. بر اساس کار تحقیقی روی ۴۲ هزار skill واقعی که نشون داده ۲۶٪ شون آسیبپذیری دارن و ۵٪ هم احتمالاً مخرب هستن! SkillSpector تا الا ۶۴ تا الگوی مشخص رو اسکن میکنه: از prompt injection و data exfiltration گرفته تا privilege escalation، memory poisoning، و MCP tool poisoning.
⚖️ انتشار Microsoft Agent Governance Toolkit: که یه لایه governance برای دپلوی کردن ایجنتها در محیط عملیاتیه. سه سوال اصلی رو هدف میگیره: این action مجاز هست؟ کدوم ایجنت این کار رو کرد؟ میتونی ثابت کنی چه اتفاقی افتاد؟ از policy enforcement با YAML/OPA/Cedar گرفته تا identity با SPIFFE و audit log با Merkle chain. حتی cost و token budget هم داخلش هست.
اما این همه ماجرا نیست. وقتی agent ها از اسباببازی به ابزار کاری تبدیل میشن، یه لایه کامل از مشکلات ظاهر میشه که قبلاً وجود نداشت:
- چه کسی هزینه inference رو میپردازه و چطور باید ردیابیش کرد؟
- اگر agent ای یه تصمیم اشتباه گرفت و خسارت زد، مسئولیت با کیه؟
- چطور ثابت میکنی که ایجنت در لحظهی تصمیم، دقیقاً با همون policy که تأیید شده بود کار میکرد؟
- وقتی دهها ایجنت به هم وکالت میدن (delegation chain)، اعتماد بینشون چجوری منتقل میشه؟
اینها سوالهای فنی نیستن. یا دقیقتر بگم: فقط فنی نیستند.
شرکتهای بزرگ دارن میفهمن که مشکل اصلی ایجنتها، هوش مصنوعی داخل شون نیست. مشکل اصلی، اعتماد، مسئولیت، و قابلیت audit است.
درست مثل همون چیزی که سالها پیش با مایرکوسرویسها صنعت یاد گرفت؛ ولی این بار با ریسک بالاتر!
سوال: ایا این موضوعات جایی بین دغدغههای سازمان و تیم شما داره؟
GitHub
GitHub - NVIDIA/SkillSpector: Security scanner for AI agent skills. Detect vulnerabilities, malicious patterns, and security risks.
Security scanner for AI agent skills. Detect vulnerabilities, malicious patterns, and security risks. - NVIDIA/SkillSpector
❤3
Final Results
9%
Copy-on-Write, MVCC
5%
LFU/LRU Cache
27%
Inbox/Outbox Pattern
11%
Bitemporal Modeling, Temporal Modeling
47%
Agent Client Protocol (ACP), A2A (Agent-to-Agent)
👀3🤓1
هر بار که تغییر بزرگی در اتمسفر توسعه نرمافزار پیش میاد؛ مثل وقتی که تکنولوژی انقلابی جدید معرفی میشه، ابزارها یا رویکردها تغییر بزرگی رو تجربه میکنن؛ مثل دورانی که SOA اومد، یا بعد که microservice اومد؛ یا این قریب به ۴ سال که GenAI از عمق تحقیاتی به سطح زندگی روزمره اومده؛ لازمه تا مفاهیم جدید رو دقیق یاد بگیریم تا درگیر حباب تکنولوژی، تبلیغات، یا استفاده اشتباه و نابجا نشیم. و به همون اندازه مهمه تا از دوران جدید جا نمونیم.
لذا اینکه چه زمانی و کجا؟ و با چه مقدمه و برای چه نیازی؟ چه راهکاری رو انتخاب کنیم؛ سوال مهمیه که حتی از اجرا کردن کًد باید برامون مهمتر باشه. مثلا بدونیم تفاوت و کاربرد اینا چیه:
Prompt-based
Tool/skill-based
MCP
Instantiated role
Single long-lived agent
Multi-agent + A2A/ACP
برای همین، چند خطی درباره A2A نوشتم که اگر دوست داشتید بخونید. رویکردم توضیح از پایه و مفاهیم بوده تا به نحوی باشه که از engineering manager تا architect تا developer رو پوشش بده. بنا به اقبال این موضوع، شاید بخش یا بخشهای بعدی هم با رویکرد عمیقتر و نگاه تخصصیتر (مثلا معماری یا توسعه یا امنیت) و عملیتر (کد) بنویسم.
🔗 لبنک مطلب و طبیعتا خوشحال میشم نظر و تجربهتون رو بنویسید
Please open Telegram to view this post
VIEW IN TELEGRAM
❤12👍3