💭 امروز سر یه گفت‌وگو با یکی از دوستام، بحث رسید به این که واقعاً چی باعث میشه یه برنامه‌نویس بهره‌وری بیشتری داشته باشه.

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


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


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

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

شما چی؟ اگر بخواید فقط یک عادت رو معرفی کنید که بیشترین تأثیر رو روی کارتون داشته، اون چیه؟

#Programming
#SoftwareEngineering
#Developer

واقعاً بعضی از شرکت‌ها رو نمی‌فهمم 🤔

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

#برنامه_نویسی
#استخدام
#Programming

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


مثلاً اینکه چقدر از ابزارهای هوش مصنوعی استفاده کردی یا چقدر «توکن» مصرف کردی.


خب، تا اینجا شاید منطقی باشه.
ولی یه سؤال:
توکن بیشتر یعنی برنامه‌نویس بهتر؟ 🤔

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


آیا واقعاً کار بیشتری انجام دادی؟
نه لزوماً.


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

۵۰۰۰ خط کد نوشتی؟
پس حتماً بیشتر کار کردی!


در حالی که شاید یکی همون مسئله رو با ۵۰۰ خط بهتر حل کرده باشه.


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


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


پس به نظرم سؤال درست این نیست که:
«چقدر از هوش مصنوعی استفاده کردی؟»
سؤال بهتر اینه:

«با کمک هوش مصنوعی چه چیزی رو بهتر کردی؟»


چون در نهایت قرار نیست کسی برنده باشه که بیشتر توکن مصرف کرده.

برنده کسیه که بهتر مسئله رو حل کرده.


#هوش_مصنوعی
#برنامه_نویسی
#مهندسی_نرم_افزار


#ArtificialIntelligence
#Programming

یه تحول عجیب توی صنعت داره اتفاق می‌افته.

با هوش مصنوعی، از برنامه‌نویس تبدیل شدیم به معمار نرم‌افزار. مسئولیت‌مون رفت بالا. تصمیم‌هامون رفت بالا. عمق کارمون رفت بالا.

ولی حقوق؟ همونجاست. شاید هم کمتر.

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

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

وقتی AI کد می‌زنه، ارزش واقعی شما توی فکر کردنه. ولی اگه بازار هنوز داره کد رو وزن می‌کنه، شما دارید توی یه سیستم قدیمی ارزش‌گذاری میشید.

فکر می‌کنی این شکاف قابل پر شدنه، یا داریم به سمت یه استاندارد جدید از ارزش‌گذاری می‌ریم؟

#هوش_مصنوعی
#معماری_نرم‌افزار
#برنامه‌نویسی
#توسعه_نرم‌افزار

#AI
#SoftwareArchitecture
#Programming
#Salary
#JobMarket
#SoftwareDevelopment
#Career

⌨️ اگر واقعاً می‌خوای ساخت AI Agent رو یاد بگیری، فقط با یک دمو جلو نرو.

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

یک Agent می‌سازن، چند تا Tool بهش وصل می‌کنن، اجرا می‌شه و تمام.

اما وقتی بخوای همون معماری رو برای یک مسئله‌ی واقعی تغییر بدی، تازه مشکلات اصلی خودشون رو نشون می‌دن:

ارزیابی عملکرد Agent چطور انجام بشه؟

اگر مدل تصمیم اشتباه گرفت، Human-in-the-loop کجا وارد بشه؟

حافظه رو چطور اضافه کنیم؟

و مهم‌تر از همه، چطور بفهمیم Agent واقعاً بهتر شده یا فقط یک دمو قشنگ‌تر ساخته‌ایم؟

برای همین، چیزی که در آموزش Agents from Scratch از LangChain برام جالب بود، تمرکز روی کل چرخه‌ی ساخت Agent بود؛ از پیاده‌سازی و تست گرفته تا ارزیابی، Human-in-the-loop، Memory و اتصال به APIهای واقعی.



لینک مخزن :Agent from scratch

#هوش_مصنوعی
#ایجنت_هوش_مصنوعی


#AI
#AIAgents
#MachineLearning
#Programming
#LangChain
#LLM
#AIEngineering

من نمی‌دونستم همچین چیزی لازم دارم واقعا میگم

یک AI Code Sandbox که در چند ثانیه یک Server آماده در اختیارت می‌ذاره؛ با OpenCode و Claude Code از قبل نصب‌شده.

بدون اینکه بخوای کلی تنظیمات انجام بدی، می‌تونی داخلش از مدل‌های رایگان و Scraperهای Apify استفاده کنی.

برای تست ایده‌ها و اجرای سریع پروژه‌های AI خیلی کاربردیه، مخصوصاً وقتی نمی‌خوای هر بار درگیر نصب و تنظیم Environment بشی.

ماهانه ۵ دلار اعتبار رایگان هم داره.

لینک : وبسایت

#هوش_مصنوعی
#برنامه_نویسی
#کدنویسی
#ابزار_توسعه
#توسعه_نرم_افزار

