tech-afternoon

🖊 چرا سؤال نداریم؟

این موضوع رو در ۳ پُست مجزا، به ظاهر طولانی ولی در قسمت‌های کوتاه که منقطع خوندنشون آسون باشه تموم کردم. توی این سه بخش سعی کردم از سه زاویه متفاوت بهش نگاه کنم:

1️⃣ چرا سؤال اصلاً توی ذهن ما شکل نمی‌گیره؟
از شکاف اطلاعاتی و اطمینان کاذب، تا نقش آموزش و کودکی در ساختن یا خاموش‌کردن پرسشگری.
🔗 [لینک بخش اول]

2️⃣ وقتی سؤال داریم، چرا نمی‌پرسیم؟
از امنیت روانی و فاصله با قدرت، تا فرهنگ، و سکوتی که گاهی اصلاً نشانه رضایت نیست.
🔗 [لینک بخش دوم]

3️⃣وقتی سؤال می‌پرسیم، آیا واقعاً دنبال فهمیدنیم؟ و اثر هوش‌مصنوعی
آیا فقط دنبال شاهدی برای تأیید جوابی هستیم که از قبل انتخاب کردیم؟ این بخش بیشتر درباره Confirmation Bias، هوش مصنوعی و خطر تازه‌ای به اسم Sycophancy است.
🔗 [لینک بخش سوم]

به‌نظرم در هر شغل، موقعیت و سطحی، «پرسشگر» بودن، بلد بودنِ پرسش خوب و توانایی دیدن و حل مسئله، مهارت‌های بنیادی‌ای هستن.

دعوت می‌کنم بخونید و اگه براتون مفید بود، برای بقیه هم بفرستید.

پی‌نوشت: معرفی موضوع، ۲۰۸۸ بار دیده شد و ۳۲ بار بازنشر! ولی قسمت اول مطلب ۵۹ بار دیده شد. نمونه بانمکی از پیشی گرفتن آگهی از آگاهی بود!

🌟 انواع حملات پرامپت اینجکشن به زبان ساده و با مثال

همون‌طور که شیوه توسعه نرم‌افزار و نحوه تعامل کاربر با نرم‌افزار، بعد از فراگیر شدن مدل‌های زبانی، تغییر کرده، نحوه تهاجم و حملات نرم‌افزاری هم تغییر کرده. یکی از موضوعاتی که باید بهش توجه مضاعفی کنیم، حملات Prompt Injection است که انواعش رو به زبان ساده و با مثال توضیح می‌دم.

به زبون ساده، Prompt Injection یعنی مهاجم تلاش کنه با واردکردن دستوراتی در ورودی، رفتار مدل رو از هدف اصلی‌اش منحرف کنه، محدودیت‌ها رو دور بزنه یا مدل رو وادار کنه اطلاعات یا عملیاتی ناخواسته انجام بده. برعکس حملات سنتی نرم‌افزار، خیلی‌هاش بُعد فنی زیاد و کدنویسی عجیب نداره، و گاها با کمی زیرکی و هوش و زبون‌بازی می‌شه حمله رو درآورد!!

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

1. Direct Prompt Injection
2. Indirect Prompt Injection
3. Stored Prompt Injection
4. Reflected Prompt Injection
5. Cross-Context Prompt Injection
6. Tool-Use Injection
7. Tool Output Injection
8. RAG Prompt Injection
9. Multimodal Prompt Injection
10. Prompt Obfuscation
11. Role-Playing Injection
12. Instruction Hierarchy Attack
13. Context Poisoning
14. Memory Poisoning
15. Data Exfiltration Injection
16. Goal Hijacking
17. Denial-of-Service Prompt Injection
18. Agent-to-Agent Prompt Injection

🔗 لینک مطلب

بعد از این نظرسنجی شاید بد نباشه تا با هم فکر کنیم ببینیم چه روش‌هایی می‌شه استفاده کرد تا AI به صورت درست و «پایدار» در اختیار طیف بیشتری از جامعه قرار بگیره.

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

