گوگل اومده با همکاری موسسه Janelia، نقشه کامل مغز یک مگس میوه نر رو open source کرده که شامل ۱۶۶ هزار تا نورون و ۱۲۵ میلیون اتصال عصبیه.
البته این نقشه فقط میگه کدوم نورون به کدوم وصله، نه اینکه دقیقا توی مغز مگس چه اتفاقی می‌افته.

مردمم اومدن اینو گذاشتن Minecraft، Beat Saber و Doom بازی کنه یا حتی باهاش رمزارز ترید کنن. یه سری براش بهشت درست کردن :))

https://www.youtube.com/watch?v=KOwsVDogscY

@DevTwitter | <مهراد/>

اگه با الون‌لبز کار میکنید یا با کلون کردن صدا سروکار دارید این نسخه‌ی اوپن‌سورس رو تست کنید. پشیمون نمیشید. دعا میکنید.

https://github.com/debpalash/VoiceStudio

@DevTwitter | <Setareh/>

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

هاگینگ‌فیس به‌تازگی یک مجموعه ویدیویی ۶ قسمتی تحت عنوان Training Agents منتشر کرده که این مباحث را با پیاده‌سازی گام‌به‌گام و کدهای متن‌باز بررسی می‌کند.

مباحث اصلی این جلسات:
۱. ارزیابی ایجنت‌ها (Agentic Evaluations) و چرایی فاصله نمرات بنچمارک‌ها با عملکرد واقعی
۲. یادگیری تقویتی (RL) برای ایجنت‌ها، طراحی محیط و توابع پاداش و گلوگاه‌های استنتاج
۳. آموزش با نظارت (SFT) روی ردپای تعاملات ایجنت‌ها با TRL و LoRA
۴. تقطیر دانش (Distillation) برای انتقال توانایی به ایجنت‌های کدنویسی کوچک‌تر
۵. یادگیری تقویتی با GRPO، تحلیل منحنی‌های پاداش و رفتار مدل در دور زدن پاداش‌ها (Reward Hacking)
۶. اتصال ایجنت به محیط‌های تعاملی شبیه به Gym و آموزش عملی با AsyncGRPOTrainer در محیط‌های Sandbox

لینک پلی‌لیست کامل در یوتیوب:
https://youtube.com/playlist?list=PLo2EIpI_JMQvQZm-kVlz4wY1vWF0LBcf5

@DevTwitter | <Mehdi Allahyari/>

اینو ندیده بودم
https://github.com/ChromeDevTools/chrome-devtools-mcp
نسخه کروم دولوپر تول برای ایجنت‌هاست که بتونن وصل شن به سایت موقع کار و دیباگ کنن مستقیم،‌ پرفورمنس هم ترک میکنه. تست میکنم اینجا مینویسم چجوریاست

@DevTwitter | <Siavash/>

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

این پلتفورم تیک تاک و اینستاگرام رو ساپورت می کنه و باهاش می تونید کاملا اکانتتون رو مونیتور کنی

اسم این رپو هست کون بینی! خیلی کمک می کنه بهتون که ببینی چه خبره

https://github.com/api-evangelist/konbiniapi

@DevTwitter | <raa's/>

آموزش Spec-Driven Development با GitHub Spec Kit

توی این ویدیو باهم یک پروژه رو دو بار می‌سازیم؛ یک‌بار با یه پرامپت ساده و کلی جزئیات ناگفته، و یک‌بار با GitHub Spec Kit. بعد هم روند ساخت و خروجی هر دو رو کنار هم مقایسه می‌کنیم.

https://www.youtube.com/watch?v=Rs4qTGEjIbk

@DevTwitter | <پدی/>

اوبر مقاله فنی بسیار خواندنی و پرنکته‌ای درباره معماری «کارخانه نرم‌افزار» خود منتشر کرده است. در حال حاضر بیش از ۷۰ درصد PRها در اوبر توسط ایجنت‌ها ایجاد یا تغییر داده می‌شوند و با وجود رشد ۹ برابری درخواست‌ها، هزینه هر تسک تا ۵۲ درصد کاهش پیدا کرده است.

نکات فنی کلیدی که برای بهینه‌سازی سیستم‌های ایجنتی مقیاس‌بالا پیاده کرده‌اند:

۱. حل مشکل اسکیماهای سنگین MCP: بارگذاری مستقیم ده‌ها سرور MCP باعث می‌شد مدل قبل از اولین پرامپت، ۵۰ تا ۷۰ هزار توکن اسکیما را در هر دور حمل کند. اوبر ابزارها را به صورت CLI و Tool Search درآورده تا فقط ابزارهای مورد نیاز وارد کانتکست شوند.
۲. رویکرد Code-Mode به‌جای ابزار چتی: به جای رفت‌وبرگشت‌های متوالی با مدل برای هر کوئری و بررسی وضعیت، کارها در قالب یک اسکریپت پایتون در ساب‌پراسس اجرا می‌شوند و فقط نتیجه برمی‌گردد که مصرف توکن را ۵۰ تا ۹۹ درصد کم کرده است.
۳. ساخت گراف کانتکست: ایجنت‌ها به‌جای جستجوی خطی در کدبیس، اطلاعات را از یک گراف با ۲۴ میلیون نود (سرویس‌ها، معماری و لاگ‌ها) می‌گیرند و زمان حل تسک از ۲۰ دقیقه به ۳۸ ثانیه رسیده است.
۴. تفکیک مدل برای ساب‌ایجنت‌ها: وظایف کوچک به مدل‌های ارزان‌تر سپرده می‌شوند و مدل‌های پیشرفته فقط برای برنامه‌ریزی اصلی استفاده می‌شوند.
۵. کش یک‌ساعته کانتکست: افزایش TTL به یک ساعت مانع از بازسازی پرهزینه کانتکست در زمان بیکاری مهندسان پشت سیستم می‌شود.

این بلاگ خودش یه کلاس درسه!
لینک مقاله اوبر:
https://uber.com/us/en/blog/efficient-software-factory/?uclick_id=8c39ed77-46d9-4e1a-bd0a-20aaec118b9a

@DevTwitter | <Mehdi Allahyari/>

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

@DevTwitter | <سج‌آد/>

برای تمرین سرویس های کلاود مثل AWS یا گوگل کلاود و یا Azure به صورت لوکال و بدون نیاز به داشتن اکانت، قبلا از لوکال استک استفاده میکردیم. جدیدا آلترناتیوی کاملا رایگان و اوپن سورس اومده، به نام floci . راحت رو سیستم خودتون با داکر ران کنید و تمام.

https://floci.io/

@DevTwitter | <Mani/>

یه اصل ساده تو مدیریت زمان هست، از کتاب معروف Getting Things Done (دیوید آلن):
«اگه کاری کمتر از ۲ دقیقه طول می‌کشه، همون لحظه انجامش بده»
دلیلش هم مشخصه: نوشتنش تو لیست، بعداً دیدنش، به یادش آوردن، دوباره سراغش رفتن... کل این پروسه خودش بیشتر از خودِ کار طول می‌کشه. پس ارزون‌ترین راه همون لحظه تموم کردنشه.
حالا حکایت ما با ai-agentها عملا اینطوری میشه که اگه این اصل رو جدی بگیریمش تقریباً همه‌چی می‌فته زیر این آستانه!
https://gettingthingsdone.com/2020/05/the-two-minute-rule-2/


@DevTwitter | <Hossein Nazari/>

میدلولها خیلی بدردتون میخوره

چند روز بعد از اینکه درباره تجربه خوبم با Graphify نوشتم،
از workflow اصلی همون پروژه حذفش کردم!

نه چون Graphify بد بود.

اتفاقاً چون استفاده ازش باعث شد دقیق‌تر بفهمم از این مدل ابزارها چی می‌خوام.

مسئله‌ای که داشتم فقط Search داخل codebase نبود.
مسئله اصلی Orientation بود.
هر تسک جدید با چند سؤال تکراری شروع می‌شد:
این component کجا استفاده شده؟
این composable رو چی مصرف می‌کنه؟
این feature بین چه فایل‌هایی پخش شده؟
اگه این قسمت رو تغییر بدم، چه چیزهای دیگه‌ای تحت تأثیر قرار می‌گیرن؟

