این‌ روزها همه دارن از «بدهی شناختی» (Cognitive Debt) حرف می‌زنن. به نظرم فقط دارن درباره‌ی اثرات و نشانه‌هاش (Symptom) حرف می‌زنند نه در مورد ریشه‌ و دلیل اصلی‌ش. بدهی شناختی به شرایطی گفته می‌شه که یه تیم، کد رو سریع‌تر از چیزی که می‌فهمه، تحویل می‌ده (Ship) و توی محیط عملیاتی مستقر می‌کنه. کد کاملن کار می‌کنه. اما هیچ‌کس نمی‌تونه توضیح بده چه جوری!
به نظرم موضوع اصلی، مالکیته (Ownership) نه بدهی!

اگه شما به تنهایی کار می‌کردید، ۱۰۰٪ کد رو خودتون می‌نوشتید. صاحبش هم خودتون بودید!

حالا یه همکار (دست‌یار هوشمند) به تیم‌تون اضافه شده که کل کد رو می‌نویسه. هیچ‌وقت هم خسته نمی‌شه.
شما ۰٪ کدها رو می‌نویسید. روی «بله» (Yes) کلیک می‌کنید. گزینه‌ی «پیشنهادی» (Recommended) رو انتخاب می‌کنید. کدی رو تأیید می‌کنید (Approve) که ازش سر درنمی‌آرید.

کد به اسم شما منتشر می‌شه. اما واقعن صاحبش شمایید؟

تصور کنید فردا اشتراک (Subscription) هوش مصنوعی‌تون تموم شده و دیگه کار نکنه. آیا می‌تونید کد «خودتون» رو تغییر بدید؟

تئودور تو فیلم Her رو یادتونه؟ برای آدم‌ها از طرف اون‌ها نامه‌ می‌نوشت تا به اسم خودشون بفرستن برای گیرنده. آخرش رو هم که یادتونه؟ سامانتا، دست‌یار هوش مصنوعی‌ش، گذاشت و رفت!

حالا این شمایید که دارید پای نامه‌ها رو امضا می‌کنید. اما واقعن می‌دونید دارید زیر چی رو امضا می‌کنید؟

اگه نمی‌دونید، پس صاحب اصلی کد کیه؟

گزیده:
تئودور به سامانتا:‌ «کنار تو حس می‌کنم می‌تونم هر کسی که دلم می‌خواد باشم.»

این روزها که تبِ سیستم‌های چندعاملی (Multi-Agent Systems) همه‌جا رو گرفته، مقاومت در برابر وسوسه‌ی استفاده از آن‌ها در طراحی سیستم کار ساده‌ای نیست. وقتی جریان غالب به این سمت و سو می‌ره، «نه» گفتن به چنین طراحی پرطرفداری شجاعت می‌خواد.

چنین وسوسه‌ای برای من آشناست. برای همین، هر بار که به استفاده از یک سیستم چندعاملی فکر می‌کنم، یک کم مکث می‌کنم و این پنج سؤال کلیدی رو که بر اساس آموخته‌هام بهش رسیدم از خودم می‌پرسم؛ به نظرم از بین پنج‌ سوال، سوال سومی از همه تعیین‌کننده‌تر.

۱. آیا می‌شه مراحل انجام کار را دقیق گفت؟

اگر مسیر کار مشخصه و مراحل به‌ندرت تغییر می‌کنه، یک طراحی مبتنی بر گردش‌کار (Workflow) که ساده و قابل‌پیش‌بینی باشه، هم کم‌هزینه‌تره و هم اشکال‌زدایی‌ش (Debugging) آسون‌تره. پیچیدگی بیشتر طراحی لزومن به معنای بهتر بودن طراحی نیست.

۲. آیا مسیر انجام کار، بر اساس ورودی‌‌ها به شکلی تغییر می‌کنه که قابل پیش‌بینی نیست؟

عیب‌یابی یک خطای غیرمعمول در محیط عملیاتی (Production) ممکنه به تعداد زیادی بررسی‌ نیاز داشته باشه که باید به صورت متوالی و با مسیرهای متفاوت انجام بشه؛ اما استخراج چند تا فیلد معلوم از فاکتورهای مالی معمولن چنین پیچیدگی‌ای نداره. این دو مساله لزومن به طراحی یکسانی نیاز ندارند.

۳. آیا معیار مشخصی برای ارزیابی نتایج وجود داره؟

پاسخ به تمام سؤال‌های دیگه، در نهایت به همین‌جا برمی‌گرده. اگر نشه کیفیت خروجی رو اندازه‌ گرفت، چطور می‌شه فهمید که یک عامل (ایجنت) واقعن بهتر از یک گردش‌کار (ورک‌فلو) ساده است یا داره عملکردش مرحله به مرحله بهتر می‌شه؟