راهکارهای پیشنهادی:
- استفاده از LiteLLM یا bitfrost (به صورت کلی، یک AI Gateway که شما به هر مدلی و هر تامین‌کننده‌ای از طریق Inference Token وصل شی؛ شرکت هم مدیریت کافی روی بودجه و مصرف توکن و مدل‌های در دسترس و امنیت و... داشته باشه)

- استفاده از مدل‌های چینی مثل DeepSeek، Kimi یا Qwen که هزینه بسیار پایین‌تری نسبت به مدل‌های آمریکایی دارن و دقت و کیفیتشون هم نزدیک و رقابتی با مدل‌های روز آمریکایی است)

در مورد harness هم به خوبی مشکل حل شده، یعنی مثلا شما می‌تونید توی گیت‌هاب کوپایلوت یا Claude Code یا... با توکن خودتون از دیپ‌سیک یا مدل‌های آنتروپیک، OpenAI یا...استفاده کنید ولی نگران مسدود شدنش نباشید (احتمال مسدود شدن صفر نیست، ولی به بارها کمتر از تهیه حساب مستقیم از آنتروپیک یا OpenAI است)، یا با OpenUI می‌تونید رابط کاربری شبیه به محیط ChatGPT یا Claude رو تجربه کنید.

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

نیل دگراس تایسون، جایی می‌گه:

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

این عارضه، خیلی جاها هست، توی توسعه و معماری نرم‌افزار و AI هم هست و خیلی آزاردهنده است. اینجوری نباشیم 😅

معرفی Ontology Playground

اصلاً Ontology یعنی چی؟
به بیان ساده، Ontology یک مدل صریح از «مفاهیم یک دامنه و رابطه بین آن‌ها» است.
مثلاً توی دامنه منابع‌انسانی، ممکنه داشته باشیم:

Employee
Department
Position
Manager
LeaveRequest

و روابطی مثل:

Employee worksIn Department
Employee hasPosition Position
Employee reportsTo Manager
Employee submits LeaveRequest

تفاوتش با ER Diagram یا دیتابیس‌مدل اینه که هدف Ontology فقط تعریف جدول‌ها و Foreign Keyها نیست. Ontology تلاش می‌کنه معنای مفاهیم، ویژگی‌ها و روابط رو به شکل استاندارد و قابل‌فهم برای انسان و ماشین توصیف کنه.
مثلا:

Manager is a type of Employee
Employee may report to another Employee
LeaveRequest belongs to exactly one Employee

این مدل می‌تونه مبنای Knowledge Graph، semantic search ، reasoning و پاسخ‌گویی هوشمند روی داده‌ها باشه.

حالا Ontology Playground چی کار می‌کنه؟
این یه پروژه کدباز وبی است که بدون backend خاصی قابل اجراست. می‌تونید Ontologyها رو به‌صورت گراف ببینی و بسازی، و روی Nodeها کلیک کنی، Propertyها رو بررسی کنی و Entityها و Relationshipها را جست‌وجو کنی.

ابزار از Import و Export فایل‌های RDF/XML و OWL پشتیبانی می‌کنه. یعنی Ontology رو می‌تونی ویژوال ترسیم کنی و بعد خرجی متنی بگیری بدی AI تا برای تولید یا ویرایش کد درک بهتری از بیزنس شما داشته باشه.

توی تنظیماتش قابلیتی به اسم AI Builder وجود داره، ولی به‌صورت پیش‌فرض غیرفعاله و برای فعال‌شدن به Azure OpenAI وابسته است.

لینک دمو برنامه
لینک ریپازیتوری گیت‌هاب

بدون شرح
البته تشخیص صحیح top یا mid یا junior بودن خودش یکی از مراحل عرفانه 😅

داستان یک Date بد!

گاهی بزرگ‌ترین باگ‌ها، اون‌هایی نیستن که همون لحظه خطا بدن یا سیستم رو متوقف کنن. بلکه گاهی باگ، ۲۰ سال، ۳۰ سال، یا حتی بیشتر کنار ما زندگی می‌کنه. همه هم می‌دونن که بده. همه هم تجربه‌اش کردن. همه هم حداقل یک بار بهش فحش و فضیحت دادن. ولی چون میلیون‌ها خط کد بهش وابسته‌ است، کسی جرأت نمی‌کنه مستقیم دست ببره و درستش کنه.

