وقتی Agentها باهوش‌تر می‌شند
 روش کار ما چطور باید تغییر کنه؟

وقتی با ابزارهایی مثل Claude Code یا Codex کار می‌کنیم، معمولاً سعی می‌کنیم با نوشتن Promptهای دقیق‌تر، دادن Context بیشتر و مشخص کردن تمام مراحل اجرا، خروجی بهتری بگیریم. این روش‌ها در بسیاری از موقعیت‌ها مفیدن، اما آیا هنوز بهترین راه برای کار با نسل جدید Agentهای هوش مصنوعی هستن؟بوریس چرنی (Boris Cherny)، مهندس و از چهره‌های اصلی توسعه Claude Code، اخیراً پنج توصیه درباره نحوه استفاده از این ابزار مطرح کرده که بعضی از اون‌ها با روش‌های رایج کار با هوش مصنوعی تفاوت دارن.طبق مطلب منتشرشده در صفحه رسمی Claude، چرنی روزانه صدها Agent رو اجرا می‌کنه و ماه‌هاست که پاسخ‌گویی دستی به بازخوردهای Code Review رو کنار گذاشته.نکته جالب توصیه‌های اون اینه که بیشتر از نوشتن Promptهای بهتر، روی تغییر نحوه همکاری با Agentها تمرکز دارن.از حذف بعضی مراحل برنامه‌ریزی گرفته تا مستندسازی اشتباهات و استفاده از Loopهای خودکار، این توصیه‌ها نشون می‌دن که با قدرتمندتر شدن مدل‌ها، ممکنه لازم باشه بخشی از عادت‌های قبلی خودمون رو هم تغییر بدیم.

۱. آیا هنوز برای هر Task به Planning نیاز داریم؟

یکی از روش‌های رایج کار با Agentهای برنامه‌نویسی اینه که قبل از شروع هر Task، از مدل بخوایم یک برنامه مرحله‌به‌مرحله تهیه کنه.مثلاً وقتی قصد داریم یک Component جدید پیاده‌سازی کنیم، ابتدا از Agent می‌خوایم ساختار پروژه رو بررسی کنه، وابستگی‌ها رو شناسایی کنه، مراحل پیاده‌سازی رو بنویسه و بعد از تأیید ما وارد مرحله اجرا بشه.این روش به‌خصوص زمانی که مدل‌ها توانایی محدودتری در مدیریت Taskهای پیچیده داشتن، کمک می‌کرد احتمال خطا کاهش پیدا کنه.اما چرنی معتقده مدل‌های جدیدتر در بسیاری از موقعیت‌ها دیگه به یک مرحله Planning جداگانه نیاز ندارن.

چرا این توصیه مهمه؟

فرض کنین می‌خوایم یک Button رو مطابق مستندات Design System به‌روزرسانی کنیم. اگر محدوده تغییر مشخص باشه و Agent به کد پروژه و مستندات دسترسی داشته باشه، شاید نیازی نباشه قبل از شروع، یک برنامه طولانی تولید کنه.در چنین شرایطی، می‌تونیم مستقیماً هدف رو مشخص کنیم و از Agent بخوایم تغییر رو اعمال و نتیجه رو بررسی کنه.اما این به معنی حذف کامل Planning نیست.برای Taskهایی مثل تغییر معماری یک پروژه، مهاجرت بین نسخه‌های مختلف یک Design System یا بازنویسی بخش‌هایی که چندین وابستگی دارن، برنامه‌ریزی همچنان می‌تونه ضروری باشه.

نکته اصلی اینه که Planning نباید صرفاً یک مرحله اجباری در تمام Taskها باشه؛ باید متناسب با پیچیدگی، ریسک و میزان ابهام مسئله ازش استفاده کنیم.

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

۲. اشتباهات Agent رو به بخشی از دانش پروژه تبدیل کنیم

یکی از جالب‌ترین توصیه‌های چرنی اینه که وقتی Claude اشتباهی انجام می‌ده، ازش بخوایم اون اشتباه رو در فایل CLAUDE.md مستند کنه یا براساسش یک Skill بسازه.در نگاه اول، این کار ممکنه شبیه ثبت یک نکته ساده به نظر برسه، اما پشتش یک مسئله مهم وجود داره.وقتی با Agentها کار می‌کنیم، معمولاً بخشی از زمانمون صرف اصلاح اشتباهات تکراری می‌شه.برای مثال، فرض کنین در یک پروژه از Design System مشخصی استفاده می‌کنیم. Agent یک فرم طراحی می‌کنه، اما به‌جای استفاده از Tokenهای موجود، مقدارهای دلخواه برای رنگ و فاصله‌گذاری تعریف می‌کنه.ما خروجی رو بررسی می‌کنیم و بهش می‌گیم که باید از Tokenهای سیستم استفاده کنه.Agent اشتباهش رو اصلاح می‌کنه و Task تموم می‌شه.اما چند روز بعد، هنگام پیاده‌سازی یک صفحه دیگه، ممکنه دوباره با همون مشکل مواجه بشیم.

