کدام ابزار برای کدام کار

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

نشانه‌ها: خروجی‌اش یک متن است که خودت جایی می‌گذاری‌اش · هر بار ورودی‌اش فرق دارد · و تو در حین کار داری تصمیم می‌گیری.

مثال‌ها: یک ایمیل سخت را پیش‌نویس کن · این متن را نقد کن · این موضوع را برایم ساده کن · سه ایراد این تصمیم را بگو.

خطای رایج اینجا این است که آدم‌ها chat را دستِ کم می‌گیرند. خیلی از کارهایی که فکر می‌کنی ایجنت می‌خواهند، با یک گفت‌وگوی خوب حل می‌شوند — و این خانواده‌ی اول درس ۰.۵ است که همان‌جا هم گفتیم اکثر آدم‌ها باید از آن شروع کنند. کل فصل بعدی (۲.۳) درباره‌ی همین است.

وقتی کار روی فایل‌های تو انجام می‌شود و چند قدم دارد که قدم بعدی‌اش به نتیجه‌ی قدم قبلی بستگی دارد.

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

کار فصل ۰.۱۰ دقیقاً نمونه‌اش بود: هشت فایلِ نامعلوم، و ایجنت باید اول می‌دید داخلشان چیست تا بفهمد چه بنویسد. همان حلقه‌ی فصل ۱.۲.

و اگر ترتیب کارها از قبل معلوم است، احتمالاً ایجنت لازم نداری. این جمله را نگه دار؛ در بخش ۲.۲.۴ به آن برمی‌گردیم.

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

این ابزارها برای این ساخته شده‌اند: «هر وقت در سرویس A این اتفاق افتاد، در سرویس B این کار را بکن.» مثلاً: هر وقت فرمی پر شد، یک ردیف به گوگل‌شیت اضافه کن و یک پیام در تلگرام بفرست.

ویژگی‌هایشان:

• با کشیدن و رها کردن ساخته می‌شوند، بدون کد.
• به ده‌ها سرویس آماده وصل‌اند.
• قابل‌اعتماد و تکرارپذیرند — هر بار دقیقاً همان کار.
• و خودشان اجرا می‌شوند؛ لازم نیست کامپیوترت روشن باشد.

آن آخری تفاوت بزرگی است که در درس ۸.۶ کاملاً باز می‌شود.

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

فرض کن می‌خواهی «هر وقت ایمیلی با فاکتور آمد، اطلاعاتش را در یک شیت بنویس». وسوسه‌ی طبیعی این است که به ایجنت بگویی این کار را بکند. سه دلیل که نباید:

• غیرقابل‌پیش‌بینی است. در فصل ۱.۱ دیدیم یک درخواست دو بار دو جواب می‌دهد. برای کاری که هزار بار باید دقیقاً یک‌جور انجام شود، این عیب است نه مزیت.
• گران است. هر اجرا token مصرف می‌کند (فصل ۱.۳). ابزار اتصال، این کار را با هزینه‌ی تقریباً صفر انجام می‌دهد.
• ترتیب کار از قبل معلوم است. و وقتی ترتیب معلوم است، تصمیم‌گیرنده لازم نداری — مجری لازم داری.

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

و ترکیبشان هم ممکن است: ابزار اتصال کار را راه بیندازد، و فقط آن قسمتی که واقعاً فهمیدن لازم دارد به ایجنت سپرده شود.

قبل از هر ساختنی، یک سؤال ساده: کسی این را قبلاً نساخته؟

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

• خیلی از کارهای «مرتب‌کردن ایمیل» با قاعده‌های خودِ ایمیل انجام می‌شوند — همان چیزی که در فصل ۰.۱ دیدیم.
• خیلی از کارهای «خلاصه‌ی جدول» با یک pivot در همان اکسل.
• خیلی از کارهای «یادآوری» با یک زمان‌بند ساده.

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

در فصل ۲.۱ دیدیم کدام کارها ارزش ساختن ندارند. اینجا یک لایه‌ی دیگر: حتی کارِ ارزشمند هم گاهی نباید الان ساخته شود.

• وقتی خودت هنوز کار را خوب نمی‌شناسی. اول چند بار با chat یا دستی انجامش بده. اتوماسیونِ کاری که نمی‌شناسی، خطا را سریع‌تر تکرار می‌کند — همان چیزی که در درس ۰.۵ هم گفتیم.
• وقتی قرار است فرایند به‌زودی عوض شود.
• وقتی کسی هست که کارش همین است.
• وقتی داری برای فرار از یک تصمیمِ سخت، چیزی می‌سازی. اگر مشکل واقعی این است که فرایند خودش غلط است، خودکارکردنش فقط سریع‌ترش می‌کند.

مورد آخر ظریف‌ترین است: اتوماسیونِ یک فرایند بد، یک فرایند بدِ سریع می‌سازد.

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

قاعده‌ی عملی برای این دوره:

• مدل قوی‌تر برای طراحی، تحلیل، و هر کاری که اشتباهش گران است یا فهمیدن می‌خواهد.
• مدل سبک‌تر برای کارِ پرتکرارِ ساده: دسته‌بندی، تبدیل قالب، خلاصه‌ی کوتاه.

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