شروع ماجرا: ده روز فرصت و یک تصمیم عجولانه
سال ۱۹۹۵، Brendan Eich در Netscape، شرکتی که بعدها پروژه Mozilla از دلش بیرون اومد؛ فقط ده روز وقت داشت تا زبونی بسازه که بعداً اسمش شد JavaScript. دستور مدیریت هم روشن بود: «شبیه جاوا بسازش.» در چنین شرایطی، برای بخش تاریخ و زمان، ساده‌ترین راه رو رفت: Date رو مستقیم از java.util.Date کپی کرد (به بیان دقیق‌تر: در عمل Date جاوا به JavaScript منتقل شد؛ حتی Brendan بعدتر توضیح داده که این بخش، port مستقیمی از Date جاوا به C بوده. Ken Smith که یکی از توسعه‌دهنده‌های Netscape بود قبلاً از Borland اومده بود؛ java.util.Date نسخه JDK 1.0 جاوا رو port کرد. این port مستقیماً برای موتور JavaScript Netscape انجام شد، که عمدتاً به زبان C بو که بعدتر به ++C نوشته شد.)!

نکته‌ی جالب اینجاست که خودِ اون پیاده‌سازی جاوا هم از اول مشکل‌دار بود؛ اونقدر افتضاح بود که فقط دو سال بعد، توی جاوا ۱.۱، تقریباً اکثر متدهاش منسوخ شدن و با یه API جدید جایگزین شدن. یعنی جاوااسکریپت یک طراحی معیوب رو از زبانی به ارث برد که خودش هم اون رو منسوخ کرد بعداً. و چون طبق اصل بنیادین TC39 یعنی «don't break the web» هیچ تغییری در Date مجاز به شکستن کدهای موجود نبود، این طراحی معیوب دقیقاً همون‌طور که بود، در استاندارد ECMAScript 1 (سال ۱۹۹۷) رسمی و منجمد شد.
فهرست مشکلات هم که برای هر کسی که با جاوااسکریپت کار کرده آشناست:
ماه‌ها zero-indexed هستند (0 میشه ژانویه) ولی روزها و سال‌ها نه! یک ناهماهنگی بی‌دلیل که فقط باگ تولید می‌کرد.
آبجکت قابل تغییر (mutable) است؛ یعنی هر تابعی که یک Date بهش پاس بده می‌تونه بی‌سروصدا مقدارش رو عوض کنه.
هیچ پشتیبانی واقعی از timezone وجود نداشت و فقط UTC و timezone محلی سیستم.
رفتار parser اون‌قدر غیرقابل پیش‌بینی بود که در عمل غیرقابل‌اعتماد محسوب می‌شد.
هیچ پشتیبانی از تقویم‌های غیرمیلادی (هجری و…) نداشت.
برای دو دهه، راه‌حل اکوسیستم این بود که این مشکلات رو دور بزنن، و نه اینکه حل کنن. کتابخونه‌هایی مثل Moment.js (که خودش mutable بود و باندل سنگینی داشت)، بعدتر هم چندین کتابخونه دیگه که هرکدوم یک لایه‌ی محافظتی روی یه هسته‌ی خراب ساختن، از راه رسیدن. الگویی که هر مهندسی می‌شناسه: وقتی یک مشکل بنیادین رو نمی‌شه حل کرد، دورش دیوار می‌کشیم و اسمش رو می‌گذاریم best practice 😅