#AI
#Programming
#Coding
#OpenCode
#ClaudeCode
#Apify
#AISandbox
#SoftwareDevelopment

سازنده PostgreSQL یه جمله جالب درباره رقیب قدیمی این دیتابیس گفته. مایکل استون‌بریکر، خالق PostgreSQL، معتقده بخشی از محبوبیت امروز PostgreSQL رو باید مدیون Oracle بود.

ماجرا برمی‌گرده به سال ۲۰۱۰، زمانی که Oracle شرکت Sun Microsystems رو خرید و MySQL هم وارد مجموعه Oracle شد. همین اتفاق باعث شد خیلی از توسعه‌دهنده‌ها نسبت به آینده MySQL نگران بشن و بعضی‌ها حتی قبل از اینکه اتفاق خاصی برای پروژه بیفته، شروع به بررسی و مهاجرت به گزینه‌های دیگه کنن.

به گفته استون‌بریکر، همین ترس یکی از نقاط شروع رشد جدی PostgreSQL بود. جالب‌تر اینکه سال‌ها بعد، وضعیت MySQL واقعاً تغییر کرده. در سپتامبر ۲۰۲۵، Oracle تعدادی از نیروهای تیم اصلی MySQL رو تعدیل کرد و این موضوع دوباره بحث آینده MySQL رو داغ کرد.

در طرف مقابل، PostgreSQL طی این سال‌ها رشد خیلی زیادی داشته. این دیتابیس در سال ۲۰۲۳ به محبوب‌ترین دیتابیس بین توسعه‌دهنده‌ها تبدیل شد و شرکت‌هایی مثل Microsoft، Google و Amazon هم سرویس‌های خودشون رو بر پایه سازگاری با PostgreSQL توسعه دادن.

استون‌بریکر درباره وضعیت امروز MySQL حتی از عبارت خیلی تندی استفاده کرده و گفته این پروژه داره به رقیبی تبدیل می‌شه که عملاً در حال محو شدنه.

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

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

در واقع Oracle احتمالاً هیچ‌وقت قصد نداشت با خرید MySQL به PostgreSQL کمک کنه، ولی نگرانی‌ای که ایجاد کرد باعث شد بخشی از جامعه توسعه‌دهنده‌ها به سمت PostgreSQL برن. پانزده سال بعد، این تصمیم عملاً یکی از بزرگ‌ترین مزیت‌های PostgreSQL رو شکل داده.

#PostgreSQL
#MySQL
#Oracle
#Database
#OpenSource
#SQL
#SoftwareEngineering
#Developers
#Backend
#Technology
#Programming
#DatabaseManagement

خیلی‌ها از Programming می‌ترسن، ولی اگر بخوام صادق باشم، خود کدنویسی برای من بخش ساده‌ی ماجراست. بخش سخت‌تر، تمام زمانی‌ـه که صرف ساختن Logic توی ذهنت می‌کنی و فکر کردن به تمام حالت‌هایی که ممکنه یک راه‌حل در اون‌ها شکست بخوره.

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

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

شاید برای همینه که همیشه Chess رو هم دوست داشتم. به نظرم Coding و Chess خیلی بیشتر از چیزی که در ظاهر به نظر میاد به هم شبیهن. توی هر دو، باید چند حرکت جلوتر رو ببینی، حالت‌های مختلف رو تصور کنی، اشتباهات احتمالی رو پیش‌بینی کنی و بدون عجله بهترین تصمیم ممکن رو پیدا کنی.

واقعاً نمی‌دونم اگر Programming و Chess وارد زندگی من نمی‌شدن، امروز چه شکلی فکر می‌کردم یا کجا بودم. ولی مطمئنم هر دو، بیشتر از اینکه فقط یک مهارت یا سرگرمی باشن، روی نحوه فکر کردنم تأثیر گذاشتن.

#Programming
#Coding
#Chess
#ProblemSolving
#CriticalThinking
#Logic
#SoftwareEngineering

شاید یکی از دلایلی که امروز صدها Open Source C2 داریم ولی تعداد خیلی کمی از اون‌ها واقعاً در دنیای واقعی قابل استفاده‌ان، همین باشه.

بعد از یه نقطه مشخص، واقعاً Coding بخش کوچکی از نتیجه نهایی می‌شه. شاید حتی همون ۱۰ درصدی که همه بیشتر می‌بیننش. بخش اصلی ماجرا جاییه که باید خارج از چارچوب معمول فکر کنی، Research خودت رو انجام بدی، فرضیاتت رو به چالش بکشی و یک سناریو رو بارها و بارها تست کنی.

ساختن چیزی که روی کاغذ کار می‌کنه یک مسئله‌ست. ساختن چیزی که در دنیای واقعی قابل اتکا باشه، مسئله کاملاً متفاوتیه.

برای همین فکر می‌کنم تفاوت بین یک پروژه معمولی و یک ابزار واقعاً کاربردی، اغلب نه در تعداد Lines of Code، بلکه در میزان فکر، تحقیق و Testing پشت اون مشخص می‌شه.