بدون معیارهای ارزیابی (Evals)، انتخاب عامل‌ (ایجنت) به‌جای گردش‌کار (ورک‌فلو) بیشتر احساسی می‌شه تا یک تصمیم مهندسی مبتنی بر شواهد.

۴. آیا هزینه‌ی خطایی که پس از انجام چندین مرحله‌، ظاهر می‌شه توجیه‌پذیره؟

یکی از چالش‌های اجرای چندمرحله‌ای عامل‌ها (ایجنت‌ها) اینه که ممکنه در طول مسیر دچار خطا بشند ولی در پایان، پاسخ نادرست رو با همان اطمینانی که پاسخ‌های درست رو می‌گند، به شما ارائه بدند. اگر چنین اشتباهی هزینه‌ی سنگینی برای کسب‌وکار داشته باشه، باید در انتخاب طراحی عامل‌محور و اختیاراتی که به‌ اون‌ها داده می‌شه، سخت‌گیرانه‌تر عمل کرد.

۵. آیا ارزش افزوده‌ی نهایی، هزینه‌ی راهکار رو توجیه می‌کنه؟

به این سوال نمی‌شه بدون دونستن میزان موفقیت (success rate) راهکار پاسخ داد؛ و برای سنجش اینها هم دوباره بر می‌گردیم به سؤال سوم.

گزیده:
«بسیاری از موارد کاربردی (use case) که این روزها با نام عامل‌محور (agentic) تبلیغ می‌شوند، در واقعیت هیچ نیازی به پیاده‌سازی عامل‌محور ندارند.»

— آنوشری ورما (Anushree Verma)، تحلیل‌گر ارشد مؤسسه‌ی گارتنر (Gartner)، ژوئن ۲۰۲۵

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

انتخاب این زمان، یکی از ساده‌ترین راه‌هایی هست که می‌شه باهاش GraphRAG و Agentic GraphRAG توضیح داد.

یه RAG معمولی، کمترین کار رو در این مورد انجام می‌ده. مدارک رو ایندکس می‌کنه تا پیدا کردن بخش‌های مشابه راحت‌تر بشه، برای هر سوال یه جستجو انجام می‌ده و می‌ذاره خود مدل هر چیزی که پیدا شده رو به هم مرتبط کنه. این روش ارزونه، و تا زمانی که سوال‌های کاربران پیچیده نشه خوب جواب می‌ده.

رویکرد پیشاپیش هزینه کن. سیستم GraphRAG مدارک‌تون رو از قبل می‌خونه و یه نقشه (map) درست می‌کنه: این فرد مدیر اون پروژه‌ است، این قطعه مال اون تامین‌کننده‌ است. ارتباط‌ها قبل از اینکه کسی سوالی بپرسه آماده‌ شدن. اما هر بار که اسنادتون تغییر می‌کنه، دوباره براتون صورت‌حساب می‌آد چون هزینه‌ی به‌روز رسانی نقشه رو دوباره بپردازید.

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

سیستم Agentic GraphRAG هر دو کار رو با هم انجام می‌ده. دو تا صورت‌حساب برات صادر می‌کنه، که البته بعضی وقت‌ها واقعن می‌ارزه.

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

شما ترجیح می‌دید اول هزینه کنید یا بعدن؟ و آیا این تصمیم رو آگاهانه می‌گیرید یا نه؟

نقل قول:

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

به ابزارهایی مانند Claude Code, Cursor, GitHub Copilot می‌گویم دستیار. ولی راستش رو بخواهید چند وقتی هست که مطمئن نیستم کی دست‌یار کیه!

ابزارهای Agentic تصمیم‌ها را در قالبی به این شکل جلوی شما قرار می‌دهند:

• Option 1 (Recommended)
• Option 2
• Other

وقتی به موضوع تسلط دارم، می‌فهمم که کدام گزینه جواب درستی برای شرایط مساله‌ است، در نتیجه با آگاهی گزینه‌ها را انتخاب می‌کنم. وقتی نصفه‌نیمه موضوع رو می‌دونم، گزینه‌های پیشنهادی رو می‌خوانم و پس از فهمیدن‌شون،‌ گزینه‌ها رو انتخاب می‌کنم. اما وقتی دانشم برای تصمیم‌گیری کافی نیست چی می‌شه؟ تنها کاری که می‌کنم اینه که روی Recommended کلیک کنم و با خودم هم کنار می‌آم که من به دست‌یارم «اعتماد» دارم!