نقطهٔ شروع واقعی: یک گفتگوی توییتری
اینجا بخشی از داستانه که کمتر روایت می‌شه و برای منی که سال‌هاست دنبال «لحظه‌های شروع» می‌گردم، جالب‌ترین قسمت ماجراست. سال ۲۰۱۷، Maggie Pint که اون موقع یه مهندس نرم‌افزار توی مایکروسافت بود و هنوز لید هم نشده بود، طی یک گفتگوی توییتری با Brendan Eich (خالق جاوااسکریپت) و Matt Johnson (نگهدارندهٔ Moment.js) درباره‌ی همین ذات خراب Date صحبت می‌کردن. و همون گفتگو بود که Brendan تاریخچه‌ی تصمیم ده‌روزه‌اش رو براشون تعریف می‌کنه. از دل همین صحبت، Maggie با Brian Terlson (نمایندهٔ مایکروسافت توی TC39 و ویراستار وقت ECMA262) هم آشنا می‌شه و همون‌جا تصمیم می‌گیرن که وقتش رسیده این مشکل رو از بیخ حل کنن.
نکته‌ای که باید با دقت گفت: این داستانِ «یک نفر که تنهایی یه مشکل بیست‌ساله‌ی زبان رو حل کرد» نیست؛ و اینجوری گفتنش، بی‌احترامی به شخصیت کاری این افراد، و به واقعیتِ پروژه است. اونچه واقعاً اتفاق افتاده این بوده که یک گفتگوی غیررسمی توی توییتر، نقطهٔ شروع یک تلاش چندساله و رسمی در TC39 شده؛ با آدم‌های مهمی مثل Philipp Dunkel، Maggie Pint ،Matt Johnson-Pint، و Shane F. Carr، به‌علاوه‌ی توسعه‌دهنده‌هایی مثل Bloomberg و Igalia که پروپوزال Temporal رو رسماً همون سال ۲۰۱۷ باز کردن. جالب اینجاست که این تلاش عظیم و چندساله، سرمنشأیی به این کوچکی و این غیررسمی داشته.

حالا چرا این‌قدر طول کشید؟
پروپوزال Temporal مسیر استاندارد TC39 رو طی کرد:
سال ۲۰۱۷ — Stage 1: پذیرش پروپوزال به‌عنوان یک مسیر اکتشافی.
سال ۲۰۱۹ — Stage 2: انتشار طراحی اولیه.
سال ۲۰۲۱ — Stage 3: تکمیل spec و پیاده‌سازی‌های آزمایشی شروع شدن.
مارس ۲۰۲۶ — Stage 4: که Temporal رسماً بخشی از ECMAScript 2026 می‌شه.
عملا ۹ سال، فقط برای طی‌کردن این مراحل. چرا؟ چون این بار قرار نبود همون اشتباه تکرار بشه. طراحی Temporal باید همه‌چیز رو پوشش می‌داد: تقویم‌های قمری-شمسی چینی، تقویم اسلامی، عبری، امپراتوری ژاپن؛ دیتابیس جهانی timezone یعنی IANA TZDB با تمام گذارهای DST؛ محاسبات duration با ماه‌ها و سال‌های با طول متغیر؛ و یکپارچگی عمیق با Intl. توی این مسیر، هر ادعای «تمام شد» با یک edge case جدید (مثل رفتار مبهم wall-clock در لحظهٔ تغییر ساعت DST) نقض می‌شده و spec دوباره اصلاح می‌شده.
یک تلنگر جالب هم در سال ۲۰۲۲ اتفاق افتاده: آسیب‌پذیری path traversal در Moment.js (CVE-2022-31129) نشون داد که حتی کتابخونه‌های پایه‌ای هم بخشی از سطح حمله اپلیکیشن می‌شن. این اتفاق استدلال برای وجود یک راه‌حل native رو قوی‌تر کرد.

رسیدن به مقصد: Node.js 26
پنجم ماه می امسال، Node.js 26 منتشر شد و برای اولین‌بار Temporal بدون هیچ flag یا پیش‌نیازی، به‌صورت پیش‌فرض فعال بود. دیگه نیازی به فلگ و کتابخونه اضافی نیست.
نتیجه، چیزیه که هر کسی که این ۳۱ سال با این زبونِ پرحاشیه زندگی کرده، حسرتش رو داشته!

