♦️یک شغل جانبی رو به رشد برای فارغ التحصیلان کالج آمریکایی: اصلاح پاسخ های اشتباه هوش مصنوعی
A Growing Side Hustle For American College Grads: Fixing AI’s Wrong Answers

Richard Nieva
2025-03-06

#FORBES
خلاصه متن:
با پیچیده‌تر شدن مدل‌های هوش مصنوعی، وظایف مربوط به آموزش این سیستم‌ها نیز به چالش‌های بیشتری تبدیل شده است. شرکت Scale AI، با سرمایه‌گذاری 14 میلیارد دلار، به دنبال نیروی کار مستقر در ایالات متحده است. در این راستا، کارگران فریلنسر در پلتفرم Outlier برای ارزیابی و اصلاح پاسخ‌های هوش مصنوعی کار می‌کنند. به عنوان مثال، اسکات اونیل، یک فروشنده لوازم لوله‌کشی، ساعات زیادی را صرف رتبه‌بندی پاسخ‌های مدل‌های هوش مصنوعی می‌کند و درآمدی بین 300 تا 1000 دلار در هفته کسب می‌کند. این شرکت با هدف استخدام کارگران تحصیل‌کرده، به 87 درصد از کارگران خود که دارای مدرک دانشگاهی هستند، متکی است. همچنین، Scale به دنبال تقویت موقعیت ایالات متحده در زمینه هوش مصنوعی است و به جای برون‌سپاری، بر استخدام کارگران آمریکایی تمرکز دارد. با این حال، این شرکت با انتقادات و شکایات متعددی در زمینه شرایط کاری و سلامت روان کارگران مواجه شده است. پیمانکاران ادعا کرده‌اند که با محتوای آزاردهنده مواجه می‌شوند و از عدم حمایت کافی در زمینه سلامت روان رنج می‌برند. در پاسخ به این انتقادات، Scale به بهبود سیستم پرداخت و شفاف‌سازی نرخ‌ها اشاره کرده است. در نهایت، با وجود چالش‌ها، این شرکت به رشد خود ادامه می‌دهد و به دنبال شکل‌دهی به آینده هوش مصنوعی است.

متن کامل فارسی:
‏https://jjs.pub/4738

#Scale_AI #Outlier #هوش_مصنوعی #حاشیه_نویسی_داده #اقتصاد_گیگ