این ماجراها من رو یاد Delegation Poker از Jürgen Appelo در کتاب Management 3.0 می‌اندازه؛ مدلی که هفت سطح تفویض اختیار را بین یک مدیر و تیمش رو بیان می‌کنه:
Tell → Sell → Consult → Agree → Advise → Inquire → Delegate

• Tell – من (مدیر) تصمیم می‌گیرم و به شما (تیم) اعلام می‌کنم. تمام!
• Sell – من تصمیم می‌گیرم، اما منطق و استدلالم رو توضیح می‌دهم و سعی می‌کنم شما رو با خودم همراه کنم.
• Consult – اول نظر شما رو می‌پرسم، بعد تصمیم می‌گیرم.
• Agree – با هم بحث می‌کنیم و با اجماع به یک تصمیم مشترک می‌رسیم.
• Advise – شما تصمیم می‌گیرید، اما من اول توصیه‌هام رو به شما اعلام می‌کنم.
• Inquire – شما تصمیم می‌گیرید، بعدن دلایل تصمیم‌تون و خلاصه‌ی ماجرا رو به من توضیح می‌دهید.
• Delegate – تصمیم‌گیری کاملن در اختیار شماست. من نیازی به توضیحات و جزییات تصمیم‌گیری ندارم.

این مدل را روی یک Agent session پیاده کنید؛ سطح تفویض ممکنه هر لحظه جابه‌جا بشه. جالبش اینه که بعضی وقت‌ها که خسته‌ام، من صرفاً نقش کلیک‌کننده (Clicker) را بازی می‌کنم:

• خلاصه رو می‌خونم و گاهی هم نمی‌خونم.
• Approve را می‌زنم.
• منتظر بعدی می‌مونم.

بخش ناخوشایند ماجرا اینجاست: کلیک روی Approve برای طرحی یا تصمیمی که امکان ارزیابی‌اش رو نداری، همان Delegate است که لباس Consult پوشیده. تایید فقط زمانی ارزش داره که اطلاعات و آگاهی (Context) کافی برای رد یا اصلاح کردنش رو داشته باشی.

به همین خاطر الان تلاش می‌کنم قبل از شروع هر نشست(Session) با دست‌یارهام، سطح تفویض اختیار رو برای هر تصمیمی مشخص کنم، آن هم بر اساس دو فاکتور: تبعات تصمیم (Blast radius) و بازگشت‌پذیری (Reversibility). فرمت‌بندی؟ کاملن قابل تفویض. هر چیزی که به داده‌ها، معماری، یا طراحی کلان مربوط باشه؟ غیرقابل تفویض! خودم باید درگیر باشم.

با توجه به نفوذ روز به روز این دست‌یارها در زندگی و کار، واقعیت اینه که دیگه مطمئن نیستم کی دست‌یار کیه. اولش فکر می‌کردم اون‌ها دستیار من‌اند؛ حالا مونده‌ام که نکنه خودم شدم دستیارِ دستیارم. 😂

من جواب این سوال رو نمی‌دونم راستش. اجازه بدید برم از رییسم بپرسم و بیام! 😂

گزیده:
ندارد

بگذارید یک آزمایش کوتاه انجام بدیم! آیا می‌تونید یک خط از آخرین چیزی که به کمک هوش مصنوعی نوشتید رو به یاد بیارید؟ منظورم از حفظه. من هم نتونستم. گروهی در دانشگاه MIT واقعاً این موضوع رو بررسی کرده‌اند.

آن‌ها ۵۴ نفر از بین دانشجویان و افراد حرفه‌ای رو انتخاب کردند و از آن‌ها خواستند در طی چند جلسه انشاءهای کوتاهی بنویسند. یک گروه از ChatGPT استفاده کرد، یکی از جستجوی گوگل، و گروه دیگه هیچ‌چیزی جز ذهن و حافظه خودشون ابزار دیگه‌ای نداشتند. روی سر همه‌ی افراد در حین نوشتن حسگرهایی قرار داده شده بود که فعالیت مغز آن‌ها را ردیابی می‌کرد.

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

۸۳ درصد از افراد گروه ChatGPT نتونستند حتی یک جمله از انشاء خودشون را، تنها چند دقیقه پس از نوشتن آن به یاد بیارند. برخی هم گفتند احساس می‌کنند تنها نیمی از انشاء متعلق به اون‌هاست. چند نفری هم گفتند احساس می‌کنند داشتند کار شخص دیگه‌ای رو ویرایش می‌کردند. انشاءهایی آن‌ها حتی کم‌کم شبیه به هم شدند. عبارات یکسان، ساختار مشابه و مثال‌های تکراری از افراد مختلف.

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

