سلام به همگی. خیلی وقته که از آخرین باری که با هم صحبت کردیم میگذره. در این مدت، نه اینکه وقتش نباشه، دل و دماغش نبود. روزهای سختی را گذروندیم؛ از اعتراضات دیماه و داغ آدمهایی که جاویدنام شدند، تا سایه سنگین جنگی که اومد و هنوز هم تمام نشده. اما خب ما هنوز زندهایم، نفس میکشیم و زندگی ادامه داره. اینه که گفتم شاید بهترین کار همین باشه؛ برگشتن به کارهایی که بلدیم و علاقه داریم.
یکی از مواردی که چند وقت اخیر ذهنم رو درگیر کرده، روندهای تغییر شغلها به واسطه هوشمصنوعی هست. صحبتهام کمی دارک هست؛ چون انگار خیلی از شغلها دارن تبدیل به «اپراتور هوش مصنوعی» میشن. و من این حس رو از صحبت با دوستان گرفتم.
خلاصه بخوام بگم در این قسمت میخوام راجع به چند تا سؤال صحبت کنیم:
- هوش مصنوعی چه تغییراتی رو برای شغلهامون رقم زده؟
- چه نشانههایی برای تبدیل برنامهنویسی به کالای عمومی وجود داره؟
- اگر فرض کنیم، هوش مصنوعی داره شغلها رو تغییر میده، چطوری میتونیم باهاش همراه بشیم؟ و بهترین خروجی رو دریافت کنیم؟
- در بلندمدت ارزش پیشنهادی یه برنامهنویس چی میتونه باشه؟
شنیدن اپیزود
همه اپیزودهای این پادکست تو کانال کست باکس منتشر میشه و البته میتونید از جاهای دیگه هم بشنوید.
اینجا هم میتونید فایل صوتی این قسمت رو گوش بدید:
روندهای کنونی
اگر خاطرتون باشه مدتها پیش اپیزود دادم و راجع به Prompt Engineering و مسیرهای شغلی مختلف هوش مصنوعی صحبت کردم. الان راستش خیلی از اون صحبتها رو نامرتبط میدونم. دنیا عوض شده.
راجع به مسیرهای شغلی اگر بخوام بگم به نظر میاد مرز بین شغلها از همیشه کمرنگتر شده. انگار داریم برمیگردیم به دورانی که همه «مهندس نرمافزار» بودند. اگر بخوام نشونههاش رو بگم یکی این که تو بعضی از شرکتها میبینم بچههای پروداکت (مدیر محصول و صاحب محصول) کمکم دارن کد هم میزنند. انقدر مدلهای هوش مصنوعی خوب کد میزنند که تا ایدهای به ذهنشون میرسه، پروتوتایپش رو درست میکنند. حتی ممکنه یه محیط براشون تنظیم شده باشه که برن روی Branch خاصی از Git کار کنند و خروجی واقعی رو ببینند. بعضاً اینطوری هست که به Claude میگن ۵ تا دیزاین مختلف هم براشون انجام بده و بعد بینشون انتخاب بشه و پیش برن.
در صورتی که قبلاً باید به دیزاینر میگفتید دیزاین کن و بعد Backend کد بزنه و Front از کد Back استفاده کنه و یه خروجی اولیه بتونه ببینه. الان انقدر هزینه توسعه نرمافزار پایین اومده که خودش تو یه ساعت اون فیچری که مدنظرش هست رو میزنه. با Claude هم چندبار ریویو میکنه. تهش برنامهنویس هر قسمت کد فرانت و بک رو ممکنه ریویو کنه و چند تا فیکس بزنه.
یا در نظر بگیرید بچههای تیم پشتیبانی (Support) که میبینم حتی با این که دانش کدنویسی ندارند، میان برای یک نیازی که داشتند راهحل توسعه میدن. مثلاً برای تنظیم شیفتها یا مرخصیها یک نیازی دارند و خودشون میرن یه نرمافزار Custom دو صفحهای توسعه میدن.
بازم اگر بخوایم مقایسه کنیم. قدیم باید به تیم توسعه میگفتن و حالا اولویتهای اون تیم بررسی بشه و کلی جلسه بگذارن و شاید براشون یه چیزی بنویسن. حالا خودشون میتونند انجام بدن و یه راهنماییای هم میگیرن و Deploy اش میکنند و خلاص.
شاید تو ذهنتون هنوز مقاومت باشه. بگید که خب اگر فلان استاندارد رو رعایت نکرده باشن، کد مقیاسپذیر نیست. اصلاً فلان روش اصولی نیست. ولی واقعیت اینه که مهم نیست. طرف تا قبلش داشته با کاغذ انجام میداده و نهایت ابزارش اکسل بوده. الان قدرت برنامهنویسی با زبان انگلیسی رو بهش دادیم و با همین مشکلش رو حل کرده.
قبلاً اگر میخواست همچین کاری رو خودش انجام بده دانش html و css و nodejs و چند تا تکنولوژی دیگه باید بلد میبود تا یه وبسایت ساده بالا بیاره. الان همون رو به راحتی LLM براش انجام میده.
یه دعوایی هم راه افتاده و یه کلمه جدید به نام Vibe Coding اختراع شده. به این معنی هست که کسی بدون نگاهکردن و فهمیدن کد، با زبان طبیعی و استفاده از LLMها یه کدی رو بنویسه. یه سری معایب داره که میگن مقیاسپذیر و قابل نگهداری (maintainable) نیست. ولی مگه چند درصد سیستمهای ما از اول قراره به اون سطح برسن؟ طرف میخواد یه اپ بنویسه نیاز خودش رو حل کنه. چرا نباید Vibe Code کنه؟
بحثم روند کلی هست. شاید بگید الان اینطوری نیست ولی نشانههایی هست که به مرور داریم به این سمت میریم.
یک زمانی فقط کسایی که دانشگاه رشته کامپیوتر رفته بودند میتونستند نرمافزار بنویسند. بعد دوران بوتکمپها شد که یه بوت کمپ برای ورود به حوزه خاصی کافی بود و الان به نظر میاد اونم دیگه لازم نیست.
خیلی خلاصه بخوام بگم همون چیزی که بالاتر اشاره کردم. برنامهنویسی داره تبدیل به یه کالای عمومی میشه.
خودم رو بخوام مثال بزنم تو تقریباً یک سال گذشته به اون معنای قدیم دیگه کد ننوشتم. تو طول سابقه برنامهنویسیم بیشتر سمت Backend و دیتابیس و ML و اینها تجربه داشتم. اما اخیراً یه فرصتی پیش اومد و یه جا کد React هم زدم. کیفیتش هم خوب شد. روی پروداکشن هم رفت و مشکلی هم پیش نیومد. همین که کلیت پروژه رو درک کردم تونستم کدش رو هم بزنم. لزومی نداشت که یاد بگیرم فلان کلاس css چطوریه و چی هست و کجا به درد میخوره.
وقتی من میتونم کد فرانت بزنم. نیروی فرانت هم میتونه اگر نیاز شد یه کوئری SQL تو backend بزنه. انگار ما در زمانی هستیم که هنوز شغلهای جدید مرزبندی خودشون رو پیدا نکردند. در نظر بگیرید که الان با Figma میشه کدفرانت هم زد. منم فرانت میتونم بزنم. منتهی من تو این زمینه استعداد و مهارت خاصی ندارم (خوشمم نمیاد راستش). هنوز که هنوزه تفاوت رنگها رو خیلی خوب تشخیص نمیدم. سلیقه هنریام زیاد جالب نیست.
این که چطوری بتونیم با هم کار کنیم که هم اون از استعدادش استفاده بشه و هم من، این سؤال کلیدی هست. هنوز بهش نرسیدیم. به زودی میرسیم. ولی به نظر میاد روند کلی اینه که دیوار ورود روز به روز کوتاهتر و سریعتر بشه.
روندها به نظرم خیلی مهمه. من یه نفر رو اخیراً دیدم که هنوز دنبال دوره Python با کلاس خصوصی حضوری بود. تا اونجا که من یادمه، از وقتی یوتیوب و دورههای آنلاین اومدند دیگه همچین نیازی به دورههای اینطوری نیست. الان که دیگه همون هم لازم نیست. شما یک پروژه شخصی برای خودتون تعریف میکنیم و با کمک ChatGPT شروع به توسعه میکنید. در حینش هم به مرور مفاهیم مهم رو ازش میپرسید و یاد میگیرید. حتی میتونید بهش بگید براتون مفاهیم مهم رو لیست کنه و به مرور بهتون یاد بده.
این مثلاً تغییرات تو آموزش هست که به نظر میاد داریم به سمتش میریم. از بحثمون دور نشیم.
حالا اگر قبول داشته باشید که AI شغلهای ما رو تا همین الانش هم متحول کرده، باید بریم ببینیم که چطوری ازش استفاده کنیم؟
مهارتهای لازم برای AI
اگر خاطرتون باشه مدتها پیش اپیزود دادم راجع به Prompt Engineering صحبت کردیم. الان دیگه مهندسی پرامپت کمتر کاربرد داره. خیلی مدلها باهوشتر شدند و بهتر میفهمند. چیزی که الان کاربرد داره Context Engineering هست (+). یعنی شرایط کار مناسب برای مدل رو فراهم کنیم و دادههای لازم رو بهش بدیم که بتونه بهتر کمک کنه. قدیم بحث این بود که چطوری کلمات پرامپت رو بهتر انتخاب کنیم که مدل خروجی بهتری داشته باشه؟ الان بحث اینه که چطوری چیزهایی که مدل نیاز داره رو بهش بدیم.
به نظرم اگر هنوز کسی داره تو وب با AI کار میکنه و همچنان تکه کد ازش میگیره، خیلی از پتانسیل AI استفاده نکرده.
چه چیزهایی نیازه؟ ابزار و دانش. ما تو شرکتها یک عالمه دانش ضمنی داریم. هر شرکتی روالهای خاص خودش رو داره. فرآیندهای سازمانی فرق دارند و معمولاً اینها داکیومنت نشدهاند. ما قبل از این که از AI انتظار داشته باشیم، باید بهش بگیم.
یا مثلاً این که تیم ما چیه. وظیفهاش چیه. مالکیت کدوم بخشهای محصول با ماست. کدوم بخشها به ما ارتباطی نداره. تا وقتی از این دید بهش نگاه نکنید، کلی از فرآیندها و دانشهای ضمنی داخل شرکتها از چشمتون محفوظ میمونند. اصلاً یکی از دلایلی که LLM خنگبازی درمیاره و خوب جواب نمیده، همینه. نمیدونه. مدل چیزی که خوب میبینه کد هست. چیزی که نمیبینه Context کد هست. چرایی پشت فیچر هاست. تصمیمهای داخل جلساته. این که فلان پروژه Backend و Frontاش جداست و دوتا پروژه مجزا شده. روی سیستم من بکاند و فرانت تو فلان فولدر هستن.
و تا حالا انگار تو سر ما بوده. این همون دانشی هست که به مرور باید استخراج کنیم و به کامپیوتر بدیم. حتی بهتره این دانش داخل گیت هم کامیت بشه. دقیقاً مثل وقتی که یه برنامهنویس جونیور وارد سازمان میشه و Seniorها دستش رو میگیرن و قدم به قدم یه سری چیزا بهش یاد میدن. بهش دسترسی گیت میدن. پروژهها رو معرفی میکنند. ساختار کلی پروژه رو میگن و هر چیزی که نیازه رو به مرور یادش میدن.
اگر بخوام دقیقتر بگم موارد زیر الان تقریباً دارن استاندارد میشن.
قبلش دو تا نکته بگم.
اول من فرض میکنم دارید از Claude استفاده میکنید و با اون مثال جلو میرم ولی از هر ابزاری استفاده میکنید برای مواردی که میگم اسمهای مشابه هست. برای کدنویسی خب با اختلاف بهتره. برای سرچ مثلاً ChatGPT خیلی عالیه و برای ویدئو و عکس، من Gemini رو بیشتر میپسندم.
دوم این که اینهایی که میگم بحث یکی دو روز نیست. شاید مدتها طول بکشه تا کمکم به مرور این اطلاعات اضافه بشن. ولی خودتون به مرور تأثیرش رو میبینید.
شروع کنیم:
اطلاعات پروژه (Claude.md)
اولین بحث اطلاعات کلی پروژه است. این که این پروژه به چه دردی میخوره. هدف کلیاش چیه. در حال حاضر کجاها ازش استفاده میشه. صاحبش کدوم تیمه. از چه تکنولوژیهایی استفاده میشه. پروژههای مرتبط بهش چیا هستن (مثلاً ممکنه CI-CD پروژه یا Infra پروژه تو یه جای دیگه باشه) و چه نوع وابستگیهایی به این پروژه وجود داره. کجا Deploy شده.
کلاد به طور خاص در اول هر مکالمه Claude.md رو میخونه و بر اون اساس جواب میده. خیلی خوبه اینها داخل سورس پروژه هم کامیت بشن و استاندارد باشه.
اینها فقط AI-Friendly بودن نیست. برای خودمون هم خوبه. چقدر شده که میخواستیم یک پروژه سازمانی رو شروع کنیم و فقط آقای فلانی میدونسته که چیکار کرده. فلانی هم مرخصیه و عملاً کاری از دست کسی ساخته نیست. تا وقتی که همه اطلاعات شرکت تو ذهن یک نفره، AI که چه عرض کنم، آدم هم نمیتونه جاش رو بگیره و این چیز خوبی نیست.
قوانین و استانداردها (rules)
هر تیم برای خودش استاندارها و اصولی داره.
- اسم متغیر چه طوری باید باشه؟
- معماری پروژه چیه؟
- روش تست کردن ماژولها چیه؟
- چه مواردی رو برای امنیت در نظر میگیریم؟
این قوانین ممکنه پیچیدهتر هم باشند. مثلاً قبلاً معماری ۳ لایه کد میزدیم و یه بخشی از کد اون معماری رو داره ولی الان به مرور داریم عوض میکنیم و دیگه از لایه سرویس مستقیماً به دیتابیس کوئری نمیزنیم و براش Repository درست میکنیم. تا اینها رو به مدل صریحاً نگم از کجا میخواد بدونه. و اینا رفت و برگشت من رو زیاد میکنه و سرعتم کم میشه.
ابزارها (MCP Tool)
این از اون مفاهیمی هست که خود Claude توسعهاش داد و الان کاملاً استاندارد شده. MCP برای این هست که به مدل بگیم اگر به فلان کارکرد نیاز داشتی، میتونی از فلان ابزار استفاده کنی. مثلاً اگر نیاز داشتی Issueهای گیتهاب پروژه رو سرچ کنی، از این ابزار میتونی استفاده کنی. اگر خواستی تیکت بسازی از فلان ابزار استفاده کنی.
این روش مدل هست برای ارتباط گرفتن با دنیای بیرون. مثلاً اگر به MCP خوندن جیمیل دسترسی داشته باشه میتونه ایمیلها رو بخونه و خلاصه کنه. و تازه با MCP هست که مدل توانایی پیدا میکنه و جالب میشه.
این که مثلاً اگر مشکلی پیش اومد مدل دسترسی داشته باشه لاگهای Staging رو بخونه و بره سعی کنه حلش کنه، خیلی زمان کدنویسی رو کاهش میده.
مجوزها و دسترسیها
احتمالاً شما هم این نگرانی براتون هست که مدل انقدر هم دسترسی نداشته باشه. اینجا یه فایل تنظیمات (به نام settings.json) وجود داره که این موارد رو تنظیم میکنیم. من به شخصه دوست ندارم دم به دقیقه سؤال بپرسه، پس دسترسی به هر نوع خوندن رو بهش میدم. اما تو موقع انجام کار و اجرای یک چیزی ازش تأیید میگیرم. یه سری از دستورات خطرناک رو هم براش بلاک کردم که کلاً نتونه انجام بده.
مهارتها یا ورکفلوها (skills)
مهارت رو میشه یه جورایی فرآیندهای تیمی در نظر گرفت.
مثلاً این که اگر خواستیم تغییری بدیم اول تسکش تو جیرا ثبت میشه (یا شده). بعد یه Branch جدید از روی staging گرفته میشه. بعد تغییرات روی Branch لحاظ میشه و نهایتاً Merge Request با کامنت آماده میشه. بعد هم نوبت ریویو هست که با توجه به این که کجا تغییر کرده، Reviewer ممکنه متفاوت باشه. این یه نمونه از فرآیند هست.
یا مثلاً این که فرآیند Deploy کد به چه صورتی هست. فرآیندهای تیمی خیلی زیادن و معمولاً ناخودآگاه از کنارشون رد میشیم. حتی این که اگر پروژه جدید داریم اول باید ایمیل ایجاد پروژه زیرساختش رو بزنیم، هم به نظرم بخشی از فرآینده و باید داکیومنت بشه که کارها سریعتر پیش بره.
نکات مهم برای استفاده
چند تا نکته به ذهنم میرسه: اول این که اگر تعداد مخرنهای گیت که روش کار میکنید زیاده، شاید بهتر باشه یه پروژه به نام knowledge hub مثلاً داشته باشید و همه تسکها رو از اون شروع کنید. و اونجا میشه همه چی رو گذاشت و هر وقت میخواد بره یه پروژه خواهر یا برادر رو بخونه، اول فایل Claude.md اش رو میخونه که کانتکست کامل داشته باشه.
این پروژه داخل تیم باشه و همه ازش استفاده کنند. داخلش بگیم که من یه فولدر گیت دارم که داخل این ۱۰ تا پروژه است. آدرسشون هم اینه. وقتی بهت یه تسکی رو میدم با توجه به دامنهاش ببین کدوم پروژه برای کدزنی درسته. یا مثلاً معماری من میکروسرویس یا monorepo هست و قص علی هذا.
نکته دوم این که بحث Planning بسیار مهمه. بعد از مدتی از کار کردن به این نتیجه میرسید که به جای این که هی رفت و برگشت داشته باشیم، اگر همون اول وارد فاز Planning بشیم (که اکثر ابزارها ساپورت میکنند) و به مرور شفاف بشه که چی میخوایم، تولید کد خیلی راحتتر میشه.
سوم بحث تستنویسی و Review کد هست. قدیم واقعاً تستنویسی لاکچری بود و کمتر تیمی انجام میداد. الان اجباری شده! هم تستنویسی و هم بحث این که یک روال درست حسابی برای Review دربیاریم و حتماً ۲ ۳ بار بدیم خود Agent و خودش خودش رو Review کنه.
خیلی خلاصه بخوام بگم، تمام چیزی که ضمنی تو سرمون بوده رو صریحاش میکنیم و خودمون رو از بخش عمدهای از کارهای گل میکشیم کنار. هم سرعت افزایش پیدا میکنه و هم وقت پیدا میشه برای انجام دادن کارهای بزرگتر.
ولی شاید براتون سؤال پیش بیاد که ارززشی که ما خلق میکنیم چیه؟
ارزش خلق شده
این سؤال واقعاً مهمه و ذهن من رو درگیر کرده. صادقانه بخوام بگم جواب ساده و سرراستی براش پیدا نکردم. چند تا نکته به ذهنم میرسه. شما هم اگر چیزی مدنظرتونه بگید:
اول این که ابزار جای مسئولیت رو نمیگیره. پزشک از دستگاه MRI استفاده میکنه اما اگر دستگاه خروجی بد داد، مسئول پزشکه. مثل پزشک که نتایج آزمایش رو میبینه و مشکوک میشه و دستور آزمایش مجدد میده.
نرمافزار هم همینه. اگر کد باگ داشت و سیستم پایین اومد، مدیر نمیگه Claude کد زد. میگه شما کد زدی و کد رو مرج کردی. خیلی وقتها پیش میاد LLM میخواد یه کاری رو انجام بده ما بهش میگیم نه. تشخیص میدیم که روش درستش این نیست. و این تشخیصها مهمه.
دوم این که راجع به این که چه چیزی ساخته بشه، مدل توانایی نداره. یه بخشی از این قضیه برمیگرده که این که چه کاری انجام بدیم از داخل جلسات درمیاد و یکی بالاخره باید به مدل بگه که انجامش بده. بعد بالاسرش وایسه اشتباه انجام نده. یه جورایی مثل معمار که بالا سر کارگر میایسته و نظارت میکنه. خیلی وقتها برای تسکهای مرتبط با معماری نرمافزار (System Design) هم مدل ضعیفه. ممکنه ۲ سال دیگه اینطور نباشه ولی الان به نظرم هست.
و سوم این که نیاز ما برای نرمافزار در حال حاضر خیلی خیلی بیشتر از این حرفهاست و ما در زمینه نرمافزار under-developed هستیم. وقتی هزینه تولید نرمافزار پایین میاد، تقاضا بالا میره و ما حتی نزدیک نیستیم که بازار نرمافزار اشباع بشه. چون خیلی نرمافزار میشه ساخت که نساختیم!
مثالش رو میگن وقتی دوربین دیجیتال اومد، همه تونستند عکس بگیرن. اما نیاز به عکاس حرفهای از بین نرفت. هنوز که هنوزه میبینیم فروشگاهها وقتی میخوان پیج راه بندازن، عکاس حرفهای میارن از کالاهاشون عکس بگیره.
وقتی هزینه ساخت پایین میاد سه تا اتفاق میافته:
- نرمافزارهای کوچیکتر اقتصادی میشن. قبلاً نمیارزید برای ۴ نفر نرمافزار نوشت. الان میارزه.
- شخصیسازی زیاد میشه.
- و ایدههای بیشتری تست میشن.
یه چیز دیگه هم که به ذهنم میرسه اینه که هویت من با کد زدن تعریف نمیشه. اگر حتی کد زدن حل بشه، احتمالاً لایههای دیگهای هستن که میشه روشون کار کرد. من خودم حتی به شغلهای مرتبط با پروداکت هم فکر میکنم. و به نظرم میشه بخشی از اون مهارتها رو یاد بگیرم و به مرور به اون سمت برم.
ولی در هر صورت خیلی نمیشه با این روندها مقابله کرد و به جای این که سرمون رو مثل کبک تو برف فرو کنیم، بهتره بپذیریمشون. یه جمله معروف هست که AI جای من رو نمیگیره ولی اونی که AI بلده چرا و به نظرم درسته. همراه این روندها پیش بریم ببینیم چی پیش میاد. شاید نیاز شد که شغلمون رو عوض کنیم. مهارتهامون رو ارتقاء بدیم.
من یه شوخیای هم دارم اینطور وقتها میگم که بالاخره ته تهش در بدترین حالت، من یه گاو و گوسفند میخرم میرم ده پدربزرگم و کشاورزی میکنم و مشکل حل میشه. یه نون و پنیری قراره بخوریم که حالا اونجا میخوریم :))
خیلی ممنون که به صحبتهام گوش دادید. امیدوارم که به دردتون خورده باشه.