‎دسته بندی
[#AI] [#Technology] [#Business]
‎[#هوش_مصنوعی] [#فناوری] [#کسب_و_کار]

DANESHAGAHI NEWS
Cup Of Jamshid
FULLY AUTOMATED BY AI AGENT
2024-2025
@daneshagahi_coj

این توییت هادی جان رو باید طلا گرفت..

۱۰ برابر شدن سرعت TypeScript با پورت کامپایلر به GO

در این ویدئو Andres Hejlsberg (خالق تایپ‌اسکریپت و سی‌شارپ) توضیح می‌دهد که چگونه با پورت کردن کدهای کامپایلر TypeScript به GO، سرعت کامپایل را 10x بهتر کرده‌اند!

او همچنین توضیح می‌دهد که چرا زیرساخت JavaScript برای این کار مناسب نیست. در حقیقت این زبان بیشتر برای کارهای UI طراحی شده بوده و زیرساخت‌های لازم برای کارهای performance-intensive مانند این کار را ندارد.

برای من خیلی جالب بود خالق سی‌شارپ، زبان GO را برای این کار انتخاب کرده، پس مستندات مربوط به این تصمیم را خواندم.
https://github.com/microsoft/typescript-go/discussions/411

اولین نکته جالب این بود که چقدر بدون تعصب و با ذهن باز زبان‌های مختلف رو بررسی کردن.
با توجه به اینکه هر دو زبان‌ C#, GO از لحاظ پرفورمنسی بسیار خوب هستند، یکی از مهم‌ترین دلایل انتخاب GO تشابه بسیار بالای سینتکس آن با TypeScript بوده است.

کامپایلر قبلی تایپ‌اسکریپت، با خود تایپ‌اسکریپت نوشته شده و تیم نمی‌خواستند که کل آن را بازنویسی کنند.
در حقیقت هدف rewrite کردن نبوده، بلکه port کردن بوده.
آنها دنبال پورت کردن آن به یک زبان با پرفورمنس بالا بودند که تشابه سینتکسی بالایی داشته باشد تا عملیات پورت بتواند راحت‌تر انجام شود.

از بین زبان‌های C#, GO و Rust، زبان گو تشابه سینتکسی بیشتری با تایپ‌اسکریپت داشته و در نهایت انتخاب شده.

به نظرم نحوه انتخاب زبان برای این کار توسط خالق سی‌شارپ و تایپ‌اسکریپ، درس‌های تکنیکال و بیزسنی زیادی برای یاد گرفتن داره. نظر شما چیه؟


https://www.youtube.com/watch?v=pNlq-EVld70

#مهران_داودی (لینکدین - بلاگ)

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنت‌ها به اشتراک بگذارید.

کانال تلگرام:
@SoftwarePhilosophy

______

#کوته_نیوز

مدیرعامل آنتروپیک(Claude):

هوش مصنوعی تا یکسال آینده درِ برنامه‌نویس‌ها میذاره و میفرستتشون باغبونی.

@DevTwitter

کنتور که نمیندازه، منم به نظرم تا یه سال دیگه ربات ها قیام میکنن، نسل بشریت کارش تموم میشه!

ورنه خاموش است و خاموشی...

تیمی را می‌توان بهره‌مند از امنیت روانی (Psychological Safety) دانست که اعضایش احساس کنند می‌توانند آزادانه نظرات‌شان را بیان کنند، سؤال بپرسند، اشتباهات خود را بپذیرند و ایده‌های جدید مطرح کنند، بدون ترس از سرزنش، تمسخر یا تنبیه.

این مفهوم ابتدا توسط پروفسور دانشکده کسب‌وکار هاروارد، اِمی ادموندسون (Amy C. Edmondson) در دهه نود میلادی مطرح شد، اما تحقیقات اخیر نشان داده‌اند که در عصر پرشتاب تحولات دیجیتال، اهمیت آن بیش از پیش افزایش یافته است.

در مطالعه‌ای که در سال ۲۰۲۳ انجام شد پژوهشگران (کلارک و گروس)، از طریق بررسی داده‌های جمع‌آوری‌شده از ۴۸ تیم نرم‌افزاری در شرکت‌های فعال در حوزه فناوری دریافتند که تیم‌هایی با سطح بالای ایمنی روانی، تا ۳۵ درصد بهره‌وری بیشتری در حل مسائل پیچیده و نوآورانه از خود نشان می‌دهند.

از دیدگاه دیگر، این بدان معناست که تیم‌هایی که فاقد این مولفه حیاتی باشند، بخشی از پتانسیل خود را بلااستفاده می‌گذارند و این مترادف با هدررفت سرمایه‌های انسانی و سازمانی است. این موضوع به‌ویژه در شرایطی که تیم‌ها با ابهامات فنی یا فشار زمانی مواجه‌اند، نمود بیشتری پیدا می‌کند. مطالعه مذکور همچنین نشان داد که ایمنی روانی با کاهش خاموشی تیمی (Team Silence) – یعنی حالتی که اعضا از بیان نگرانی‌ها یا ایده‌های خودداری می‌کنند – ارتباط مستقیم دارد.

چرا ایمنی روانی برای تیم‌های توسعه نرم‌افزار حیاتی است؟
فرآیند توسعه نرم‌افزار ماهیتاً پیچیده، تعاملی و وابسته به خلاقیت و حل مسئله مستمر است. در چنین محیط‌هایی:

۱. اشتباهات اجتناب‌ناپذیرند
از خطاهای کدنویسی تا تصمیمات معماری، اشتباهات بخشی طبیعی از فرآیند توسعه هستند. اگر اعضای تیم نگران باشند که به خاطر گزارش یک خطا یا بیان یک نگرانی سرزنش شوند، مشکلات پنهان باقی می‌مانند و در نهایت، کیفیت محصول کاهش می‌یابد. فرهنگ سرزنش، باعث اختفای مشکلات می‌شود، درحالی‌که محیطی امن، شفافیت را تقویت می‌کند.

۲. نوآوری حیاتی است
نوآوری از دل ایده‌های جدید و جسورانه زاده می‌شود؛ مانند استفاده از ابزارهای نوین، اتخاذ رویکردهای خلاقانه در تست نرم‌افزار یا یافتن راهکارهای بهینه‌ برای مقیاس‌پذیری. اما اگر اعضای تیم به دلیل ترس از طرد شدن، ایده‌های خود را مطرح نکنند، خلاقیت سرکوب می‌شود. نسبت ترس و ایده‌، مانند نسبت کویر و سرسبزی است؛ هرچه ترس بیشتر باشد، چشم‌انداز نوآوری خشک‌تر خواهد شد.

۳. فشار زمانی بالاست
در پروژه‌های نرم‌افزاری، مهلت‌های فشرده و فشار برای تحویل سریع محصول امری رایج است. در چنین شرایطی، اگر اعضای تیم به دلیل ترس از پیامدهای منفی، از بیان نگرانی‌های خود خودداری کنند، مشکلات پنهان می‌مانند، ریسک‌ها افزایش می‌یابند و دستیابی به ضرب‌الاجل‌های تعیین‌شده دشوارتر می‌شود.

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

ایمنی روانی به این معنا نیست که مهربان باشیم؛ بلکه به این معناست که بتوانیم با یکدیگر صادق باشیم.

با این حال، می‌توان با اتخاذ برخی اقدامات، مسیر را هموارتر کرد:

✅ وجود رهبری حمایت‌گر: مدیر یا تیم‌لید باید نشان دهد که اشتباهات، فرصتی برای یادگیری هستند نه دلیلی برای سرزنش. واکنش رهبران به اشتباهات، فرهنگ تیم را می‌سازد؛ اگر اعضا ببینند که اشتباهات مجازات می‌شوند، از پذیرش و بیان آن‌ها خودداری خواهند کرد.

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

✅ تشویق پرسش‌گری و چالشگری: رهبران و اعضای تیم باید به‌طور فعال پرسیدن سوال و ابراز شک را به عنوان یک ارزش تلقی کنند. ایجاد سازوکارهای عملی برای بیان پرسش‌ها – از جمله جلسات اختصاصی برای طرح سوالات، ابزارهای ناشناس برای ارسال بازخورد، و قدردانی از پرسشگران – می‌تواند به این هدف کمک کند.

در نهایت، ایمنی روانی نه یک مزیت لوکس، بلکه یک ضرورت برای عملکرد بهینه تیم‌ها در دنیای امروز است. تیم‌هایی که این فضا را ایجاد می‌کنند، نه‌تنها از پتانسیل کامل اعضای خود بهره‌مند می‌شوند، بلکه پایدارتر، نوآورتر و مقاوم‌تر در برابر چالش‌ها خواهند بود.

پی‌نوشت:

آری، آری، زندگی زیباست.
زندگی آتشگهی دیرنده پابرجاست.
گر بیفروزیش، رقص شعله‌‌اش در، هر کران پیداست.
ورنه، خاموش است و خاموشی گناه ماست.
—سیاوش کسرایی

- روح‌الله دلپاک
@DelpakLog

صوت جلسه 21
جلسه به شدت جذابی بود، البته همه جلسات جذابیت زیادی داره ولی این یکی بدلیل موضوع به شدت چالش برانگیزش، جذاب تر شد.

مواردی که خارج از کتاب بهشون اشاره شد در جلسه.
- دقت به بررسی معنایی خود عبارات Online transaction processing (OLTP) و online analytical processing (OLAP) و ایجاد مدل ذهنی صحیح از این کلمات و دقت به این موضوع که هر دو عبارت تقسیم های حوزه ابزار هستند و در علوم کامپیوتر جایگاهی ندارند همانند دیگر کلمات حوزه ابزار مثل Cloud
- اشاره به تفاوت دو کلمه Analytics و ANALYSIS که اینجا هم بهشون قبلا پرداختیم. هر چند در جلسه من به اشتباه تعریف دو کلمه را جابجا نسبت به قبلا گفتم که همینجا باید بگم دوستان دقت کنند، هر چند در انتها به توافق با بهنیا عزیز هم نرسیدیم که دقیقا این مرز را قائل بشیم یا نه، هر چند در وجود دو نیازمندی #داده_اکتشافی گذشته نگر و آینده نگر قطعا اتفاق نظر داریم.

ابزار مدیریت محصول Linear که یکی از استارت‌آپ‌های خیلی موفق چند سال گذشته است، به خاطر نگاه متفاوتی که به روند توسعهٔ محصولشون داشتن در کامیونیتی‌های پروداکت و UX خیلی ازش صحبت می‌شه. اونا تونستن که محصول خیلی باکیفیتی ارائه بدن و خیلی‌ها معتقدن از رقیب‌های بزرگشون مثل Jira و Clickup تجربهٔ کاربری بهتری ارائه می‌دن.

یک محصول خوب با پشتیبانی یک تیم مهندسی خوب ساخته می‌شه. Sabin Roman که Engineer Manager و Hiring Manager این شرکته، اخیراً مصاحبهٔ خیلی خوبی با Gergley Orosz داشته. هر دوی این افراد در گذشته در Uber با هم همکار بودن و به همین دلیل مقایسه‌های جالبی بین شرکت بزرگی مثل Uber و استارت‌آپ نسبتاً جدیدی و کوچکی مثل Linear شکل می‌گیره.

نکاتی در مورد فرهنگ شرکت Linear که برام جالب‌ بود:
- شرکتشون کاملاً ریموته و بر روی این اصل پافشاری می‌کنن. مصاحبه‌کننده بر این باوره که remote first بودن مزایای زیادی رو به شرکت‌ اضافه می‌کنه، حتی با وجود این که سربار بیشتری برای مدیرهای شرکت‌ داره.
- حل یک باگ همواره براشون اولویت بالاتری از توسعهٔ محصول داره و همهٔ اعضای تیم موظفن که در زودترین زمان ممکن باگ رو رفع کنن و برای این مسئله فرآیند مشخصی دارن.
- مهندس‌هاشون ارتباط مستقیم و بدون واسطه‌ای با مشتری‌ها دارن و حرف‌هاشون رو می‌شنون و مشکلات محصول رو می‌بینن.

ویدیو رو می‌تونید از این لینک ببینید.

@aminrbg

به نظرم Linear برای مدیریت روال های توسعه نرم افزار خیلی خارق العادس، به نظرم فیچر های خیلی خوبی داره مثل نگهداری Issue ها به صورت دوطرفه هم داخل گیتهاب و هم داخل Linear.
من توی مایگریشنم از Notion به Linear خیلی خوشحالم.

حالا میخوام یه ترکیب برنده رو بگم برای تیم های ریموت کوچیک.

Linear + Slack + WorkWeave + Github


Linear: Task management
Slack: Team comunication
WorkWeave: Team Performance Measurment
Github: Issue management, Code management.

جدای از 1 لایه و 2 لایه و 15 لایه، یا 6 ضلعی و 20 ضلعی و غیره، یا حتی کثیف و تمیز و تمیزتر،

معماری خوب، معماری هست که به مرور زمان نیاز به معمارش نداشته باشه.

این حرف نبی رو باید با الماس گرفت (طلا کمه)

در این قسمت از سری پادکست‌های Code lodge، به بررسی عمیق نقش هوش مصنوعی در دنیای توسعه نرم‌افزار می‌پردازیم. در این گفتگو، همراه با دوست صمیمی‌مان، مسعود عزیز، به نقد جنبه‌های مختلف استفاده از AI در محیط‌های دولوپمنت می‌پردازیم؛ از جمله مباحث پیرامون نگرانی‌های مرتبط با اتوماسیون بیش از حد و جایگزینی نیروی انسانی و دست کم گیری نقش مهم مدل های زبانی در توسعه. هدف ما ارائه بینشی جامع از چالش‌ها و فرصت‌هایی است که هوش مصنوعی برای توسعه‌دهندگان به ارمغان می‌آورد و راهکارهایی برای حفظ کیفیت و خلاقیت در کار ارائه می‌دهد.
میزبانان شما:
⁠بهنیا آزاد⁠
⁠مسعود بیگی⁠

این ایپزود را می توانید از طریق لینک های زیر هم بشنوید :

- 🔗Spotify

- 🔗Amazon

- 🔗Castbox

-🔗Apple podcast

-🔗 Shenoto


#Codelodge
#Software
#AI
#LLM
#softwareDeveloper
#SoftwareEngineer
@codeLodge

سال نو مبارک رفقا ❤️❤️❤️

Software is becoming systems of software. Our thinking generates the concepts that we rely on when designing our systems. When our concepts work together in harmony, supporting a system’s purpose, they have integrity.
Without conceptual integrity, our software systems are built by “many good but independent and uncoordinated ideas.”

From Learning System Thinking Book

از این حرف چی میشه برداشت کرد؟‌
نظر من:‌
اینکه ممکنه ما در مولفه های معماری نرم افزارمون هماهنگی بین اجزای نرم افزاری رو جا بندازیم. نکته ای که داره اینه که خیلی وقت ها انقدری درگیر ایزوله کردن ماژول ها میشیم که اصلا یادمون میره که این ماژول ها باید با هم ارتباط بگیرند، هماهنگ باشند و باهم کار کنن! اصلا یک سری رفتار ها از ارتباط و هماهنگی بین دوتا ماژول شکل میگیره. نکته دومی هم وجود داره با استفاده از هزار تا تکنولوژی و ابزار هم این موضوع لزوما درست نمیشه. مثلا اگر شما از ابزار های Event Sourcing داری استفاده میکنی به این معنی نیست که مسئله ارتباط بین ماژول ها رو حل کردی، فقط میشه گفت که زیرساخت این موضوع ممکنه اضافه شده باشه. همچنان باید یک پروتکل ارتباطی وجود داشته باشه که در بستر Event Sourcing بتونه به نیاز های ارتباطی پاسخ بده.