💡 چیزی که این داستان یادم می‌اندازه
من سال‌هاست درباره‌ی فاصله‌ی بین «مهارت فنی» و «ownership» زیاد نوشتم، صحبت کردم و تلاش کردم توی مسیر رشد دیگران قرار بدم. این داستان، دقیقاً همون فاصله رو نشون می‌ده، اما در سطح یک اکوسیستم کامل. تصمیم Brendan Eich در ۱۹۹۵ نه غیرمنطقی بود و نه بی‌کفایتی؛ او ده روز وقت داشت. مشکل واقعی جای دیگه‌ای بود: این بدهی فنی برای دو دهه به رسمیت شناخته می‌شد، دورش مستندسازی و کتابخونه ساخته می‌شد، ولی هیچ گروه مشخصی مسئولیت حل ریشه‌ای‌اش رو عهده نمی‌گرفتن! تا اینکه یک گفتگوی غیررسمی، افراد درست رو در یک اتاق (یا یک رشتو توییتری) کنار هم گذاشت.
نکته برای من این نیست که «یک نفر جسور مشکل بیست‌سی‌ساله‌ی یه زبون رو حل کرد». نکته اینه که حل بدهی فنی بزرگ، همیشه به یک لحظهٔ شروع کوچیک نیاز داره. یک نفر که تصمیم می‌گیره به‌جای دورزدن مشکل، درباره‌ی ریشه‌اش صحبت کنه. بعدش کار سخت، یعنی ۹ سال طراحی دقیق و صبورانه، شروع می‌شه. و اون بخش، هیچ‌وقت کار یک نفر نیست.

پی‌نوشت: این بخش کوچکی از یه ارائه مفصل چند جلسه‌ای برای گروهی از تازه لیدِ فنی شده‌های یه سازمان بزرگ بود؛ گاهی برای یادگیری؛ مثال و داستان بهتر از شمردن نکته‌ها و تیترهاییه که یا سریع از خاطر می‌رن یا تبدیل می‌شن به لقلقه زبون آدم‌ها برای شوآف. اگر دوست داشتید؛ PostgreSQL یا MongoDB یا داستان Mel و Monorail و... هر کدوم مثل حکایت‌های کلیله و دمنه یا بوستان سعدی هستن (البته در مثال محل مناقشه نیست) که در قالب یه قصه میشه ده‌ها صفحه درس و نکته رو یاد گرفت. علاقه‌مند بودید لابلای وبلاگ پدیدآورنده‌ها و ردیت و توییتر، داستان‌های جذابی پیدا می‌شه. یا سری مصاحبه‌های Ryan Peterman یا داستان‌های Dave Plummer

پی‌نوشت۲: احتمالا مطلب بعدی یا A2UI خواهد بود یا در مورد روش‌های ارزیابی عملکرد دوره‌ای تیم‌های فنی. اگر پیشنهاد یا نکته‌ای دارید حتمن کامنت کنید :)

نقش Forward Deployed Engineer یا FDE

توصیف ساده FDE کسیه که برای تولید محصول، به جای منتظرِ requirement موندن، خودش می‌ره وسط میدون، requirement رو کشف می‌کنه، ابهام‌ها رو کم می‌کنه، prototype یا راه‌حل production-ready می‌سازه، سیستم رو با محیط واقعی customer fit می‌کنه و فیدبک‌ها رو برمی‌گردونه به محصول.

کِی FDE کاربرد داره؟
ریشه پیدایش چنین نقشی بیشتر به شرکت‌هایی مثل Palantir برمی‌گرده.
وقتی محصول خیلی تکنیکال باشه، در عین حال، مشتری که می‌تونه کاربر درون‌سازمانی هم باشه؛ خیلی technical نیست. مثلا شرکت Palantir، محصولاتی مثل پلتفرم‌های AI/Agentic، یا ابزارهای پیچیده انترپرایز که توی صنایع سنتی مثل manufacturing، aviation، CPG و HR استفاده می‌شن داره. یعنی جایی که مشتری، مسئله بزرگ یا خیلی بزرگ داره، ولی توان فنی کافی برای تبدیل مسئله به راه‌حل نرم‌افزاری نداره.

دقت کنیم که FDE به هیچ وجه Sales Engineer یا Software Engineer معمولی یا Consultant / Professional Services نیست!
به‌طور خلاصه، FDE یک مهندس مشتری‌محوره که بین consulting، product management و software engineering می‌ایسته، ولی خروجی نهاییش باید نرم‌افزار و outcome واقعی برای مشتری باشه، نه فقط دمو، تحلیل یا توصیه.