در نهایت Coding شاید فقط ۱۰ درصد نتیجه باشه. ۹۰ درصد دیگه مربوط به طرز فکر، Research و تست بی‌پایانه.

#Programming
#Cybersecurity
#RedTeam
#C2
#OpenSource
#OffensiveSecurity
#Pentesting
#SoftwareEngineering
#Research
#ProblemSolving

یک موضوع دلی رو بگم بهتون دوستان.

امروز داشتم با یکی از دوستام صحبت می‌کردم و یاد یه عادت قدیمی افتادم. سال ۲۰۱۸، وقتی تازه شروع کرده بودم Windows Internals رو یاد بگیرم، من و چندتا از دوستام یه عادت نسبتاً ساده برای خودمون ساخته بودیم.

هر روز ۱۰ تا فایل EXE یا DLL از System32 انتخاب می‌کردیم و فقط درباره‌شون می‌خوندیم. نه خبری از Hack خاصی بود، نه Reversing و نه کار عجیب‌وغریبی. اسم فایل، کاربردش، اینکه چرا وجود داره، چه کاری انجام می‌ده و هر چیزی که می‌شد درباره‌ش پیدا کرد.

این کار رو تقریباً ۶۰ روز ادامه دادیم و حجم دانشی که فقط با Google کردن و خوندن به دست آوردیم واقعاً عجیب بود.

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

خیلی‌ها با دیدن مباحث Advanced از همون اول می‌ترسن، در حالی که چیزی که واقعاً تفاوت ایجاد می‌کنه، کیفیت Fundamentals هست.

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

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

و البته بله، من خودم چندتا Course هم می‌فروشم؛ ولی حتی با وجود این، هنوز فکر می‌کنم چیزی که بیشتر از هر منبعی نتیجه می‌ده، Time + Consistency + Discipline هست.

#WindowsInternals
#Cybersecurity
#Programming
#Fundamentals
#Learning
#ReverseEngineering
#Infosec
#Security
#SoftwareEngineering
#Discipline

صرفاً Prompt نوشتن و کپی کردن خروجی AI ازت Developer نمی‌سازه.

اگر کدی که AI برات نوشته رو نمی‌فهمی، نمی‌تونی Debug اش کنی، نمی‌دونی چرا این Architecture انتخاب شده و وقتی چیزی خراب می‌شه نمی‌فهمی مشکل از کجاست، در واقع بیشتر از اینکه Developer باشی، AI Babysitter هستی.

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

#VibeCoding
#Programming
#SoftwareEngineering
#AI
#Developers
#Coding

واقعاً چرا هنوز توی خیلی از مصاحبه‌های Programming ازت می‌خوان Code رو از صفر و با دست بنویسی؟

وقتی قراره در دنیای واقعی از AI برای کدنویسی استفاده کنیم، شاید بهتر باشه مصاحبه‌ها هم از این مدل ارزیابی فاصله بگیرن.

به‌جای اینکه ببینیم کسی چقدر سریع می‌تونه چند خط Code رو بدون کمک بنویسه، بهتر نیست درباره Fundamentals سؤال بپرسیم؟ اینکه چرا یک تکنولوژی رو انتخاب می‌کنی، چطور یک مسئله رو تحلیل می‌کنی، چطور Architecture مناسب رو انتخاب می‌کنی، چطور یک Bug رو پیدا می‌کنی و چطور تشخیص می‌دی کدی که AI تولید کرده واقعاً درست و قابل استفاده هست یا نه.

در نهایت، AI می‌تونه Code رو بنویسه. چیزی که هنوز باید خود Developer بلد باشه، فهمیدن مسئله و تصمیم گرفتن درباره راه‌حل درستشه.

شاید وقتشه Technical Interview هم خودش رو با دنیای AI وفق بده.

#AI
#Programming
#Coding
#SoftwareEngineering
#TechnicalInterview
#Developers
#VibeCoding
#ArtificialIntelligence

به نظرم خیلی‌ها دارن بدون اینکه واقعاً بفهمن کدی که تولید می‌کنن چطور کار می‌کنه، همین‌طوری YOLO می‌کنن.

با Vibe Coding بعضی وقت‌ها واقعاً می‌تونی از A برسی به Z.

ولی خیلی وقت‌ها چیزی که تحویل می‌گیری اینه:

A → F + N → Z

وسطش خالیه.

مدل بهت می‌گه:
«انجام شد، از A تا Z کامل شد.»

و تو هم بررسی نمی‌کنی.

یا حتی بدتر؛ از خود مدل می‌خوای که کد خودش رو بررسی کنه.

اینجاست که یه مشکل جدی به وجود میاد.

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

برای همین من فکر می‌کنم Vibe Coding قرار نیست جای فهمیدن رو بگیره.

هوش مصنوعی رو استفاده کن.

سریع‌تر کد بزن.

کارهای تکراری رو بده بهش.

ولی از Loop خارج نشو.

کدی که نمی‌فهمی چطور کار می‌کنه، واقعاً هنوز مال تو نیست.



#VibeCoding
#AI
#Programming
#SoftwareEngineering
#Developers
#LLM