مسیر ادامه

این حوزه سریع عوض می‌شود، و دنبال‌کردنِ همه‌چیز هم غیرممکن است و هم لازم نیست. تلاش برای به‌روز ماندن در همه‌چیز، معمولاً به خواندنِ زیاد و ساختنِ هیچ ختم می‌شود.

یک قاعده‌ی ساده کافی است:

به‌خاطر بسپار ماهی یک بار، سه منبع — نه روزی ده تا. و مهم‌تر از خواندن، این سؤال است: «آیا این چیزی را که من می‌سازم عوض می‌کند؟» اگر نه، رد کن. بیشترِ خبرهای این حوزه، برای تو خبر نیستند.

و سه منبعی که واقعاً ارزش ماهی یک بار را دارند، هر کدام یک محصولِ متفاوت:

• تغییرات پلتفرم و مدل‌ها — release notes پلتفرم. اینجا می‌فهمی مدل تازه‌ای آمده، قیمتی عوض شده، یا چیزی از کار افتاده.
• تغییرات خودِ ابزار خط فرمان — CHANGELOG کلاد کد. اگر روزانه با ترمینال کار می‌کنی، این مربوط‌ترین منبع به کارِ توست.
• و مقاله‌های مهندسی — anthropic.com/engineering. کم‌تعداد ولی عمیق؛ چند فصلِ همین دوره از همین‌جا آمده‌اند. این یکی طرزِ فکر را به‌روز می‌کند، نه فهرست امکانات را.

و اگر برنامه‌های موبایل و وب را هم استفاده می‌کنی، release notes برنامه‌ها منبع چهارم است. بیشتر از این‌ها لازم نیست.

و یک چیزی که مهم‌تر از دنبال‌کردن اخبار است: وقتی چیزی در کارت گیر کرد، همان لحظه یاد بگیر. یادگیریِ در لحظه‌ی نیاز، ده برابرِ یادگیریِ پیش‌دستانه می‌ماند — همان چیزی که فصل ۷.۱ درباره‌ی واژه‌ها گفت.

سؤالی که دیر یا زود می‌رسد: «این چیزی که ساختم، می‌شود به بقیه هم داد؟»

جواب ممکن است بله باشد — ولی بدان که فاصله‌اش زیاد است، و صادقانه‌اش این است:

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

پله‌های بین این دو، به ترتیب — و هر پله را جدا بردار:

1. یک همکار هم استفاده کند (تمرین فصل ۸.۸.۲). اینجا می‌فهمی چقدر از کارت به دانشِ نانوشته‌ی تو وابسته بوده.
2. چند نفر در سازمان. اینجا مسئله‌ی مالکیت جدی می‌شود (فصل ۸.۸.۴) و باید کسی جز تو هم بتواند خاموشش کند.
3. و بعد، بیرون از سازمان. اینجا دیگر بحث فنی نیست: پشتیبانی، مسئولیت، داده‌ی دیگران، و قواعد حقوقی.

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

به ترتیبی که واقعاً جواب می‌دهد — و اولی را اکثر آدم‌ها رد می‌کنند:

1. از خودِ ایجنت (فصل ۲.۸.۳). خطا را بده و فارسی بخواه (فصل ۴.۳.۲). برای بیشترِ گیرها همین کافی است، و سریع‌ترین است.
2. مستندات رسمی. اگر سؤالت «این ابزار چطور کار می‌کند» است، جوابش آن‌جاست — و برخلاف تصور، خواندنش با کمکِ ایجنت سخت نیست (فصل ۴.۳.۴).
3. جست‌وجو با پیام خطای دقیق. کلِ متن خطا را در گیومه بگذار، نه توصیفِ خودت از مشکل.
4. و آدم‌ها. یک همکار، یک گروه، یا کسی که در فصل ۹.۳.۴ به او یاد داده‌ای.

و یک قاعده که وقت زیادی نجات می‌دهد: اگر بیست دقیقه روی یک گیر ماندی و پیشرفتی نکردی، روش را عوض کن — نه اینکه بیشتر تلاش کنی. session تازه، یا سؤالِ متفاوت، یا راهِ کاملاً دیگر (فصل ۲.۸.۵).

و آخرین چیز. کلِ این دوره — ده ماژول و شصت‌وشش فصل — در یک تصویر:

سه چیز که این تصویر می‌گوید و ارزش آخرین دقت را دارند:

• این یک حلقه است، نه یک خط. پروژه‌ی پایانی پایان نیست؛ یک دورِ کامل است. مهارت وقتی ساخته می‌شود که دورِ دوم را بزنی (فصل ۹.۳.۱).
• راستی‌آزمایی داخل حلقه است، نه بعد از آن. تنها مرحله‌ای که می‌شود حذفش کرد و کار همچنان «تمام‌شده» به نظر برسد — و به همین دلیل تنها مرحله‌ای است که باید عمداً نگهش داری.
• و سه پایه، مرحله نیستند. هیچ‌وقت «حالا نوبتِ محافظت است» نمی‌رسد؛ در هر مرحله برقرارند.

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

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