و Graphify برای اولین بار این حس رو بهم داد که قبل از باز کردن فایل‌ها، می‌شه یه نقشه از پروژه داشت.

بعد رفتم سراغ Codebase Memory MCP تا ببینم همین ایده وقتی مستقیم وارد workflow خود Coding Agent می‌شه چه فرقی می‌کنه.

مهاجرت هم اصلاً بی‌دردسر نبود :)))

بعد از نصب و Index کردن پروژه، MCP داخل Codex با خطای Transport closed شکست خورد. CLI کار می‌کرد، Index سالم بود، حتی MCP خام هم جواب می‌داد؛ ولی چیزی که واقعاً می‌خواستم یعنی workflow داخل Codex کار نمی‌کرد.

بعد از بررسی و سه Clean Start مستقل، MCP بالاخره در هر سه Session پایدار کار کرد و migration رو نهایی کردم.

اما بخش جالب‌تر برای من اولین تسک واقعی بعد از مهاجرت بود.

می‌خواستم نسخه موبایل پورتفولیوم رو اصلاح کنم: Header، Language Selector، Bottom Navigation و Responsive behavior.
قبل از اینکه شروع کنم فایل‌ها رو بگردم، از CBM خواستم محدوده کار رو پیدا کنه.
یکی از چیزهایی که سریع مشخص کرد این بود که BottomNav.vue از قبل توی پروژه وجود داره، ولی اصلاً داخل Layout mount نشده.
همین کشف ساده جلوی ساختن دوباره چیزی رو گرفت که از قبل داشتم.
ولی در همون تسک محدودیتش هم مشخص شد.

و CBM معماری اولیه رو خوب پیدا کرد، اما detect_changes نتونست impact واقعی یه تغییر UI رو کامل بفهمه.

Responsive CSS، Safe Area، RTL، Overflow توی عرض 320px و چیزی که کاربر واقعاً توی Browser می‌بینه، لزوماً توی Call Graph مشخص نیست.
و اینجا به نتیجه‌ای رسیدم که به نظرم از خود مهاجرت مهم‌تره:
من دیگه Graphify و Codebase Memory رو دو رقیب مستقیم نمی‌بینم.

برای پروژه‌های Code-heavy، جایی که بیشتر سؤال‌ها درباره implementation فعلی، dependencyها، refactor و impact تغییراته، CBM برای من انتخاب طبیعی‌تریه.

ولی وقتی پروژه فقط Code نیست و PRD، ADR، Research، Architecture Docs، PDF، Diagram و Domain Knowledge بخش مهمی از پروژه‌ان، Graphify هنوز ارزش خیلی جدی‌ای داره.

حتی برای یه محصول بزرگ احتمالاً از هر دو استفاده می‌کنم:
کدبیس Memory برای اینکه بفهمم:
«الان کد چطور کار می‌کنه؟»
و Graphify برای اینکه بفهمم:
«چرا اصلاً اینطوری طراحی شده؟»
با یه شرط مهم:
هیچ‌کدوم Source of Truth نهایی نیستن.

و Graph کمک می‌کنه سریع‌تر برسم به جواب.
ولی برای implementation هنوز سورس رو می‌خونم، برای requirement خود PRD رو چک می‌کنم و برای UI هنوز Browser حرف آخر رو می‌زنه.

تجربه کامل migration، failure، تست MCP و اولین task واقعی بعد از مهاجرت رو اینجا نوشتم:

http://aliarghyani.vercel.app/fa/blog/graphify-to-codebase-memory-mcp

@DevTwitter | <Ali Arghyani/>

وقتی با همکارت تو چت به نتیجه نمی‌رسی چی می‌گی؟ «بیا یه جلسه بذاریم.» یه ابزار کوچیک ساختم که با Claude Code هم جلسه می‌ری. MR رو بهش می‌دی، باگ رو بهش می‌دی، دیزاین‌داک رو بهش می‌دی، و صوتی راجع‌بهش حرف می‌زنین.

https://github.com/mhrlife/nutshell

@DevTwitter | <The Big Rad/>

وقتی یه قابلیت رو به یه AI Coding Agent میسپاریم، مسئله فقط تولید کد نیست؛ مسئله اینه که AI دقیقاً چه چیزی رو باید پیاده‌سازی کند؟