چطور جلوی تکرار این اتفاق رو بگیریم؟

به‌جای اینکه هر بار دستور مشابهی بدیم، می‌تونیم قواعد مهم پروژه رو در فایل‌های راهنما یا Skillهای اختصاصی ثبت کنیم.برای مثال، می‌تونیم مشخص کنیم که در پیاده‌سازی Componentها باید از Tokenهای تعریف‌شده استفاده بشه، Componentهای موجود در اولویت باشن و قبل از ساخت Component جدید، Library بررسی بشه.با این کار، دانشی که از یک اشتباه به دست آوردیم، به بخشی از Context قابل‌استفاده در Taskهای بعدی تبدیل می‌شه.البته اینجا یک نکته مهم وجود داره: قرار نیست هر اشتباه Agent به یک قانون دائمی تبدیل بشه.بعضی خطاها فقط به شرایط یک Task خاص مربوط می‌شن. اگر تمام اصلاحات رو بدون بررسی وارد دستورالعمل‌های پروژه کنیم، به‌مرور با مجموعه‌ای از قواعد طولانی، تکراری و حتی متناقض مواجه می‌شیم.بنابراین بهتره اشتباهات تکرارشونده رو شناسایی کنیم، علت اون‌ها رو بررسی کنیم و فقط قواعدی رو ثبت کنیم که واقعاً برای کارهای آینده ارزش دارن.این رویکرد کمک می‌کنه تجربه کار با Agent از مجموعه‌ای از گفت‌وگوهای جداگانه، به یک فرایند قابل‌بهبود تبدیل بشه.

۳. به‌جای گفت‌وگوهای مداوم، از Loop و Routine استفاده کنیم

در روش معمول کار با ابزارهای هوش مصنوعی، ما یک Prompt می‌نویسیم، خروجی رو دریافت می‌کنیم، بررسیش می‌کنیم و بعد دستور بعدی رو می‌دیم.این چرخه ممکنه برای یک Task ساده مناسب باشه، اما وقتی تعداد کارها زیاد می‌شه، بخش قابل‌توجهی از زمان صرف مدیریت همین رفت‌وبرگشت‌ها خواهد شد.چرنی پیشنهاد می‌کنه به‌جای اینکه همیشه مستقیماً با Agent گفت‌وگو کنیم، از Loopها و Routineهایی استفاده کنیم که فرایند انجام کار رو مدیریت می‌کنن.او در توضیح روش خودش می‌گه که به‌جای صحبت مستقیم با Agent، با Loop یا Routine کار می‌کنه و اون فرایند، Claude رو هدایت می‌کنه.

تفاوت این دو روش چیه؟

فرض کنین می‌خوایم یک Component جدید رو در پروژه پیاده‌سازی کنیم.در روش معمول، ابتدا از Agent می‌خوایم Component رو بسازه. بعد خودمون تست‌ها رو اجرا می‌کنیم، خطاها رو پیدا می‌کنیم و دوباره از Agent می‌خوایم مشکلات رو اصلاح کنه.این فرایند ممکنه چندین بار تکرار بشه.اما می‌تونیم یک Workflow تعریف کنیم که Agent بعد از پیاده‌سازی، خودش تست‌ها رو اجرا کنه، خطاهای مشخص رو بررسی کنه و در محدوده‌ای تعیین‌شده برای اصلاح اون‌ها تلاش کنه.برای مثال، Workflow می‌تونه شامل این مراحل باشه:۱. بررسی مستندات و Componentهای موجود در پروژه.۲. پیاده‌سازی تغییر موردنظر.۳. اجرای تست‌ها و بررسی خطاهای TypeScript و Lint.۴. اصلاح مشکلات شناسایی‌شده.۵. اجرای مجدد تست‌ها و ارائه گزارش نهایی.در این روش، لازم نیست برای هر مرحله یک Prompt جدید بنویسیم.اما نکته مهم اینه که Loop باید معیار موفقیت و شرایط توقف مشخصی داشته باشه.اگر Agent نتونه بعد از چند تلاش مشکل رو حل کنه، نباید بدون محدودیت به اجرای دوباره ادامه بده. بهتره متوقف بشه، مشکل رو گزارش بده و در صورت نیاز از انسان کمک بخواد.این تفاوت مهمیه، چون هدف از خودکارسازی، حذف نظارت انسانی نیست؛ بلکه کاهش مداخله‌های تکراری و غیرضروریه.برای تیم‌های طراحی و توسعه، چنین رویکردی می‌تونه در کارهایی مثل بررسی Componentها، اجرای تست‌های Accessibility، کنترل هماهنگی با Design System و شناسایی مشکلات کد کاربرد داشته باشه.البته خودکارسازی هرکدوم از این فعالیت‌ها به ابزارهای در دسترس، کیفیت تست‌ها و محدودیت‌های پروژه بستگی داره.