محققان این پدیده رو «بدهی شناختی» (cognitive debt) نام‌گذاری کردند. به این معنا که ابزار امروز به جای شما فکر می‌کنه، و شما بعداً تاوانش را می‌دید، و اون زمانی هست که مجبورید کارتون رو یادتون بیاد یا کارتون رو توضیح بدید.

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

مرجع:
https://arxiv.org/abs/2506.08872

گزیده:
ندارد

در سال ۱۹۹۵، واتس هامفری (Watts Humphrey)-معروف به پدر کیفیت نرم‌افزار- فرایند توسعه‌ی نرم‌افزاری معرفی کرد که برای توسعه‌دهندگان در سطح فردی طراحی شده بود.

این فرایند در عمل شکست خورد.

«فرایند نرم‌افزار شخصی» (Personal Software Process – PSP) به توسعه‌دهنده اجازه می‌داد فرایندی تعریف‌شده، قابل‌اندازه‌گیری و با امکان بهبود مستمر برای خودش داشته باشد. این فرایند روی کاغذ کار می‌کرد، اما سربار ثبت و مستندسازی‌اش عامل شکست این فرایند شد: ثبت زمان، ثبت خطاها و پر کردن فرم بعد از هر فعالیت. تقریبن هیچ‌کس نمی‌توانست این کارها را برای طولانی‌مدت انجام بدهد. هامفری بعدها به سراغ فرایندهای در سطح تیم (Team Processes) رفت. و ناگفته خود پیداست «تیم» کوچک‌ترین واحد طراحی فرایند در سی سال گذشته بوده است.

به باور من این موضوع در حال تغییر و تحول است.

نگاهی کنید به آن‌چه یک دستیار کدنویسی هوش مصنوعی (AI Coding Assistant) واقعن در اختیار شما می‌گذارد:

→ مهارت‌ها (Skills): توانایی‌های ازپیش‌تعریف‌شده و قابل استفاده‌ی مجدد برای انجام کارهای مشخص در چرخه‌ی حیات توسعه‌ی نرم‌افزار (Software Development Life Cycle – SDLC)، مانند تحلیل، طراحی، آزمون و بازبینی
→ زیرعامل‌ها (Subagents): عامل‌های تخصصی که هرکدام مسئول انجام وظیفه‌ای مشخص‌اند
→ هوک‌ها (Hooks): اقداماتی که در نقاط مشخصی از فرایند به‌صورت خودکار اجرا می‌شوند
→ فایل‌های حافظه (Memory Files): فایل‌هایی برای نگهداری قواعد، دستورالعمل‌ها و اطلاعاتی که عامل باید در طول کار به خاطر داشته باشد

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

این نگاه، تکرار داستان «ساخت ارتشی از عامل‌ها» (Army of Agents) که این روزها همه‌گیر شده نیست. عامل‌ها هیچ‌وقت موضوع اصلی این داستان نبوده‌اند. اصل ماجرا این است که این روزها ماشین (یا همان هوش مصنوعی)‌ می‌تواند همان سرباری که PSP را از پا درآورد یک تنه به دوش بکشد: ثبت پیوسته، اندازه‌گیری و اعمال قواعد.

هامفری درست می‌گفت؛ فقط سی سال زود گفته بود!

من اسم این ایده را «فرایند تک نفره» (Process of One) گذاشته‌ام و این روزها سخت مشغول فکر کردن و ساختن آن هستم.

سرگرم طراحی و راه‌اندازی فرایندی هستم برای خودم و زندگی‌ام: فعالیت‌ها، نقش‌ها، دروازه‌های کیفیت (Quality Gates) و بازنگری‌ها (Retrospectives). همه‌ی کارهایی که زمانی برای تیم‌ها انجام می‌دادم، حالا برای تیم یک‌نفره‌ی خودم انجام می‌دهم. با این تفاوت که این بار، ماشین (دست‌یار هوش مصنوعی) کارهای ثبت و پیگیری‌ای را انجام می‌دهد؛ همان کارهایی که فرایند هامفری را از پا درآورد ولی این‌بار نمی‌تواند فرایند من را به چالش بکشد.

این اصل مهندسی هوش مصنوعی (AI Engineering) را هم برای این کار می‌توان استفاده کرد: چیزی را که اندازه‌ نمی‌گیرید، درباره‌اش فقط می‌توانید حدس بزنید (if you don’t measure it, you’re guessing). پس برای ارزیابی کارایی فرایند شخصی‌ام مدام می‌پرسم : آیا واقعن داره کار می‌کنه؟

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