اینجاست که مفهوم Spec-Driven Development یا SDD مطرح می‌شود.

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

به زبان ساده، یعنی بجای اینکه AI را مستقیماً از یک ایده یا Prompt به سمت کد بفرستیم، ابتدا مشخص می‌کنیم دقیقاً چه چیزی باید ساخته شود، چه رفتاری باید داشته باشد و چه محدودیت‌هایی دارد.

برای مقایسه
Vibe Coding:
۱. نوشتن Prompt
۲. تولید کد
۳. اصلاح Prompt
۴. اصلاح کد
۵. تکرار این چرخه

Spec-Driven Development:
۱. تعریف دقیق نیازمندی
۲. تهیه و بررسی Spec
۳. طراحی و برنامه‌ریزی
۴. پیاده‌سازی توسط AI Agent
۵. بررسی و اعتبارسنجی خروجی

برای اینکه موضوع ملموس‌تر شود، فرض کنیم می‌خواهیم یک سیستم ورود بدون رمز عبور با Magic Link بسازیم.
به‌جای اینکه فقط به AI بگیم: «یک سیستم Magic Link برای ورود کاربران بساز.»

ابتدا Spec را تعریف می‌کنیم:

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

Acceptance Criteria:
ایمیل باید حداکثر طی ۳۰ ثانیه ارسال شود.
لینک منقضی‌شده باید خطای مشخصی نمایش دهد.
لینک استفاده‌شده دیگر نباید قابل استفاده باشد.
حداکثر ۵ درخواست برای هر ایمیل در یک ساعت مجاز باشد.
حالا AI Agent بر اساس این Spec، طراحی، Taskها، کد و حتی تست‌ها را تولید می‌کند.
در پایان هم به‌جای اینکه صرفاً بپرسیم «کد درست به نظر می‌رسد؟»، می‌توانیم بررسی کنیم:

آیا تمام مواردی که در Spec تعریف کرده بودیم واقعاً پیاده‌سازی شده‌اند؟

نکته مهم این است که Spec لزوماً یک سند ثابت و کاملاً انسانی نیست. در Workflowهای جدید، AI می‌تواند در استخراج ابهامات، تکمیل Spec، طراحی و حتی تبدیل آن به Taskهای قابل اجرا کمک کند؛ اما انسان همچنان مرجع تصمیم‌گیری و تأیید نهایی است.

به همین دلیل، با گسترش AI Coding Agentها، مفاهیمی مثل Spec-Driven Development و ابزارهایی مانند GitHub Spec Kit، OpenSpec و Kiro مورد توجه قرار گرفته‌اند.


@DevTwitter | <Amir Salehi/>

یه اپ مک تمیز پیدا کردم که با SwiftUI نوشته شده: Claude Usage Tracker.
.
مصرف Claude رو لحظه‌ای تو منوبار نشون می‌ده، مولتی‌پروفایل داره، آیکوناش کاستومایز می‌شن و statusline ترمینال هم داره.
.
۳.۴k استار.
اوپن‌سورس، credential ها تو Keychain.

https://github.com/hamed-elfayome/Claude-Usage-Tracker

@DevTwitter | <ʀ≡ᴢᴀ/>

یه بازی دیگه با three.js

https://whack-game.pages.dev/

@DevTwitter

⚠️ کاربران همیشه خطاهای اپلیکیشن را گزارش نمی‌کنند؛ گاهی فقط صفحه را می‌بندند و می‌روند.

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

🔘 با سنتری هم‌روش می‌توانید:

• جزئیات و شرایط وقوع خطاها را بررسی کنید.
• خطاها را بر اساس رخدادها و کاربران تحت‌تأثیر اولویت‌بندی کنید.
• با Traceها و Spanها، عملیات کند را پیدا کنید.
• با Session Replay، مسیر کاربر پیش از بروز مشکل را بازبینی کنید.

💎 در این ویدیو، نگاهی کوتاه به قابلیت‌های اصلی سرویس سنتری هم‌روش انداخته‌ایم.

🔗 شروع تست رایگان:

🔗 https://hmrv.sh/Shh46Z

☁️@hamravesh
#سنتری #توسعه_نرم‌افزار #مانیتورینگ #عیب‌یابی

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

