مدیریت محصول از دهه ۱۹۳۰ تا امروز چندین بار بازنویسی شده، و حالا هوش مصنوعی دوباره همه چیز رو زیر و رو کرده. یه PM باتجربه توضیح میده که چطور با ابزارهایی مثل Claude Code، کارهایی که قبلاً ساعتها وقت میبردن رو در چند دقیقه انجام میده. اساس کارش اینه که مکالمه با AI خودِ کار شده، نه ابزار جانبیش. محور اصلی این رویکرد یه سند استراتژی ساختارمنده که با مصاحبهی تعاملی یه ایجنت پر میشه.
اوپنای مدل GPT-5.5 Instant رو بهعنوان مدل پیشفرض جدید ChatGPT معرفی کرد و جای GPT-5.3 Instant رو گرفت. این مدل جوابهای کوتاهتر، دقیقتر و شخصیسازیشدهتری ارائه میده و طبق اعلام اوپنای، ۵۲.۵ درصد کمتر ادعاهای اشتباه (هالوسینیشن) نسبت به نسخه قبلی داره. این مدل از حافظه مکالمات گذشته، فایلهای آپلودشده و حتی Gmail متصلشده برای شخصیسازی پاسخها استفاده میکنه. رولاوت برای همه کاربران ChatGPT شروع شده و از طریق API هم با نام chat-latest در دسترسه.
اوپنایآی یه آپدیت جالب برای اپ دسکتاپ Codex منتشر کرده که مهمترین بخشش یه ویژگی کاملاً بازیگوشانهست: حیوانات خانگی انیمیتدِ پیکسلآرت که روی صفحه بهعنوان overlay نشون داده میشن و حتی وقتی Codex مینیمایز باشه هم حضور دارن. علاوه بر این، Codex حالا میتونه تنظیمات ابزارهای دیگهای مثل Claude Code رو بهصورت خودکار شناسایی و ایمپورت کنه. یه دیکشنری صوتی هم اضافه شده که بهت اجازه میده اختصارات و عبارات خاص خودت رو ثبت کنی تا دیکته صوتی دقیقتر بشه.
نیک نیسی از WorkOS تعریف میکنه که چطور دو ابزار هوش مصنوعی ساخت، ولی بعد از مدتی متوجه شد هیچ راهی برای سنجش کیفیت خروجیشون نداره. راهحلش نوشتن یه سیستم ارزیابی (eval) بود؛ چیزی فراتر از تستهای معمولی. تستهای سنتی برای رفتار قطعی طراحی شدن، ولی LLMها هر بار خروجی متفاوتی میدن و باید با نرخ موفقیت سنجیده بشن، نه pass/fail ساده. این مقاله داستان ساختن دو سیستم eval کاملاً متفاوت برای دو مشکل متفاوته که یه درس مشترک داشتن.
سه سال پیش یه نویسندهی فناوری پیشبینی کرد که پرامپتنویسی یه چیز موقتیه و با بهتر شدن مدلهای هوش مصنوعی از بین میره. حالا خودش قبول میکنه که اون پیشبینی نه کاملاً درست بود، نه کاملاً غلط. بخشی از پرامپتنویسی قدیمی — مثل ترفندهای «قدمبهقدم فکر کن» — واقعاً منسوخ شده؛ ولی نسخهی جدید و جدیتری جاشو گرفته. امروز پرامپتنویسی یعنی مدیریت context، طراحی ابزار، و ساختن سیستمهای قابلاعتماد برای عاملهای هوش مصنوعی که تو محیطهای واقعی کار میکنن.
گیتهاب از ۲۰۰۸ تا حالا روابط بین ریپوها رو عمیقاً مدل نکرده. در حالی که امروز وابستگیها از طریق فایل manifest مدیریت میشن، نه fork، ابزارهای forge هنوز این رابطه رو جدی نمیگیرن. نویسنده لیستی از ویژگیهایی میده که یه forge واقعاً به نگهدارندگان پروژههای اوپنسورس کمک میکنه؛ از تست downstream گرفته تا فید اطلاعرسانی برای وابستگان. اینا دقیقاً چیزاییه که نه کلاینتها میتونن حلشون کنن، نه هیچکدوم از رقبای GitHub در حال ساختنشون هستن.
کدنویسی اجنتیک و رویکرد «توسعه مبتنی بر اسپک» (SDD) داره بهعنوان آیندهی برنامهنویسی معرفی میشه؛ جایی که انسان فقط نقش «هماهنگکننده» داره و AI کدها رو مینویسه. اما شواهد نشون میده که استفادهی مداوم از این ابزارها داره مهارتهای فنی و تفکر انتقادی توسعهدهندهها رو به شکل محسوسی فرسایش میده. طعنهی اصلی اینجاست: همون مهارتهایی که برای نظارت درست روی AI لازمه، دقیقاً همونهاییان که با استفاده از AI از بین میرن. این چرخهی معیوب حتی مدیران ارشد مهندسی در شرکتهایی مثل LinkedIn رو نگران ک
وقتی به AI میگی یه فیچر بساز، همهچیز خوب به نظر میرسه — تا یادت بیاد یه edge case مهم رو فراموش کردی، یا ببینی از offset pagination به جای cursor استفاده کرده. این چرخهی بیپایان «درست کن، اشتباه جدید، دوباره درست کن» همون چیزیه که نویسنده بهش میگه AI Psychosis. راهحل پیشنهادیش اینه که قبل از کدنویسی، اسپکهای دقیق به فرمت YAML بنویسی — رویکردی که بهش «Specsmaxxing» میگه. برای این کار هم یه ابزار اوپنسورس به اسم Acai.sh ساخته که کمک میکنه اسپک بنویسی، کد بسازی، بررسی کنی و ایتریت کنی.
Agent Skills یه پروژهست که سعی میکنه رفتار ایجنتهای کدنویس هوش مصنوعی رو به سطح یه مهندس ارشد برسونه. مشکل اینه که این ایجنتها بهصورت پیشفرض مستقیم میرن سراغ نوشتن کد، بدون اینکه اسپک بنویسن، تست بزنن یا اصلاً scope کار رو مشخص کنن. این پروژه با تعریف «اسکیل» بهشکل فایلهای مارکداون گردشی، ایجنت رو مجبور میکنه همون مراحلی رو طی کنه که یه مهندس باتجربه طی میکنه. پروژه با بیش از ۲۶ هزار ستاره، نشون میده که این دغدغه برای خیلیها آشناست.
استفاده از هوش مصنوعی در تیمهای توسعه نرمافزار فقط به پرامپتنویسی ختم نمیشه؛ اصل مهمتر اینه که AI هر چیزی که در تیم وجود داره — چه خوب، چه بد — رو تقویت میکنه. اگه فرایندهای بررسی کد و استانداردهای مستندسازی داشته باشی، سرعت و کیفیت هر دو بالا میره. ولی اگه بدون اینا وارد بشی، AI فقط بینظمیات رو سریعتر میکنه. این مقاله به تیملیدها کمک میکنه بدونن AI باید چه کدی بنویسه، چه چیزی رو خودشون بنویسن، و چطور واقعاً بسنجن که این سرعت ارزش داره یا نه.
سیلزفورس یه رویکرد جالب برای توسعه محصولات هوش مصنوعیاش داره: نقشه راه AI رو مستقیماً از مشتریانش میگیره. این شرکت با هزاران مشتری — بعضیهاشون هفتگی — جلسه داره تا مشکلات واقعی رو شناسایی کنه و سریع بهشون پاسخ بده. پلتفرم مدیریت ایجنتهای هوش مصنوعی Agentforce هم دقیقاً از همین فرآیند زاده شد. این استراتژی به سیلزفورس اجازه میده خیلی سریعتر از روال معمول شرکتهای بزرگ، کد بفرسته و ویژگیهای جدید رو تست کنه.
تست نرمافزار فقط نوشتن چند unit test ساده نیست — روشهای پیشرفتهتری وجود دارن که میتونن باگهایی رو پیدا کنن که بههیچوجه بهشون فکر نمیکردی. از تزریق تصادفی بودن به تستها گرفته تا تکنیک «swarm testing» و «buggification»، هر کدوم از این رویکردها بخشهای کور پوشش تست رو روشن میکنن. این مقاله یه منوی کامل از بهترین تکنیکهای تست نرمافزاره که میشه هم دستی و هم با کمک ابزارهایی مثل Hypothesis یا AFL++ ازشون استفاده کرد.
در دنیای AI امروز، ساختن یه محصول خوب دیگه کافی نیست؛ چون هر فیچری رو میشه ظرف چند روز کپی کرد. سامت اوزکاله، مدیر محصول و بنیانگذار Mues AI، میگه که مزیت رقابتی واقعی دیگه تو محصول نیست، بلکه تو توزیع (Distribution) هست. به جای وسواس روی دفاعپذیری محصول، باید انرژیت رو روی ساختن کانالهای توزیع، سرعت و ارتباط عمیق با کاربران بذاری. GTM (مسیر ورود به بازار) دیگه یه بحث فرعی نیست، خودِ محصول شده.
طبق آخرین گزارش دولت انگلیس درباره امنیت سایبری، ۴۳ درصد از کسبوکارها و ۲۸ درصد از سازمانهای خیریه در سال گذشته دچار حملات سایبری شدن. جالبه که پشت اکثر این نقضهای امنیتی هیچ تکنولوژی پیچیدهای نیست — فیشینگ بهتنهایی مسئول ۸۵ درصد از حوادث گزارششدهست. کارمندا روی لینکهای جعلی کلیک میکنن، اطلاعات ورود رو تحویل میدن، و همین کافیه. با وجود اینکه سازمانهای بزرگتر یهسری سیاستهای امنیتی دارن، هنوز خلأهای جدی توی ارزیابی ریسک زنجیره تأمین و حفاظت از دادههای شخصی دیده میشه.
همه دارن از هوش مصنوعی برای نوشتن پستمورتم استفاده میکنن، ولی این یعنی چی دقیقاً؟ یه نسخه از این ماجرا پستمورتمها رو هم سریعتر میکنه هم مفیدتر، یه نسخه دیگه فقط سریعتر میکنه و بیسروصدا بیفایدهشون میکنه. تفاوت اصلی اینه که AI باید کارهای مکانیکی و وقتگیر مثل ساختن تایملاین و پیشنویس اولیه رو انجام بده، نه اینکه جای تفکر تیم رو بگیره. سنتز واقعی — فهمیدن چرایی اتفاقها و تصمیمگیری برای اقدامات بعدی — هنوز باید توسط آدمها انجام بشه.
خیلی از پروژههای هوش مصنوعی نه بهخاطر ضعف مدل، بلکه بهخاطر ضعف سازمان شکست میخورن. در یه کارگاه با ۸ مدیر ارشد، ۴۷ دانش ضروری برای یه ایجنت هوش مصنوعی شناسایی شد؛ ۲۱ تاش هیچجا مستند نبود، ۷ تاش رو کسی نمیتونست درست توضیح بده، و ۴ تاش رو عمداً به شکل دیگهای ثبت میکردن. مشکل اصلی اینه که سازمانها منطق تصمیمگیری واقعی خودشون رو نه مستند کردن، نه همیشه میتونن توضیح بدن، و نه همیشه میخوان بنویسنش. ایجنت هوش مصنوعی روی یه نسخهای از شرکت کار میکنه که در واقعیت وجود نداره.
روزگاری سختترین کار یه مدیر محصول این بود که سازمان رو متقاعد کنه یه فیچر بیشتر به محصول اضافه بشه. حالا با ظهور هوش مصنوعی اجنتیک، یه فیچر میتونه صبح طراحی و بعدازظهر شیپ بشه و این یعنی بکلاگ عملاً از بین میره. مشکل اصلی دیگه «نداشتن وقت برای ساخت» نیست، بلکه «نداشتن وقت برای تصمیمگیری درباره اینکه چی نسازیم» هست. تاریخ نشون داده که همین مسیر، مایکروسافت ورد رو به یه نرمافزار شلوغ و پیچیده تبدیل کرد. حالا این خطر با سرعت چند برابر جلوی همهی تیمهای نرمافزاری قرار گرفته.
یه حس عجیب این روزا همهجا هست: نه چیزی خراب شده، نه سیستمها از کار افتادن، ولی یهجورایی همه چیز «اشتباه» به نظر میرسه. این مقاله این پدیده رو «Reality Drift» یا همون واقعیتزدگی مینامه؛ وقتی سیستمها بهظاهر بهتر میشن ولی ارتباطشون با هدف اصلیشون رو از دست میدن. نویسنده ۱۲ نشانهی ملموس از این پدیده رو در زندگی روزمره فهرست کرده؛ از خرید بستنی تا پشتیبانی مشتری و سیستم بهداشت. آگاهی از این نشانهها کمک میکنه بفهمیم چرا با وجود «بهبود» مداوم، تجربهی واقعیمون بدتر احساس میشه.
حرف زدن درباره «تحول هوش مصنوعی» کافی نیست؛ شرکتهایی که واقعاً جلو میافتن، هر هفته یه سری کارهای مشخص و تکرارپذیر انجام میدن. T.A. McCann که روی چند هیئتمدیره میشینه، میگه فاصله بین شرکتهایی که AI رو جدی میگیرن و اونایی که نمیگیرن، هر ماه داره بیشتر میشه. این مقاله پنج حرکت عملی رو معرفی میکنه که تیمهای پیشرو الان اجرا میکنن و نتیجه میگیرن. هیچکدوم به بودجه کلان یا استراتژی پیچیده نیاز ندارن، فقط به تعهد هفتگی.
وقتی دو محصولساز (PM) روی یه مشکل مشترک کار میکنن بدون اینکه هماهنگ باشن، نتیجهاش گیجشدن تیمهای دیگه، سؤالهای تکراری از مشتری و از دست رفتن اعتماده. این مقاله یه مدل عملی به اسم «Dual-PM» معرفی میکنه که بهشون کمک میکنه از درون تقسیم کار داشته باشن ولی از بیرون یه صدای هماهنگ داشته باشن. راهحل نه جلسههای بیشتره، نه سلسلهمراتب جدید؛ بلکه یه سری رفتار سادهست که باید با هم تصمیم بگیرن دنبالش برن.