۴. Context بیشتر همیشه به معنی خروجی بهتر نیست

یکی از توصیه‌های غیرمنتظره چرنی اینه که تا جای ممکن System Prompt، ابزارها و Context اولیه رو محدود نگه داریم و اجازه بدیم مدل خودش اطلاعات موردنیاز رو پیدا کنه.این توصیه در نگاه اول ممکنه با چیزی که درباره Prompt Engineering یاد گرفتیم متفاوت باشه.معمولاً توصیه می‌شه برای گرفتن خروجی بهتر، اطلاعات بیشتری درباره پروژه، محدودیت‌ها، اهداف و نیازمندی‌ها در اختیار مدل قرار بدیم.اما مسئله فقط حجم اطلاعات نیست؛ ارتباط اطلاعات با Task و زمان دسترسی به اون‌ها هم اهمیت داره.فرض کنین از Agent می‌خوایم یک فرم ورود فارسی طراحی کنه.می‌تونیم تمام مستندات Design System، مشخصات Componentها، Tokenها، Patternها و قواعد طراحی رو داخل Prompt قرار بدیم.اما آیا Agent برای ساخت یک فرم ورود واقعاً به تمام این اطلاعات نیاز داره؟احتمالاً نه.ممکنه فقط به مستندات Input، Button، Form Validation، Typography و قواعد RTL نیاز داشته باشه.اگر Agent به ابزار مناسبی برای جست‌وجو و دریافت اطلاعات دسترسی داشته باشه، می‌تونه هنگام انجام Task سراغ بخش‌های مرتبط بره.

این موضوع چه ارتباطی با MCP داره؟

یکی از کاربردهای MCP اینه که Agent بتونه به منابع اطلاعاتی و ابزارهای بیرونی متصل بشه.برای مثال، با استفاده از MCP دیگ، Agentهای سازگار می‌تونن به اطلاعات Componentها، Tokenها و Patternهای Design System دیگ دسترسی پیدا کنن.در چنین شرایطی، به‌جای اینکه تمام مستندات رو در ابتدای گفت‌وگو وارد کنیم، می‌تونیم امکان دسترسی به اطلاعات مرتبط رو فراهم کنیم.البته این روش هم محدودیت‌های خودش رو داره.اگر Agent نتونه اطلاعات درست رو پیدا کنه یا منابع در دسترسش ناقص باشن، ممکنه نتیجه مناسبی تولید نکنه.بنابراین نباید توصیه چرنی رو به معنی حذف Context ضروری در نظر بگیریم.

هدف اینه که به‌جای انباشتن اطلاعات در Prompt، شرایطی فراهم کنیم که Agent به اطلاعات درست، در زمان مناسب دسترسی داشته باشه.

این تفاوت می‌تونه روی نحوه طراحی ابزارها، مستندات و حتی ساختار Design Systemهایی که قراره توسط Agentها استفاده بشن، تأثیر بذاره.

۵. آماده باشیم روش‌هایی رو که قبلاً جواب می‌دادن، کنار بذاریم

آخرین توصیه چرنی شاید ساده به نظر برسه، اما یکی از مهم‌ترین نکات کار با ابزارهای هوش مصنوعیه.او اشاره می‌کنه که بارها متوجه شده بعضی از فرضیاتش اشتباه بودن و مجبور شده روش‌هایی رو که طی سال‌ها یاد گرفته، کنار بذاره.این موضوع فقط درباره Claude Code نیست.ابزارهای هوش مصنوعی با سرعت زیادی تغییر می‌کنن و روش‌هایی که برای یک نسل از مدل‌ها مناسب بودن، لزوماً برای نسل بعدی بهترین انتخاب نیستن.برای مثال، ممکنه قبلاً برای پیاده‌سازی یک قابلیت مجبور بودیم Task رو به چندین مرحله کوچک تقسیم کنیم و برای هر مرحله دستور دقیقی بنویسیم.اما مدل‌های جدیدتر ممکنه بتونن بخش بیشتری از همون کار رو با استقلال بالاتر انجام بدن.از طرف دیگه، بعضی روش‌های جدید هم ممکنه در عمل نتیجه مناسبی نداشته باشن.برای همین بهتره به‌جای اینکه یک Workflow رو به‌عنوان بهترین روش همیشگی در نظر بگیریم، عملکردش رو مرتب ارزیابی کنیم.آیا مرحله Planning واقعاً کیفیت خروجی رو بهتر کرده؟ آیا اضافه کردن Context بیشتر باعث کاهش خطا شده؟ آیا Loopهای خودکار زمان انجام Task رو کم کردن یا فقط تعداد دفعات اجرای ناموفق رو افزایش دادن؟پاسخ این سؤال‌ها رو باید با بررسی نتیجه واقعی کار پیدا کنیم، نه صرفاً براساس توصیه‌های رایج.یکی از مهارت‌های مهم در کار با Agentها، فقط یاد گرفتن روش‌های جدید نیست؛ تشخیص زمان کنار گذاشتن روش‌های قدیمیه.