خلاصه تغییرات کلیدی:
۱. تغییر متریک اصلی به ATF (مدت‌زمان رندر اولین بخش تصویر در گوشی کاربر) و تبدیل رندر HTML به یک پایپلاین کاملا Async.

۲. جداسازی Hydration به دو فاز مجزا؛ واکشی سریع سیگنال‌های رتبه‌بندی برای اجرای زودهنگام مدل‌ها، و لود موازی جزییات نمایشی (قیمت، تصویر و...).

۳. بهینه‌سازی امبدینگ‌ها با کاهش دقت اعشار و فشرده‌سازی تا ۴۶٪، در کنار تبدیل پوینترها به Value types در کد Go که مصرف ۴۰ درصدی پردازنده توسط Garbage Collector را به شدت کم کرد.

۴. استفاده از لوپ خودکار ایجنتی؛ ایجنت با تحلیل پروفایل‌های زنده پروداکشن، باتل‌نک‌های ریز را پیدا می‌کرد، کد بهینه‌سازی می‌نوشت، پول‌ریکوئست می‌زد و با بنچمارک نتیجه را می‌سنجید.

۵. برنامه‌های آینده بر پایه مایکروبچینگ، فیلترینگ در لایه ایندکس (Zero-Pass Ranking) و استریم فرگمنت‌های نتایج به سمت کلاینت.

لینک مقاله: بخوانیدش، خیلی جالبه!
uber.com/us/en/blog/uber-eats-search-pipeline/

@DevTwitter | <Mehdi Allahyari/>

چینی‌ها انگار تصمیم گرفتن صنعت ویدئوی AI رو هم به دردسر بندازن!

فقط یه عکس + یه فایل صوتی می‌دی…

و LongCat-Avatar برات یه ویدئوی چنددقیقه‌ای از همون آدم می‌سازه که لب و صدا کاملاً با هم Sync هستن

بدترش برای سرویس‌های پولی؟

- اوپن سورس
- رایگان
- قابل اجرا توسط خودت

چیزی که قبلاً دوربین، استودیو، بازیگر و کلی ادیت می‌خواست، حالا با چند فایل و یه ریپو قابل انجامه! AI Video داره خیلی سریع‌تر از چیزی که فکر می‌کردیم جلو میره

ریپو : https://github.com/meituan-longcat/LongCat-Video

مدل : https://huggingface.co/meituan-longcat/LongCat-Video-Avatar-1.5

@DevTwitter | <امیرحسین ثقه الاسلامی/>

سال‌هاست توی پروژه‌های فرانت‌اند، تقریباً همه‌مون با این ترکیب کار کرده‌ایم:
یک ابزار برای پیدا کردن مشکل‌های کد (ESLint)
یک ابزار برای فرمت کردن کد (Prettier)

ترکیب خوبیه؛ ولی هرچی پروژه بزرگ‌تر و وابستگی‌ها بیشتر میشن، هزینه‌ی اجرای این ابزارها هم بیشتر خودش رو نشون میده.

دقیقاً همین‌جاست که Biome وارد بازی میشه.
این ابزار با زبان Rust نوشته شده و از همون اول با هدف سرعت بالا و یکپارچه‌سازی ابزارهای Code Quality ساخته شده. یعنی به‌جای اینکه چند ابزار مختلف رو برای Lint، Format و مدیریت تنظیمات کنار هم بچینیم، میتونیم بخش قابل‌توجهی از این کارها رو با یک ابزار انجام بدیم.

اما چرا Biome این‌قدر مورد توجه قرار گرفته؟

-️ از نظر Performance: به‌دلیل معماری و پیاده‌سازی Rust، در پروژه‌های بزرگ میتونه زمان اجرای Lint و Format رو به شکل محسوسی کاهش بده؛ مخصوصاً وقتی این فرآیندها مرتباً در Editor یا CI اجرا میشن.

- از نظر Configuration: دیگه لازم نیست برای هماهنگ کردن چند ابزار و تعداد زیادی Plugin و Config، چندین لایه تنظیمات داشته باشیم.