فرق بین ownership of project و ownership of problem اینجا خیلی مهمه. آدمی که project ownership دارد ممکنه آدم سخت‌کوشی باشه، ساعات زیادی کار کنه و پروژه رو هم تموم کنه. ولی FDE باید problem ownership داشته باشه. یعنی موفقیتش با این سنجیده می‌شه که آیا مشکل مشتری واقعاً حل شده یا نه، نه اینکه PR merge شده یا ticket بسته شده.

چنین افرادی برای سازمان‌ها خیلی ارزشمندن. چه برای مصاحبه کردن چه در ارزیابی خودتون می‌تونید از ۳ بُعد بررسی کنید که به صورت کلیدواژه و خلاصه می‌گم:

بُعد Communication -> شنیدن فعال، شفاف حرف زدن، آماده بودن و executive presence

بُعد Product sense -> توضیح تصمیم‌ها، انتخاب scope درست و trade-off prioritization

بُعد Engineering -> درک عمیق از completeness، test cases، edge cases misuse cases، end-to-end delivery

نکته مهم هم اینه که FDE برای همه‌جا مناسب نیست. برای محیط‌های پویا و خلاق و پیشرفته؛ ارزش زیادی داره، چون فرد می‌تونه کنار تیم بیزینس یا عملیات بنشینه و سریع adjustment رو انجام بده. اما توی سیستم‌های سنتی، stable، heavily governed و با release process سخت‌گیرانه، این مدل اگه درست کنترل نشه می‌تونه ریسک تولید کنه.

این هم فراموش نکنیم که عنوان‌های جدید، همیشه با خودشون جوگیری رو هم میارن؛ خصوصا این روزها و با وجود AI!

مفهوم Loop Engineering:
لایه‌ی بعد از Prompt، Context و Harness Engineering

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

این چرخه دستی بود، و آدمیزاد حلقه‌ی کنترل (control loop) رو با دست می‌چرخوند. ولی Loop Engineering دقیقاً یعنی همین حلقه رو از دست آدم دربیاری و بدی دست یه سیستم کوچیک. یعنی به‌جای این‌که خودت هر بار prompt بزنی، ببینی جواب چی شد، بعد دوباره prompt بزنی، یه لایه‌ی نرم‌افزاری می‌سازی که این کار رو برات تکرار می‌کنه: goal رو تعریف می‌کنه، کار رو به ایجنت می‌ده، نتیجه رو verify می‌کنه، اگه قبول بود state رو ذخیره می‌کنه و می‌ره سراغ کار بعدی، اگه رد بود دلیل رد شدن رو ثبت می‌کنه و دوباره تلاش می‌کنه. این یعنی همون loop، و مهندسی‌اش میشه Loop Engineering.
نکته‌ی مهم اینه که این لایه، لایه‌های قبلی رو حذف نمی‌کنه، روشون سوار می‌شه. یعنی کماکان Prompt و Context وجود دارن، فقط دیگه آدم نیست که هر دور دستی بنویسدشون؛ خود loop این کار رو انجام می‌ده.

🕠 مرور تاریخچه:

اگه مسیر رو دنبال کنیم، چهار مرحله داشتیم:

توی Prompt Engineering یاد گرفتیم چطور با مدل حرف بزنیم. (۲۰۲۲-۲۰۲۳)

توی Context Engineering یاد گرفتیم چه چیزی رو به مدل نشون بدیم. (۲۰۲۴-۲۰۲۵)

توی Harness Engineering یاد گرفتیم چطور ایجنت رو امن* اجرا کنیم. (اوایل ۲۰۲۶)

توی Loop Engineering یاد می‌گیریم چجوری سیستمی بسازیم که خودش چرخه‌ی کار رو جلو ببره، اما فقط تا جایی که بتونه ثابت کنه واقعا به مقصد تعیین شده رسیده. (اواسط ۲۰۲۶)

اگر علاقه داشتید وارد جزئیاتش بشم، بنویسید 😊

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

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

اما حداقل فعلا، هیچ مدل هوش مصنوعی نمی‌تونه جای بعضی چیزها رو بگیره:

- ذهنیت و مهارت ownership
- داشتن accountability و responsibility واقعی
- رفتار حرفه‌ای و مهارت‌های نرم
- توانایی دیدن مسئله تا انتها، نه فقط انجام دادن یه تسک

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