آیا داریم از Prompt Engineering به Workflow Engineering حرکت می‌کنیم؟

اگر این پنج توصیه رو کنار هم بذاریم، یک تغییر مهم در نحوه استفاده از Agentها دیده می‌شه.در روش‌های اولیه کار با هوش مصنوعی، بخش زیادی از تمرکز روی نوشتن Promptهای دقیق‌تر بود. تلاش می‌کردیم تمام اطلاعات، مراحل و محدودیت‌ها رو در یک درخواست مشخص کنیم تا مدل خروجی بهتری تولید کنه.اما با قدرتمندتر شدن Agentها، بخش بیشتری از کیفیت خروجی به محیطی بستگی پیدا می‌کنه که برای کار کردن اون‌ها فراهم می‌کنیم.این محیط می‌تونه شامل دستورالعمل‌های پروژه، ابزارهای قابل‌دسترسی، مستندات ساختاریافته، تست‌های خودکار و Workflowهایی باشه که شرایط اجرا و توقف رو مشخص می‌کنن.برای مثال، فرض کنین دو تیم می‌خوان با استفاده از هوش مصنوعی یک صفحه جدید پیاده‌سازی کنن.تیم اول یک Prompt طولانی می‌نویسه و تمام جزئیات طراحی، Componentها و محدودیت‌ها رو توضیح می‌ده.تیم دوم علاوه بر تعریف هدف، به Agent دسترسی کنترل‌شده به مستندات Design System می‌ده، قواعد مهم پروژه رو در فایل‌های راهنما ثبت می‌کنه و تست‌هایی برای بررسی خروجی در نظر می‌گیره.در تیم دوم، بخشی از دانش و کنترل کیفیت به‌جای اینکه فقط داخل Prompt قرار بگیره، در ساختار Workflow تعریف شده.این به معنی بهتر بودن قطعی روش دوم در تمام شرایط نیست، اما می‌تونه اجرای Taskهای مشابه رو قابل‌تکرارتر کنه و وابستگی به دستورهای دستی رو کاهش بده.برای تیم‌هایی که روی Design System کار می‌کنن، این تغییر اهمیت بیشتری هم داره.چون اگر قرار باشه Agentها در فرایند طراحی و توسعه نقش فعال‌تری داشته باشن، فقط داشتن Component Library و Documentation کافی نیست.باید بررسی کنیم که آیا Agent می‌تونه Component مناسب رو پیدا کنه، قواعد استفاده از اون رو بفهمه، محدودیت‌ها رو رعایت کنه و خروجی خودش رو با معیارهای مشخص ارزیابی کنه یا نه.در چنین شرایطی، Design System فقط منبعی برای استفاده طراح‌ها و توسعه‌دهنده‌ها نیست؛ می‌تونه به یکی از منابع Context و قواعد مشترک برای Agentها هم تبدیل بشه.

جمع‌بندی

پنج توصیه بوریس چرنی درباره Claude Code یک پیام مشترک دارن: برای استفاده بهتر از Agentهای جدید، شاید لازم باشه بیشتر از اینکه Promptهامون رو تغییر بدیم، روش کارمون رو بازطراحی کنیم.این تغییر می‌تونه از تصمیم‌های کوچیکی مثل حذف Planning غیرضروری شروع بشه و به ساخت Workflowهای خودکار، مستندسازی اشتباهات و فراهم کردن دسترسی به اطلاعات مرتبط برسه.البته هیچ‌کدوم از این روش‌ها نسخه یکسانی برای تمام پروژه‌ها نیستن. میزان استقلال Agent، نوع Context، نیاز به برنامه‌ریزی و سطح نظارت انسانی باید متناسب با پیچیدگی و حساسیت هر Task تعیین بشه.اما یک نکته مشخصه: وقتی Agentها توانایی بیشتری برای انجام کارهای چندمرحله‌ای پیدا می‌کنن، نقش ما هم از مدیریت تک‌تک دستورها به سمت تعریف هدف، طراحی محدودیت‌ها و ارزیابی نتیجه حرکت می‌کنه.شاید سؤال مهم بعدی این نباشه که چطور Prompt بهتری بنویسیم؛ بلکه این باشه:چطور محیط و فرایندی طراحی کنیم که Agent بتونه با مداخله کمتر، خروجی قابل‌اعتمادتری تولید کنه؟