- از نظر یکپارچگی: Linting و Formatting در یک اکوسیستم انجام میشن و همین موضوع میتونه تعداد ابزارها و وابستگی‌های پروژه رو کمتر کنه.

- از نکات فنی جالبش اینه که در نسخه‌های جدیدتر (سری ۲.x)، قابلیت Type-aware Linting رو بدون نیاز به اجرای کامل TypeScript Compiler ارائه میده؛ چیزی که قبلاً بین ابزارهای Lint جاوااسکریپتی کم‌سابقه بود.

-️ برای پروژه‌های React، TypeScript، Next.js و حتی Monorepoها هم، Biome میتونه یک گزینه‌ی جدی برای جایگزینی بخشی از Toolchain قدیمی باشه.

البته این به معنی این نیست که ESLint و Prettier دیگه به درد نمیخورن.
اکوسیستم ESLint هنوز بسیار بزرگه و Pluginهای زیادی داره؛ مثلاً بعضی قوانین خاص eslint-plugin-import هنوز معادل کاملی توی Biome ندارن و ممکنه در پروژه‌های خاص بهشون نیاز داشته باشید.
همین‌طور فرمت‌دهی Biome حدود ۹۷٪ با Prettier سازگاره، نه صددرصد؛ یعنی موقع مهاجرت ممکنه یه سری Diff جزئی رو ببینید، هرچند در عمل تأثیر چندانی روی کدبیس نداره.

شاید وقتش رسیده Toolchain فرانت‌اند رو کمی ساده‌تر کنیم.

@DevTwitter | <Pouya Bakhshi/>

توییتی که ۱۷۰ میلیون ویو خورده توی ایکس

یه استعفای جنجالی از Anthropic!

یکی از محقق‌های سابق OpenAI و Anthropic امروز استعفا داده و گفته:

«هیچ‌کدوم از این دو شرکت مسئولانه عمل نمی‌کنن.»

ادعاش اینه که هر دو شرکت با سرعت دارن به سمت ابرهوش خودبهبوددهنده (Self-Improving Superintelligence) می‌رن؛ چیزی که به گفته‌ی اون، عملاً دارن با زندگی همه‌ی ما قمار می‌کنن.

این آدم ۳ سال روی Pretraining در OpenAI و Anthropic کار کرده.

وقتی یه نفر از داخل این دو شرکت چنین هشداری می‌ده…

شاید بد نباشه جدی‌تر به این سؤال فکر کنیم:

آیا رقابت برای ساخت AGI داره از کنترل خارج می‌شه؟

@DevTwitter | <امیرحسین ثقه الاسلامی/>

یه ابزار جالب هوش مصنوعی دیدم برای جستجوی شغل که این کارا رو انجام میده برات:
- شغل‌ها رو جستجو می‌کنه
- رزومه‌ات رو برای شغل مد نظر شخصی‌سازی می‌کنه
- کاورلتر می‌نویسه
- برای مصاحبه آماده‌ت می‌کنه
https://github.com/MadsLorentzen/ai-job-search

۴۳هزار استار و ۱۵هزار فورک داره. یاد یه چیزی افتادم. بارها پیش اومده که رزومه‌ها رو بررسی کنم. رزومه‌هایی که رنگ و بوی هوش مصنوعی میداد راستش واسم جالب نبود. نه اینکه بدم بیاد، بلکه فکر می‌کردم با این رزومه نمیشه سطح طرف رو متوجه شد و ارزش‌گذاری کرد. و بنابراین از راه‌های دیگه تلاش می‌کردم واقعاً ببینم طرف چکارست.

به نظرم این روش‌ها و ابزارها فقط شاید توی کوتاه مدت جواب باشه. تصور کنید استفاده از این ابزارها بیشتر فراگیر بشه و همهٔ رزومه‌ها و کاورلترها به دست هوش مصنوعی نوشته بشه. همه رزومه‌ها خوشگل و شیک و پر از کلمه‌ها و جمله‌های سنگین و رنگین. دیگه کم‌کم بررسی رزومه و کاورلتر با انسان و ATS کار بی‌ارزشی میشه، و ملاک‌ها و معیارهایی جز یه نوشتهٔ دو صفحه‌ای (=رزومه) برای بررسی سطح کاندیداها مهم‌تر میشن.

@DevTwitter