رونوشت: اهل تفکر و تعمق؛ اگه این مهارت‌ها قابل‌اندازه‌گیری با AI نیستن، پس تو فرآیند استخدام/ارزیابی چطور باید سنجیده بشن؟

🫂 چالش‌های مصاحبه‌های فنی: بررسی لایوکدینگ، نقش AI

این توییت، مسبب نوشتن این مطلب شد!

داستان از جایی شروع شد که یک روز شلوغ کاری، مجبور شدم توی مرحله لایوکدینگ یک مصاحبه شرکت کنم، ولی بعد از ۹۰ دقیقه مصاحبه که نتیجه ناامیدکننده‌ای داشت، این توییت رو نوشتم. چند ساعت بعد، دیدم بازخورد و تعداد مشاهده‌هاش نسبت به میانگین توییت‌های من خیلی بیشتر شد! لذا به نظرم اومد که شاید موضوع بدی نباشه برای نوشتن...

به‌طور خلاصه بازخوردها حول دو محور اصلی بودن:
- چرا استفاده از AI در مصاحبه مذموم دونسته شده
- چرا لایوکدینگ داریم؟ و برخی این روش رو منسوخ می‌دونستن

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

یادمون نره؛ مصاحبه قرار نیست حقیقت مطلق رو کشف کنه. مصاحبه یعنی کاهش ریسک تصمیم استخدام.

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

- یک مصاحبه فنی خوب رو چجوری طراحی کنیم؟
- با AI چه کنیم؟
- مثال و تجربه شخصی

🔗 لینک مطلب

15

🖊 مطلب بعدی:

چالش‌های مصاحبه‌های فنی: بررسی لایوکدینگ، نقش AI

هفته پیش یه توییت زدم که تمایز تعداد بازخوردها و دیده‌شدنش نسبت به عدد معمول توییت‌های هر از گاهیِ من، باعث شد به فکر نوشتن مطلبی در همین رابطه بیوفتم.

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

فعلا این بخش‌ها رو در نظر دارم، اگر دغدغه، سوال یا پیشنهادی داشتید حتمن بنویسید شاید به بهتر شدن مطلب کمک کنه:

مصاحبه‌های فنی:
- اصل مسئله چیه؟چرا لایوکدینگ اومد؟ چرا هنوز هست؟ از کجا و چه زمانی خراب شد؟ آیا همه‌جا باید بمونه؟
- مصاحبه بد چه جوریه؟
- مصاحبه خوب چه سیگنال‌هایی داره؟
- موضوع AI در مصاحبه: ممنوع، آزاد یا کنترل‌شده؟
- شرکت‌ها بسته به اندازه و نیازشون چجوری باید مصاحبه طراحی کنن؟
- مسئله ابزار نیست، مسئله طراحی مصاحبه متناسب با نیاز و شرایطه.
- تجربه و روش خودم

💡مرور الگوی outbox/inbox

توی نظرسنجی آخر، گزینه Inbox/Outbox Pattern رأی دوم رو آورد، بالاخره امروز مطلب رو جمع‌جور کردم. با اینکه «مرور» است ولی از نظر حجم کمی بیشتر از مطالب رایج شد (چون اصل داستان سیستم‌های توزیع شده، خیلی مبحث گسترده‌ایه و مرور یک مفهوم رایج و دم‌دستی‌اش هم نیاز به توضیح بیشتری داشت.

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

- مرور الگوی outbox/inbox
- مسئله اصلی: Dual Write Problem
- الگوی Outbox
- الگوی Inbox
- بررسی جزئی‌تر مفهوم Idempotency
- طراحی بهتر پیام‌ها
- تفاوت Domain Event و Integration Event
- روش‌های پیاده‌سازی Outbox Publisher
- ابزارها و فریم‌ورک‌های رایج برای پیاده‌سازی inbox/outbox
- مفاهیم مکمل: Poison Message، Retry و Dead Letter
- لزوم Observability و Monitoring
- کاربرد Ordering پیام‌ها
- پاک‌سازی داده‌ها
- تفاوت Outbox با Event Sourcing
- نسبت Outbox و Inbox با Saga
- چه زمانی واقعا به Inbox و Outbox نیاز داریم؟

🔗 لینک مطلب