تئودور، سامانتا و امضای کد نانوشته! این‌ روزها همه دارن از «بدهی شناختی» (Cognitive Debt) حرف می‌زنن. به نظرم فقط دارن درباره‌ی اثرات و نشانه‌هاش (Symptom) حرف می‌زنند نه در مورد ریشه‌ و دلیل اصلی‌ش. بدهی شناختی به شرایطی گفته می‌شه که یه تیم، کد رو سریع‌تر از چیزی که می‌فهمه، تحویل می‌ده (Ship) و توی محیط عملیاتی مستقر می‌کنه. کد کاملن کار می‌کنه. اما هیچ‌کس نمی‌تونه توضیح بده چه جوری! به نظرم موضوع اصلی، مالکیته (Ownership) نه بدهی! اگه شما به تنهایی کار می‌کردید، ۱۰۰٪ کد رو خودتون می‌نوشتید. صاحبش هم خودتون بودید! حالا یه همکار (دست‌یار هوشمند) به تیم‌تون اضافه شده که کل کد رو می‌نویسه. هیچ‌وقت هم خسته نمی‌شه. شما ۰٪ کدها رو می‌نویسید. روی «بله» (Yes) کلیک می‌کنید. گزینه‌ی «پیشنهادی» (Recommended) رو انتخاب می‌کنید. کدی رو تأیید می‌کنید (Approve) که ازش سر درنمی‌آرید. کد به اسم شما منتشر می‌شه. اما واقعن صاحبش شمایید؟ تصور کنید فردا اشتراک (Subscription) هوش مصنوعی‌تون تموم شده و دیگه کار نکنه. آیا می‌تونید کد «خودتون» رو تغییر بدید؟ تئودور تو فیلم Her رو یادتونه؟ برای آدم‌ها از طرف اون‌ها نامه‌ می‌نوشت تا به اسم خودشون بفرستن برای گیرنده. آخرش رو هم که یادتونه؟ سامانتا، دست‌یار هوش مصنوعی‌ش، گذاشت و رفت! حالا این شمایید که دارید پای نامه‌ها رو امضا می‌کنید. اما واقعن می‌دونید دارید زیر چی رو امضا می‌کنید؟ اگه نمی‌دونید، پس صاحب اصلی کد کیه؟ گزیده: تئودور به سامانتا:‌ «کنار تو حس می‌کنم می‌تونم هر کسی که دلم می‌خواد باشم.» https://t.me/bibalan_com https://bit.ly/47Ske7e

دشوارترین کلمه در طراحی عامل‌‌ها (ایجنت‌ها): نه! این روزها که تبِ سیستم‌های چندعاملی (Multi-Agent Systems) همه‌جا رو گرفته، مقاومت در برابر وسوسه‌ی استفاده از آن‌ها در طراحی سیستم کار ساده‌ای نیست. وقتی جریان غالب به این سمت و سو می‌ره، «نه» گفتن به چنین طراحی پرطرفداری شجاعت می‌خواد. چنین وسوسه‌ای برای من آشناست. برای همین، هر بار که به استفاده از یک سیستم چندعاملی فکر می‌کنم، یک کم مکث می‌کنم و این پنج سؤال کلیدی رو که بر اساس آموخته‌هام بهش رسیدم از خودم می‌پرسم؛ به نظرم از بین پنج‌ سوال، سوال سومی از همه تعیین‌کننده‌تر. ۱. آیا می‌شه مراحل انجام کار را دقیق گفت؟ اگر مسیر کار مشخصه و مراحل به‌ندرت تغییر می‌کنه، یک طراحی مبتنی بر گردش‌کار (Workflow) که ساده و قابل‌پیش‌بینی باشه، هم کم‌هزینه‌تره و هم اشکال‌زدایی‌ش (Debugging) آسون‌تره. پیچیدگی بیشتر طراحی لزومن به معنای بهتر بودن طراحی نیست. ۲. آیا مسیر انجام کار، بر اساس ورودی‌‌ها به شکلی تغییر می‌کنه که قابل پیش‌بینی نیست؟ عیب‌یابی یک خطای غیرمعمول در محیط عملیاتی (Production) ممکنه به تعداد زیادی بررسی‌ نیاز داشته باشه که باید به صورت متوالی و با مسیرهای متفاوت انجام بشه؛ اما استخراج چند تا فیلد معلوم از فاکتورهای مالی معمولن چنین پیچیدگی‌ای نداره. این دو مساله لزومن به طراحی یکسانی نیاز ندارند. ۳. آیا معیار مشخصی برای ارزیابی نتایج وجود داره؟ پاسخ به تمام سؤال‌های دیگه، در نهایت به همین‌جا برمی‌گرده. اگر نشه کیفیت خروجی رو اندازه‌ گرفت، چطور می‌شه فهمید که یک عامل (ایجنت) واقعن بهتر از یک گردش‌کار (ورک‌فلو) ساده است یا داره عملکردش مرحله به مرحله بهتر می‌شه؟ بدون معیارهای ارزیابی (Evals)، انتخاب عامل‌ (ایجنت) به‌جای گردش‌کار (ورک‌فلو) بیشتر احساسی می‌شه تا یک تصمیم مهندسی مبتنی بر شواهد. ۴. آیا هزینه‌ی خطایی که پس از انجام چندین مرحله‌، ظاهر می‌شه توجیه‌پذیره؟ یکی از چالش‌های اجرای چندمرحله‌ای عامل‌ها (ایجنت‌ها) اینه که ممکنه در طول مسیر دچار خطا بشند ولی در پایان، پاسخ نادرست رو با همان اطمینانی که پاسخ‌های درست رو می‌گند، به شما ارائه بدند. اگر چنین اشتباهی هزینه‌ی سنگینی برای کسب‌وکار داشته باشه، باید در انتخاب طراحی عامل‌محور و اختیاراتی که به‌ اون‌ها داده می‌شه، سخت‌گیرانه‌تر عمل کرد. ۵. آیا ارزش افزوده‌ی نهایی، هزینه‌ی راهکار رو توجیه می‌کنه؟ به این سوال نمی‌شه بدون دونستن میزان موفقیت (success rate) راهکار پاسخ داد؛ و برای سنجش اینها هم دوباره بر می‌گردیم به سؤال سوم. گزیده: «بسیاری از موارد کاربردی (use case) که این روزها با نام عامل‌محور (agentic) تبلیغ می‌شوند، در واقعیت هیچ نیازی به پیاده‌سازی طراحی عامل‌محور ندارند.» — آنوشری ورما (Anushree Verma)، تحلیل‌گر ارشد مؤسسه‌ی گارتنر (Gartner)، ژوئن ۲۰۲۵ https://t.me/bibalan_com https://bit.ly/4sa4w0B