شما فرایند خودتان را چگونه طراحی می‌کنید؟

پانوشت:
ساخت یک کاتالوگ از این الگوها (Patterns) رو شروع کردم؛ تا امروز ۱۹ الگو با کمک ای‌آی بررسی و مدون شده‌. همه‌ی الگوها با یک ساختار یکسان نوشته شده‌: موقعیت (Situation)، مساله (Problem)، راهکار (Solution) و منبع (Source). می‌‌تونید اونها رو در این آدرس در گیت‌هاب پیدا کنید: لینک

گزیده:
بیرون ز تو نیست هرچه در عالم هست
در خود بطلب هر آنچه خواهی که توئی
مولانا

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

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

«مَت پوکاک» (Matt Pocock) این وضعیت رو منطقه هوشمند (Smart Zone) و منطقه کندذهن (Dumb Zone) می‌نامد. مدل در ابتدای یک نشست (Session) بسیار سریع و دقیقه، اما کیفیت‌ کارکردش قبل از اینکه ظرفیت گفتگوی شما با اون (چت) واقعاً «پُر» بشه، افت می‌کنه. و بخش غافلگیرکننده داستان اینجاست: «حافظه‌ی کاری» (Working Memory) یا «پنجره‌های کاری» (Context Windows) بزرگی که همه درباره‌اش صحبت می‌کنند، در عمل، فضای هوشمند بیشتری در اختیارتون نمی‌ذارند؛ فقط منطقه کندذهن بزرگ‌تری در اختیارتان می‌گذارند.
[حافظه‌ی کاری یا پنجره‌ی کاری، حداکثر متنی است که یک مدل زبانی می‌تونه در هر زمان ببینه یا به خاطر بسپاره]

شرح فنی: طول پنجره‌ی کاری مؤثر یک مدل زبانی، بسیار کوتاه‌تر از پنجره تبلیغ‌شده‌ی اونه. دلیل‌ش اینه که با طولانی شدن گفتگوی شما با مدل زبانی، تمرکز مدل بین توکن‌های (کلمات) بیشتری پخش و در نتیجه تمرکز اون ضعیف‌تر و کم‌رنگ‌تر می‌شه، جزئیاتِ بخش میانی متن نادیده گرفته می‌شه (پدیده «گم شدن بخش میانی متن» یا Lost in the Middle) و مدل مدام بر اساس اشتباهات قبلی خود که هنوز در تاریخچه چت باقی مونده‌اند، به کارش ادامه می‌ده.

بنابراین، راه‌حل این مشکل نوشتن یک پرامپت (Prompt) بهتر نیست؛ بلکه داشتن یک حافظه کوتاه‌تره: یک کار رو انجام بدید، گفتگوی اون کار رو پیش ببرید و بعد که تموم شد، همه‌ چی رو پاک کنید و روز از نو و روزی از نو.

برای کارهای بزرگ‌تر، حافظه را به خارج از گفتگو منتقل کنید: هدف نهایی کارتون رو توی یک فایل مشخصات (Specification) بنویسید، مسیر رسیدن به هدف رو به کارهای کوچک و مستقل از هم تقسیم کنید و به هر کار یک حافظه/پنجره (Context) تر و تمیز و نو اختصاص بدهید. هدف این نیست که هر چیزی که هوش مصنوعی احتمالاً می‌تونه بدونه بهش بدهید؛ هدف اینه که دقیقن همون چیزی رو که برای کار پیشِ رو نیاز داره، در اختیارش بگذارید.

پس یادتون نره: دستیار شما هیچ‌وقت خسته نمی‌شه، فقط پُر می‌شه.

ویدیو و کارگاه فوق‌العاده‌ی مَت پوکاک با عنوان “Full Walkthrough: Workflow for AI Coding” را توصیه می‌کنم که ببینید. من از این کارگاه چیزهای زیادی یاد گرفتم.

منبع: کارگاه مَت پوکاک با عنوان Full Walkthrough: Workflow for AI Coding.: [لینک]

یک نکته کاربردی از این کارگاه: یک شمارنده توکن (Token Counter) رو در محیط کارتون و جلوی چشم داشته باشید. به محض تمام شدن یک کار، گفتگوی خودتون با دست‌یار هوش‌ مصنوعی‌تون رو پاک کنید. یک نشست (Session) جدید، همیشه از یک پرامپت هوشمندانه بهتر عمل می‌کنه.

گزیده:
هر نفس نو می‌شود دنیا و ما
بی‌خبر از نو شدن اندر بقا
مولانا